Legality of Jaguar closed-loop control modes

[rrossbach]

In an official Q&A answer just posted today, it appears that the Jaguar closed-loop control modes are now not considered competition-legal (see the specific question and answer from the GDC here. (http://forums.usfirst.org/showthread.php?t=16140))

We're interpreting this to mean that ONLY voltage mode is competition-legal - which is surprising, as we'd previously understood that the essential safety feature of the FMS being able to disable Jaguar-controlled motors was achieved via the special heartbeat sent from FRC_NetworkCommunication, and thus completely protected from any team-written software going awry. Hence the reason for the FRC-specific firmware on the Jags - if the Jag doesn't see the FRC-specific heartbeat, it cuts off the motor output regardless of whether a closed-loop control in the Jag is trying to drive it or not.

Due to the implications of this, we'd like to see if others in the community read this Q&A the same way we have, before we ask GDC for explicit confirmation. Please post your thoughts.

- Ron
Team #2607 controls mentor

[aldaeron]

I would post to Q&A before Tuesday so you can get an answer and continue working on your design. It is good to get advice from other folks, but the Q&A ruling is final.

[Joe Ross]

I thought that was an ambiguous way to answer the question. Is the closed loop control command that does originate from the cRIO the command, or is the calculated voltage output the command? I find it hard to believe that they would make it illegal without outright stating it, so clarification is in order.

[drakesword]

My interpretation is that you can send the closed loop commands from the cRio.

A Jag may not send closed loop commands to another jag.

[rrossbach]

We've posted a Q&A requesting explicit statement of which control modes are competition-legal.

- Ron
Team #2607 controls mentor

[jhersh]

The way I see it, the intent of these rules is to keep robots safe. Based on the technology, the cRIO needs to control the Jags so that the Field Management System can stop the robots. That is the point of the FIRST specific Jaguar firmware. All modes are safe and controlled by the FMS.

I expect the GDC will state that all modes are legal.

-Joe

[rrossbach]

The way I see it, the intent of these rules is to keep robots safe. Based on the technology, the cRIO needs to control the Jags so that the Field Management System can stop the robots. That is the point of the FIRST specific Jaguar firmware. All modes are safe and controlled by the FMS.

I expect the GDC will state that all modes are legal.

-Joe

Yep, that's the way we see it too - hopefully the GDC will confirm that understanding.

[EricVanWyk]

There is no rule that prohibits the Jaguars from reading the values from the encoders, however note that Rule R49 requires that the ROBOT must be controlled by the cRIO. In other words, commands may not originate in the Jaguar or any other controller, they must originate in the cRIO.

The commands for the various control moods do originate in the cRIO, it is just that the command is "Set your speed according to these parameters and the encoder".

The key word is command, not data.

[Ether]

The commands for the various control moods do originate in the cRIO, it is just that the command is "Set your speed according to these parameters and the encoder".

The key word is command, not data.

I believe you are right, but then why did GDC find it necessary to say "commands may not originate in the Jaguar" ? In what meaningful sense would this even be possible?

[Al Skierkiewicz]

Ron,
I was under the impression that the heartbeat is to insure that something has not interrupted the CAN connection and therefore allow the Jaguar to continue to execute the last command received. This is something different than a disable command generated by the Crio either through internal firmware for a fault or as received from the FMS. Is this correct?

[EricVanWyk]

I believe you are right, but then why did GDC find it necessary to say "commands may not originate in the Jaguar" ? In what meaningful sense would this even be possible?





I think that half of the response is unrelated. I don't know why they bothered to type it.

A "bad" student could reprogram the Jaguars with entirely new firmware, but this would break several other rules. There would be no doubt that they were doing something illegal though, so I don't know why they bothered to mention it here.

[rrossbach]

Ron,
I was under the impression that the heartbeat is to insure that something has not interrupted the CAN connection and therefore allow the Jaguar to continue to execute the last command received. This is something different than a disable command generated by the Crio either through internal firmware for a fault or as received from the FMS. Is this correct?

I'd have to let jhersh and/or dyanoshak provide the authoritative answer....but IIRC when the robot is disabled the cRIO stops sending out the FRC "trusted heartbeat" to the Jags, which causes the FRC-specific firmware on the Jag to disable the motor output - not unlike what the standard Jag firmware does when it doesn't see any CAN messages.

Since this "trusted heartbeat" is completely protected from interference - intentional or unintentional - from team software, it's this handshake between the protected FRC software on the cRIO and the FRC-specific firmware on the Jags that provides the required safety, allowing the driver station (or FMS when connected) to disable the Jag motor output, effectively negating any motor output "commands" that come from the team software on the cRIO or the internal control loops on the Jag. That's why the Jags require the special firmware when using CAN in order to be competition-legal.

I believe you are right, but then why did GDC find it necessary to say "commands may not originate in the Jaguar" ? In what meaningful sense would this even be possible?

I think that half of the response is unrelated. I don't know why they bothered to type it.


I see the ambiguity as coming from the terms "reading the values", "command" and "control". Even ignoring the second part of the response, the first sentence is also unclear IMHO.

To quote, adding my own emphasis:
"There is no rule that prohibits the Jaguars from reading the values from the encoders, however note that Rule R49 requires that the ROBOT must be controlled by the cRIO."

Here's a very plausible paraphrase (which is hopefully NOT what the GDC intends):

"There is no rule that prohibits the Jaguars from reading the values from the encoders, however the Jaguars are only permitted to provide the values to the cRIO and all control calculations must be performed on the cRIO."

Seems like we all agree it'd be non-sensical for the GDC to intend this - but it's unclear enough that we had visions of robots being wrongly declared illegal based on different inspectors' opinions. :eek:

[Stuart]

ok so if we interpret this the strictest way possible ( where the jag cant independently make a decision about its output ) wouldn't the current/voltage protection( a jag will shut itself off if it over amps or the voltage gets under 6v) built in to the Jags break this rule?

I dont think that this interpretation is correct ( or will remain correct ).

[biojae]

The GDC has spoken, no closed loop control from the jaguar.
http://forums.usfirst.org/showthread.php?t=16326
No closed-loop control modes are permitted within the Jaguar per <R62>.

[taichichuan]

The GDC has spoken, no closed loop control from the jaguar.
http://forums.usfirst.org/showthread.php?t=16326

Geez. This is a really unfortunate answer from the GDC. :ahh: It greatly complicates the cabling and increases the complexity of closed-loop control.

Can someone ask on the First forum (it won't let me post) if this means that speed, current and position modes of the Jaguar are prohibited? If so, then there's no reason to use CAN bus. We might as well stay with PWM and the Victors.

Heavy sigh...

[EricVanWyk]

...

[biojae]

Geez. This is a really unfortunate answer from the GDC. :ahh: It greatly complicates the cabling and increases the complexity of closed-loop control. Now, we're going to have to run another set of cabling... Sigh.

Can't the encoders still be connected to the Jaguar?
The only rule restriction is that commands must come from the cRio.

The cRio can read the position (or speed) from the jaguar.
PID (or other closed loop control) can be calculated on the cRio.
Then the calculated voltage can be sent to the jaguar.


There is no rule that prohibits the Jaguars from reading the values from the encoders, however note that Rule R49 requires that the ROBOT must be controlled by the cRIO. In other words, commands may not originate in the Jaguar or any other controller, they must originate in the cRIO.

[taichichuan]

Can't the encoders still be connected to the Jaguar?
The only rule restriction is that commands must come from the cRio.

The cRio can read the position (or speed) from the jaguar.
PID (or other closed loop control) can be calculated on the cRio.
Then the calculated voltage can be sent to the jaguar.

In order to use the Jaguars in one of the closed loop modes, you have to load PID values to the Jag. That would appear to be prohibited by the GDC's ruling.

[biojae]

In order to use the Jaguars in one of the closed loop modes, you have to load PID values to the Jag. That would appear to be prohibited by the GDC's ruling.

The jaguar would be in Voltage control mode.
The position (or speed) values can be read through the CAN bus (after the correct settings are loaded into the jaguar, SpeedReference for example).
The voltage to send to the jaguar can then be calculated on the cRio.

This does not use any of the Jaguar closed-loop modes, and so it seems legal.

[Vikesrock]

I see no justification for this ruling within rule <R62>.

<R62> All outputs from sensors, custom circuits and additional electronics shall connect to only the following:
A. other custom circuits, or
B. additional COTS electronics, or
C. input ports on the Digital Sidecar, or
D. input ports on the Analog Breakout, or
E. the RS-232 DB-9 RS-232 port on the cRIO-FRC, or
F. the Ethernet network connected to either Port 1 or Port 2 of the cRIO-FRC, or
G. the CAN-bus if and only if all Jaguar speed controllers on the CAN-bus are wired in full compliance with Rule <R58> and Rule <R59>, or
H. the sensor inputs on the Jaguar speed controller.

If they intended to use <R62-G> to justify the ruling by way of <R58> they should have cited <R58> directly. If they are not using <R58> as the justification then I see no part of this rule prohibiting closed loop control on the Jaguars. The Jaguars themselves are not "sensors", "custom circuits" or "additional electronics" as their output is permitted to be attached to motors which are not listed in this rule.


<R58> may provide some justification for such a ruling
<R58> Each Jaguar must be controlled with signal inputs sourced from the cRIO-FRC and passed via either a connected PWM cable or a CAN-bus connection.

I would argue however, that any of the closed loop control modes are controlled with inputs sourced from the cRIO-FRC. Control of the Jaguar is provided through a combination of configuration parameters, setpoints and the heartbeat provided by the cRIO.

I'd have to imagine that the people that put all the time and effort in to support the closed loop modes in the three different languages have to be a bit frustrated right now. I see the blue box under <R62> as a giant vote of "no confidence" in the Jaguar firmware. If the GDC believed that the Jaguar firmware would shut off the Jaguar outputs when the robot was disabled, what harm is there in allowing teams to use the closed loop modes with a "use at your own risk" disclaimer?

Teams that spent offseason time working with the CAN bus and closed loop modes are also likely to be a bit aggravated. This type of thing is exactly the kind of transparency that people are asking for from FIRST. I don't think you would have seen any uproar about this if FIRST had issued a technology roadmap detailing what they were planning on opening when at the time they changed control systems. Then teams could have allocated their offseason time in a more applicable manner, perhaps practicing custom dashboards knowing that a laptop with a larger screen could be used, or offboard camera processing, knowing that COTS computing devices were going to be legal.

[MikeE]

The jaguar would be in Voltage control mode.
The position (or speed) values can be read through the CAN bus (after the correct settings are loaded into the jaguar, SpeedReference for example).
The voltage to send to the jaguar can then be calculated on the cRio.

This does not use any of the Jaguar closed-loop modes, and so it seems legal.

While it is possible to run PID on the controller successfully, there are substantial advantages of running it on the motor controllers themselves. In particular there is less need to consider timing jitter in control loops or message bandwidth limits if using the Black Jaguar serial to CAN convertor.

But mostly this is a poor decision due to the reason Eric stated above.

[Stuart]

ok so what about the attached limit switches on the JAGS. by default ( and I don't think there is a way of turning this off) in both the PWM and CAN mode you can attach 2 limit switched to the Jag to stop the motor at both its low and high points . . am I to understand that these ports are off limits as well?

I get the desire to minimize “unanticipated surprises”, but we have had these devices for 3 seasons, CAN for 2 ( I would like to know if any one used the closed loop modes last year),and a whole range of beta tests ( not to mention the inclusion of the closed loop modes in the custom FRC Labview and Jag firmware builds).

it just seams a little weird

[jtechau]

Personally I'm fine with that decision (strange as that decision may seem). It's one thing to use closed-loop control. It's another to implement it in your own code, especially if you're using PID control. I'd much rather have my team know how the stuff works, than just be able to hook it up and see it do its magic.

After all, that's pretty much what FIRST is all about.

[Stuart]

Personally I'm fine with that decision (strange as that decision may seem). It's one thing to use closed-loop control. It's another to implement it in your own code, especially if you're using PID control. I'd much rather have my team know how the stuff works, than just be able to hook it up and see it do its magic.

After all, that's pretty much what FIRST is all about.

While I agree with the sentiment. I disagree with the argument.

a few years ago Dean talked about the idea that technology is something that is new to the generation. for his grandfathers generation the car was technology, for his generation the internet is technology, for this generation . . well we dont know. The point is each time we progress, the wild and amazing things of the past become base and mundane ( I would say transparent). When I was in high school ( circa 2004) it was all 15 pin analog ports and limit switches. if we wanted to do channel mixing that was like 2 weeks worth of coding, and trig for getting relitive positioning of the field, forget it!( I often wonder if those doing FIRST in 1994 would take a look at what I did in 2004 and say "well all the hard stuff is done for him what is he learning"). But now channel mixing and trig functions are mundane they are transparent, we talk about the underlying principals drop in the VI and move on. does this make the season any less hard? No work will always rise to its own level. This just pushes us to find something else thats new and interesting and exciting (technology).

[drakesword]

Raise your hand if your team will be programming and testing both methods in the unlikely case of an overturn

*raises hand*

[MikeE]

Personally I'm fine with that decision (strange as that decision may seem). It's one thing to use closed-loop control. It's another to implement it in your own code, especially if you're using PID control. I'd much rather have my team know how the stuff works, than just be able to hook it up and see it do its magic.

After all, that's pretty much what FIRST is all about.

I don't understand this argument. Even if you are using the Jaguar closed-loop control the PID values still have to be tuned, and you can't reasonably perform that tuning unless you understand the control algorithm. If the PID controller is implemented on the cRio there are some code structural issues to deal with but otherwise it's the same tuning problem, requiring the same level of algorithmic understanding.

The first programming language I learned was Z80 assembly, but I don't believe that I understood more when myopically concerned with register use than I do now when using WPIlib and can concentrate on higher-level design.

[jtechau]

While I agree with the sentiment. I disagree with the argument.

I don't understand this argument.

You both bring up some good points. But my point was not so much about being able to learn, understand and program closed loop control or PID controllers specifically. Remember that these are mostly novice programmers. The more experience they get, the more they'll learn.

[MikeE]

You both bring up some good points. But my point was not so much about being able to learn, understand and program closed loop control or PID controllers specifically. Remember that these are mostly novice programmers. The more experience they get, the more they'll learn.

That's a very fair point.

My personal bias is to increase the students' understanding of the process of software system design rather than the gritty details of lower level implementation and syntax, although obviously some students do need to master the latter.
This bias matches my observations of the industry where there are substantially more application programmers than system software programmers.