[Ken Streeter]

Originally Posted by ozrien

So it looks like for teleop your Mecanum drive used speed-closed-loop pretty much all the time (FP closed-loop).

Did you find that helped improve driving the robot during teleop?

Yes, our mecanum drive used exclusively speed-closed-loop, with the TalonSRX performing the closed-loop control in the Talon with directly-connected USDigital encoders. We tuned the PIDF control parameters manually (we ended up only using F & P as you mention), but once they were set, we simply told the TalonSRX the parameters to use, and let the TalonSRX do all the work.

We did code a contingency "open loop" capability via a button press on the driver station in case we had an encoder failure during a match. However, we never needed to use that in any matches. A nice feature of the "open loop vs. closed loop mode" button, however, was it permitted a direct comparison to see what was being gained with the "closed loop" control -- one could drive the robot a bit in "closed loop" mode to see how it performed, then press a button to try "open loop" mode and see how it performed without the closed-loop. The difference was significant -- the closed-loop control provided greatly enhanced driver control, particularly at low speeds.

By using the speed-closed-loop control, commands to make all 4 wheels turn slowly would actually make all 4 wheels turn at the desired rate, even if one wheel had slightly greater mechanical resistance or was carrying greater load due to weight distribution, or was up on the corner of a scoring platform. This was most beneficial at low speeds, particularly when trying to move as slowly as possible, such as in the final alignment of a tote or placing an RC. The closed-loop control also helped the robot drive more consistently whether it was carrying no totes, 1 tote, or a few totes.

The other feature that really helped our driving was implementing "heading preservation" when commanding the mecanum robot to translate, but not rotate. Whenever the robot was being commanded to translate, but not rotate, the code would determine the cumulative heading error since the last time the driver had commanded a rotation, and proportionally correct the heading (using a gyro as the heading reference). What this meant is that when commanding the robot to strafe sideways or diagonally, the robot would hold the initial heading, even in varying CG situations (such as whether or not totes were being carried.) This feature was a huge help.

We implemented a "field-oriented drive" capability (it's actually nearly trivial to do so with the control paradigm used for mecanum drive) but our drivers preferred the traditional control scheme.

As an aside, we used position-closed-loop on the TalonSRX for both of our elevators. Again, we wired the USDigital encoder directly to the TalonSRX, simply set the PIDF parameters (we only needed P and D), and let the Talon do the heavy lifting. We made use of the "VoltageRampRate" feature to prevent sudden "jolts" of the elevator when starting / stopping, and were very pleased with how that worked out, too. These experiences have us sold on the TalonSRX.

Originally Posted by ozrien

Kaizen looks pretty good to me, I'll take functionality over clean-up any day.

Thanks for the kudos. Some of the code is still a mess.

It did work well, though -- I haven't yet tired of watching last year's auto: https://www.youtube.com/watch?v=rTspn46gKkg