When the touch sensor is pressed continuously the robot stays in the detect wall behavior, where it first drives a little backwards, followed by turning a little to the right. This is done with the *RegulatedMotor*, where a non blocking command is sent to the left motor, commanding the motor to turn 180 degrees backwards, and a blocking command to the right motor commanding it to turn 360 degrees backwards.
#### Implementing a ESCAPE behavior
##### Specification of the behavior
We want a behavior that if the ESCAPE button is pressed, System.Exit(0) is called resulting in the robot shutting down. This behavior should have the highest priority.
##### The implementation
When the escape button is pressed, the robot takes the following action:
```java
publicvoidaction(){
LCD.drawString("Now exiting...",0,0);
BumperCar.leftMotor.stop();
BumperCar.rightMotor.stop();
System.exit(0);
}
```
In detect wall we have added a proper suppression so that the escape behavior can take precedence.
##### Observation of the behavior
When we push the button when the robot is driving forward, it stops immediately. However if it is pressed when it just started avoiding an obstacle, we saw a weird behavior, where the robot reached a state where it the current action for avoiding is allowed to follow through, but the it did not stop the program afterwards, but detect wall was suppressed, so if it was near an obstacle, it was simply standing still. If we pushed the button later in the avoidance period it finished up and exited as we expected.
#### Taking control
The arbitrator have a monitor that looks at all entries in the list of behaviors and sees if the behavior wants to get control. This is done by running through the list from high priority to low and return the entry with highest priority which want control.
(“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 while loop run through the behaviours from highest priority to lowest priority and breaks out of the loop after when it reach a behaviour whose takeControl returns true.
#### Separating taking control and distance measurements
Getting the distance takes a little time, which goes against the contract of a behavior, since takeControl should return immediately. This is simply done by creating a small local thread that updates the distance every 20ms.
```java
_ping=newThread(newRunnable(){
publicvoidrun(){
while(true){
sonar.ping();
_distance=sonar.getDistance();
Delay.msDelay(20);
}
}});
_ping.start();
```
#### Backwards for one second
To get the robot to move backwards for one second before turning, the following code has been added to the action of detect wall.
```java
BumperCar.leftMotor.backward();
BumperCar.rightMotor.backwart();
Delay.msDelay(1000);
```
#### Making call interruptible
A problem with the implementation of Detect Wall is that both delay and the last rotate is blocking calls, meaning that we cannot do anything new. This have been solved by making small methods that do the same, but we have use some busy waiting instead, where we do checks if it should start from the beginning or if it has been suppressed.
### Conclusion
We have gained knowledge about the built in arbitrator and the behavioal interface.
//experiment two ultrasonic sensors look at each other
// no effect, using one robot (probably only one of the sensors sending at a time)
## general plan
ultrasonic rotating on motor = look at opponent, turn to face
8 bumpers around the car = detect if hit (ultrasonic knows direction)
need to check length to object (in case ultra sonic is look at a dropped item, it
should rotate to find where the attack came from)
2 light sensor in front to detect white line when driving forward
2 light sensor in back to detect white line when driving backwards
# Conclusion
# Conclusion
# References
# References
[1], description - link
[1], description - link
* // remember using / referencing to litteratur for higher grade than 7
