Lab session 10 : Investigating leJOS subsumption API

Date: 18. November 2010

Duration of activity: ? hours

Group members participating : Michaël Ludmann, Guillaume Depoyant, Anders Dyhrberg

I. Objectives and summary

Investigate the BumperCar sample behavior, based on the LejOS incorrectly implemented  (or misnamed) subsumption architecture.

I.1 Press the touch sensor and keep it pressed. What happends ? Explain
- While the bumper is continually pressed, the robot just keeps repeating the behavior "DetectWall"

1. Set one engine to make half a wheel rotation and the other engine to make a full wheel rotation, causing a small turn.

It is noted that the behavior is blocking in the last engine call while executing it. 

I.2 Both DriveForward and DetectWall have a method takeControl that are called in the Arbitrator. Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called when the triggering condition of DetectWall is true.

- No the DriveDorward is never called, since DetectWall has a higher priority, and the arbitrator breaks from arbitration when, it reach DetectWall all the time.

I.3 Implement a third behavior, Exit. This behavior should react to the ESCAPE button and call System.Exit(0) if ESCAPE is pressed. Exit should be the highest priority behavior. Try to press ESCAPE both when DriveForward is active and when DetectWall is active. Is the Exit behavior activated immediately ? What if the parameter to Sound.pause(20) is changed to 2000 ? Explain.

- Exit behavior was implemented, and added to the behavior array, as the last one, making it the highest priority behavior. When pressing exit while driving forward it was working as expected, but while DetectWall was active it was not responding. This is due to the fact that the last motor call is a blocking call. The DetectWall action was modified to this implementation below, to make is respond to exit as expected. 

public void action() { Motor.C.resetTachoCount(); _suppressed = false; Motor.A.rotate(-180, true);// start Motor.A rotating backward Motor.C.backward(); // rotate C farther to make the turn while (!_suppressed && Motor.C.getTachoCount() > -360) { Thread.yield(); //don't exit till suppressed } Motor.C.stop(); }

What if the parameter to Sound.pause(20) is changed to 2000 ? Explain.
- The exact behavior was not completely justifiable. It was interrupting the code flow a lot. The arbitrator was forced to pause 2 seconds every time it has to go through the array to test which behavior wanted control. Even when DetectWall was not requesting control it was taking 2seconds to figure it out.
We did study the documentation and the source code for the Sensor.getDistance(), and is was clear that when the sensor is in ping mode, it is making the required pause by it self. Therefor it was decided to remove the delay completely.

I.4 To avoid the pause in the takeControl() method of DetectWall a local thread in DetectWall could be implemented that sample the ultrasonic sensor every 20 msec and stores the result in a variable distance accessible to takeControl. Try that. For some behaviors the triggering condition depends on sensors sampled with a constant sample interval. E.g. a behavior that remembers sensor readings e.g. to sum a running average. Therefore, it might be a good idea to have a local thread to do the continous sampling.

- Since the delay was removed this assignment did not appear strictly nessecary for us to do. But we considered this technic useful we did implemented it.

I.5 Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.

I.6 Try to implement the behavior DetectWall so it can be interrupted and started again e.g. if the touch sensor is pressed again while turning.