[ace123]

Our team created a large abstraction library (user_io.c/h,user_motors.c,user_controls.c) which basically has stuff like get/set_motor_speed and get/set_motor_pos and update_input/output(), which work on all motors. The arm routes though PID (position) and velocity, but others just simply go directly to the motors (with limiting, overflow and deadband checks).

In come cases, you can use position PID with the motors to make it line up correctly. My team was planning on using PID for the arm and motors (we had it working perfectly) until they made a last-minute decision not to attach or calibrate pots.

Although we had a large abstraction library, we could not use most of it due to a robot lacking some small parts. The motors library got too complicated, and I wasted an hour of time due to some default deadband value of 127 in the middle of the arm code.

Basically, either KISS (Keep it simple) or else heavily test every part of it, make easy-to-change numbers, and have #ifdefs to disable code when, for example, you are suddenly without pots.

One thing that helped a lot was the reuse of code (just call update_inputs() at the beginning of the auton and main loop, and update_outputs() at the end of the loops, and share arm and drive code: an arm motor is a motor and a drive motor is a motor, and drive can have position, and arm can have velocity.) If a value changes at last minute, then just edit it in one place, and not everywhere you use the motor.

For things like arm grabbers, pneumatics, etc., just make a simple flag in a controls structure which reads from the control board or the auton loop. Then just use a timer and set a relay to 1 or 0 or a motor to forward or backward based on that timer.