The theory behind artificial intelligence is inspired from “primitive” animals. The increasing levels of abilities require different amounts of intelligence and are handled in asynchronous modules with additional prioritization. Modules of higher prioritization will suppress modules of lower prioritization. Example: An animal gets interrupted in the eating process because a dangerous situation suddenly occurs. The module of the animal’s brain, which handles danger, will suppress the module, which controls the eating process.
What if an animal is to choose between two identical opportunities?Example: A dog is put between two eating toasts; the eating toasts are exact identical. Because the attractiveness from each eating toasts is the same, the dog will be unable to decide and die of hunger. The modules of intelligence have been developed by thinking of the process of evolution.
Goal
Rodney A. Brooks’ article “A Robust Layered Control System for a Mobile Robot” presents an idea to program animal like creatures based on observations in biological world. The principle of the modules is formed to a description of layers. Each layer consists of sequence functions as presented in Figure 1. Rodney A. Brooks’ article describes the modules running on separate computational machines . Note: The already given java code from lab session 8 makes use of multi threads instead of separate computational machines.
Figure 1: An illustration of the module function sequence
Figure 2 illustrates modules shared into levels that run “concurrent”. A higher level suppresses a lower level and so on. The hierarchic level control offers the possibility for a similar developing process as the biology evolution. The developing process starts from the state of “reptilian brain” as level 0 and then more intelligent parts are added as needs arises. In Lab session 8 the “reptilian brain” level is described as random drive. To avoid a crash an “evolutionary”/developing process leads to the next level. A valuable observation in this developing process is that a layer of highest priority can exclude lower levels by suppressing them infinitely.
Figure 2:An illustration of the hierarchy programming architecture of level control
Sub goals
The Lab session is shared into two exercises.
1. Make an observation of developed multi threaded control handed out by Ole Caprani. The layers is presented in Figure 3.
2. Implement an additional layer to follow a light source (based on lab session 7). The priority of new integrated layer has to be carefully evaluated according to theory from coherent lecture.
Figure 3: Shows how levels are shared out the lowest level starts from the bottom.
Plan
· Build a NXT robot with two light sensors and ultra sonic sensor.
· Analysis the software for lab session 8
· Evaluate the performance of the software for lab session 8
· Extend the abilities of the NXT robot with the software from lab session 7
· Evaluate the performance of the new software
Results
Description of experiment
Software explanations
Why a daemon thread?
The main difference between user threads and daemon threads is that the JVM will only shut down a program when all user threads have terminated. Daemon threads are terminated by the JVM when there are no longer any user threads running, including the main thread of execution. A daemon thread is a thread with no other purpose than to serve other processes.
What is a super class?
In computer science a super class is the mother class form which other classes are derived. The classes that are derived from a super class are known as sub classes. A super class allows for a generic interface to specialized functions through the use of virtual functions. This could be interface to the NXT motors or LCD.
Programming attempts
Two attempts were completed to evaluate the suppress mechanism, where the performance for both is observed and explained in the following subparagraphs.
Basic program observations
The SoundCar program has three different behavior objects implemented;
- RandomDrive – Makes the car drive randomly around.
- AvoidFront – Makes the car trying to avoid obstacles.
- PlaySounds – Plays a sound every 10th seconds.
The software required for the SoundCar to run as intended was loaded into the Lego NXT car (build as described on page 30 in the Lego building instruction booklet) and the behavior of the vehicle was observed;
- The SoundCar starts out by driving randomly around for a while. Every time it detects an obstacle in the way, the car backs off a bit and turns to the left (i.e. the “random driving” is suppressed ).
- Every 10 seconds a short melody line is played. When playing the melody line, the car stands still and waits for the melody to finish (i.e. “random driving” and “avoid obstacles” are suppressed).
- The only external event capable of triggering the car to respond is objects detected by the ultrasonic sensor (which triggers the avoiding behavior).
- In the LCD is simply output, which of the threads are active and which are suppressed.
The three threads RandomDrive, AvoidFront andPlaySounds are “concurrent” with different priorities;
- PlaySounds – highest priority; suppresses AvoidFront and RandomDrive.
- AvoidFront – second highest priority; suppresses RandomDrive.
- RandomDrive – lowest priority; suppresses nothing.
Thread triggering conditions;
- PlaySounds is triggered ever time a 10.000mS delay has elapsed.
- AvoidFront is triggered by an external event (an obstacle) has been detected.
- RandomDrive is triggered/running all the time if not suppressed by another thread.
Extended program observations
The basic program was extended with the Braitenburg behavior from lab session 7. The approach was simply to evaluate the complexity of the Braitenburg class and compare it with the abilities from the basic program.
Random drive is the most primitive because it is interpreted as careless wandering with no purpose.
To avoid an object in front of the robot can be interpreted as “avoid danger”. The light following ability is then interpreted as ability to find food. The ability is prioritized above the careless wandering but beneath the ability to avoid danger.
rd = new RandomDrive("Drive",1, null);
bb = new Braitenberg("Search light",2,rd);
af = new AvoidFront ("Avoid",3,bb);
ps = new PlaySounds ("Play ",4,af);
When the light following ability was added the random drive was constantly suppressed because “food” / light always are present (graphical presentation in Figure 4).
Figure 4: Shows how levels are shared out the lowest level starts from the bottom.
This could be accepted as natural consequence or the code could be changed, so both abilities are executed at some time.
One method is to run the light following class X times and then make the class unusable for some time.
public Braitenberg(String name, int LCDrow, Behavior b) {
………
public void run(){
while (rumtimes <>
{ ………
……
An alternative solution could be to evaluate the light conditions. If the general light amount is too low, then do not search for it. Analogy: is there is very little food present do not bother to find.
public Braitenberg(String name, int LCDrow, Behavior b) {
………
public void run(){
while ((ls1.getNormalizedLightValue() >thresholdLight ||ls2.getNormalizedLightValue() >thresholdLight))
{ ……………
Pictures of Lego model
Figure 5 - Picture of robot
Conclusion
If the structure becomes too complex, the suppress pattern might need more inputs, than just a predefined prioritized action model. This is because a basic ability might always be suppressed this primitive behavior. This could be intentionally as a consequence of evolution or unwanted because the robot then is unable to fulfill a specific task. A human being can no longer breath under water because of evolution has made it meaningless.
References
Ref 1 A robust layered control system for a mobile robot, IEEE Journal of Robotics and Automation, RA-2(1), p. 0
Ref2 A robust layered control system for a mobile robot, IEEE Journal of Robotics and Automation, RA-2(1), p. 1
