PID on Jaguars is Illegal

[Kevin Sevcik]

Per GDC Q&A here:
http://forums.usfirst.org/showthread.php?t=16326

No closed-loop control modes are permitted within the Jaguar per <R62>.

Plenty of time later for commentary on this lovely ruling, just wanted to get the word out before people got too invested in tuning and/or ditching PID on the cRIO.

[MikeE]

Per GDC Q&A here:
http://forums.usfirst.org/showthread.php?t=16326



Plenty of time later for commentary on this lovely ruling, just wanted to get the word out before people got too invested in tuning and/or ditching PID on the cRIO.

Wow! I didn't see that one coming.
Perhaps Team Update #4 is being delayed until enough old control systems are in stock.

[artdutra04]

Per GDC Q&A here:
http://forums.usfirst.org/showthread.php?t=16326Major step backwards... :(

[Chris is me]

I have no idea why this is illegal.

[taichichuan]

Major step backwards... :(

Agreed. This is very disappointing. Especially after having investing so much time in supporting the closed loop modes last season and submitting the code to firstforge. I was looking forward to being able to utilize the CAN bus this year. But, with this ruling, the Jaguars have been reduced to not much better than the victors. The GDC has gutted the value of a lot of effort from folks like myself, Joe Hirshberger from NI and many others to get the best use of the Jags.

[Jonathan Norris]

Yea this is a poor decision by the GDC... I hope it will be reversed. There really is no reason why this should be illegal, why make us uses these advanced speed controllers that have processors and software capable of position/speed control when we are not allowed to use those capabilities. Why not just let use use a simpler/cheaper speed controller if we canot use the Jaguar to its full ability. Its not like it gives teams some unfair advantage, its makes tuning systems easier... I really don't get this one. :confused:

[Joe Schornak]

Isn't the Jaguar's PID functionality one of the main benefits of using the CAN bus?
This is a rather odd ruling. I can sort of see the logical path behind it, but wouldn't an exception (no non-cRIO motor control signals EXCEPT for the Jaguar PID) be more beneficial than an absolute ban?

[AllenGregoryIV]

Just when we were going to get started with CAN.

Thanks Kevin for pointing this out, fingers crossed for a reversal.

[dtengineering]

While I agree that I can't see any good reason to disallow the primary feature that makes the Jaguar an advancement over other controllers, it isn't like the cRio hasn't got power to spare.

It was a bit of trick to program four closed-loop drive motors for our mecanum drive using the old PIC based controller and I would have really liked to be able to offload some interrupts and clock cycles back then, but with what I've seen using labview on the cRio makes it trivial.

Well, okay... almost trivial.

Maybe the PID libraries and routines aren't as well developed in the other languages on the cRio, but in Labview it would seem unimportant where the closed-loop routine resides.

Jason

[114Klaatu0x72]

“Nothing defines humans better than their willingness to do irrational things in the pursuit of phenomenally unlikely payoffs” - Scott Adams

Maybe something is wrong is some code somewhere and they don't want it to rain on Tuesday on a full moon and send a robot driving through a wall, maybe the GDC wants us to learn more about making our own PID loop systems because they really are a great learning experience, and maybe there's just somebody somewhere realizing they put something from their list of things not to put into the rules, into the rules. Some may see this as a poor choice, but I really don't think it takes all that much away from teams in general, mainly because I don't try to define things as what they used to be, but what they currently are.

[TRay]

I haven't been following the labview encoder capabilities lately (b/c we planned to use the jags) but I remember the FRC FPGA image for the RIO originally only supported like 2 quadrature encoders. We were planning on using 5.... Gonna have to research this now. May face a HUGE design change..... grumble grumble....

[Jim Giacchi]

My main concern over a rule like this is how would inspectors even check it? There isn't anything visible to tell you this is occuring and there are no differences in wiring. The only way would be to check your code... and to be frank, half the inspectors as it is barely even know whats going on with the simple stuff, this would be nearly impossible to enforce.

I'm not saying teams would do it, simply trying to point out that it doesn't make sense for more then just the obvious why give us CAN and then not allow us to use why its there.

[apalrd]

I..only supported like 2 quadrature encoders. We were planning on using 5.......

It supports 12. Up to 4 FPGA Encoders, which use 4x decoding (interrupt on both edges of both pins) and 8 FPGA Counters, which use 1x or 2x decoding (interrupt on one or both edges of one pin).

[martin417]

Whether or not you agree with the ruling, it was obviously the intention of the GDC from the outset. If you read the blue box in the referenced rule, you will see that they knew they were disallowing features, and that they intend to open these features gradually, maybe next year? It should be noted that this wording is identical to last year, so it is not a step backward. Both years state that "Thus, any additional devices on the Ethernet or CAN-bus must not provide command signals that do not originate from the cRIO-FRC" If you offload the PID to the Jag, the Jag is providing the command signals, not the Crio. So, if you did it last year, you got away with a rule infraction. I also agree that it will be almost impossible to enforce. Reviewing the code of every robot is not an option.

Custom circuits and additional electronics are allowed to utilize the Port 2 Ethernet bus and/or the CAN-bus to communicate between devices. Note however, that the ROBOT must be controlled by the cRIO-FRC (see Rule <R49>). Thus, any additional devices on the Ethernet or CAN-bus must not provide command signals that do not originate from the cRIO-FRC It is our intent to incrementally open access to the full control system technologies in a controlled manner that reduces the risk of “unanticipated surprises” as we gain experience with the system.

[sam_who]

Isn't this our third year to use the cRIO? I'm thinking we've done the time for "gradually".

Could we please start using the jaguar CAN capabilities before the jaguars go the way of the Victors?

[jtdowney]

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. :D 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]

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]

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]

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]

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]

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. :D Thankfully the cRio has some serious processing beef.

1114 has a pretty decent description of it here (http://www.simbotics.org/files/first-robotics-canada/workshop-presentations/programming-pid.pdf)


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.

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.

[Stuart]

Second on Kevin's proposal.

[Alan Anderson]

Looks good. I suggest the following minor change:
2. ...Reasonable interpretation would read this as the cRIO sending a position/velocity COMMAND to the Jaguar, and the Jaguar translating this into an the appropriate voltage command control to the motor...

[drakesword]

With saying that the jag in closed loop acts just like a servo wouldn't that make jags and victors illegal?

Both don't just change the voltage they switch it on and off very fast the uC and supporting circuitry fiddle with the transistors to switch the output on and off and they generate the commands themselves.

Does that mean we need to revert to spikes? I dont think they gave us enough with the kit!

[andreboos]

... 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.

A very good point. However, I think the distinction may be that the firmware for the Jaguars is to some degree mutable, while I believe servo control is implemented purely in hardware.

[Kevin Sevcik]

Drake,

My implication was that a jag in closed loop is highly equivalent to an RC servo. Just with external motor and sensor, and tunable PID parameters. So if a closed loop Jag is illegal, then..... The intention is to point out that we're already using independent position controllers on the robot in the form of servos.

All,

I'm informed that some rather more appropriate people are working on this issue now, so I'm going to hold off on any new posts to the Q&A for a little while. I'd like to see what transpires over the weekend before adding to the GDC's busy schedule. I'd ask that anyone else please hold off until Monday evening as well, so as to avoid complicating the situation.

[Kevin Sevcik]

A very good point. However, I think the distinction may be that the firmware for the Jaguars is to some degree mutable, while I believe servo control is implemented purely in hardware.Except that only holds for analog servos. Digital servos implement their control in software, and some of them are even customizable/programmable in various manners.

[MikeE]

It's not unexpected that there is a review of this decision behind the scenes. As well as many volunteers, WPI, NI and particularly TI have invested in expanding the use of the Jaguars. And I thank them for that investment.

On a more general point, section 4.3 of the Game Manual includes the exhortation:
When reading these rules, please use technical common sense (engineering thinking) rather than “lawyering” the interpretation and splitting hairs over the precise wording in an attempt to find loopholes. Try to understand the reasoning behind a rule.
That really should be a two way street, and while the Blue Boxes have helped put context to many rules, this ruling appears to be a counter-example where over-judicious reading of the letter of a rule is elevated over the spirit.

[MikeE]

Per GDC Q&A here:
http://forums.usfirst.org/showthread.php?t=16326



Plenty of time later for commentary on this lovely ruling, just wanted to get the word out before people got too invested in tuning and/or ditching PID on the cRIO.

There seems to be a Booth Review in progress. Or CD complaints caused a Challenge Flag to be thrown.

The original link is no longer viewable and the answer no longer appears in the Q&A Robot section http://forums.usfirst.org/forumdisplay.php?f=1481

[jhersh]

Woohoo... Closed loop control on CAN is legal!!

Update 4 (http://www.usfirst.org/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2011_Assets/Team_Updates/Team_Update_04.pdf)

[Alexander Meyer]

Woohoo... Closed loop control on CAN is legal!!

Update 4 (http://www.usfirst.org/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2011_Assets/Team_Updates/Team_Update_04.pdf)

{fistpump}

I can't tell you how relieved I am..

[klmx30302]

c/p from team update #4:
As long as the CAN bus is wired legally so that the heartbeat from the cRIO is maintained, the closed loop control features of the Jaguar motor controller may be used. (That is, commands originating from the cRIO to configure, enable, and specify an operating point for all Jaguar closed loop modes fit the intent of <R49>.)

(our software subteam breathes a sigh of relief.)

[zbanks]

I'm glad it's legal. I was looking forward to using it this year.

Of course, after reading this thread earlier today, I spent about an hour abstracting and reworking the code.

Although it's still improved, I wish I had known earlier...:rolleyes:

[MikeE]

It's a relief to see the ruling reversed, but a pity the decision was published in the official Q&A in the first place.

Thanks to the positive contributors to this thread for raising awareness and being a part of encouraging a sensible resolution.