Working with Robots!

In theory, there is no difference between theory and practice.
But in practice there is..! -- Einstein

The above quote paints the walls of 4th floor of our bldg BC at epfl.
There was a chance for me to experience that, when i worked with some robots. My experience says that, there is, in fact, a lot of difference!
As part of a course offered by amazing Prof. Thomas Hensinger (read his page for his mind blowing research!), we had to do some experiments with NXT robots. As part of this experiment, each team is provided with two robots. In the end, there would be a competition where a pilot robot operated by the assistant using remote control will be placed in between the two robots. The trailing robot has to emulate the movements of the pilot robot and follow the robot exactly. The same goes with the leading robot.

We initially started making the follower follow the leader, using our two robots. An Ultra Sonic sensor is provided with each robot which is used to measure the distance to the nearest obstacle (which can be a robot or anything else- there is no way to know whether u r seeing a robot or a wall!!). To increase the reliability of readings, we fixed two sensors on the trailing robot. We had to modify the design of the leader so as to be detected much accurately by the the sensors of trailing robot. Then comes the concept of the PID controller. The concept is really amazing and an elaborated explanation of the tech details can be found on wiki. Basically it is used in the trailing robot so as to catch up the leader steadily rather than abruptly.

Oh..! It is done...Is it so simple? No way. Since robot has two motors, unless both are synchronized, it can not go in straight line and the trailing robot misses the line of sight. Even though some compromise on being in the straight line are assumed and the sensors, in fact rotate in a horizontal plane to measure the readings, synchronization is still needed. The NXC (Not Exactly C) provides some API for synchronization, it takes little experimentation (in fact a lot if you r not lucky) to tune the parameters and pick up the right api. In spite of the right api used, we never got the right synchronization expected. I felt the reason could be supporting the robot with two wheels in the rear side (which do not have motors--only front wheels do have). Since there are two wheels, the friction exercised by the surface should be same on both otherwise, robot wont be stable in a straight line irrespective of perfect sync of the motors. So I replaced two wheels with a single wheel (in the middle of the robot) and not to my surprise, it was working great! (see the photograph for design). Now time for expanding this prototype to the actual problem setting. We decided to attack it this way- the trailer robot senses the movements of the pilot using the sensors and communicates with the leader using bluetooth. So we did blue tooth programming and after lot of pain and effort we could make that communication working. Since messages should not be lost and leader has to receive the message almost immediately after trailer sends. So finally we put all pieces together and it was working great under some constraints.

In the final competition, almost all teams showed same performance. None of them was perfect and either the trailer bumps into the pilot and both get struck and the leader keeps on moving OR the leader gets lost completely and moves in its own world. So that reminded me above quote. May be our task demands more sweating probably before it actually meets the theory! You can mail me for the detailed report and the programs or get my epfl website once it is up!!