Redbot Rover
A rover meant to navigate an obstacle course using a SparkFun Redbot. Coded using arduino uno, our robot featured an exterior from foam and foam core with modified wheels, encoders, and a music feature at the end.
About
Design:
The final design of our rover included the typical redbot parts and assembly combined with our own creative flair for improved traction, playing victory sounds, and aesthetics. Our rover was built to resemble a martian bug type creature to blend in with its surroundings while on its mission, using lightweight materials like foam sheets and foam core to ensure the weight of our bot was not too high. These materials allowed us to fully utilize the scope of the power of the wheels’ motors, while also ensuring the aesthetics did not mess with our code. To modify the traction, we added the rubber coating from some other scrap wheels, which we noticed was much more grippy than the initial wheels on the redbot which did not offer much friction between them and the course. These wheels allowed our redbot to be able to climb ramps consistently. Finally, we added our own extension to the redbot which allowed a song to play. To do this, we first connected a speaker and proto to a mounting board. We attached the mounting board to our bot with a foam core compartment. We allowed the redboard to communicate with the speaker by connecting the proto and A3 pins. We then accessed the music example code and imported “notes.h”, a file containing all the notes on a piano. Utilizing an online keyboard and sheet music, we found the correct notes and created a function to play our song. Finally, we adjusted the timing of the notes until the song played as intended.
Software and Hardware:
GitHub repository: https://github.com/JaxonJefferson/Sparkfun-Redbot.git
Our final rover included use of only encoders for sensors. The idea was to use the encoders in order to make accurate turns, and in order to allow the redbot to drive straight, since the motors varied in strength slightly even if set to the same speed. In our moveForward function, we record the left and right encoder values with a small delay i.e. 100ms, and then look at the difference between them. We then made tiny adjustments based on this. For example, if the left encoder was larger, this means that the left motor was outpacing the right, and so the right motor’s speed was increased by 1 (unless the right motor was already at the max speed passed into the function, in which case the left motor’s speed would be decreased by 1 instead). Although the change in speed is small, the idea is that these adjustments happen 10x per second which is better than a smaller number of changes over a longer timeframe. The encoder values were also reset to 0 after each of these 100ms cycles, as letting their values build would just result in never changing speeds, since even if the effective speed of the motors is the same, the code only sees that the encoders are unbalanced. The left and right turns similarly were based on encoder values, and turned until a certain change in encoder was detected. Ultimately, we were severely held back by the precision of the sensor. The robot would do different things every run despite all of the code being based on encoder values, and the encoders also occasionally fully stopped working, causing our code to be stuck in an infinite loop. Another issue with the encoders is that they did not work the same at different speeds. For example, 100 ticks on 100 speed would result in fewer rotations than 100 ticks on 200 speed, even when using the brake function on the motors. This is possibly due to a ceiling on how often the encoder is able to update its value.
Completion:
Our rover could not successfully complete the course without human intervention. However, in our last in-class run, we were able to get it to the finish line with 2-3 touches to realign it, since our main issue was getting our robot to go in a straight line. Our robot utilized the upper path, successfully making it straight in the beginning, turning, and going up the ramp autonomously. It then needed adjusting to get down the leftward path after the ramp, but could make it down the final line just fine. Finally, our music played perfectly. The rover was partially successful because of the time we put into coding it to travel a certain way, but partially not successful because one of our encoders broke, and they were always wildly inconsistent, causing our robot to have trouble going straight as well, which was certainly the course’s greatest challenge for us. We attempted to overcome this by testing our rover many times, but could not get it perfect.
Future:
Firstly, if we had another two weeks to complete this challenge, we would spread out the workload much more than we did. We would set goals that we aimed to complete at the end of each week to keep a good pace and allow ample time for tweaking. As for the redbot design, we would try to find a solution to all the inconsistencies we experienced because of the encoders and batteries. Whether this would be ordering different parts or switching to a different type of sensor for our wheels, we would have more time to test out all of these other methods and select the most effective one. We would also have time to make our robot more professional-looking and add more decorations to it.
