Notes:

* forward, backward will run infinitly unless a stop is called for that motor
* take notice of the momentum issue. We used it to our benefit
* There is also a nifty function flt() which will kill power to the motors but will free resistence
* calling system.exit(0) will allow you to run the program again without shutting off and turning on the robot

Trial Notes

* Mega Robot Design - bricks communicate with each other
* Light bar code reader for rotational sensor

Additional Notes

* TimingNavigator - still is not exact. Rely's too much on battery power being consistant.

We would have to change the number of degrees to rotate based on battery poewr and the class ws still not exact. Program execution would fly so fast, calls to stop and restart the motor would not happen in time, and the motors would try and go two different directions at once with a grinding noice.
* RotationalNavigator - needs rotational sensors which count every 1/16 of a revolution of the motor
Apparently timing nav is not geared towards the trusty design. Rotate causes the robot to move forward. We had to decompile the class and change motor calls so it would rotate for our particular robot. This may be why the accuracy of the angle rotation is not 100% correct.

	while(i<45){
		rotate(1F);
		i++;
	}

Apparently supposed to wait until the robot does the turn (which is implemented by a rough guess on how long the thread should sleep and wake up to stop the motors) it doesn't sleep long enough and winds up rotating the robot about 1/2 of what it is supposed to. The program execution goes so much faster than the motors have a chance to rotate that the program will then jump back into main where the robot is told to follow a line and now there aremultiple motor calls which causes grinding and lockup.

* Use of loops (while loops)

Using while to call forward or backward presents the same problems as timeNavigator(). Also, as battery levels die, it takes more loop counters to allow rotation to finish.

Our Solution

Have each track begin with a four way intersection. It will perform a check on the time it takes to turn 90 degrees. We now have a weight on how long it should take to do an x-angle turn. So when we hit an intersection it is easy to determine if it is a four way or a three way by looking at the triggering state, and the state after (1/4 sec) momentum. Now we can start the motors, sleep the current thread for the desired amount of time to make an x-angle turn using our estimate for 90 degrees. This can be a rough estimate for the machine to learn as it goes along.

On the problem with using long values, Mete adds: "we wanted the machine dynamically determine how long it takes to rotate 90 degrees using a four-way cross. After that’s determined, we wanted to use that estimated time for other rotation we needed along the path. But we abandoned the idea when since we cannot use arithmetic operations on long type. "

If I could tell you three things...

My three pieces of advice.
1) Before you do anything else, read through the lejos documentation carefully, especially the README file. Pay particular attention to the "to do" list of things that are not yet implemented in lejos. In the version of lejos we used, there were no switch statements, for example.
2) The bigger the group, the more important that you are organized well. Decide upfront what everyone should be working on, and then meet regularly.
3) One of the problems we had with determining the best sensor configuration was that the width of the track was just bigger than the width of the sensor. The result was that if we put the sensors right next to each other, we ran the risk of having two going dark over a straight line at once, but if we put the tiniest bit of space we could between them (one lego "bump"), there would be times when none of the sensors were dark and the robot thought it was lost. It might be worthwhile to redesign the test tracks so that the common unit of measurement is a sensor width. This might help with some of the problems we were having with the robot running through intersections.
The only thing that I thought was really difficult about the project was that we were limited to three sensors. We had ideas for ways to improve the sensor configuration but we couldn't test those that involved more than three. I guess another piece of advice to the next group is that if they have enough people, someone could be devoted to researching to see if overloading sensors is possible, or, if the group decides it could be necessary, to find out about possibly linking multiple rcx bricks together.
-Chris

Advice:
1: Don't put the sensors right next to each other
2: Plan to have to rethink your ways of tackling a problem many times
3: Think as simple as possible intially. This will allow you to edit the code easier as you encounter problems.
-Ben

1-read the documentation before doing anything
2-first think and finalize the design of the robot and then work on the programming
3-stick with your robot design and try working on the programming if an issue comes up
-Mete

Make sure you're sensors are as close to the ground as possible, read up on threading in java because it will be to your advantage when writing code for the robot, try to make a robot that doesn't fall apart after each course run.
-Machel