[MikeE]

We developed camera tracking and have used gyro in previous years but this year we found that the line sensors were very reliable as long as they are calibrated properly to the field. The lights on the front of the sensors make them very easy to calibrate manually when sliding the robot from side to side over the lines.

Our robot has KoP quad encoders for each of the mechanum wheel modules, so we know how far the robot has travelled forward. There is code to detect if an encoder is providing unreliable values, hence excluding it from calculation. Typical problems are no signal due to wiring problems or physical encoder damage.

We do have an encoder on the elevator, but we have found the most reliable method is to drive the elevator to the top and check the current draw from the motor via CAN. As soon as the elevator gets to the top, the motor starts to stall, increasing current draw which we detect and stop the motor. This method also help if we are get too close and hit some other part of the peg grid structure since it will stop the elevator, rather than unsuccessfully trying to drive it through the grid to a preset point.

The code is written in Java in the autonomousPeriodic() method as a state machine, with timeouts on many states to allow for sensor failures.

Summarizing: line sensors for direction, quad encoders on drivetrain for distance travelled, current draw from elevator motor and timing for pneumatics. Ultrasonic range finding would be a helpful addition.

The biggest problem was lack of access to a real field to test out the system. In particular we had extremely limited access to the practice field during our Regional. Testing by watching the system perform during a match is a very public way of finding bugs, which I do not recommend for the thin-skinned.