Week 10

In this lab session we will experiment with navigating a differential-driven Express Bot like car while using the tacho counters to keep track of its position and direction.

Duration of activity: 10 hours
Group members participating: Ole Rasmussen, Kasper Føns

Goal

To complete the exercises for Lego Lab 9.

Plan

Since our goal is to complete the exercises for this weeks lab the plan will be to complete each exercise in sequence:

1. Blightbot
   Investigate the accuracy of a Lego car inspired by Brian Bagnall's Blightbot [1] navigating in a Cartesian coordinate system.
2. Avoiding objects while navigating
   Experiment with navigating the Lego car with the leJOS classes while avoiding obstacles.
3. Improved navigation
   Experiment with different navigation methods.

1. Blightbot

In this section we will measure how accurately our Lego car drives with the navigator class in leJOS. We will be performing two experiments: accuracy of general navigation and comparing accuracy of driving straight and rotating.

1.1 Setup

The setup for both experiments consists of the following parts: the Lego car, a whiteboard and a whiteboard marker. The car will be driving on the whiteboard with the whiteboard marker.

The car we have used for the experiment is a slightly modified version of the Express Bot (the modifications are just a result of it's usage for the Sumo competition and thus of no relevance to this experiment).

To measure the accuracy of the cars navigation we have attached a marker to the back of the car by using an elastic cord (figure 1 & 2). The car will be performing several navigational runs on a whiteboard.

Figure 1: The marker is attached to the back and is used as the "back-wheel" for the car. This way the car will partly be resting on the marker, pressing it downwards towards the whiteboard (see figure 2).

Figure 2: The marker touching the whiteboard.

The source code for the program used to generally navigate the car can be seen in figure 3.

Figure 3: Source code for a test program using the Navigator and DifferentialPilot classes.
Notice that we have shortened the path by a factor of 2 to stay within the bounds of the whiteboard.
Original code was borrowed from here.

1.2 Influencing factors

We believe the following to be factors that could influence the experiment:

• Initial placement of the car
  For subsequent runs the car must be placed on the exact same position facing the exact same direction.
• Position of whiteboard marker
  The position of the whiteboard marker may influence where on the whiteboard is drawn compared to the base of the car. It may also influence the thickness of the drawings. 

1.3 Experiment 1: comparing accuracy of several navigation runs

Figure 4 and 5 shows the Lego car performing two navigational runs.

Figure 4 - First run with our code from Figure 3.

Figure 5 - Second run with our code from Figure 3.

Figure 6 shows the result of the two runs.

Figure 6: Two subsequent runs of the Lego car with the same navigation program. The green dot marks the starting point while the two red dots mark the ending points. The blue circle is a circle with radius 4.5cm interpolated from the starting point as center and ending points a points on the circumfence.

As can bee seen on figure 6 the two runs aren't exactly matching but what's interesting is that they seem to be displacements of each other. It is important to mention that it was relatively easy to place the car on the same starting point each run but it was much harder to ensure the initial directions were the same as well. This was not unexpected though, as we mentioned it to be an influencing factor in section 1.2. From the figure it looks like the displacement could very well be due to initial differences in direction, as the runs differ already from the start on the first straight line. Had we placed the facing the exact same directions we may have had two almost exact matching runs apart from the ending point.

The ending points are interesting because they both seem to be offset from the starting position by a certain amount. The evidence for this is that the ending point closest to the starting point is the ending point for the run that goes a bit more upwards in the beginning; thus turning the direction upwards (or left depending on how you view it) displaces the ending point upwards (and out) as well. In other words it seems like the initial direction of the car determines an ending point on a circle that's surrounding the starting point. We have measured the radius of this circle to be 4.5cm based on the distance to either of the ending points for the two runs. Basically this means that had the initial directions of the car been the exact same the two ending points may have been also the exact same (almost). We are not sure what causes this offsetting anomaly but in the next experiment we will investigate Brian Bagnall observations that rotating (not driving straight) is the hard part that may be the most likely cause.

1.4 Experiment 2: Accuracy of driving straight. vs rotating

Here we will test both straight line and rotation accuracy.

1.4.1 Straight line accuracy

First we will test if we can drive straight and check that the distance driven matches the real world. The setup is a whiteboard with two parallel lines 120cm apart. We want to test if the robot can drive the 120 centimeters to hit the other line. Figure 7 shows the setup. Figure 8 shows the source code. 

Figure 7 - Test setup. Two lines parallel lines 120cm apart.
We will test if the robot will travel from one side to the other.

Figure 8 - Forward test source code. Same wheel diamater and trackWidth as in Figure 4.
The navigator is told to move 120cm forward.

We then placed the robot on the left side and started it. We did this multiple times. Figure 9 shows the overall result while Figure 10 shows the stopping positions in closeup. 

Figure 9 - The robot started from the left and moved towards the right side.
It was told to travel 120cm, but as can be seen, it did not go that far and stopped a bit short of the goal.

Figure 10 - Even though the runs don't actually hit the 120cm line, they are very consistent.
This means that the robot will travel the same distance, even though it might be a bit too short compared to the real world.

We can see that the robot does not travel the full 120cm, but it is very close (1,5 - 2,0cm off). The runs are very consistent, all traveling the approximately the same distance. We believe the distances are precisely the same, but because of small errors in the start direction and start position they end up with different distances to the black finish line.

From this we can conclude that straight-line moving is not what makes our test run in Figure 6 end up in the wrong position. We suspect the rotation accuracy might be the problem and will test this now.

1.4.2 Rotational test

We will test the rotation by telling the navigator to go forward 120cm, and then go back to the starting point. This will then be done 10 times to see if it is precise enough for that.

The source code for the rotating accuracy test can be seen in Figure 11.

Figure 11 - Test code for performing 10 runs going forward and back to start.

The actual test run can be seen in Figure 12.

Figure 12 - Test run with program from Figure 11.
It can be seen that the rotation performed is not precise.

From this we can conclude that the rotation is not precise. We are unsure of why this happens. We suspect that it might be when making fast rotation moves, that the robot does not have enough traction with the surface. We will test this in the next section.

1.4.3 Decreasing acceleration

We modified the program from Figure 11 slightly. We simply called pilot.setAcceleration(1) before giving it to the navigator. The result can be seen in Figure 12.

Figure 12 - Test run with acceleration set to 1. It took forever to complete, but is much more precise.

It can be seen that it runs better, staying closer to the start position, but it is still not perfect. This time we will test if going forward or backwards is the problem, and not the rotation.

1.4.4 Straight line again

In this test we will only go forward for 100cm, then reverse for 100cm. This is done 10 times. The code can be seen in Figure 13, the result can be seen in Figure 14.

Figure 13 - Test code for driving forward and backward. Notice that no navigator is used.

Figure 14 - Result from driving 100cm forward and backward 10 times.
Still not precise.

1.4.5 Accuracy conclusion

As can be seen from all our experiments, it seems that it is not possible to get a very precise run with the robot. Even straight line forward and reverse is not precise. It should therefore be noted, that if one is the build a map, drifiting of coordinates will occour over time.

2. Avoiding objects while navigating

The simplest way to avoid objects is to attach some ultrasonic sensors on top of the robot, and when an object is closer then some threshold, the navigator should be stopped and an avoid behavior should take command. The avoid behavior could use three ultrasonic sensors to make decisions about what way to turn, just like Maja J Mataric [2]. When the avoid behavior does not detect any more objects, the navigator is restarted. We even made a robot design (Figure 15), but then found that we were not to implement a program, just discuss how to avoid objects.

3. Improved navigation

In Enabling Your Robot to Keep Track of its Position [3] it is assumed that all moves are divided into small moves all assumed to be in straight lines. In Foreward Kinematics for the Khepera Robot [4] it is not assumed to move in straight lines. Here we can calculate more precisely where we are if we are moving in an arc.

The question is then if it is possible to upgrade Lejos navigation system to use the more precise mechanisme in [4] to get better locations. After examining Lejos code, it seems they are already using that mechanism. The DifferentialPilot fires move events and these move events describes if the move happened in an arc or in a straight line. An OdemeterPoseProvider is used to update locations and it uses the math described in [4] if an arc move happened and uses the simple math in [3] if the move was a straight move.

Therefore the optimizations of [4]is already implemented in lejos.

References

• [1] Brian Bagnall, Maximum Lego NXT - Building Robots with Java Brains, Chapter 12, Localization, p.297 - p.298.
• [2] Maja J Mataric, Integration of Representation Into Goal-Driven Behavior-Based Robots.
• [3] Java Robotics Tutorials, Enabling Your Robot to Keep Track of its Position.
• [4] Thomas Hellstrom, Foreward Kinematics for the Khepera Robot

Read More

Week 9 - Sumo

In this lab session we will make a Sumo Wrestler.

Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Sørensen

Figure 1 - Sump Wrestler Baby.
Lets see if we can take him out....

Goal

To build a Sumo Wrestling robot and win the competition. Also, learning some behavior driven robot programming.

Plan

We will execute the following in sequence:

1. Create the base sumo wrestling robot from building instructions
2. Compile, test and observe default behavior driving wrestling controller program
3. Examine the source code to determine how it works
4. Explain questions about the source code
5. Add OverturnOpponent behavior

1. Create base Sumo Wrestling robot

In this step we will construct the base sumo wrestling robot. We will build it from the instructions given here. There were no problems constructing the robot. The base robot as constructed can be seen in Figure 2.

Figure 2 - The constructed base sumo wrestling robot.

There is not much more to say to this section. Lets move on and add some behavior to the robot.

2. Sumo Wrestling controller program

In this section we will install a pre-programmed controller program onto the robot. Dependencies for the program is given here. Having installed the robot we took a test run at the wrestling area. We observed that the robot only drove forward for very little time and then stopped to change direction. We adjusted the threshold value inside the AvoidEdge behavior from 45 to 50.

Testing the robot again, we observe that the robot manages to stay inside the wrestling ring, stopping when approaching the edge. If not at the edge, the robot randomly drives forward and turns. Our robot was able to push another standard robot out of the arena - Hurrah!

3. Examine source code

Here we will examine which behaviors exists on how they work.

Examining the source code shows three different behaviors. They each have the ability to disable the behavior listed before it. They are listed below.

1. Drive behavior
2. Turn behavior
3. AvoidEdge behavior

Lets see how they are each triggered:

3.1 Drive behavior

The drive behavior is not triggered by anything, it simply drives forward, and then yields, letting other Threads be scheduled.

3.2 Turn behavior

The turn behavior is triggered every five seconds. It then stops the car, waits for it to stop, and turns it for some milliseconds in the interval [500, 1500].

3.2 AvoidEdge behavior

The AvoidEgde behavior is highest priority behavior. It has the ability to supersede all the other behaviors. It is triggered by a the LightSensor registering a light value above a given threshold.

The behavior is then to drive backwards for one second, turning left for 800msec and then stopping and staying there for 500msec.

3.3 Sum up

The given behaviors will make the robot drive around randomly, but avoiding the edge. The code is nicely structured and it should be easy to extend with new behaviors.

4. Explain questions about the source code

In the lab lesson, three questions are asked. We will try to answer them here.

4.1 Why are threads running in Daemon mode?

The behavior class extends from the Thread class. The constructor inside the Behavior class sets the thread to run in Daemon mode. The question is here, why?

The JDK Javadoc has a good explanation of what a Daemon thread is:

"Marks this thread as either a daemon thread or a user thread. The Java Virtual Machine exits when the only threads running are all daemon threads. 

This method must be invoked before the thread is started."

So if only Damon threads exists in a given Java Runtime, the Runtime will exit. This is used in the SumoBot class, so that when pressing the Exit button, the Main method will return and thereby the only thread running in non-daemon mode has halted, making the program exit.
Had the Behavior threads not been marked as Daemon threads, the program would continue to execute.

4.2 How is the SuppressNode used to suppress access to the motors in the Behavior class?

The suppression mechanism used is a hierarchy where a behavior on level is able to suppress any behavior on levels below it. This hierarchy can be seen in Figure 3.

All behaviors have access to the sensors, but only one behavior have access to the actuators at a given time. Level 1 is able to suppress Level 0, and so on up the levels.

Figure 3 - Layered behaviors

When constructing a behavior using the Behavior class, one can supply a behavior which it is able to suppress. This can be used to create a hierarchy as just described. When a behavior at level N calls the suppress method on the Behavior object, the SupressNode's suppress method is called. This method will increment a counter for the Behavior at level N-1 and call the supress method on that SuppressNode which, in turn, will increment a counter at level N-2 and so on until the bottom is reached. This will make sure that a behavior at Level [0, N-1] have a SuppressNode with a counter value larger than 0.

When a behavior wants to control the actuators, the behavior will first check if the SuppressNode given for it has a counter value at zero, if not, nothing happens.

4.3 Compare the suppression mechanism with Fred Martins' Arbiter

Fred Martins' Arbiter is a central component which registers which behaviors wants to have access to an actuator. The behaviors have a priority, and the behavior with the highest priority will have sole access to the actuator. This acomplishes the exact same thing.

5. Add OverturnOpponent behavior

This section is about adding a behavior to flip over our opponent. We did not believe in the construction of the forlift arm in the hinted building instructions. Lifting heavy robots is not an easy thing.

We wanted to build our own system. Figure 4 shows our construction with our forklift system.

Figure 4 - Custom built forklift system

We added an behavior to supersede all behaviors except the AvoidEdge behavior.

The behavior triggers every four seconds, lifting the forklift, waiting a bit, then taking it down again. See below for a run against another robot in the arena:

Read More

Week 8

In this lab session we will try to make a robot racer that races to the top of a mountain as defined in Lesson7 - Also called the Alishan Train Track.

Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Sørensen

Figure 1: The Alishan Train Track

Goal

To build the fastest robot to complete the Alishan Train Track.

Plan

We will execute the following in sequence:

1. Create a super fast robot using gearing
   Constructing and experimenting with a self-built NXT robot which maximizes speed.
2. Make a control program for the robot
   Here we will create the control program for the robot created in the previous step.

1. Create a super fast robot using gearing

In this step we will construct a fast robot. In a later step, we will make this robot complete the Alishan Train Track.

We decided to develop two distinct robots in paralleled.

1. One which uses two motors and gearing on these to achieve speed. Lets call it Speedy.
2. A second robot, which uses three motors for each wheel with gearing for maximum speed. Lets call it The Rock.

1.1 Speedy

Our speedy robot can be seen on Figure 2. It has a large gearing but only two motors, one for each wheel.

It can drive at very high speeds. The gearing can be seen in Figure 3. Our idea is to make this robot "fly" up the Alishan Train Track and win the competition. As you will see, we did not manage this.

Figure 2 - The Speedy Robot. It would drive in the opposite direction.

Figure 3 - The Speedy gearing

1.2 The Rock

The Rock robot is an experiment where we wanted to use three motors to drive one wheel, which should be massively geared for an even higher speed. It can be seen on Figure 4.

Figure 4 - The Rock. As can be seen, it is massive and consists of two NXT's.
The gearing can be seen in the lower left corner.

 We did not manage to actually make The Rock drive, thereby the name. The power from the motors were too much for the gearing, which always gave in and needed to be repaired. Also, at one point, we erroneously uploaded a program for the Speedy robot to The Rock, which made a pair of the motors turn opposite of each other  This skewed both of the "sticks" which were inserted in the motors. See Figure 5.

Figure 5 - Skewed "stick" - destroyed by the force of The Rock.

2. Make a control program for the robot

Since we only made Speedy actually move, this is the only robot we have tried to implement a controller program.

Our idea was to create a sequential program which did not have any sensors. We only had to get to the top and back once, and have that on video, if we tried this enough times, one of the times should be good enough. This was at least the intuition behind our program.

We measured the distance from the bottom of the track up to the first corner, in the number of tacho counts needed. Our program would then move forward for that amount of tacho counts, make a turn, and then forward for the same amount of tacho counts.

We inserted sleeps between each action (forward, turn, ...) to see how it behaved. This is one of the test runs:

As can be seen, we did not do very well. This is not the best run we have had. We had a run which got to the second turn and fell off the track when going to the top. However, we did not get that taped.

Our robot is very susceptible to changes of the track, the battery level, inconsistencies of motor power and both wheels must drive straight.

We were not able to get it to the top. If we had more time, our next attempt would be to add a light sensor in the front to detect on which side of the line we were, and correct a little bit to stay on track.

Read More