|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.|
Throw away the chair and cushioning.
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.
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.
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.
The GNSS (GPS) and the LSM9DS0 IMU 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.
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.
Consider using ROS, but be warned: ROS is a big system, and will take a lot of time to understand, and set up.
A Raspberry Pi one (single processor @700MHz) was used in the original rover, and kept pretty busy.
So it ran at around 86% load without a terribly intelligent navigation algorithm, and rtkrcv wasn't even running on the Pi yet.
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).