In this challenge the goal was to circle around an obstacle in the middle of the table while starting and finishing in the appropriate boxes. This could be achieved by either autonomous movement or remote control.
The robot is capable of both autonomous movement and remote control.
The autonomous movement is it secondary function. written at the last minute completely from scratch there were only a handful of tests. One of the problems identified in these tests was how it would know to stop after i reached the end, with such little time to do anything we could not implement a dedicated sensor to identifying the end box. So the work around was a variable to count how many times it turn and after the third time stop as to finish in the box. There is a remaining problem in that the ultra sonic sensor is not always reliable, this may be due to a hardware problem or and unidentified error in the code.
The remote control robot worked off Bluetooth with another robot. The remote control used two levers hooked up to motor to control power of the robots motors based on the degrees of the levers. The degrees are times by two to get the power for the motors. We original used wheels on the control but it was to hard to control due to poor design and us being bad divers.
The design of the robot was ramshackle and somewhat flimsy. This is fine if the robot does not fall and shatter into am million pieces or accelerate to fast fall apart, both of which happened twice.
The task was to make a robot/machine that can go up and down the table making a U-turn around an object at the top, so I thought I would be unique and make a remote controlled car. The idea was that the car copied the controller exactly, in other words it was mimicking it.
Prototypes: The first car we had was the basic car in the instructions, but due to some technical difficulties, the car we had was torn apart by my partner and I was left with the scraps of it. We did manage to fix it though so that’s good. Other than that the prototype worked that good that we just rolled with it. The controller had the joystick thing a little bit lower and I kept on accidentally pressing buttons so we changed it (moved the parts upwards a little). We also tried a 1 – 3 ratio for the wheel (controller to vehicle) and it was good but turning was a pain so we left it at 1 – 1.
Outcome: It worked. The outcome was great. I am not the best at driving it but with a little bit of practice you could do it easily.
Future Plans: We added buttons/touch sensors to it to make breaks but we ran out of time. Just saying if I had brakes than I would be slightly better at driving it. I noticed that the gap difference between the vehicle and controller, the spinning on the controller was affecting the movement, so if we had more time I would have added a wider vehicle wheel gap to make up for it. another thing I would add is for when it is moving it plays “Gas Gas Gas” by Manuel and plays “Deja Vu” by Initial D when turning.
Our challenge was to design a remote controlled or automatic robot that could get around an obstacle. We choose to build a robot that could autonomously get around the obstacle.
The robot does not work for a two main reasons.
The robot is not well designed for this particular challenge
The code is complicated and can have many thing go wrong with it
Robot Design versions
The the first version of the robot did not have the ultrasonic sensor and light sensor. Instead used a touch sensor to detect the edge of the table and turn away this ultimately did not work as constant pressure could not be maintained .
The second version replaced the touch sensor with instead a light sensor. The light sensor did work and is could avoid driving off the edge of an table but the robot still had no ability to detect the obstacle and drive around it.
The third and final design version re added the touch sensor as a way to easily start the program. It also added the ultrasonic sensor to allow it to detect the obstacle and avoid it.
Code Design Versions
The code did not change a huge much as i only started coding when the final design on the robot was complete this limited the amount of time i had to test the code and work out the the design would have worked far better if it was remote controlled.
Looking back on the project i should have tried to keep the robot and code as simply as possible for the course to reduce the chances of errors forming in the code or design. And if i had more time i could have prototype a bit more and sooner relies the robot design was far more suited to remote controlled than automatic. In future need to edit myself and try and keep it as simple as possible.
We designed and constructed this robot, to partake and complete the obstacle course project.
Program your robot to run an obstacle course in the fastest time
This challenge introduces the following concepts
Autonomous v remote control
reliability and repeat ability
Bluetooth? (intermediate – requires some additional knowledge)
Autonomous – One point for each
Robot uses sensors to dive around the obstacle and back to the start, without failing, or falling of the edge.
Easy to use and reliable
Fastest autonomous robot or does something equally amazing.
We knew from the beginning we needed the robot to have a extended neck to easily detect darkness or light, and to also give robot wheels time to turn. Ball at the back to make turning easier, because then it doesn’t have to carry the back wheels.
The robot ran the obstacle course and ran it in a little bit over 9 seconds.
The robot managed to get around the Lego brick using the ultrasonic sensor to detect when it was past it and proceeded to do a series of movements which would get him around to the other side and then drove past the finish line.
The robot was reliable as almost every time it went it did what it had to and did it well.