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.)
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.
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.
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.
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.
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”.
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?
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 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.
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 think that half of the response is unrelated. I don’t know why they bothered to type it.
[/quote]
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:
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 ).
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.
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.
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.
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 and Rule , 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
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 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.