Allegrobotics - Davrover
Converting an electric wheel-chair base to an autonomous rover
Disclaimer
Components
 |
Boxes | Jaycar | A number of these, slightly larger than used in this project. Always use a bigger box. |
 |
Raspberry Pi | Core Electronics | The brain of the rover. |
 |
Raspberry Pi Prototyping Board | EBay | An easy way to connect things to the header-block of the Raspberry Pi. |
 |
Voltmeter | EBay | Monitor battery charge and generally check that the voltages are okay. |
 |
Latching Panic Button | EBay | This is essential. Rovers are temperamental, and large rovers are dangerous. |
 |
Step-down Power Supply | EBay | To (back-)power the Raspberry Pi. Don't use one of these. Use a proper automotive one. |
 |
CSG M8T U-Blox GNSS (GPS) | CSG Shop | Raw-mode capable of GNSS, supported by RTKLIB. Two of these will required for DIY RTKLIB / Kinetic. |
 |
Sabertooth 2x25 | Dimension Engineering | Main drive motor controller. These are great. |
 |
WiFi Dongle | EBay | For communicating with WiFi network (including the RTKLIB base station). The on-board RPi one won't have the range. |
 |
50A Anderson Plugs | EBay | May be required to connect battery or drive motors. Cheap if ordered in bulk on EBay. |
Preparing the chair base
Throw away the chair and cushioning (unless you are thinking of re-using it for an eMule).
Strip it down and clean it up. Photograph the model numbers on the motors and batteries in case the labels are damaged or made illegible in the clean-up, or subsequent trauma.
Take out the brakes from the motors. Usually this involves unscrewing the plastic cover from the ends of the motors, unscrewing the brakes and cutting a few wires.
Remove the existing motor controller(s).
They are probably of little use - in particular they have safety features built-in like turning off if the brakes are not detected. They can be reprogrammed, and modified, but that is a lot of reverse engineering. Fitting a Sabertooth 2x25 is an easier option.
Work out how to get power to the Sabertooth 2x25 from the batteries, and to the motors. Anderson plugs are good, but there are many others too.
This may mean cutting the existing wires (from the battery and to the motors) and connecting plugs.
The cables from the batteries and motors are typically quite short - just long enough to reach the old controller - so cut the old plugs off in a way to leave the cables as long as possible.
Modifications
Paint it red. Robots are dangerous. They should be red. Affix a red strobe light too.
This one has had the original wheels replaced with $11 pneumatic tyres from Bunnings to increase traction and decrease vibration.
The springs on the back have been replaced by fixed struts to increase the ground clearance.
It does not yet have a mast for the GNSS receiver.
Circuit diagram
Doesn't show the voltmeter used to check voltages.
Control box
Get a box for the bits and pieces.
Work out how big it will need to be and get a larger one.
Fitting stuff into a box (with all the plugs and cables) is harder than it looks.
It must be big enough for at least
The Sabertooth 2x25
Raspberry Pi (with hobby plate to access GPIO block)
Step-down power supply to power Raspberry Pi and the USB devices hanging off it
Panic Button (these actually take up quite a lot of space)
Panel switches (on the top)
Voltmeter (on the top)
Plugs, cable, sockets
Other things not thought of yet, but will seem obvious later.
This project used a WiFi access point on the peak of the homestead roof, which in theory can be seen all over the farm.
However it is pushing the range limits of WiFi, hence a quality (hi gain) WiFi dongle was used.
Back-powering the Raspberry Pi through the GPIO block seemed to help.
Navigation mast-head
The GNSS (GPS) and the IMU (BNO055) may need to be separated from the rest of the componentry and the metal of the rover base. The metal, in particular, affects the magnetometer. Here they are placed in an elevated plastic box on a mast made from PVC plumbing pipe and appropriate joiners.
Unfortunately the mast compromises the design: The LidarLiteSweeper should be both as low as possible (to detect low obstacles), but be the highest point of the rover to get a 360° view. The mast will get in the way of the scanning, and will probably require software programming to remove it from view. This will create a blind-spot.
Software libraries
-
Raspian - Linux for Raspberry Pi
RTKLIB - for the GNSS handling (see DGPS)
i2c-tools - Raspberry Pi I2C Library
Arduino - for software development on the Nano / medulla
Pi4J - Java I2C libraries
Java - for software development.
Software
A truckload of software to make this do anything sensible. Most of the software is out of the scope of this document, but here are some snippets.
-
http://github.com/allegrobotics/arduino lidarlitesweeper: code to run on the Arduino to make the sweeper run, and report distances back to the Pi.
Of course this is a LidarLite version 1 - the version 2 has some more smarts, and the program could probably be optimised a bit better.
Ahrs.java which was adapted from Open-Source-AHRS-With-x-IMU, to compute the orientation from the IMU output.
Consider using ROS, but be warned: ROS is a big system, and will take a lot of time to understand, and set up.
Raspberry Pi load
A Raspberry Pi one (single processor @700MHz) was used in the original rover, and kept pretty busy.
-
Just opening the TX port (/dev/ttyAMA0) with Java RXTX to control the Sabertooth brought the CPU to 15% (this was just inefficiency in the drivers, which presumably busy-poll in NBIO mode where they should block).
Interrogating the IMU every 50ms and computing orientation was another 15%. Raspberry Pis will do low-level IO, but they aren't actually good at it. This workload could be shuffled into the Arduino with a bit of effort.
Reading the data from the LidarLiteSweeper and converting to Cartesian coordinates was another 10%. It's processing a new point every 10ms or so. The conversion to Cartesian coordinates is done totally with integer lookup tables (avoiding Double trigonometry functions in the java Math library), which improved this slightly, but it's still pretty slow.
Threads for recomputing current motor speeds, computing optimal direction (path finding), monitoring the NMEA from the GNSS, and monitoring the RTKLIB input were another 10%.
Full telemetry interrogation by a web-browser several times per second added another 40%
So it ran at around 86% load without a terribly intelligent navigation algorithm, and rtkrcv wasn't even running on the Pi yet.
Possible Solutions
-
Don't worry about it. Things may slow down a bit when extra functionality is added.
Get a faster Raspberry Pi. Fortunately the Raspberry Pi 2 is a quad processor @1GHz, and the Pi 3 is a 64 bit machine.
Use socat or nc to turn the serial devices into TCP sockets (and save 15%).
Another less sanitary approach might be to implement some of the RPi function in C++ - particularly the Sabertooth output (why waste time in a busy loop read if the interface is write-only?), and the IMU handling (and AHRS analysis).
The future
-
Collision detection (as apposed to collision avoidance with the Lidar). At some point the LidarLiteSweeper will fail to detect obstacles, and detection will be necessary.
Weed Detection. Mounting a face-down camera and analysing the image to detect weeds.
Weed Removal. Either through spraying or mechanical means (a length of wire like a lowering spring on a motor can dig out weeds without chemical environmental damage).
Pest Eviction. Easing the kangaroos out of the paddocks, if kangaroos
can be differentiated from sheep 
and alpacas 
).
Leave a comment
Something I'm doing wrong? Solved my problems? Got a better idea? Got a similar problem?Think I might have solved your problem? Ninety-nine problems, but your robot ain't one? Say so ..