CAN on the entire 2012 robot

[Phalanx]

Hi everyone,

Team mercury 1089 has used CAN in a variety of different setups with varying results.

We used CAN over our entire robot in 2010, and while it worked well, it did suffer from "brown out" conditions which caused our robot drive to stop functioning. As long as we didn't brown out, it worked well.

This past year we used CAN and the PID built into the Jaguar to manage our shooter motor, but, we used PWM with JAG's to run the drive system. We did find a bug in the Labview Periodic Status Update VI that would throw an error, but once we knew the condition and the bug, we suppressed that error.

When the JAG browns out it "forgets" your CAN configuration settings(it still remembers it's ID number) and resets to PWM operation mode by default. We really need to write some code to detect the brown out condition and reinitialize the JAG with our settings.

[connor.worley]

Maybe I can provide some insight as to why a team wouldn't use CAN. My team chooses not to use CAN for two big reasons:

• We've had multiple Jags fail in testing
• We haven't had a Victor fail in testing or in our past 10 competitions (not sure about before then- that was before I joined)

The features CAN offers are appealing, but the implementation is prone to failure, at least in my team's case.

[mikets]

Last season, our team tried CAN for the first time. We read about the brownout problem and decided to do something about it before it happens to us. Our team uses Wind River C++. We wrote a wrapper CANJag class inheriting the CANJaguar class for detecting brownouts and restoring all the configurations if necessary. We never had any problem with CAN during the entire season. So we never really know if the code worked. After the season ended, we had a public event that required demo'ing our robot the entire day. It went very smoothly but at some point, our driver reported to me that he saw yellow warnings flying by the debugger saying something about brown out detected. I took a look and was delighted to see that was a warning in the new module detecting brownouts and restoring configurations. The driver didn't even notice anything wrong with respect to the driving. It just kept going normally (may be a little sluggish). It turned out, the driving demo non-stop for a few hours ran down the battery to a voltage level that started to cause brownouts. So we replaced with a fresh battery and everything was good again. If you want to look at how we implemented that class, you can access it here in case you want to port it to LabView (http://proj.titanrobotics.net/hg/Frc...rclib/CanJag.h).
Ideally, this code should be integrated into WPILib. This module basically shadows all the important configuration data. It overrides the CANJaguar::Set method so that before setting the motor power, it checks for brownout condition. If there is no brownout, no extra work done. But if it does detect brownout, all the shadowed configurations will be programmed back to the Jaguar before programming the motor power. The module also has an optimization to minimize unnecessary CAN traffic by checking if the caller is setting the same motor power over and over again (which is very common in your iterative robot loop). It will only send a CAN message to set power if the power is different from the last value.
Actually even better, if the CAN implementation of Jaguar or Talon makes configuration data non-volatile, then we don't need this code at all! But of course, shadowing values is still beneficial for CAN traffic optimization.

[techhelpbb]

Originally Posted by mikets

Last season, our team tried CAN for the first time. We read about the brownout problem and decided to do something about it before it happens to us....

I think this is excellent work and very valuable to the whole community but I've said that before.

I do want to point out that there's another issue with a brown out that may not be considered.

If you use encoders and the Jaguars brown out the pulse counts will no longer be accurate. In a velocity control sense where the system can move freely all the way around that's not a big issue. However, in a system with limits and no limit except the encoder readings that could be an issue to consider.

[mikets]

Originally Posted by techhelpbb

If you use encoders and the Jaguars brown out the pulse counts will no longer be accurate. In a velocity control sense where the system can move freely all the way around that's not a big issue. However, in a system with limits and no limit except the encoder readings that could be an issue to consider.

That's a fair scenario. I will modify the code to also restore the position count. That should take care of that scenario.

[techhelpbb]

Originally Posted by mikets

That's a fair scenario. I will modify the code to also restore the position count. That should take care of that scenario.

A modification like that is a great idea but there's something to consider with it:

The problem with quadrature and even single channel encoders is that if you fail to track their outputs momentarily you loose your accurate fix on their direction of rotation during the missing interval and the amount of rotation during that interval as well.

Absolute encoders can help because they produce directional information that is absolute to the encoder rotation/position. To a point that helps till the encoder has enough time to fully revolve and then that information will be wrong. So it gives you a little more buffer but I can see how a fast moving input to the encoder could quickly entirely revolve before a Jaguar resets to full operation.

So if the Jaguar browns out or looses power it'll cease to service the encoder interrupt and that information will be lost. Restoring the last known good value is a good starting point, but if the mechanism was influenced by gravity or momentum while the Jaguar was 'out to lunch' the old data might not be any more valid than the most current reading.

Here's a scenario:

An arm with shoulder. The shoulder has a limited range of rotation. The arm is exposed to additional load as the end effector holds an object. During the course of driving the arm tries to move the shoulder back to one limit. As it approaches that limit the forces increase and the Jaguar browns out. The routine sees the brownout and resets the encoder position to a value approaching that limit. However due to momentum the encoder is now at or past that limit. So the arm tries to move back to that limit. It's choices are: move a complete rotation which it can't so that's an overload or hit the hard stop trying to move to a fictional target and that's an overload. Either case there could be mechanical issues induced and more brown outs causing more and more attempts to reach a fictional target.

[mikets]

Yes, I understand. The software recovery solution in our CANJag wrapper class is not the answer to every brownout scenarios but I believe it will handle majority of the cases. For special case like you pointed out, you may need to do extra steps to ensure it still works after the recovery. For example, if your scenario does not tolerate any inaccuracy of the encoder due to loss of count during brownout, your code may want to also add a recovery calibration (e.g. detecting brownout and then move the arm to resting position with a limit switch, reset the encoder at the resting position, try the operation again). Since this is very scenario specific, it cannot be fixed in the CANJag wrapper generically. So it is up to your code to anticipate and recover from brownouts.

[Phalanx]

Something else you can consider in your mechanical design to go along with your brown out recovery software.

Typically we have a "RESET" button on our custom driver or arm operator station. It's function is to basically ignore just about everything except for it's "HOME" indicator and reset the manipulator to it's "HOME" position.

What we usually do is have a mechanical "HOME" for our manipulator that is a physical stop. Typically that "HOME" is monitored by a limit switch. So when the limit switch is engaged we know our manipulator is "HOME". When it's "HOME" we reset our encoder counts to zero, turn off it's motor, etc....

This does two things. It allows us to reset/recover our position, and a helps alleviate position drift.