Semi-autonomous 4×4 rover Mark II

When I started at Missouri S&T in the fall of 2017, I decided to learn from my missteps with my Mark I rover and build a Mark II version. The Mark I had been a success in many ways, but it had presented a lackluster performance in regards to mobility.

With the Mark I, I hadn’t considered the implications of fixed wheels on a long rover. As a result, the tank-type steering I had employed didn’t produce enough turning torque to overcome the static friction of the wheels. With the Mark II, I would drastically decrease the length of the rover so that turning with tank-type steering would not be difficult.

I also threw out a lot of the extraneous requirements that I had imposed upon the Mark I, such as making it rain-resistant. Without these constraints, the design of the actual rover body became extremely simple.

Some shiny new hubs for a shiny new rover.
Modeled in Inventor.

A nice drawing for a nice wheel hub thingy.

The new hubs looked so much better compared to the original Mk. I hubs.
Original hubs on the right, new hubs on the left.

By the time I got around to modeling, I was really very excited to get it all working. I had a bunch of parts that I scavenged from the Mk. I, so I drew up a sketch of the general electrical system and assembled the whole thing in two or three days.

These images were taken in the early part of electronics/wiring testing, before I could get the new hubs 3D printed.

I had noticed with the Mk. I that I had an electrical issue when I powered the controller off the same bus as the motor power supply. To overcome this issue, I used a second battery as the power source and a modified 12V USB car charger to convert it down to the 5V that the Raspberry Pi ran on.
This modified car charger can be seen in the bottom image sitting on the upper deck of the rover, connected to a desktop power supply.

After the rover was built physically, I had to figure out how to program it. I was using a Raspberry Pi as the brains of the beast, so I decided to make a program in Python to run on the rover and carry out any actionable commands received by the XBee radio.

I wrote the rover-side portion of the control system from scratch and optimized it through extensive testing. For the user-input side of things, I chose to expand upon software I’d previously created for my miniature-blimp class project. I added many internal functions, and integrated the whole thing into a (mostly) user-friendly GUI application that would allow anyone with a USB joystick and an XBee radio (linked to the one onboard the rover) to send commands.

This setup procedure was done to ensure that the joystick potentiometer readings would scale properly.

This was the main control hub on the user side. Video linking was never worked out, but everything else was fully functional.

If you’re interested in trying to read all this, I’ve linked the image to a full-size version.

This was the part of the code on the rover that made everything else happen.

Eventually, I got sick of swapping around physical cables on the Raspberry Pi in order to program it, so I created bash scripts that could be triggered from a user command issued over the XBee radio. When they ran, they either enabled or disabled the wireless access point functionality of a USB Wi-Fi dongle. By doing this, I could enable the access point mode most of the time so that I could use a secure shell (SSH) to transfer files from my computer to the rover. If I ever needed to install or update some piece of software, I could disable access point mode and it would connect to a nearby Wireless Access Point (WAP) with credentials that I’d hard-coded into the rover.

This is a simple .txt instruction sheet for the bash scripts I wrote.

At this point, the rover drove around like an RC car with a bit more functionality. Unfortunately, I discovered that the XBee radio was suitable only for line-of-sight communications. This revelation occurred when the Loss of Contact subroutine kicked after I drove it around a corner and it stopped moving. The line-of-sight constraint meant that I wouldn’t be able to let the rover drive around autonomously (I had planned for GPS waypoints) while maintaining contact with it.

Around that time, I also started to become extremely busy with my calculus III class, so the project was pushed to the side. After that, I haven’t really worked on it much since.

Some very simplistic autonomy logic, sketched out for convenience.
In my mind, I thought of it like a Riemann sum of the universe. My rover wouldn’t have the memory capacity to store a point cloud of every sensor reading, but if it could get one trustworthy datum for every square foot that it passed near, then the vertical value of that square foot could be used to try and determine a motion path.

While this project has drifted away from my consciousness, it’s still something I’m very much interested in pursuing. I have other things that are (currently) more interesting to me, but I know that someday the rover in my closet will once again get a few shiny upgrades and drive around in the sun.