Diary of a Student Engineer Part 7: Obstacle Course Time
Finally, we’ve reached the climax of Assignment 2: The Obstacle Course. As discussed in previous posts the goal here is to write code for the robot which will allow it to navigate an obstacle course (shown below), and then catch a few ping-pong balls at the end before exiting the course.
Coding
So the first task here was to write the code. Some good news here was that we could add a stabiliser wheel for the robot which meant we could skip any necessary balancing code. So with the addition of a caster wheel at the front of the robot (as well as a mini stapler which acted as ballast to stop it from falling backwards when moving off from a stationary position), the coding challenge became a lot simpler.
My approach for the Arduino programme was to utilise what I could from the bootloader code, such as pre-written functions. Then the code specific to the obstacle course would be written by myself. In this case, the only bootloader code I needed was the header files for operating the motors. Conveniently, this included some simple functions for determining the direction of the robot and the speed.
This just left me the task of writing a script that would tell the robot the order for which it should carry out each turn in the course. For a pre-determined obstacle course, this made a combination of switch cases and FOR loops a suitable method of programming the robot. The benefit here was that the code became quite intuitive and did not take too long to write as it pretty much followed the same pattern throughout and only had to change a few parameters like direction (Left or Right). However, some things that I would change if I was to do it again are:
- Shorten the script! When the code repeats itself a lot, the solution is almost always to write a function that can replace all the unnecessary code. In this scenario, the script wasn’t too long so it wasn’t too big a hassle to copy and paste, but inefficient? Yes.
- Incorporate self-balancing code. This would take time but would be an interesting challenge nonetheless. It wasn’t necessary for this assignment but would maybe be something worth revisiting in the future.
- Motor drift. After some testing, the motors started to drift out of sync and so the robot started to collide with obstacles, inducing a lot of frustration. To fix this I increased the speed of one of the motors to make up for the asynchronous behaviour. This was a short term solution. If I was to do it again, I think it would be far more useful to incorporate data from Hall sensors to write a handy programme that could automatically prevent this problem from occurring.
Testing
So next it was time to test the robot out for real. After a few trial runs, I managed to get the robot to smoothly and accurately navigate the course but of course the major challenge was catching the ping pong balls at the end. As I mentioned in the previous post, I designed the launcher using elastic bands as the basis for storing potential energy. This meant that I could somewhat control the trajectory of the balls by adjusting the tensile stress placed on the elastic. This allowed me to choose a container for the robot that had quite a small surface area — so I used the internal cardboard packaging of an Easter egg. But what I did not consider was the bounciness of the ping-pong balls! In the video below, you can see that the robot navigates the course well and positions itself right at the correct position to catch the balls, but then they bounce back out…
Thankfully there was a simple solution for this problem. I used some bubble wrap at the base of the container to absorb the kinetic energy of the ping pong balls, and it was smooth sailing from there. This was the result:
Besides the initial misfire by me, the robot successfully catches a few ping-pong balls after navigating the obstacle course and exiting at the end.
And with that, Assignmnent 2 is eventually complete. Only one more to go now,;the ominous Rube Goldberg Machine. Stay tuned!
