Introduction

The introduction project was a LEGO Mindstorm based robot, having the task of cleaning a white table of the size 1m² of 10 black LEGO bricks.

The rules of the game can be found www.mip.sdu.dk/~legobot/BookOfRecords.

LEGO Mindstorm’s base unit is the RCX 1.0. This unit has 3 outputs and 3 inputs and can be programmed in NQC, LEOS or the Java based LEJOS.

First draft

At the start of the project, the group members found that they had lost there childhood skills of building out of LEGO bricks.
Therefore, many wild ides came up, which proved impossible after making prototypes.
According to the first draft (a sketch is shown at figure #1), the robot was to drive in circles, gathering bricks as it went and shooting them, with a catapult, out of the field.

Another behavior pattern to choose from was driving from one of the corner.
When the robot had reached the black line, it was supposed to back up, turn 90 and then drive straight over the board. When reaching the black line, the robot was to back up further than before, turn 90 and drive over the board again. Both of the behaviors are showed on the figure 2 and figure 3.

After building a prototype, it proved that it was to difficult to gather the bricks up on the catapult and the idée was dropped.

Second draft

After dropping the catapult idea, it was decided to push the bricks. In trying the idea, the group found out that with the big velocity the robot was driving at, it was at risk that the bricks would fall out of the grasp of the robot during the turns.
Therefore the design was changed and a kind of insects belly or a bottle was supposed to be made under the robot, to gather the bricks and count them.

To control the robot, it was equipped with a differential drive, as shown on figure #4.

By using this differential drive and monitoring the big wheel in the middle, only one censor is needed to monitor both motors and give feedback to the RCX unit. This feedback can be used in the software to monitor how fast each wheel is spinning. This can be used to drive in a straight line or to controle the turns of the robot.

Final robot

The final robot, as can be seen on figure 5, we built differed from the second draft as we unplugged the differential and added an extra sensor on the left arm (see figure 6). Hereby we were able to program the robot to follow the black line, instead of assuming that the differential provided us with a straight line driving (for a detailed description see the Programming section).

The final behavior pattern is as follow (see figure 2); when the robot is started, it turns around itself to push away any bricks lying close to it. Then it move around in a spiral, till it’s left arm has crossed the black tape. After that it drives in a circle  until the sensors have registreret the black line 4 times. There after the robot starts tracking the black line, collecting brick lying near the black line, and in the corners. If the robot encounters a corner it will move backwards, leaving collected bricks behind, outside the black tape, then turn right a bit and move forward until the black tape is detected, which it will follow till the next corner is detected. The robot will continue following the black tape in infinity (read: till it runs out of battery) to assure that all bricks have been captured.

Programming

We choose to program the robot with leJOS which is faster to learn when you are a Java freak J.

Programming the robot to follow the behavior described above (see Final robot section) we need three methods beside the main method; moveSpiral(), turn() and followBlackLine(). Given these three methods the main method could be implemented as following:

Following is pseudo-code describing the three methods used in the main method provided.

 For a detailed implementation download the code.

Test

The test and the programming are closely related. Because we only could attach three sensors, we had to use for-loop etc. when moving the robot forward or backward in a specific amount of time. The only problem with above, is the dependency on the battery voltage, which makes the robot move slower or faster. This problem can only be solved by either add more sensor (not possible) or adjusting the for-loops. We used the latter solution, which affects the behavior of the robot when the battery wears up.

A video sample showing the final behavior of the robot, can be seen here.

Competition

Name of the GAME: SPEEDY CLEANER
For more information about the rules follows THIS hyperlink, go into the “Games” menu and then further in the “Speedy Cleaner” menu.

Results of the competition 2003:

Conclusion

From the results of the competition, we can conclude that we designed and constructed a robotic vehicle that did as designed and acted on our ideas. Nerveless, we as a group, experienced the difficulties in mechanics because none of the team members had any higher knowledge of the subject. On the other hand we had no problems with the software structure and implementation therefore, focus was on the mechanics! Moreover, our initially design got changed several times along the way (which was quite a lot considering the 2-3 days of time span at our disposal) which is a clear result of the wrong assumptions and little experience of the hardware. However we managed to make a robotic vehicle that acted to our predefined behaviors, which showed to be as affected as planned.
The reason for the robot missing the last brick in the 3 race is the misplacement of the robot on the field. In such a spiral driving, the start position is crucial for the exact behavior.Another aspect of robotic problematic was enlightened during the competition, namely the environment. We found that tiny changes in the environment could alter the course of the vehicle; hence, all of the groups had only tested and developed the prototype in one room and the competition was held in another room – which in our case resulted in additional sections in the competition, because we had tested the robot in the lap had 15 sec for behavior one (spiral) and additional 15 sec for behavior 2 (quadratic).

Perspective

We could enhance the robotic vehicle with additional movement patterns that could act as backup. We could also have enhanced the vehicle with more sensors and mechanical structures that could provide additional stability to the line of movement (e.g. the differentiator) which could result in a faster drive or touch sensor that counted the bricks and drove out if it had all of them.

To the Top