[marccenter]

Tom,
Thanks for your post.
I mentored Team 1286 and didn't get much time for tuning the algorithm on the actual robot itself.
I haven't touched the code since the Detroit regional,but it is interesting to note that I followed a similiar path.

Step 1: Drive forward slowly (base PWM value is large due to friction from tank tread design). (no wheel encoders).
Step 2: (Kevin Watson's camera code modified to only search at a specific tilt - angle for better speed).
Step 3: Based on the PWM value of the tilt servo I used a lookup table to determine how much tilt PWM value to add
to the base PWM value.
(The tilt PWM value was calibrated to slow down as the target was reached - MBC).
Step 4: Based on the PWM value of the pan servo I used a correction to the base PWM value plus tile PWM value to turn to the correct angle. (One side was sped up and/or the other side slowed down to correct angle - MBC). So now have base PWM forward value plus tilt angle PWM value plus pan servo PWM value.
Step 5: We drove forward the amount until the total PWM value caused the robot to stop (as tilt angle increased, tilt
angle PWM value decreased, as pan servo angle neared zero, pan angle PWM value approached zero).
Step 6: (no arm on robot - tank tread design only) - No tube to release at "the rack".

Was I successful? Yes, somewhat. After spending many hours at the bench prior to the Detroit Area Regional to get
everything right , I was able to move straight forward and stop. I was also able to start off to one side of the intended target and move forward and stop. I was disappointed that the team didn't give me multiple opportunities to test at Detroit.

A couple of important comments are in order:
1) Spent lots of time making software work on the bench prior to getting to the robot
2) Getting the camera to work and interface to the software the way you want it to work is a job in itself
3) I used fixed point math (all numbers were between 0 and 255) - I am familiar with using fixed point due
to past work experience.
4) No trig functions are necessary to operate. I think this is difficult idea for high school students to contemplate (using PMW values as a surrogate for angles).
5) Only Proportional logic used in conjunction with table lookups and fixed point math. This simplifies
implementation. Proportional gain changes as a function of the error (important - most PID's discussed utilize
constant P rather than varying P). More refinement may have demonstrated the need to provide integral correction
capability.
6) A calibration philosophy must accompany the control strategy. Trying to remember back to my high school experiences
over 30 years ago, I would find it a challenge to A) have a control strategy and then B) have a calibration strategy

7) Calibration strategy: A) Go straight forward slowly, entire time with enough power to reach rack during autonomous
period. This establishes your base calibration values for your robot incorporating friction. With calibrations for each side,
I also accomodated frictional differences between both sides B) Calibrate camera for tile angle. Find camera tilt angle value at starting position- make this value (179) correspond to largest output value in your tilt angle PWM calibration table(16?). Find camera tilt angle value at end posiition (195) make this value correspond to zero in your tilt angle PWM calibration table. C)Calibrate camera for pan angle (not completed). Start in left or right starting position or equivalent. Find maximum
pan angle (80). Associate this with largest PWM correction in table lookup to make robot turn to desired direction.


Tom, I like the use of your case statements to indicate your starting position and target height . When I
stopped my development at Detroit, I essentially had the starting position logic operational.
I am considering drafting a white paper "The almost ready for Prime Time autonomous mode for Team 1286
for Rack 'N' Roll - 2007" Perhaps it would be a good read for next year's teams.