... | ... | @@ -60,12 +60,10 @@ TODO: insert program code |
|
|
|
|
|
### SharedCar and Arbiter
|
|
|
|
|
|
In the provided code, the arbitration suggested by Jones, Flynn, and Seiger [2, pp. 306] is implemented in the classes ***SharedCar*** and ***Arbiter*** in the "reverse order" compared to the code presented by Jones et al.: The Arbiter goes through the list and enters
|
|
|
In the provided code, the arbitration suggested by Jones, Flynn, and Seiger [2, pp. 306] is implemented in the classes ***SharedCar*** and ***Arbiter*** in the "reverse order" compared to the code presented by Jones et al.: The Arbiter goes through the list and for the first ***SharedCar*** whose ***CarCommand*** instance is not null, calls ***CarDriver***'s *perform()* method with the *SharedCar*'s ***CarCommand*** instance and reports the *SharedCar* as the winner. It then breaks the for loop and starts over with the *SharedCar array* from 0, thus always starting from the most competent behaviour layer.
|
|
|
|
|
|
Compare this with the arbiter of Fred Martin, [4, page 214-218].
|
|
|
|
|
|
"reverse order": goes through list and enters loop on the first SharedCar that has a command waiting and then performs the command before breaking the for loop and starting over with the list.
|
|
|
|
|
|
|
|
|
## Conclusion
|
|
|
We managed to stay well within our allocated timeframe, spending only four hours in total on building and performing experiments. We attribute this to the nature of the exercises; this time the focus was mainly on observation and *understanding* the structure and implementation of the behaviour control paradigm, rather than on making something function (such as trying to get the robot to balance on two wheels).
|
... | ... | |