Blog moved

The blog for the exam project has been moved to http://teamnxtgen.blogspot.dk/

Date: 6/5 - 2014
Duration of activity: 5
Group members participating: Alexander Rasmussen, Søren Ditlev

---

Goal:

To experiment with localization and navigation using differential driven car.

Plan:

According to Brian Bagnall[] we plan  to construct a car that navigates using cartesian coordinates and the NXT tacho counter.  Attaching marker in font base of the car would make the cars route visible and thus make it easy examine and compare different routs, this process is described by Toto[] .

Picture of Car. Here you see how measurement of the track width and the attachment of the marker.  

  

Results:

Brian Bagnall Experiment

In this session we will apply the tacho counter of the NXT motor to keep track of the position and direction of a LEGO car with differential drive where two motors are used independently to move and steer the car. The  software for controlling the car will be implemented in accordance with the guide on Controlling Wheeled Vehicles[]

public class NavBot {

DifferentialPilot difPilot = new DifferentialPilot(5.5f, 17.5f, Motor.C, Motor.B);

Navigator navigator = new Navigator(difPilot);

public static void main(String[] args){

Button.waitForAnyPress();

NavBot navBot = new NavBot();

navBot.go();

}

int size = 5;

public void go(){

//Brian Bagnalls route run 3 times

for (int i = 0; i < 3; i++) {

navigator.goTo(200/size, 0);

navigator.waitForStop();

navigator.goTo(100/size, 100/size);

navigator.waitForStop();

navigator.goTo(100/size, -50/size);

navigator.waitForStop();

navigator.goTo(0, 0);

}

}

First test we did, were without any initial measuring of the car instead we used the track width and wheel diameter that were used by Brian Bagnall. For every test we did the path was repeated 3 times, to get a better idea of the inaccuracy that the system might had.

Picture of the initial run:

After the first run we calibrated the system by using measurements that we measured on the car and tried to run the system again. This resulted in the car turning in too little an angle an the car driving of the course. The fact that the actual measurements didn’t make the turning curve more precise was a bit unexpected. In the first run we had a track width of 16 but the measured width was actually 14, so the fact that we decreased the width made the car more inaccurate. Therefore we instead increased the track width slowly, and found it to be best 17.5cm. We also experimented with the wheel diameter how that would affect the accuracy of the car. We found that if you increase the wheel diameter the car will turn more sharply whereas decreasing would have  the reverse effect. The most accurate wheel diameter seemed to be around 5.6 cm which is also actual diameter of the wheel.   

Run width track width 17.5:

and Wheel diameter of 5.6

The fact that we were not able to get a more accurate run may be do to poor calibration or that the car slipped on the maybe too smooth surface on the whiteboard that we used for testing.

Distance vs. Turning

To investigate Brian Bagnalls claim that the blighbot does a good job measuring distances, but lacks accuracy when turning. We measured the lines of one of the runs, and found that at the lines were almost completely the same length, only vary a centimeter or two per run, this supports Bagnalls claim. The lack of turning accuracy may be due to poor calibration from our side, as mentioned above the car performed better with a track width longer than what we measured, and therefore it is hard to figure out what calibration will suit the system best.

Picture of measurement of distances:

Avoiding obstacles

We didn’t get to implement this solution into our system, but a way it could have been done is to use a ultrasonic sensor to detect any obstacle on the route. If an obstacle is detected the car will try to avoid it by eg. backing up, turning and try to go around, the tachocounter or navigator class should be able to still figure out the locations of the car and return to its route after avoiding the obstacle.

For this approach to work properly, the system must have a very good calibration otherwise it won't be able to figure out its position and may not find its way back to its original path after avoiding an obstacle.

Improved Navigation

We did not have time to do this part of the assignment.

Conclusion:

We were able to redo Brian Bagnalls test to see how the tacchocunter works and what weaknesses it may have.

Date: 05/05 
Duration of activity: 4 Hrs
Group members participating: Alexander Rasmussen Søren Ditlev

---

BumperCar

Goal:

To investigate the behavior based architecture[1] implemented in the subsumption API of Lejos.

Plan:

In order to investigate the behavior based architecture we will build the Bumper car[2] and implement the Bumper car software[1]. This allows us to experiment with the behaviors “drive forward” and “detect wall”. We plan to do the following experiments to get in depth understanding of how the behavior architectures works.

1. Press the touch sensor and keep it pressed. What happends ? Explain.
2. 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. Try to press ESCAPE both when DriveForward is active and when DetectWall is active. Is the Exit behavior activated immediately ?
3. Both DriveForward and DetectWall have a method takeControl that are called in the Arbitrator. Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called when the triggering condition of DetectWall is true.
4. The takeControl method of DetectWall contains a call to the ultrasonic sensor method getDistance that includes a delay. This means that the call of takeControl for the other behaviors is delayed and the reaction to an event is not immidiate. In it is recommende that takeControl "should return quickly, not perform a long calculation." To avoid the pause in the takeControl method of DetectWall a local thread in DetectWall could be implemented that sample the ultrasonic sensor e.g. every 20 msec and stores the result in a variable distance accessible to takeControl. Try that.
5. For some behaviors the triggering condition depends on sensors sampled with a constant sample interval. E.g. a behavior that remembers sensor readings or sum a running average. Therefore, it might be a good idea to have a local thread to do the continous sampling.
6. Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.
7. Try to implement the behavior DetectWall so it can be interrupted and started again e.g. if the touch sensor is pressed again while turning.

   

Results:

1. The System drives backwards and turns a little then waits to see if sensor is still touched, if not drives forward, if it is still touched repeats behavior.
2. To implement the exit behavior we copied what we could see from the detectWall class and modified what was needed. In order for the system to exit we had to add a suppress implementation to the detectWall since it no longer was top priority.

Code snippet of Exit implementation:

class Exit implements Behavior

{

private boolean _suppressed = false;

@Override

public boolean takeControl() {

return Button.ESCAPE.isDown();

}

@Override

public void action() {

System.exit(0);

}

@Override

public void suppress() {

_suppressed = true;

}

}
When the system is in “Drive forward” behaviour it exits immediately. However when the system runs the “Detect wall” behaviour the system does not exit, unless the escape button is pressed at the exact moment after the detec wall session has ended and before new one have started.

3. The way the arbitrator works is by cycling through the behavior list with the highest priority first, for each behavior it calls the method takeControll() which returns a boolean. If the behavior returns true it will run the action if false, the lower prioritized behavior will be called.
4. To implement a faster sonar response, we used the method proposed in the assignment. We implemented a new thread that read the sonar response and then updated a variable which the action method then could access if needed.

Code snippet:

Thread thread = new Thread() {

public void run(){

while(true){

sonarValue = sonar.getDistance();

}

}

};

thread.start();

5. The referred problem was addressed during the implementation in regards to question 4, since we already here made the local thread in which variables are stored.  
6. To implement a 1 sec backward drive before before doing a turn was done by making a while loop that would run for a sec and yield the thread, as long as the behavior isn’t  suppressed.

Code snippet:

BumperCar.leftMotor.backward();

BumperCar.rightMotor.backward();

while(System.currentTimeMillis() - timeVal < 1000 && !_suppressed){

Thread.yield();

}

7. We have tried to implement a quick interruption of the detectWall behavior but for all the different implementation that we tried, a slight delay would still occur.

Video of system with all implementations[3]

Motivation Functions

To implement the motivation functions we used the arbitrator and behavior classes given by Ole Caprani, and then modified the takeControl functions to return an integer instead of a boolean so that it would fit the arbitrators needs. The return values of the different classes were, ordered so that the behaviors with the least priority would output the smallest value.

Conclusion:

We are able to make the system function as desired though all seven exercises. Since the we did not have time to perform do these exercises on Thursday the 01/05  we were not able to partake in the sumo wrestling contest, and therefore made no further alterations to out system that would have possible to compete in the contest.   

References

[1] http://www.lejos.org/nxt/nxj/tutorial/Behaviors/BehaviorProgramming.htm

[2] http://www.nxtprograms.com/9797/express-bot/index.html

[3] https://www.youtube.com/watch?v=LOR8xUICLY4

[3]

Date:  10/4 - 2014 & 14/4 - 2014Duration of activity: 2 x 7 hours
Group members participating:  Alexander Rasmussen, Søren Gregersen, Søren Ditlev

---

Robot Race

Goal  

To build a robot that can complete the Alishan train track in the fastest possible time.

Plan

We plan to use 2 light sensors to follow the black line on the Alishan track, these two sensors should make it possible to follow and discover the black line.

First off we will make a simple implementation of a line follower[1], and then expand it to use 2 sensors. When we get that working we will try to implement a pid controller and see how that works. Once the system is able to drive following a line we plan to implement tacho counters to keep track of when the system should turn left, right and 180. This should be done concurrently so that the tacho counter will overrule the the line follower. Once the system is turned  the system should be able to relocate and follow the the line again. Finally a color sensor mounted in front of the system will be able to detect the green field and make the system stop.

Results

We managed to get the simple line follower working with two sensors, however it was really slow and made a lot of oscillations, this was due to the simple implementation of the line follower that we used. So in an attempt to avoid these oscillations, we tried to implement the PID controller, by making the car move forward if both light sensors detected white surface, and then adjust when one of the sensors reached the line. This did not work out as we had planned since the system still oscillated a lot and was very slow.

The approach with two light sensors accompanying each other, might not be the best way to implement a line follower, it looks like they will always be trying to move the car towards each other and therefore the two pid’s would works against each other making the system highly likely to start oscillating.
A better approach might be to just use a color sensor for the line following part since we need it for stopping in the goal zone anyway and we know from previous lessons that it can move fairly fast[2].

Result = ∞ infinity

Conclusion

We tried to make a pid line follower with 2 light sensors, but the  systems oscillated a lot and was very slow. We used a lot of effort to try and correct the PID line follower, but we could not seem to get it work satisfactory. The problem we kept coming back to had to do with implementation of two light sensors. The PID counter for each of the sensors affected the other sensor forcing the system to turn constantly. Since we are able to solve this problem we did not not move on to solve the next problem, making the car turn at the correct places on the Alistar train track and thus did not complete the the track.        

References

[1] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson1.dir/LineFollower.java

[2] Video of a fast PID LineFollower: ]http://www.youtube.com/watch?