Compass-rover with event-orientated subsumption architecture under Robolab 2.5
As we announced it here the Pewatron-compass-rover.
NOTE that you MUST run the compass-calibration program first. See Compass ! The subsumption-files are found at the subsumption architecture page.
DOWNLOAD the new sub.vis here.
This is a real multi-tasking job. To manage all these tasks we altered the arbitrate-task a bit :
 |
 |
 |
 |
For better survey the major part of the course-adjust-task is arranged in an own icon :
The actual program commands the robot to go north for a certain amount of rotations, then go south, finally stop. The robot may avoid obstacles and continue its way in the correct direction. Build a robot accordingly!
Note that this program allows 5 (yes, you read five ! ) sensors to be connected to the RCX. As the LEGO-touch-sensors do not short-circuit when they are pushed, but present a resistance of about 2kW, we may -as we did already in the past - connect the compass-sensor parallel to the touch-sensors. When one particular bumper is pressed, the port-voltage drops and the raw sensor-values fall below 150. Using the event-monitoring features of firmware 2.0, the sensor port is monitored and a bumper-event is triggered asking the robot to do some avoiding movements.
subsumption_compass.vi :
Remind that all the 32 variables are in use now. You may NOT do any datalogging with Robolab.
The program subsumption_compass.vi demonstrates well the facility of a subsumption architecture to manage many tasks. But a problem occured : the azimuth is no more displayed. This is due to the the rotation-sensor functions. In order to overcome this, we propose two sub.vis without sensor display, the first time we altered a Robolab function.
The obstacle-avoiding is not satisfying in subsumption_compass.vi. If a bumper-event is detected, the highest priority-task takes full control over the robot. Let's say the robot is turning to the left for 3 seconds, then advancing during 2 seconds. The robot may be in contact with the obstacle, but no bumper-event is generated. The 2 seconds the going-forward-command forces the robot against the obstacle, while the wheels are spinning. Then the motor-access is released to the course-adjusting task. The robot returns to the desired direction and hits the obstacle again.
We propose a better solution :
subsumption_compass2.vi
Now the go_forward command is fixed between the event-monitoring-part. Thus, if a further event is generated in the same task, the robot doesn't advance anymore.
But, no event is registered from the other bumper task if there is an impact. This may cause serious problems depending on the shape of the obstacle. To overcome that difficulty, we use only ONE bumper_command. Doing so both bumper tasks get the same priority and there should be no problem anymore
subsumption_compass3.vi :
The last problem that remains is the situation, when the robot gets stuck in a corner. We are working on this. Stand by !
