NXT Programming - Lesson 5 - The Race

---

Date: 03.10.2007
Duration of activity: 2 in the morning + 3 hours of lab session
List of participants: Daniela, Samuele

---

Goal of the day: come up with some idea, and decide how to compete

First of all we tried the same algorithms used the previous session, but with sensors aligned to the wheel axis.

Results where almost the same

Then we started dealing with the second idea.
As a generalization of the Y shaped robot thought the previous day, we thought to design the robot with a symmetric shape.
It would have then no need to never rotate, but it could choose to move straight in one of six directions, putting the three motors in the same shape as the sensors, and activating one or two of them, and making the others push in the opposite direction.
In this model, every motor always pushes in the direction of the movement, and two other motors push in a direction which forms an angle of Pi/6 with the movement direction.
Their summed power, regardless of friction, is then always, where p is the power of a single motor:
p + 2 * cos(Pi/6) * p = p + 2 * [sqrt(3) / 2] * p = [1+sqrt(3)] * p, which is more than 2 * p

Encouraged from the theoretical demonstration that our robot would have always run faster than any other robot with only two motors, we started building it.




And here it is. Its name is Omega3.

Then, we started all over with programming it.
We created a TriangularLocomotion class, which supports 6 directions, and a TriangularSight class, which represents the abstraction of the three outer sensors, telling in which of the 6 directions it sees the line.

The hardware test, with a simple algorithm that moved the locomotion where the sight saw the line, made it go back and forth over the line, since the concept of following wasn't injected in it yet, and it simply "stayed" on the line. It seemed promising, we went on programming.

We started with a simple stateless algorithm, that decided the direction to follow only using the sensor "sight", and the expected direction of the path (to make it know that it has to follow that direction, and can therefore apply only slight direction changes, and not going back).
We had troubles to make it move, and decided that such a structure, without any built-in concept of what is forward and what is backward, needed an algorithm with a state.

We wrote then a direction buffer class, with the methods insertLinePosition and getDirection.
It receives every sampling, makes some assumptions, and then figures out the new direction.
Internal states of this class were then coded to Forward, WaitingForBend and Bending.

• When in the forward state, the robot always goes straight if it sees a line in that direction (regarding of other sensors).
  When it loses the line, it moves to WaitingForBend state, because when the ahead sensor goes off the line, you expect that the sensors, which are probably out of the line, will cross it as well.
• When in the WaitingForBend state, then, you just take the direction of the first sensor which crosses the line, and go in Bending state.
• In Bending state, then, you are allowed to apply some correction to the trajectory, by considering the whole sensors reading, and going in the direction in which you see the line, if this implies only a small correction to the direction, or ignoring the sensor reading if it suggests to go backward.

Everything was coded, debugged and tested for hours, but we couldn't make it work. It moved, but it didn't follow any line for more than some seconds.
We are sure that in a perfect world, with continuous sensor readings, or at least more frequent and precise, our robot would have worked really nice. But it wasn't the case.

Goals reached: learned that you should try to use strange strategies to do much better than the others, only when you have backed up your old robot with your old algorithms, which could at least run as the others do.