... | ... | @@ -60,6 +60,10 @@ If the touch sensor is pressed, the takeControl() method returns a value of 100 |
|
|
##### Fig. 3: takeControl() method. Shows how different values are returned according to sensor values and if the methods is ‘active’.
|
|
|
>
|
|
|
|
|
|
The Arbitrator class constantly determines priority on the different behaviors (see fig. 4 below). It looks through an array of behaviors and invokes the takeControl() method on the current behavior. This method returns an integer value. This value is compared to the maxPriority value and if it is greater it will replace the current value:
|
|
|
>
|
|
|
|
|
|
|
|
|
```
|
|
|
// Find behavior with highest priority
|
|
|
maxPriority = -1; highest = -1;
|
... | ... | @@ -121,4 +125,19 @@ Our implementation was based on the classes from the previous task with the inte |
|
|
2. Each behavior has a fixed priority.
|
|
|
3. Each behavior can determine if it should take control.
|
|
|
4. The active behavior has higher priority than any other behavior that should take control.”
|
|
|
This meant that we also implemented the takeControl(), action() and suppress() methods in each behaviour class to keep a structure to the behaviours. takeControl() determines when each behaviour is supposed to take over, action() determines what the behaviour should do, and suppress() terminates the code running in the action() of the behaviour. |
|
|
\ No newline at end of file |
|
|
|
|
|
This meant that we also implemented the takeControl(), action() and suppress() methods in each behaviour class to keep a structure to the behaviours. takeControl() determines when each behaviour is supposed to take over, action() determines what the behaviour should do, and suppress() terminates the code running in the action() of the behaviour.
|
|
|
|
|
|
### Plan
|
|
|
We intend to program a behaviour pattern with three behaviours. The default behaviour with the lowest priority, we called lookForTarget, and wanted it to look for the opposing robot.
|
|
|
The behaviour that was to have the second highest priority we called charge, and was supposed to get the robot to drive straight at the opposing robot (or any object, really) when detected by the ultrasonic sensors.
|
|
|
The third behaviour, that was supposed to have the highest priority, we called survive, and was all about keeping the robot within the white circle of the wrestling arena.
|
|
|
Construction wise we had to build upon on the express-bot robot base, but added a large pushing surface to get better contact with an opponent, as seen in fig. 7.
|
|
|
|
|
|
![sumo-bot](http://gitlab.au.dk/uploads/group-22/lego/fc06bfdf24/sumo-bot.jpg)
|
|
|
##### Fig. 7: The Sumo wrestling robot, with ram, two ultrasonic sensors and a light sensor.
|
|
|
|
|
|
### Result
|
|
|
#### Behavior 1
|
|
|
|
|
|
The look for target behaviour as located in the LookForTarget Class, is a simple constant rotation in place where the robot is placed when the match begins. Motor A is the left motor and motor B is the right motor from the robot's point of view. This will mean that when looking for a target, the robot will always turn to the right. A video of the behavior in action can be seen in fig/video ???.(Indsæt link til video) |
|
|
\ No newline at end of file |