mandag den 21. december 2009

Project - Lab session 2

Work time: 11122009 – 21122009, approximated 3x6 hours + homework

Attendees: Jesper Jakobsen, Mads Hansen Lund and Michael Nygaard Pedersen

http://drop.io/legocarsten/blog

and

http://drop.io/legocarsten/media/movie

torsdag den 10. december 2009

Project - Lab session 1

Work time: 03132009 – 10122009, approximated 3x6 hours + homework

Attendees: Jesper Jakobsen, Mads Hansen Lund and Michael Nygaard Pedersen

http://drop.io/legocarsten/blog


torsdag den 3. december 2009

Selection of project

Attendees: Jesper Jakobsen, Mads Hansen Lund and Michael Nygaard Pedersen
Work time: 9.15 - 14.05, 27/12-09 og 9.15 - 11.00 03/12-09

fredag den 20. november 2009

Lab Session 10

Attendees: Jesper Jakobsen, Mads Hansen Lund and Michael Nygaard Pedersen

Work time: 9.15 - 14.05

Goal

The goal is to investigate the subsumption interface implemented by LeJOS.

Plan

The sumsumption API implements an arbitrator class, which controls which behavior should become active in a behavior control system. The plan for investigation is written beneath.

· Build a differential driven robot with a touch sensor in the front.

· Implement a behavior based architecture with two behaviors using the behavior API implemented by LeJOS. The Behavior API is very simple, and is composed of only one interface and one class.

· Implement a third behavior using the behavior API.

· Investigate the usage of motivation functions and the need for multithread programming.

Results

Description of experiment

Two behaviors

The NXT robot (BumperCar) was programmed to include two behaviours; DriveForward and HitWall.

When started, the BumperCar drives straight ahead until it hits an obstacle which activates the touch-sensor placed in front of the car, making the car drive backwards for approximately 1 second followed by a 300ms turn. Hereinafter the car starts driving forward again.

A variety of different experiments were performed on the BumperCar with these two behaviors implemented.

Press the touch sensor and keep it pressed. What happens?

The car continues to execute the action() defined in the HitWall thread (i.e. the car drives backwards for approximately 1 second and then turns for approximately 300mS, followed by another backwards drive ...etc.) The actions to perform in the HitWall thread are shown below.

public void action() {

// Back up:

Motor.A.backward();

Motor.C.backward();

try{Thread.sleep(1000);}catch(Exception e) {}

// Rotate by causing only one wheel to stop:

Motor.A.stop();

try{Thread.sleep(300);}catch(Exception e) {}

Motor.C.stop();

}

Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called when the triggering condition of HitWall is true.

When the HitWall condition is triggered (true), the Arbitrator only calls takeControl() methods of behaviours of higher priority than HitWall, which at the moment does not exist. So takeControl() of DriveForward is not called.

Three behaviors

Implement a third behavior, Exit. This behavior should react to the ESCAPE button and call System.Exit(0) if ESCAPE is pressed. Exit should be the highest priority behavior.

The exit behavior class is shown below.

public class escapeFunc implements Behavior {

public boolean takeControl() {

return Button.ESCAPE.isPressed();

}

public void suppress() {}

public void action() {

System.exit(0);

}

}

The suppress method is empty since the exit behavior is of highest priority, which is declared in the BumperCar class shown below.

public class BumperCar {

public static void main(String [] args) {

Behavior b1 = new escapeFunc();

Behavior b2 = new DriveForward();

Behavior b3 = new HitWall();

Behavior [] bArray = {b2, b3, b1};

Arbitrator arby = new Arbitrator(bArray);

arby.start();

}

}

Three instances of Behavior are created (b1, b2 and b3). These are placed in an array, with the lowest priority behavior taking the lowest array index. Next, the Arbitrator object is instantiated and the arbitration process is started.

Try to press ESCAPE both when DriveForward is active and when HitWall is active. Is the Exit behaviour activated immediately?

When pressing the ESCAPE button while DriveForward is active, the robot application is terminated immediately. But when pressing the ESCAPE button while HitWall is active, the robot does not respond because of the thread.sleep() methods used in the action() method of HitWall (Videos is found under Observations).

Multi threaded programming

If the robot should handle yet another behavior, which implements the ultra sonic sensor more than one thread should be used in order to ensure a certain sample frequency. This approach was not implemented, but is tried briefly explained. The class HitWall is changed beneath to illustrate the idea.

import lejos.robotics.subsumption.* ;

import lejos.nxt.*;

public class HitWall implements Behavior {

public TouchSensor touch = new TouchSensor(SensorPort.S2);

public boolean takeControl() {

return touch.isPressed() || ultraSonicDistance <>

}

public void suppress() {

Motor.A.stop();

Motor.C.stop();

}

public void action() {

// Back up:

Motor.A.backward();

Motor.C.backward();

try{Thread.sleep(1000);}catch(Exception e) {}

// Rotate by causing only one wheel to stop:

Motor.A.stop();

try{Thread.sleep(300);}catch(Exception e) {}

Motor.C.stop();

}

}

The HitWall class will now perform a redundant check, if the variable ultrasonicDistance is updated in its own thread every 20th millisecond.

If the blocking mechanism (observed and explained in the previous subparagraph) should be removed another type of motor control should be used. By studying the LeJOS API the function underneath was found.

void

rotate(int angle, boolean immediateReturn)
causes motor to rotate through angle;
if immediateReturn is true, method returns immediately and the motor stops by itself
If any motor method is called before the limit is reached, the rotation is canceled. (Ref2)

This function can be interrupted if another motor method is called, this means that the suppress mechanism must include a motor method in order to stop the active behavior and continue with the behavior with a higher priority if suddenly activated.

Motivation functions

The motivation based behavior selection in agents theory is an extension of the artificial intelligence theory which has been described in lab session 8 and 9. In lab session 8 and 9 the prioritization of the layers was predefined and static. The motivation based behavior selection in agents’ theory handles the layers’ prioritization adaptive with a motivation agent.

The motivation factor can be described from a cheetah’s eating -, hunting - and sleeping behavior. The eating motivation is depending on the energy level, the hunting motivation is depending if there occur prey and the motivation for resting depending on the time. The motivation is dynamical depending on the cheetah needs illustrated from Figure 1.

Figure 1 illustrates that motivation level for the “layers” is dynamic, which leads to different prioritizing of the layers depending on the time. The priority depends on the motivation functions, which differs during the 24 hours. Note that the time axis is modified to have equal length in order to compare the functions properly.










Figure 1: Modified figure from Motivation Networks - A Biological Model for Autonomous Agent Control. The figure illustrates how the prioritization level is shuffling from the motivation factor.

Observations

Pictures of Lego model












Figure 1 - Picture of robot

Conclusion

The subsumption architecture was implemented with a great deal of success. The LeJOS arbitrator API implements usefull subsumption architecture, but it is implemented in a single thread and therefore there is no guarantee that a behavior can be executed at any time.

References

Ref1: ThiemoKrink, Motivation Networks - A Biological Model for Autonomous Agent Control., p.2

Ref2: http://lejos.sourceforge.net/p_technologies/nxt/nxj/api/lejos/nxt/Motor.html



fredag den 13. november 2009

Lab Session 9


13112009

Attendees: Jesper Jakobsen, Mads Hansen Lund and Michael Nygaard Pedersen

Work time: 9.15 - 13.35

Goal

The goal is to investigate different types of navigation e.g. tacho counter and a digital compass.

The robot construction is based on “Maximum Lego NXTBuilding Robots with Java Brains” Ref1 to get a horizontal placement of the NXT. The horizontal placement of the NXT is done to satisfy a horizontal placement of the compass sensor. The specific requirements from “HiTechnic’s Compass Sensor manual” will be satisfied (see the requirements below).

The specific requirements from HiTechnic’s Compass Sensor Manual:

· The compass has to be placed at least 10 cm from the NXT.

· The compass has to be placed at least 15 cm from the motors.

· Calibration for the compass.

o Turn at least 360 degrees.

o The circular spin should not be done too fast (use at least 2 seconds for a rotation)

Sub goals

The NXT robot should be able to navigate in a Cartesian coordinate system and reproduce the same movement several times. There is several physical aspects to take in account, because the simple navigator refers to physical size, which might vary as a function of the robot weight and construction quality.

Plan

· Implement a simple navigator based on readings from the tacho counters, which is placed in a standard NXT motor

· Investigate the possibilities to implement an ultra sonic sensor to avoid collision during a navigation sequence.

· Implement and test the compass functionality by implementing the compass class and compare the performance with the simple tacho navigator.

Results

Description of experiment

Four different investigations where preformed during this lab session.

Tacho counter navigation

A differential driven NXT robot was build with respect to the building instructions given on page 293 to 296 in Ref2 with a board marker mounted to gather information on the movements of the robot.

Using the SimpleNavigator class of lejos.robotics.navigation, the robot was programmed to follow the pattern shown below;

robot.goTo(50,0);

robot.goTo(25,25);

robot.goTo(25,-12.5f);

robot.goTo(0,0);

This pattern was repeated six times to investigate the accuracy of the goTo method of the SimpleNavigator class (i.e. does the robot return to its starting position?).

The results are presented in the picture below;










Figure 1 - Tacho navigator pattern

Clearly, the robot does not return to its original position. Each repetition of the pattern is shifted approximately 10 degrees with respect to the previous run through. The distances driven are the same, but the robot seems to loose track of its position when doing turns, i.e. the robot does not rotate as much in reality as it “thinks” it does, which then gives rice to the 10 degree (±2) shifting in track orientation.

This 10 degree shifting was attempted minimized by changing the value (in software) of the wheel diameter as well as the value of the track width. Unfortunately no radical improvement was observed. The surface also changed the result.

Tacho counter combined collision detection (investigation)

The tacho counter functionality can be thought of as the most primitive layer in a behavior model, if the purpose of the system is to navigate without any caretaking to surroundings. A simple two layer suppression strategy can be added, if the robot should be able to avoid collision (Figure 2).




Figure 2 - Suppression strategy

When the navigation drive is suppressed it must begin calculating how the route changes and continue to log coordinates so it can drive to the preferred set point (if possible).

The center of the circular movement can be calculated by the equation beneath.



The speed can be calculated by the following differential equation (presented in matrix form) and a numerical integrator can then approximate the new x and y coordinates (Ref8).



This approach has not been fully implemented because of the limited time.

Digital compass calibration

The earth differs in its magnetic field depending on the placement. The compass sensor has to be calibrated to compensate for local magnetic field. A recalibration is only needed when the robot is tested on a new localization. The manual and “Maximum Lego NXTBuilding Robots with Java Brains” does not mention a specific requirement for the how much the localization has to differ for a needed recalibration.

The calibration code is more or less copied from “Maximum Lego NXTBuilding Robots with Java Brains” with small modified correction for the leJos version 0.85.

The test run of calibration was not succeeded since the software didn’t stop after its predefined rotation and instead run into an unlimited loop.

Modification from “Maximum Lego NXTBuilding Robots with Java Brains” to leJos version 0.85:

Added

import lejos.nxt.addon.*;

Chanced from import lejos.navigation.*; to import lejos.robotics.navigation.*;

Added cmps as a extra parameter
CompassPilot hector = new CompassPilot(cmps, 5.6F, 16.0F, Motor.B, Motor.C, true);

Handheld compass

The handheld compass code is more or less copied from “Maximum Lego NXTBuilding Robots with Java Brains” with small modified correction for the leJos version 0.85.

The test run of the handheld compass code showed that the compass sensor is very sensitive to Electromagnetic emission. It can be concluded that robot does not have the optimized environment to succeed with the today’s lab session.

Modification from “Maximum Lego NXTBuilding Robots with Java Brains” to leJos version 0.85:

Added

import lejos.nxt.addon.*;

Digital compass navigation

The compass navigation code is more or less copied from “Maximum Lego NXTBuilding Robots with Java Brains” with small modified correction for the leJos version 0.85.

The test run of the compass navigation didn’t succeed; this was already expected from the handheld test run.

Modification from “Maximum Lego NXTBuilding Robots with Java Brains” to leJos version 0.85:

Chanced from SimpleNavigator robot = new CompassNavigator(pilot);

To SimpleNavigator robot = new SimpleNavigator(pilot);

Pictures of Lego model











Figure 3 - Picture of robot

Observations

Problems encountered

Mentioned in the chapters: Digital compass calibration and Digital compass navigation and observed (see videos)

Conclusion

The conclusion can be made by just observing the uploaded videos. The simple navigator worked “ok”, but was not very precise. A performance optimization was not obtained by including the compass functionality, because of either missing calibration or electromagnetic emission.

References

Ref1: Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.292 - p.296

Ref 2: Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.285 - p.302

Ref 3: Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.300

Ref 4: Recorded video of the test run Compass Calibration.

Ref 5: Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.301

Ref 6: Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.302

Ref 7: Recorded video of the test run Compass Navigation.

Ref 8: Forward Kinematics for the Khepera Robot - Thomas Hellström

lørdag den 7. november 2009

Lab Session 8

Attendees: Jesper Jakobsen, Mads Hansen Lund and Michael Nygaard Pedersen
Work time: 9.15 - 13.35

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

Ref3 A robust layered control system for a mobile robot, IEEE Journal of Robotics and Automation, RA-2(1), p. 7

Faste læsere