Todays goals:

Are as described in the lesson 9 exercises notes:

  • Exercise 1 – Prepare Max for navigation
  • Exercise 2 – Testing the Differential controller
  • Exercise 3 – Navigating the Cartesian coordinate system
  • Exercise 4 – Navigation while avoiding objects
  • Exercise 5 – Improved Navigation

Additional “Optional” Goals

  • Make whiteboard marker rig

The Plan

Because of the thorough guide described in the lesson 9 exercises notes, no further planning was necessary.

Then we did the exercises as explained.

Exercise 1 – Prepare Max for navigation


In this exercise we will build Max and prepare him for navigating. We will construct him as an Express Bot (which we also used back in Lesson 6), and in that was prepare him as described in the lesson 9 plan.


None needed


None needed


We have constructed Max

Exercise 2 – Testing the Differential controller


This exercise aims to try out some of the tutorials from the leJOS site, found here. By doing this, we hope to gain knowledge of how the differential controller works on how to determine the correct parameters.


The first experiment: In this test we use the tutorial for drawing a square, which can be found here. We measure the distance from the middle of each tyre (as we believe this is where it touches the ground), and use this as one of the parameters of the differential controller. The other parameter needed for the controller can be found printed on the tyres. The tyres state their diameter are 5.6cm, and the distance between the two wheels are 17 cm.

Determination of wheel size: As an alternative to measuring the wheel diameter we will make a program so that we can calculate the wheel diameter by the distance traveled.

Determination of track width: As an alternative to measuring the track width we will make a new program so that we can calculate the track width by the degrees turned.

Rebuild Max: Seeing as finding the actual wheel diameter and track width did not solve the inaccuracy of Max’ behaviour, it meant that something else was the cause. We believe that the tyres used on Max are curved, so we are not sure from where we should measure the distance between the wheels. Also, having just taped on the marker could cause friction between the marker and the table, causing inaccuracies. This caused us to rebuild Max by changing wheels to more solid wheels, and also adding a new Marker holder and new track to drive on.


The first experiment: We used the code provided for drawing a square (here). The only things we changed were the parameters for the differential controller:

sq.pilot = new DifferentialPilot(2.25f, 5.5f, Motor.A, Motor.C);


sq.pilot = new DifferentialPilot(5.6f, 17.0f, Motor.A, Motor.C);


The first experiment: We made Max run the code provided first without a marker, to see how the code performed. We put Max on a whiteboard (as seen in this video), and attached a marker to his front, to see how he actually performed.

The angle is off slightly Figure 1: The angle is off slightly

As seen in figure 1, Max’ end angle was not exact to the one in the beginning. We argue that the lack of precision here can be caused by the following:

  • The marker was not attached rigidly to Max’ frame.
  • The tyres could be skidding on the surface.
  • The parameters set for the differential controller were not exact.
  • Some backlash in the motors could affect the tacho counters.

The length Max moved forward is also not exact to the desired outcome from the code. Instead of driving 20cm before turning, Max only drives 19,5cm. One particular reason is the measures size of the tires and the tires actual size. By being 0,5cm from the intended length, the measured diameter of the wheels is larger than the wheels actual diameter.

Determination of wheel size: Seeing as the actual distance that Max traveled was a little off, we used a little basic math to determine what diameter the wheels actually were. All of this relates to circumference of Max’ wheels which determine how far he travels per rotation.

So to completely understand this, we do some slightly more complex math shows how this relate and then show a more simple way of doing the actual calculation. First, we need to determine how many rotations Max made to travel the distance. This can be done by taking the desired length of, in this case, 20cm and dividing that with the supposed circumference which we set at 5,6*π

We then take the actual distance traveled of 19,5cm and divide that by the number of rotations taken, giving us the actual circumference which then in turn can be divided with Pi giving us the actual diameter.

All of this can be simplified to a calculation of the relations between the measured and desired length times the supposed diameter:

Note: The longer the length we make Max drive, the greater the differences are from the actual and intended moved, thus giving more precise results for the calculating the actual wheel size and making the impact of measurement errors smaller.

Determination of track width: Because the angle turned by Max was too hard to determine manually it meant that we could not measure it and calculate the track width. Instead, we took a trial and error approach and tried different widths until Max turned the desired 180 degrees as seen in the following Figure 2. All of the different track widths were tried multiple times to confirm that the results were consistent and valid.

Results from different track widths Figure 2: Results from different track widths

As seen in Figure 2 at 15.0 Max was spot on thereby determining his track width.

Rebuild Max As a result of Max still being inconsistent and inaccurate when drawing a square, we decided to give Max an overhaul to remove some of the things that may be causing problems. First, we started by mounting small 36,8 x 14mm solid wheels, this should take away some of the error caused by the 56mm wheels flexibility. Then we decided to make a whiteboard marker rig, which we had put in as a bonus exercise for fun, because mounting the marker with tape was just not rigid enough resulting in the rig seen in Figure 3.

Max with newly mounted Marker rig Figure 3: Max with newly mounted Marker rig

Finally we recalibrated the wheel diameter and track width as seen before and then put Max on a new surface to drive, because we had observed small dents and curves on the whiteboard that we were using. We then made Max draw a square again to see the results, which can be seen in the following Figure 4.

Max and a drawing of a “square” Figure 4: Max and a drawing of a “square”

Max stopped right on the mark three times in a row allowing us to conclude that he now was correctly calibrated and was running as intended.

Exercise 3 – Navigating the Cartesian coordinate system


We will in this exercise investigate how accurately Max will be able to drive through a series of coordinates in a Cartesian coordinate system by seeing how close he will be to the original position as this is the final position. Although we have experienced increased inaccuracy when driving on the whiteboard, we decided to use this as we had no paper available in the required size.


We start by testing the path suggested in the exercise which consists of the coordinates (200,0), (100,100), (100,-50) and then back to (0,0) by using a marker and run the track we will then be able to measure how accurately Max travels, specifically looking at how far off the start and end point are since they should, theoretically, be the same. However seeing as we have no whiteboard that would accommodate such a large traveling path (over 2 meters) we decided to half the distance so instead of traveling two meters in the first coordinate, Max will only travel one meter.

After trying a few runs, Max still had some inaccuracy, which were greater than what was to expect from the irregular surface of the whiteboard. We therefore tried looking at what else could cause the problem. After observing Max closely when he was driving, we saw his turns experiencing drag from the marker pen. This made us test the difference of Max turning with and without a marker pen attached, by having Max turn 720 degrees counterclockwise and then comparing the start and stop points. As seen in Figure 5 when turning with the marker attached it came approximately 15 degrees short of the 720 but when the marker was lifted during turning, Max turned approximately 5 degrees to far.

Max turning 720 degrees with and without a marker drawing Figure 5: Max turning 720 degrees with and without a marker drawing

As can be seen, the amount turned is affected by the marker pressing down to draw, with this in mind we are able to somewhat correct for this in the track width variable. After we had corrected as much as we could for the marker, we continued by making Max travel through the waypoints mentioned before.


The program used was based on a java example provided in the exercise notes, which we then updated to accommodate the new leJOS API as seen below.

public navigation(){
  pilot = new DifferentialPilot(3.68f, 15.0f, Motor.A, Motor.C);
  navigator = new Navigator(pilot);

  navigator.addWaypoint(100, 0);
  navigator.addWaypoint(50, 50);
  navigator.addWaypoint(50, -25);
  navigator.addWaypoint(0, 0, 0);


The code can be found here


Without doing any further calibration and trying to keep a mild pressure with Max’s marker, while running the track, Max’ start point and end point were very close. Max’ end point is at maximum 1cm behind and 1,5cm to the right. The closest distances are 3mm behind and 0mm to any side. There is even consistency in that the offsets between start and end point, those that occur, are always behind and to the left meaning that with further calibration more precision might be possible.

Max running the track can be seen in this video.

Exercise 4 – Navigating while avoiding objects


The plan for exercise 4 is to utilize the arbiter concept from Lesson 7 and have two behaviors included. First, we will have the avoid behavior and second we will have the follow behavior which will follow the predetermined path.


First we need to know if it is possible for the Navigator class to remember where in the coordinate system it is when we force it to avoid an item. To do this, we added a Waypoint Listener that allowed to force an avoidance behavior after the second waypoint and then observe if the Navigator would make Max travel the remaining waypoints correctly. As seen in Figure 6 Max was navigated from the start position (P1) to the first waypoint (P2) and from there to the second waypoint (P3). This is where we forced the fake avoid behaviour of driving 20cm straight to (P4) Max then turned and drove to the third waypoint (P5) and as seen by the green line, this is where he was supposed to go. Finally Max went to (P6) and turned so that he would have the same heading as when he started. The small gap between the start and end point is consistent with the inaccuracy discussed in the previous exercises.

Result of test run to see if Navigator keeps real time position update Figure 6: Result of test run to see if Navigator keeps real time position update

Now that we knew how to implement avoidance behaviour without the Navigation losing its actual position, we can now make changes to the arbiter code from Lesson 7 to support the use of a Navigator and DifferentialPilot. After this we once again made Max drive the four waypoints, but this time with a obstacle in the middle as seen in Figure 7

Max facing an obstacle in the middle of his path Figure 7: Max facing an obstacle in the middle of his path


The test program used to see if the Navigator class would keep a real position can be found here

The program is in all ways just as the arbiter from Lesson 7, the only difference is that it now uses the Navigator and DifferentialPilot to control the wheels instead of the Car class. This is simply done by replacing all code from calling car into calling the Navigator with a DifferentialPilot.

We decided to hardcode a simple avoidance behaviour into Max meaning that when he would see an obstacle he would turn left, drive 20cm and drive right eventually clearing the obstacle. This is of course not a viable solution for all kinds of obstacles, but seeing as the point of the exercise was to make Max change his path and return to it, we then decided on the faster solution.


The final code can be found here

Results As seen in this video, Max was able to successfully avoid obstacles while still getting to the predefined waypoints.

Exercise 5 – Improved navigation


This exercise is about comparing different ways of updating a robot’s position and direction while said robot is moving. The comparison will be between the Java Robotics Tutorial from RidgeSoft, and the formula used by Thomas Hellström. We will identify what the differences are, and which one is the most accurate.

Furthermore, we will try to figure out how leJOS updates the position and direction and discuss if it can be improved by using the techniques proposed by Hellström.


In this section we will simplify and explain the different ways of calculating the position.

RidgeSoft proposes a way of calculating position, where the position is updated by calculating the distance travelled in a straight line resulting in a new position. The distance traveled is calculated by taking the circumference of the wheels and the number of rotations taken since the last update.

Thomas Hellström proposes a way of calculating the position, where the distance traveled is calculated as if the robot is traveling in an arc defined by the difference between the number of rotations the left and right wheels have taken. The actual distance traveled is also calculated from the circumference of the wheels and the rotations made.

Lejos calculates the position of the robot by combining the two way presented above, this is seen in the programming section below. Lejos decides the way of calculation based on what kind of move command the robot was given: “Travel” means to go straight, “Arc” means going to the endpoint in an arc. Besides the move command given leJOS also sees how big the turned angle is, deciding that if the change in angle is below 0.2 degrees then the robot is going straight.


private synchronized void  updatePose(Move event){

  float angle = event.getAngleTurned() - angle0;
  float distance = event.getDistanceTraveled() - distance0;
  double dx = 0, dy = 0;
  double headingRad = (Math.toRadians(heading));

  if (event.getMoveType() == Move.MoveType.TRAVEL   || Math.abs(angle)<0.2f){
    dx = (distance) * (float) Math.cos(headingRad);
    dy = (distance) * (float) Math.sin(headingRad);
  }else if(event.getMoveType() == Move.MoveType.ARC){
    double turnRad = Math.toRadians(angle);
    double radius = distance / turnRad;
    dy = radius * (Math.cos(headingRad) - Math.cos(headingRad + turnRad));
    dx = radius * (Math.sin(headingRad + turnRad) - Math.sin(headingRad));

  x += dx;
  y += dy;
  heading = normalize(heading + angle); // keep angle between -180 and 180
  angle0 = event.getAngleTurned();
  distance0 = event.getDistanceTraveled();
  current = !event.isMoving();


RidgeSoft has an advantage: because of the simpler calculation, the time needed to perform the calculation is short and is therefore able to make more updates within a shorter time period, however since a prerequisite for this calculation to be accurate is that the robot travels in a series of small straight lines, which is rarely the case, the accuracy is compromised.

Thomas Hellström’s way of calculating the new position does not prerequisite that the robot drives in a straight line which means that it will provide a more accurate position, but require more calculation to do so, meaning that the calculation time is longer allowing for fewer updates.

Both of these calculations are however affected heavily by quick changes in direction and travel in between updates. Meaning that the calculations can not differentiate between a robot going straight and then turning on the spot and a robot making a gentle curve since the rotation count is the same. This however is only a problem if the time between position updates are too great.

Finally seeing if the calculations proposed by Thomas Hellström could improve the leJOS calculations, but seeing as leJOS already have implemented the only thing that you could do is to force it to use the arc calculation. However, as it already does this if the angle is larger or equal to 0.2 degrees makes it improbable that any actual improvement would be apparent.

Bonus Exercise – Make whiteboard marker rig


The plan for our bonus exercise is to make a rigid marker rig that can hold a whiteboard marker tightly fastened to Max as he drives around, without the marker moving when e.g. turning around.


We tested the rig as part of the previous exercises.

These test however made it clear that driving with the marker down and drawing caused Max to lose precision while using the lejos Differential pilot. Therefore we decided to make an addition to the rig allowing us to raise and lower the marker so that we could make dots when Max would be standing still and thereby avoid effecting the navigation as seen on Figure 8.

Max with a marker rig raising/lowering mechanism. Figure 8: Max with a marker rig raising/lowering mechanism.


The test program used can be found here


The marker rig worked as intended as seen in the previous exercise results. Additionally the raising and lowering mechanism running can be seen in the following video.



When taking a dead reckoning approach to navigation, the precision of the sensors have an immense impact on the accuracy of the calculated position, in our case being the tacho counter. However, also how the data is handled is important, for example the navigator used in leJOS framework takes a series of prerequisites like that the robot transfers 100% of the counted rotations into equivalent movement and that it is driving on a plane surface.


The approach of navigating using only the tacho counters in the wheels as a sensor is not a viable solution for long term navigation, but as demonstrated allows for a decent level of maneuvering and navigation, which could be used if the main navigation system should fail.