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

Faste læsere