RaspberryPi Prototype

General Description: This is a small-scale prototype that was constructed using a RaspberryPi 4b and Vex Robotics/off-the-shelf parts, designed with a heavy focus on software testing and proof-of-concept evaluation.

End Goal: The purpose of this second prototype was to become comfortable using the RaspberryPi interface and software systems, and use a connection over the internet to control physical motors and receive sensor input. The concepts that we learned while designing and building this small-scale rover can be easily applied to the full scale final product, and our evaluation of its performance in real-world scenarios will help guide our design process for the future.

RPi Experimentation

We had never used a RaspberryPi before, and so the first time booting up the system took a lot of experimentation and special equipment. Once that was done, we moved on to setting up and getting comfortable with the operating system. Since it didn't come preinstalled, we downloaded a much more customizable Python IDE called PyCharm, and began experimenting with that. At first, we just began by writing some code to control LEDs, but then quickly moved on to testing with servos, motor shields, & brushless motors.

Here's a short video showing the process of experimentation with a servo motor, one of the first tests to control external hardware with the RaspberryPi and PyCharm.

VID20210920143635.mp4

Building the Prototype

The next step was to assemble a prototype using our knowledge from the experimentation. After drawing up some plans, thinking about the original CAD model, and comparing different types of suspension, we decided it would be most beneficial to build this prototype as a four wheel drive tank-steer rover with a roughly rectangular base. For the sake of quick prototyping, the use of a VEX™ base plate allowed us to easily swap pieces on and off. For our main RaspberryPi power source, we used a standard 10,000 mAh phone charging battery, which provided a consistent 5 volts. This was attached securely as the first layer on top of the metal base. Next, we taped down the RaspberryPi and connected the motor driver on top, which had two separate channels. Each geared, brushed, DC motor on either side of the rover got wired into sequence with each other, so that one side corresponded to one channel. For our power source for the motors and motor shield, we used a 2200 mAh LiFe 8 cell battery pack. This provided the necessary 6.6 volts to run the rover for the first time. Four geared, brushed, DC motors This consisted of a Raspberry Pi mounted on top of a metal VEX™ base plate. Four geared motors were mounted at the corners of the base plate and connected to a motor shield on the Pi.

Field Testing & Evaluation

This prototype was never designed to be used in the field but an opportunity to test it in the Turkana desert presented itself and we took advantage of it. We flew to the Turkana Basin Institute and while there we tested the prototype in the kind of terrain and conditions we might be expecting on the final product. All the electronics and software worked well and as intended. This also allowed us to get some sick shots for the documentation.

A Quick Upgrade

The wheels, being held on by duct tape and rubber bands, were predictably not the most structurally sound part of the rover and so a decision was made to design and print some custom motor mounts.

The mounts were then installed on the prototype and the wheels attached.

Obstacle Avoidance

Hardware

Implementing obstacle avoidance into the hardware of the rover was a simple task of attaching an ultrasonic sensor to the front of the rover that can measure the distance to an object in front of it using echolocation.

Software

The software end consisted of telling the ultrasonic sensor to send a pulse and then measure the time until the pulse returns. From there the logic was to drive forward until echo was received suggesting the presence of an object within a margin and then turn to avoid the object. This was very rudimentary and simply a proof of concept.

Rover Prototype 2 - Obstacle Avoidance.mp4

GPS Wrangling

Driver

In order to interface the GPS with the raspberry pi we used a module called gpsd. This module allowed us to calibrate, read data, and interface python with the GPS module through a serial port. (Data Reading Above)

Calibration

The GPS proved to be initially difficult to make work as it needed to be calibrated outside. This meant the rover had to run on internal battery in the sun. We very quickly ran into overheating and power issues which we had to resolve by adding heatsinks and cutting down to bare essentials.

Reading Data to Python

To read data into python we first needed the python module compatible with gpsd. This allowed us to read data directly from gpsd and print them to the console.

Hardware

GPS and Compass Setup

In order to get better compass and GPS readings, we decided to elevate our sensor on a high pole or "mast" above the main electronic components of the rover, emulating past and current rover designs. By placing the GPS further away from the central body, the interference from the metal frame would be weaker, and given values more accurate. In our first version of the mast, we used a strong Vex robotics part, and raised the sensor by about 15 cm.

However, this simple decision would prove to be one of the worst , and yet simple mistakes, we've made so far. For weeks on end, we would try to calibrate and recalibrate the compass, take it outside for better sky-access, or even change software libraries and drivers altogether. Nothing would change the inaccuracy or outright crashing of the compass and GPS module.

After many hours of frustration, we finally decided to just abandon the GPS module we were using, and move to a simpler compass, which we know works on the Arduino well, and a specific piece that we've tested in the past. However, after printing a custom mount and attaching it to the rover (atop the mast), we realized the same thing was happening. Either the given values would just freeze, or be completely wrong. This was when we realized the big mistake. The mast we had attached all those weeks ago, was metal. Every time the compass or GPS was booted up, the interference from the mast would immediately change the readings, and nothing we did on the software side would change it. We quickly changed out the metal support structure for a plastic one, and decided to keep both the original GPS and the newer compass module, for improved accuracy. Hopefully we learned an important lesson along the way!

Compass Pi Interfacing

The compass we had, an HCM5883L, used an I2C protocol to communicate with a given microprocessor, a raspberry pi in this case. However, the raspberry was not designed to be able to easily handle I2C communication. For this reason, we made the decision to add an Arduino Mega in between the compass and the raspberry pi. The Arduino system was designed with sensor communication at the core. From the Arduino, we connected to the pi using a USB serial port. This Arduino will likely be used to handle all sensor data going forward.

Next Steps

Page updated

Report abuse