* 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
* Mega Robot Design - bricks communicate with each other
* Light bar code reader for rotational sensor
* 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.
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.
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. "