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

Caster Wheel with Necessary Ballast

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.
Approach taken for navigating course

Testing

Testing the Launcher

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:

Obstacle Course Video w/ elevator music for your enjoyment

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!