Legality of Jaguar closed-loop control modes

[EricVanWyk]

...

[biojae]

Originally Posted by taichichuan

Geez. This is a really unfortunate answer from the GDC. 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.

Originally Posted by FRC GDC

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]

Originally Posted by biojae

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]

Originally Posted by taichichuan

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]

Originally Posted by biojae

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]

Originally Posted by 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.

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]

Originally Posted by 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.

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]

Originally Posted by Stuart

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

Originally Posted by MikeE

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]

Originally Posted by jtechau

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.