Project - Meeting 10

Date: 11-06-2012
Duration of activity: 2 hours
Attendants: Stefan & Jeppe

Goal:

• Adjust the backdown algorithm, such that the robots are sured to be on the right side of the black line.  
• Make the arm of the grabber lower under the bridge.  
• Make the space between the robots a bit bigger when they are driving toward the basket.

Plan:

• We will take a look at the video recorded last time and find out which minor issues that we have to correct. 
• We will start by adding a "fixed point" to the arm of the Grabber robot, such that is has a fixed start position every time we start it.
• Give a detailed table of the message, command sequence for each robot.

Results:

In this section we will describe the last adjustments made on the robots before we can have a perfect run.

Last Adjustments

Since the grabber had to be at a specific position to be able to grab the object on the bridge, we installed a cross-bean om the motor, so we were able to reset the grabber to the exact same position each time. The software was then altered to take this new initial position into account.

Another part that needed some tweeks, was that the second stacking-robot was driving slightly faster then the first stacking robot. This sometimes resulted one robot catching up with the other and starting to climb up the slide, while they were supposed to drive forward to the basket. This problem was solved by increasing the delay between the robots starting to follow the line toward the basket.

We placed black markers on the track to make sure that the robots would always start in the same position and that the object on the bridge would always be picked up.

The final detail we had to resolve for today, was the fact that the piece of paper on top of the first stacking-robot was still too short. This would sometimes result in the second stacking-robot starting to rotate, because the light-sensor did not have any black line to follow.

The final architecture

In this section we will present an overview of our final algorithm. In the next section we will present the messages and actions executed by the robots.

The basic algorithm consists of the following components:

• Bluetooth communication
• Sensor detector thread
• Line follower thread (action)
• Back down thread (action)
• Grabber arm thread (action)

The basic idea is that the action threads are activated and deactivated by incoming messages. 

The over all algorithm between the robots is constructed in such a way that two actions will never be triggered at the same time. Fx. the robot will not be in a state where it is both trying to back down and follow the line. Below is the complete and final table of commands and actions for each robot. 

Messages and Actions

To summarize the final command sequence, we have specified a message, action table for each robot.
Each robot now knows exactly what to do when it receives a message of a certain type.

Grabber Robot

Message Received	Action	Description
READY_STACKING1	Start Follow line	When Stacking1 - the last robot - is ready, start.
STOP_STACKING2	Take or release object. Once the object has been taken, send out the message MOVE_DOWN_STACKING2	When Stacking2 is to stop, the Grabber robot should either take the object or drop it, depending on wether or not it is holding the object already.
STOP_GRABBER	Stop Follow line	Send when the grabber is to be stopped. Ie. when the grabber hits the push sensor on the Stacking2 robot (that it is climbing on top of). Also the the grabber must lower its arm a bit again in order to precisely take the object.
MOVE_DOWN_GRABBER	Start backing down from the Stacking2 robot. When the robot is down, send the message MOVE_TO_BASKET, to indicate to the other robots that they should start moving toward the basket.	Send when it is safe for the Grabber robot to climb down from the Stacking2 robot.
MOVE_TO_BASKET	First wait 18 seconds, then start following the black line to the basket. Also the Grabber will have to lower its arm a bit in order for it to pass safely under the bridge.	The Grabber robot must wait for the other two robots to move a bit ahead, before it starts moving. This is to avoid collisions on the way (some robots are faster than others due to battery level, motor quality etc.)
BASKET_REACHED	Stop. Raise the arm a bit, in order to be able to climb the Stacking2 robot.	The Grabber robot must wait for the other two robots to move a bit ahead, before it starts moving. This is to avoid collisions on the way (some robots are faster than others due to battery level, motor quality etc.)

Stacking2 Robot

Message Received	Action	Description
STOP_STACKING2/td>	Stop following the black line.	When the Stacking2 robot is on top of the Stacking1 robot, it should stop.
STOP_GRABBER/td>	Start following the black line on top of the Stacking1 robot.	When the Grabber is stopped on top of the Stacking2 robot, Stacking2 should start moving on top of Stacking1.
MOVE_DOWN_STACKING2/td>	Start backing down. When down, send MOVE_DOWN_GRABBER message.	When the Grabber robot has taken the object, it will tell the Stacking2 robot to start backing down.
MOVE_TO_BASKET/td>	Wait 12 seconds. Start follow black line to the basket.	When the robot is told to start moving to the basket it must first wait for the Stacking1 robot to move ahead to avoid a collision.
BASKET_REACHED	Stop following the black line.	The basket has been reached by the Stacking1 robot. Stop and wait.

Stacking1 Robot

Message Received	Action	Description
MVOE_TO_BASKET	Start following the line and activate the "detect basket" sensor. When the basket is reached, send message: BASKET_REACHED, wait 1 second, send message READY_STACKING1 (this will make the Grabber robot repete the actions from the first climb).	The robot will start moving toward the basket. Once the basket is reached, send out the proper commands for the robots to start stacking again.

Final Run

Now it should be possible to complete the track with the updated set of parameters. The run is shown below:

Conclusion

The robots can now complete the track. We ran through the track four times and had perfect runs in the three of the runs. The robots carried out the tasks surprisingly stable. It turns out that even though there are many variables, building a almost 100% reactive system was a very good choice.  The only part of the track that is "hard coded" is the backing down procedure, where the robots just drives "blindly" backward until they are down on the track. This is very short part of the whole track so it did not really turn out to be an issue. We managed to implement a very stable line follow algorithm making the robots follow the straight lines with no visible oscillation. This in turn made it very easy for the robots to climb on top of each other since they would always be aligned with the black line.

Having the Grabber robot grabbing the object each time perfectly was also some what a positive surprise. The difficulty is that the middel robot must stop at the same point every time, but so must the grabber robot on top, such that the three robots when stacked, always is a the same position. Having the robots climbing each other two times on the same track flawlessly three out of four times was very nice to see.