Like other teams using Jaguars on the CANbus, we saw a few areas of operation that need to be improved. As a mentor, I can see why quite a few teams are leery of the results. Quite often, the deficiencies we saw, and others have commented on, are not really fair to pin on the Jaguar, since it is more likely that the Jaguars expose problems that the cRIO’s longer time slices tend to hide.
Instead of complaining about the Jaguars PID implementation, I think it would be more constructive to offer suggestions for incremental fixes that would make it easier to recommend closed-loop on the Jaguars with confidence. In this spirit, I’ll offer the first suggestions:
For speed control; turn off the output if the commanded speed is 0, and the brake is set to coast.
Rationale - We send 0 speed commands initially to our drive motors, as part of the initialization. When the robot is suspended (to keep the wheels off of the ground), there is enough backlash in the typical FRC gearboxes that the encoders will register small movements. The PID then attempts to counter the perceived speed, causing a thrashing of the wheels and gears, when a 0 rpm speed is commanded. Turning off the output for this case is safe.
Offer a simple filter (e.g. moving average of last n readings) for the encoder feedback. This could be on all the time with a user-settable range like 0 < n < 32. Unfiltered would correspond to n = 1, and lag and smoothness increases from there.
Rationale - It appears that the Jaguars are too responsive to the noise in the encoder signal. The speed of the control loop is far faster than the motors that will be hooked up, so the minor lag of grabbing 5-15 encoder readings would not be noticed.
If I’ve understood correctly, and assuming properly tuned PID gains, you can accomplish this by using enableControl() and disableControl() which are provided by the CANJaguar object in WPILib.
In your initialization code, you shouldn’t need to send an initial 0 speed command. Just configure the speed mode, speed reference, PID gains, etc. Then enableControl() only when you actually want to start controlling the output - the motors won’t move until you enableControl() and set a speed command via setX(). Each call to enableControl() turns off the output though, so only call it once when you want to start controlling.
disableControl() will turn off the output and set the Jaguar back into %voltage mode (which is the default).
The documentation in the Jaguar “reference design kit” - available here - also explains in more detail what all of the CAN messages do.
My team is using LabView, and we haven’t found an equivalent for the enable and disable command for individual CAN jaguars. Perhaps there is a terminal on one of the vi’s that we missed.
My proposal is essentially to automate the disable/enable on the jaguar, based on setting conditions, rather than explicit programming from the team code. If you look at limit switches, for example, there is no way to enable or disable them from LabView. They are explicitly enabled by default, so you do not have to send an explicit command to enable them on the Jaguar. If you use BDC-Comm, you can disable or enable the limit switches. The FIRST Labview libraries take this choice (or responsibility) away from the student programmer, and make the limit switches always functional. No code required.
You can also implement them yourself, using the the documentation that rrossbach pointed you to.
I do think that the choice to switch out of a closed loop mode into an open loop mode when 0 is commanded is better left to the programmer, rather then being built into the jaguar, because I think both options are correct, for different circumstances.
I do think having encoder filtering is something that should be implemented inside the jaguar.
I used the limit switches as an example, because it appears that there was a conscious decision by the WPI implementors to provide a default safe mode.
On the jaguars, I see that there is inconsistent behavior already with regard to the jaguar being commanded to a 0 set point. For example, if you use voltage mode with a ramp rate, and have the brake set by jumper or CAN specification. You can ramp to 100%, and then immediately ramp down to -50% or -100%, but as soon as you command a voltage between ~-10% to 10%, the brake kicks in immediately, with no ramp. A near 0 commanded voltage ignores the ramp rate that is set. Likewise, with the brake set to coast, there is no ramp down to 0, it just free-wheels.
In speed control mode, the jaguar is attempting to control the output, even if commanded to 0. My proposal would at least synchronize the behaviors of these two modes.
Thanks for the link for WPI feedback! Also, thanks to rossbach for the CAN documentation link. We will go through the CAN reference to see what we are missing.