Lesson7.md

@@ -101,8 +101,9 @@ TODO: insert program code
 
 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 behavior layer. The reason that this order is "reverse"; is that in the code presented by Jones et al., the arbiter goes through the behaviors in increasing order of competence, overruling the previous setting of the motor input.
 
-TODO: Compare this with the arbiter of Fred Martin, [2, pp. 214-218].
+Martin's arbiter [3, pp. 214-218] takes a third approach by keeping a list of priorities and a list of enabled/disables statuses (represented by the associated priority value for *enabled* vs. a 0 for *disabled*). Each behavior is in charge of enabling/disabling itself, and a ***prioritize()*** function continuously checks these lists and sets the motor power to values specified by the enabled behavior with the highest priority.
 
+TODO: sig noget mere, eller er det her nok?
 
 ## 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 behavior control paradigm, rather than on making something function (such as trying to get the robot to balance on two wheels).