tirsdag den 17. april 2012

Lab 8, Robot Race


Date(s): 12-04-2012, 14-04-2012, 15-04-2012, 16-04-2012,
Duration of activity: 30 hours
Group members participating: Jeppe, Stefan, Thomas

Goal

Solve the Robot Race challenge.
The main goal is to just complete the track.

Plan

We wanted to try out a few ideas:
1) A simple robot that will just make it on the track.
2) The standard robot
3) A robot that navigates using a joint in the middle.
4) An other simple robot that will follow a more or less static path using only tacho counts.

Video record one of the robots that actually made it to the top and down again.

Results

1) The Simple Robot
The initial idea was to hardcode a robot that only by using controlMotor(...) and Thread.sleep(...), would be able to complete the track.
To test this we quickly made some simple code for the default robot (build after the booklet, 9797), which made us capable of reaching plateau two on the track. This convinced us that the general concept was durable and we started building a faster robot.
This new robot was given a gearing, which made it capable of driving much faster than the default robot. However, this made us aware that we did not have two motors which were equally fast.
This ment that our robot was turning slightly to the left when both motors had the same amount of power. Thus we went away from this kind of hardcoding of the robot, it would have to be a bit more advanced.

2) The standard robot
We returned to the default robot with some bigger wheels mounted. We also mounted two light sensors in front of it, such that it could follow the black line.
We wanted to add a gyroscope on the robot such that we could read if the robot was on the plateau where it was supposed to turn 180 degrees, or if it was on the ramp where it should just follow the line.
Since we did not have a gyroscope, we tried mounting a distance sensor (sonic sensor) on each side of the robot such that we could tell if we had reached a plateau or not.
We coded a simple line follower which could follow the straight line and stop when the robot reached the first plateau.




3) The Snake Robot
The robot would navigate by following the black line on the straight parts of the track. On the horizontal plateaus the robot would switch to a static 180 degree turn procedure after which the line follow program would take over.
The car has two engines. One that drives the car forward and one that is responsible for the navigation. See the sketch.



Two touch sensors are used to detect when the robot is at a horizontal plateau. Two arms (one on each side of the robot) sweeps close to the track, when the ground changes from the sliding part to the horizontal part, either the right arm or the left arm will push in the touch sensor. If the car is on the first plateau (turning right) the left arm will push in the touch sensor and vice versa.
Two light sensors are used to follow the black line.

The navigation is done using a PD controller. Where the error is modelled as the difference of measurement between the two light sensors, the error is translated as "for how long should the navigation motor spin in order to make the robot go in the right direction".

We programmed the robot to climb to the top plateau quite safely and at a "medium speed". We decided to give up the robot at that point since it was too big and slow.



4) Mr. Suicide
The Mr. Suicide robot (the video will explain the name) is "hardcoded" to make it all the way to the top without using any sensors other than the tacho counter in the motors.
The navigation relies on the fact that the robot can go on a straight line and turns the right amount of degrees on each plateau. This is achieved by looking at the difference of tacho count between the two motors. The P-controller looks as follows:


int error = MotorPort.B.getTachoCount() - MotorPort.A.getTachoCount();
MotorPort.A.controlMotor(speedA + error, forward);
MotorPort.B.controlMotor(speedB - error, forward);

This made the robot go on a straight line thus being reliable.
At the turns, the robot turned until a certain tacho count for each motor was reached.
After a long time of adjusting parameters, the robot was some what reliable and could complete the track in about every second or third tryout.

We discovered that the tacho count is best for going straight, when it comes to turning the robot around at the plaetaus, we relie on the fact that at certain number of degrees rotated by each motor will actually physically rotate the car - exactly - 180 degrees. This is not always true. This is very dependent of the battery state of the car!

However after a short while it became clear exactly which parameters are the most critical ones:
1) Number of degrees for motor A to rotate at plateau 1.
2) Number of degrees for motor B to rotate at plateau 2.

Thus calibrating could be done in a matter of a few minutes no matter the state of the battery.

Since the main goal of the competition was to get back to the green starting pad as fast as possible, we decided to make a small shortcut, by just plunging the robot down from the second plateau on to the green start field.
To avoid smashing the robot or the equipment, we mounted a lot of rubber tires on to the robot.
The tires was mounted in such a way that the robot would not bounce off the track, but stay in the geen start area when it falls down.

We managed to complete the track many times and video recorded 7 of them.
The most perfect (and fast) execution was completed in 28 seconds, as seen in the video:
http://daimi.au.dk/~u061245/Perfect7.mov

These was the results for the executions:

Perfect run 1: 32 sec.
Perfect run 2: 31 sec.
Perfect run 3: 30 sec.
Perfect run 4: 31 sec.
Perfect run 5: 34 sec.
Imperfect run 6: 27 sec.   Car bounced off the green area
Perfect run 7: 28 sec.



Conclusion


We tried out a few possible solutions before we finally reached the conclusion that the most simple robot would do the job.

The Mr. Suicide robot only needs calibration from the battery of the robot and not from the environment. It is very dependent of the start position, but also surprisingly successful considering that it was not always placed exactly on the same spot.
The Suicide robot took one afternoon to code and another afternoon to optimize. Using a static approach turned out to be very simple due to the nature of the track.



References
[1], Lesson 8, Robot Race,
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson8.dir/Lesson.html

Ingen kommentarer:

Send en kommentar