Lesson 9: The living GPS Borg.

Today we all met in Zuse to do the exercises for Lesson 9.

The goal is to perform some experiments with the tacho navigator in order to explore the accuracy and potential uses.
The codebase in this experiment and the ideas and inspiration for this lesson comes from chapter 12 of the book: "Maximum Lego NXTBuilding Robots with Java Brains" by Brian Bagnall.
The robot used for this experiment is similar to the one seen on the exercise page. In fact we just used our "default" Lego robot, with some minute changes. The main one of these being, that we changed which end of the robot was 'forward' so that the turn wheel in the center is now the front of the robot.

Experiment 1:
The goal of this experiment is to determine the accuracy of the tacho navigator. We will be driving the route displayed on page 298 in chapter 12 of Bagnall's book 5 times. Each time measuring how far from the starting point the robot stops. (closer is of course better). This will give us an initial idea of the accuracy of this form of navigation.

The dark coin is the starting point and the light coin is the point were it stopped.

These are our initial results:
Run no. Deviation from start point - Direction from start point to endpoint
1: 11,5cm - W
2: 6,8cm - W
3: 10,0cm - SW
4: 7,3cm - W
5 8,7cm - NW

We observe, that the deviation is somewhat 'stable' in that it always ends behind the starting point (west of it). What this tells us is, that the accuracy of our own measurements on wheelbase might be off a bit, but also that the robot can not be considered 100% accurate in this form of navigation. Things like 'slippage' of the wheels and the inaccuracy of the mechanics that is Lego, plays a big part when driving a robot like this. For example, if the Borg drove over a coin then that was sometimes enough to introduce errors in the angles of the Borg. And once an angle error has been introduced into the driving then there is no way to take it back. At least not in the code we are using.

One thing we noticed when writing the code to test turn behavior is that when we wanted the Borg to rotate 360 degrees then nothing happened. It might be that the compiler optimizes that away since that is basically the same as doing nothing, we are not sure. We did manage to force it to turn by making a for loop that rotates the Borg 90 degrees 4 times. Even then did it not end up facing the same direction as it started in.

As a follow up to this experiment we observed that changing the wheel base to be more robust (e.g. we locked the wheels in place to be sure that they did not vary at all in between experiments) produced more stable results and therefore more accurate made the Borg get closer still to the starting point. However, the exact stopping point still varied between each run in a similar matter as before.

Thought experiment:
The last problem we will consider in todays lessons, is how it would be possible to make the robot move from one place to another using the TachoNavigator class, while avoiding any obstacles on the way.
The general problem in doing this, is keeping the TachoNavigator up-to-date with the current position while avoiding obstacles. One way to do this was to implement behaviors as we have seen last time. Having a "move to point" behavior, that utilizes the TachoNavigator running as the default behavior, but either
a) stopping every X units to detect any obstacles in its way and then starting the "avoid" behavior, or
b) having the avoidance behavior being able to inhibit the "move to point" behavior, while it avoids an obstacle.

option b) would probably be preferred, as it makes more sense to talk about "behaving" in some manner in this way.
The main thing here is then that the avoidance behavior should take over, but not just avoid randomly. It could be a "wall follower" behavior that tries to follow the obstacle outline in the general direction of the point we want to go to. The last part of this sentence is important, since we do not want the robot to be sidetracked to a dead end, or an entirely different location. So it should always try to have some "desired" direction that goes toward the final point it wants to reach. After avoiding the obstacle (in one way or another), the UpdatePosition method should be called in the TachoNavigator class, and the "move to point" behavior should take over again.

The code used in this experiment can be found here.