Quote:
Alex,
One thought I had after my intitial post is the problem of keeping the steering motors in alignment. It is an issue using two motors and chain for us. To keep all four tracking is going to take some processing power and sensors.
|
We used an
"Magnetic Rotary Absolute Encoder" on each wheel. They act like potentiometers, since they are connected to an analog input and are read as a value between 0-1023. However, they do not have stops like potentiometers and can be rotated freely. Therefore, they have the resolution of a one-turn pot but can be used in multi-turn applications.
We used this little piece of code to keep track of rotations:
Code:
char encoder_turns(int pot, int last, int window) {
if(pot - last > 1023 - window)
return -1;
else if(last - pot > 1023 - window)
return 1;
return 0;
}
Since a value read from the encoder will always refer to the same physical position, we didn't have to worry about loosing positions after turning off the robot. However, since we had the encoder connected to the main (rotating) shaft using two plastic sprockets, we lost calibration there since the sprocket would sometimes "ride on a chain" or skip a few teeth on fast movement. It wasn't a major problem, since we recalibrated before every round.
We then used 2 PI loops on each module (cw,ccw) to get it in the position we wanted. I could write a whole essay on control theory right here, but I think Jimmy's post "sums" it up:
http://www.chiefdelphi.com/forums/sh...int#post617897
Quote:
|
We limit the travel to only one rotation plus a few degrees, max. This year we closed that down even further. The wiring comes right up out of the top of the module and the upper bearing point is a hollow tube which the wires run through.
|
We also ran the wires upwards through a central shaft. We made them long enough to allow for about 3 rotation each way. We kept track of the turn count in programming and saved it to the eeprom so that we wouldn't loose track. We also wrote an unspin function that unspins the wires.