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.
Major step backwards… 
I have no idea why this is illegal.
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.
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. 
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?
Just when we were going to get started with CAN.
Thanks Kevin for pointing this out, fingers crossed for a reversal.
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
“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.
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…
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.
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).
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 ). 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.
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?
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.
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.
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.
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.
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.