Obstacle Course Conquered
Hello everyone and welcome back to the blog! In the last few weeks I have been keeping you on the edge of your seat waiting for the obstacle course challenge. Each week I would tease a new blog only for it to be some type of modifications/build, however I will now present to you the real deal, the moment you’ve been waiting for, the real obstacle course!
Even though this cardboard construction might look like a walk in the park let me tell you that I definitely lost a few nerves during this assignment. Firstly I planned to incorporate both the ultrasonic and IR sensors into my code. My understanding was that I would use the ultrasonic sensor to initiate the IR sensors whenever there was an obstacle in front of the robot. The IR sensors would then scan the left and right surroundings, after which one side would always be free. The robot would then turn in the direction where the IR sensors showed no walls. After initialising all components in the void setup and calculating the signal travel time for both sensors, the void loop code looked like the following:
I was ecstatic when the robot seamlessly galloped through the first set of gates (a) and then swiftly took a left turn at the first wall (b), however things took a turn for the worst after this moment… The expectation was for the robot to turn right but what actually happened was that the robot would just stop. This meant that none of the ‘if’ statements written above were true and my serial monitor showed that both the IR sensors were reading as 17, i.e. there was an obstacle on both sides. I tried to change many factors such as the brightness in my room with my window blinds or the colour of the obstacle walls but to no avail. My only reasonable explanation is that the IR sensors minimum working distance was larger than the maximum distance in some parts of the obstacle course, therefore I decided to start a new code.
The new code would rely on a more rudimentary approach with the programming focusing on the DC motor movement. This involved coding the specific time and motor speed each motor should be turned on for by the use of the Forward, Left, Right and Stop functions.
I then generated and tested the code throughout the obstacle course and after multiple trials the robot could successfully navigate the course. However I did find some issues with my method. Namely the amount of charge on the battery slightly affected the DC motors performance; I found that at full charge the motors would travel a longer distance with the same time and motor speed parameters, than when the battery was nearly discharged. Also the fact that both motors weren’t identically the same meant the robot would veer to one side, therefore the left motor needed a slightly higher input to make the robot travel in a straight line.
Finally when the robot could cruise around the obstacle course with no issues, I setup my launcher and it was time to complete the challenge. To give you all a perfect view of what was happening I decided to use two camera angles, namely a wide angle view of the whole course and then a top view overlooking the course specifically. I found this worked best as the wide angle view had perfect visibility of the launcher in action however the robot course navigation perspective was poor, and vice versa with the top view camera angle. So without further ado here is the obstacle course challenge! (and please excuse my dads rather shaky hand while kindly filming the top view camera angle)
As can be seen the robot steered the course without issue and during the ball collection I managed to get 50% of the fired ping pong balls into the basket! I was very happy with the result however if I was ever to repeat this challenge in the future I would have some recommendations. Firstly I would redesign my reloading device in my launcher. This is because it can be seen that as the number of balls in the reloading chamber decreases the range of the launcher slightly increases. I would explain this by saying that the balls all rest on top of each other in the reloading chamber, therefore their mass acts on the ball which is currently being fired, over time as the amount of balls in the reloading chamber decreases and hence the mass decreases, there is less of an restriction acting on the ball which is being fired. To aid this I would suggest dropping the balls into the firing chamber at a controlled instance of time. Furthermore I would like to see how my first code which incorporated the ultrasonic and IR sensors and could automate the robot for any course would perform if this course was bigger and hence more suitable for the IR sensors working environment.
I hope that you enjoyed not only this blog of the obstacle course challenge but also all the previous blogs building up to this event. In my next post I will present to you my Rube Goldberg Machine with an interesting twist at the end. If you like the content posted on this channel please consider following!
