PID on Jaguars is Illegal

[jtdowney]

Originally Posted by Jim Giacchi

My main concern over a rule like this is how would inspectors even check it?

When I inspect this year I will certainly be looking to see if any sensors are wired into the Jaguar. After that it will likely be somewhat on the honor code. There are some rules that while valid can be hard to enforce such as verifying that you didn't build anything prior to kickoff.

As for no closed-loop feedback from the Jaguars, it is very upsetting. However teams did truly awesome things with sensors on the IFI control system and I am sure our cRIO has some power to spare.

[Kevin Sevcik]

So, first and foremost, there's still some reason to use the CAN-bus. You can still offload some functionality to the Jags, such as limit switches, potentiometers, encoders, and current sensing. Yes, your feedback on encoders and other sensors will be delayed, relative to what you'd get on the cRIO, but it is an option.

Second, even without the sensors and closed loop control, CAN-bus is still makes some sense. Provided you're not using the serial adapter, but the ethernet-CAN adapter. You can send commands rather faster over the CAN-bus than you can over PWM, and they'll be more stable with better resolution. So I wouldn't let this ruling dissuade you from using CAN. If you're aiming for tight, fast response control loops, then it's still the way to go.

Third, I'm also mighty confused by this restriction from the GDC. Especially if the 2011 FRC firmware for the Jags still supports closed loop control modes. (I haven't gotten a look at it yet.) We use independent servo controllers all the time in industry, and they're perfectly safe. They're all designed with various disable mechanisms to safely shutdown the servo in the event that communications with the host controller are lost. Near as I can tell from the reference code, the Jaguar is set up the same way. So you'd still have the exact same level of safety in the system as you do with the PWM inputs. If offloading control to the Jag was unsafe somehow, then CAN-bus commands wouldn't be any safer. If the Jag failed to disable closed loop on loss of signal, it's still going to fail to disable PWM control on loss of signal.

The only theory I've got is that they're really wanting to stick with good, general application rules, with as few exceptions as possible. We can all admit that the most problematic parts of most rules are the one or two exceptions specifically in the rules. You do have to admit that the blanket ban on external command signals is some fair bit simpler than a ban with an exception for Jags, or Jags with XX firmware, or external control loops that aren't vetted by FRC, or external control loops that don't meet the following safety protocols, etc. etc. etc.

[Alexander Meyer]

Hehe, looks like it's back to the drawing board. I always wanted to know more about how PID loops work--guess I'll be getting up close and personal now. Thankfully the cRio has some serious processing beef.

[Bryscus]

I want to know why there would be so much effort put forward to write libraries for the Jaguar CAN code and then stomp on the all the time and energy of those people. Last year we used closed-loop position feedback and there were MANY threads on CD involving discussions of such - yet there was no limitation then. This year it's supposed to be even SAFER with the updated code. And why would WPI put all these functions into their INCLUDED LIBRARIES if the GDC was just going to rule them out. This is a completely illogical ruling and I suggest that a petition is created to combat this lunacy (wait, that's 2009).

- Bryce

P.S. If you can sense frustration in my message, you're very perceptive.

[gpetilli]

This year they opened up the CAN bus, added rules for wiring sensors to the Jaguars and updated firmware in Jaguars to shut down if they don’t get a “heartbeat” from the CRio. I cannot understand why the GameDesignCommittee came down with a rule clarification banning PID in Jaguars when the clearly were acting to enable it. Hopefully they will reconsider - distributed processing is an important lesson for our young engineers.

[Jon Stratis]

Originally Posted by Kevin Sevcik

So, first and foremost, there's still some reason to use the CAN-bus. You can still offload some functionality to the Jags, such as limit switches, potentiometers, encoders, and current sensing. Yes, your feedback on encoders and other sensors will be delayed, relative to what you'd get on the cRIO, but it is an option.

Actually, that doesn't seem to be the case. Sure, you can hook up encoders and potentiometers, and send those signals, along with current sensing, to the cRio for processing. That's not offloading functionality though - it's just giving you a few more ports to hook sensors into in addition to those provided by the digital side car and analog breakout. But limit switches? Wouldn't <R62> apply here as well:

"...any additional devices on the Ethernet or CAN-bus must not provide command signals that do not originate from the cRIO-FRC."

A limit switch hooked up to the Jaguar would be providing a command signal to stop the motor when it reaches a specific point. In fact, this signal can override the signals sent from the cRio and give you different behavior than the code tells you. If you have an elevator with a limit switch to tell you when it's hit the top, the Jaguar can no longer legally stop the elevator for you - that has to be done in the code. As such, this would seem to disallow hooking limit switches into the Jaguars at all.

[gpetilli]

is thermal shutdown illegal?

[Alan Anderson]

I agree with the proposal that speed control should be commanded only by the cRIO. I do not agree with the conclusion that internal closed-loop control of motor speed by another device is therefore illegal. Even though the Jaguar is controlling the motor speed, it is doing so based on the cRIO's command.

I do wish the GDC had made what I think is the proper distinction between "command" and "control". I still hold some hope that they will find a way to change their answer without seeming capricious.

[Bryscus]

Here are some other things I'd like to mention.

If the GDC wants to limit what can and can't be done in the Jags, they should have TI write new firmware to disallow any possibility of using these functions. I had a long conversation with the Black Jag designer and firmware programmer from TI last year at the Championship about all the good and bad of the closed-loop firmware that TI provided on the Jags. We were one of the teams that decided to take a risk that the CANJaguar software for the cRIO and Jaguar firmware would mature enough to operate properly for last year. If this was disallowed last year, then there were some serious oversights from the GDC. And now that the code has matured to its greatest form to-date it is illegal. Why would FIRST want TI to improve its closed-loop firmware and also sanction a CANJaguar project if the code is not even going to be used?

Also, as someone stated below, distributed computing and control systems is THE FUTURE. How can FIRST claim to be investing in the future if they want to impose archaic designs on teams? We're already using a processor that was introduced almost 20 years ago. Every system around us uses multiple application specific devices. To remove these concepts is shortsighted.

Lastly, the Jags basically have a timeout. They're not supposed to keep functioning if a signal is lost - and this timeout I believe is ?100ms. This is well below the threshold for human comprehension. If there is no signal, the Jag shuts down. So to say that the cRIO is not controlling the Jag has be to based on how long one expects the latency to be between the cRIO and the Jag. For example, if the cRIO commands 90 degrees (in position feedback mode) and the motor is currently at 0 degrees, there will be a time delay between when the motor starts moving and when it reaches 90 degrees. The cRIO must keep commanding 90 degrees in order for the Jag to keep trying to make the motor go to 90 degrees. If at any time a signal is lost, the Jag will stop commanding the motor and everything will stop.

I also hope this ruling is retracted .

One step forward, two steps back.

[Tim Skloss]

Originally Posted by Jim Giacchi

My main concern over a rule like this is how would inspectors even check it?
.

Inspectors would see the encoders plugged into the Jaguars.

If you run the encoders to the digital sidecar and do the PID in Labview then that would be LEGAL.

[anthonyttu]

I don't agree with the statements that the signals are originating from the Jags The CRIO gives a speed/position/current then the Jag following orders. By the same rule <R62> limit switches directly into the jag will also be baned. Thus making the Jag worthless the CAN buss worthless and the whole reason for upgrading the entire control system pointless.

[artdutra04]

Originally Posted by Alan Anderson

I agree with the proposal that speed control should be commanded only by the cRIO. I do not agree with the conclusion that internal closed-loop control of motor speed by another device is therefore illegal. Even though the Jaguar is controlling the motor speed, it is doing so based on the cRIO's command.

I do wish the GDC had made what I think is the proper distinction between "command" and "control". I still hold some hope that they will find a way to change their answer without seeming capricious.

I'm hoping this was what the GDC meant in their reply, as we really enjoyed using the on board PID control in the Jaguars last year.

[MikeE]

Originally Posted by Tim Skloss

Inspectors would see the encoders plugged into the Jaguars.

If you run the encoders to the digital sidecar and do the PID in Labview then that would be LEGAL.

But encoders plugged into the Jaguars are perfectly legal according to <R62-H>. However, unless the inspector has a CANbus monitor or reverse engineers the deployed code, they can't tell whether the readings from the encoders are only sent to the cRio or are interpreted locally on the Jaguar.

So encoders etc. plugged into the Jaguars are a necessary condition for one type of distributed speed control, but not a sufficient condition.

[Andrew Schreiber]

Originally Posted by Alexander Meyer

Hehe, looks like it's back to the drawing board. I always wanted to know more about how PID loops work--guess I'll be getting up close and personal now. Thankfully the cRio has some serious processing beef.

1114 has a pretty decent description of it here

Originally Posted by Bryscus

Lastly, the Jags basically have a timeout. ....

This is only for the FRC Firmware in as far as I am aware.

There is also a signed mode built into the CAN signal so that any arbitrary device cannot inject motor control signals only "trusted" devices.

Originally Posted by Tim Skloss

Inspectors would see the encoders plugged into the Jaguars.
.

Which this ruling DID NOT forbid, it merely said we can't use the the PID on the Jag's PID. We can still use them to put sensors onto the CAN bus and reduce wiring complexity.

For reference, I strongly hope they change this rule.

[Kevin Sevcik]

To all reading this thread,

I think we should probably try to coordinate the inevitable Q&A submissions asking for clarification and/or modification of this ruling. Bombarding the GDC with 50 followups on this isn't going to help.

So, first and foremost, if you're reading this and have already sent a followup Q&A, please reply below to let us know, along with a copy or summary of what you posted.

Second, lets all wait about 2-3 hours to see if anyone's already posted followups.

Third, I'll nominate myself to post a followup on the Q&A at around 2PM CST addressing these issues. My proposed post follows, any suggestions or edits appreciated.

1. Limit switches, thermal/overload limiting, and voltage ramping. Do limit switches count as command signals coming from the Jaguar? What about the intrinsic current and thermal overload limiting? Does the programmable acceleration/deceleration function count as the Jaguar modifying or interfering with the command signal from the cRIO?

2. The Jaguar purports to implement an FRC specific trusted communication protocol with the cRIO to ensure proper shutdown when communications are lost. As such, a properly programmed and operating cRIO should have constant control of a properly programmed Jaguar at all times, regardless of the operating mode of the Jaguar. The Jaguar is then simply operating as a standard servo controller that will shut down when host communications are lost. Reasonable interpretation would read this as the cRIO sending a position/velocity COMMAND to the Jaguar, and the Jaguar translating this into an appropriate voltage command to the motor. In fact, this would appear to be absolutely identical to the functioning of the perfectly legal RC servos, which implement closed loop position control of a DC motor based on potentiometer feedback and a cRIO position command.
So we're curious is <R62> outlaws RC servos as well. And if not, what the distinction between the RC servo controller and a closed-loop Jaguar might be.