Table of Contents
The primary deliverables for the M.A.R.S.U.P.I.A.L. are the tracked drive train and the wireless mesh node modules and deployment system. Mush of the rest of the design will be borrowed from the current Badger platform in an effort to maintain as much compatability with existing systems as possible.
Concept Development (generation, improvement, selection)
One complaint with the current Badger setup is the extremely short radio control range. Because of this, Badger is limited to line-of-sight operation, which severely limits its usefulness.
In order to extend the usable range of wireless operation, a mesh networking setup was proposed. This would allow the system to operate beyond the range of a single radio link.
Alternative rejected proposals:
Stronger radios - these would increase the cost disproportionately, and risks running afoul of FCC regulations or incurring extra licencing requirements.
Wired / Fiber link - easy to tangle, difficult to manage.
The desired functionality of the mesh system is as such:
- Signal strength of radio link is determined to be sufficiently weak.
- A new node is powered up and joined into the network.
- The node is dropped and double-checked for functionality.
- The robot continues on, using the built mesh network to relay link data and commands to the base station indirectly.
Each mesh node must be able to [re]join the mesh network automatically. The mesh must be able to deal with nodes entering and dropping without warning, and must make a best-effort attempt to route all packets. The mesh must be able to transport TCP & UDP packets in a topology-transparent manner. The nodes must be self-contained and able to sustain communications for as long as the robot can operate. The nodes must be deployed from the robot, and kept charged while in storage.
In testing several small radios, WiFi was determined to be the best option. When combined with the B.A.T.M.A.N. mesh protocol, it creates a mesh system that fills all the above-listed needs (TCP/UDP, self-healing, automatic joining). To operate WiFi & B.A.T.M.A.N., a Linux system is needed. Arch Linux on an Olimex OLinuXino Nano was chosen for the hardware's small size and the Linux distro's compact, streamlined design. No battery pack was found that met the size requirements, so a custom one was designed to fit.
Data transfer through several nodes was tested. With a direct link, transfer speeds averaged at 1.3MB/s. In transferring through two different nodes, an average of 100-300kB/s.
Antenna choices are still being evaluated, as they will have a large impact on wireless range.
As with any complex system, there are a myriad of risks to be taken into consideration. The most high-priority risks are listed below:
The system may encounter radio interference. Likelihood: 5. Impact: 4. Mitigation: Deploy nodes early and often to create reundant paths.
The nodes may be knocked offline (hardware failure). Likelihood: 2. Impact: 4. Mitigation: Deploy redundant nodes.
Node battery may die. Likelihood: 2. Impact: 4. Mitigation: Monitor battery level in all nodes and report pre-fail conditions to operator.
Nodes may be maliciously tampered with / deactivated / stolen. Likelihood: 1. Impact: 5. Mitigation: Accept risk. Most use scenarios for the robot do not involve the prospect of active sabotage.
Mesh network may not provide enough bandwidth for video streaming. Likelihood: 2. Impact: 3. Mitigation: Provide redundant nodes. Apply quality of service to prioritize control signals during low-bandwidth intervals. Reduce quality of stream to prioritize real-time over resolution.