PID on Jaguars is Illegal

[Kevin Sevcik]

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

Originally Posted by GDC

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]

Originally Posted by Kevin Sevcik

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]

Originally Posted by Kevin Sevcik

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

Major step backwards...

[Chris is me]

I have no idea why this is illegal.

[taichichuan]

Originally Posted by artdutra04

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.

[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]

Originally Posted by TRay

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?