We’ve never used CAN mode before - since we were rookies.
Do the Jaguar (and Talon) CAN modes have encoders built in? Lots of people say that we should use CAN, but we’d like to have cleared explanations and also some sample code (we’ll be searching Github for this).
Can we tell a Jaguar to make the motor make exactly 6.22 rotations - to move an arm to a certain position? Will it automatically continue to hold the position against gravity (think Aerial Assist with an arm holding up a ball)?
What can CAN mode do that PWM cannot (aside from monitoring power consumption)?
So … no encoders are needed with CAN mode – correct? The motor will tell us how much it has turned and in which direction?
From my experience with CAN and the cRIO, the Jaguar has a pinout to connect to an encoder and can handle PID control for you, CAN can still do control essentially like PWM, you can tell the controller to maintain a specific position or a specific speed (using PID).
To the last point of yours, the motor cannot know how far it has turned without some feedback like an encoder or potentiometer.
In order to be able to send distance (rotation commands) to a Jaguar, you would need to use an encoder. The difference between PWM and CAN is that you can connect the encoder to a jag, and reference the encoder as a part of the jaguar object, instead of as a separate object programming-wise. It can also handle PID loops internally.
Do you happen to know if the new Talon has both a CAN port and a PWM wire?
Oh. So, if you have to have an encoder anyway, then really the CAN mode Jaguar is not much better in terms of what it can do. One object or two - not much of a big difference from programming standpoint.
The idea behind supporting closed loop control via CAN was to have the sensor (encoder, potentiometer, limit switch, etc.) directly connected to the motor controller so that the processing power of the CPU (MCU) within the motor controller could be harnessed to do the control loop (PID).
This has some advantages:
Less processing run on the main robot controller means more cycles for other things.
The loop rate of the PID on the motor controller can be higher since there is no communication delay. The motor controller reads the sensor (directly), performs the PID computation, and updates the output to the motor. On Jaguar, this now happens at 1 kHz.
Advantage 1 (above) gets reduced every time more processing power, memory, etc. gets added to the robot controller. However, advantage 2 is still there. In fact, I’d argue that if there wasn’t an advantage of using closed loop control via CAN, the smart folks at Cross the Road Electronics wouldn’t have made the Talon SRX.
So, using CAN on Jaguar or Talon SRX to use this has some benefits.
We’ve had a number of issues with CAN on the Jaguars in the past. The support folks at Vex were very helpful, but in the it seemed to be issues with different versions of the Jaguars so we dropped it. FWIW, part of the issue was conformal coating on the modular connectors, but changing that did not completely resolve the issue.
This year we have to use CAN to get battery voltage from the PDB as well as communicate with the pneumatics module, and want to use it for motor control, but it seems the Talon SR’s in the KOP do not have CAN, but rather the Talon SRX’s do.
CAN is definitely more complicated than PWM, which is extremely simple. With PWM you just give it a -1.0 - 1.0 value. With CAN you can configure it to take speed commands (RPM), distance commands (Rotations), Percentages (-1.0 - 1.0), and others. If you use PWM though, I think you CAN (pun intended) get those functionalities, but with a little more work.
To be fair, most of those complications you mention are completely optional. The only mandatory complication with CAN is that you initially have to assign a unique address to each Talon, PDP, and PCM on the CAN bus. And you have to assign the correct ID to any Talon you have to replace for some reason. Now that all the the assignment happens on the roboRIO webpage, I think it’s only a little more complicated than wiring up a dozen PWMs to the correct ports.
I’ll readily admit the using CAN before this year was rather more complicated, since you needed to make up the correct RJ11 cables, terminate the bus correctly, make up a (correct) serial-RJ11 adapter, and (shudder) deal with BDC Comm for assigning IDs and testing. Definitely more complicated last year.
Well put Kevin. With the Talon SRX specifically, we took the lessons learnt from seasons past to make the CAN use-case a lot more robust and painless.
-With weidmuller connectors, there is no risk of bad crimps or bad connectors.
-With the terminating resistor built into the roboRIO and PDP there is no risk of manually soldering resistors or hand-crimping them and not being sure they are actually in-circuit.
-With the new lightening tab in the DS you can grab the CAN bus utilization (%) and error counts.
-The roboRIO web-based configuration will tell you when you have multiple CAN nodes with the same devID and will let you fix it without isolating one CAN node.
-boot-loaders for all new CAN nodes gracefully handle bad firmware files, losing power/CAN in middle of flash, flashing wrong product firmware, etc…
This season’s CAN implementation really is a new type of animal.
We put those to the test with our beta testing. We FUBAR’d the firmware update on one of the Talon SRX modules half way through and it was awesome when we were able to recover it with no problems.
I skimmed the software manual, and I would like to buy a Mountain Dew or beverage of choice for the people behind the firmware. The Talon firmware solves SO many problems with using advanced features on the Jag:
Unsolicited position and velocity feedback. You had to poll the Jag and you could only get feedback for the closed loop mode you were in.
PIDF with automatic and triggerable integral anti-windup. The PID on the Jag was nigh useless without feedforward and anti-windup.
On the fly gain schedule switching and single frame parameter setting. Setting P, then D, then I while closed loop is live would be pretty terrifying.
Slave mode. You couldn’t use the onboard PID on the Jag anyways if you were planning on driving a system with more than one motor. Now if your lift is underpowered, slap a second motor on and slave the Talon to your primary.
Single edge count up feedback. Cause it makes flywheel shooters easier and you can’t on a Jag.
No more BDC Comm.
No more BDC Comm.
Thanks not even mentioning the vastly improved electrical specs and positively miniscule size and weight.
However, I do have a few suggestions/feature requests for future firmware releases. Some are admittedly based on my assumptions about how you’re doing things, since the firmware source code isn’t available and we don’t have our Talons or a system to test them on yet. So far it’s three things that aren’t mentioned in your firmware feature list in the SRM:
Velocity averaging. I’m assuming right now you’re just counting pulses per PID cycle, which can make for pretty coarse feedback in some cases. 2^n rolling average should be pretty simple to implement, and would stabilize values.
Analog filtering. Either same 2^n rolling average, or a simple exponential filter to deal with a noisy signal.
1/period velocity feedback. It’s a lot more accurate at low speeds/counts, and sometimes even better for flywheel feedback.
A Bang Bang Controller mode would be cool as well. I know the teams that used it in previous years, including us liked it alot. Would be cool having it just integrated into the controller.
Another feature I would like to see would be a way to set the distance per count. With no setting for that this year, gain numbers are going to have to be incredibly small to work with something like a 256 or 360 cpr encoder.
I believe that you will get “Bang-Bang Controller” functionality from the built-in PIDF if you set Kp = infinity (just choose a really big number) and set Ki = Kd = Kf = 0. For “flywheel” applications, you’ll also need to constrain the minimum output to be 0, so that when the flywheel is over the target speed, the controller doesn’t “Bang” to maximum reverse.
In 2012, we used a bang-bang controller for our basketball-shooting flywheel. It worked pretty well. In 2013, we started out using a bang-bang controller for our full-court shooter – it was pretty good, but not good enough for FCS. With experimentation during the 2013 season, we found that a PF controller (PIDF where I=D=0) worked more smoothly and more accurately. As mentioned above, PIDF with Kp=infinity and Ki = Kd = Kf = 0 degrades to bang-bang, so it’s easy to test both alternatives by just varying the parameters while the robot is operating. For us in 2013, the improvements made the difference between FCS that nearly worked and actually did work. Retrofitting the improvements to our 2012 robot increased our accuracy shooting basketballs, too.
We’re planning to use the Talon SRX this year with the built-in PIDF for most of our control loops. Haven’t gotten them working yet, but that’s been due to cabling issues, rather than problems with CAN or the Talon SRX.
[Rising Counter.]
If you use the Rising Counter/Encoder (EncRising) feedback device then the feedback device will only count in the positive direction which means the measured velocity will also be positive (or zero) and…
Section 18 Closed loop code]
…additionally the oneDirOnly param will be true since EncRising is the “positive only sensor” mentioned in the function header comment. This is the only way to set oneDirOnly param. This will ensure that negative error (target speed < actual speed) doesn’t output negative throttle (which is bad for a velocity control, we don’t want to spin backwards!). I found that out the hard way when I tested velocity servo without it during development.
If you do want to do this be sure to note the part in Section 7.4 where you must set ReverseFeedBackSensor to false. Otherwise the PIDF will output negative throttle and oneDirOnly will clamp it to zero. If your motor and sensor is out-of-phase this is a good place to use “Reverse Closed-Loop output” instead. FYI same signal can be used to invert the output of a slaved Talon SRX.
Also EncRising isn’t available in LabVIEW (Section 21.7).
[min and max output]
Not supported, didn’t have time for it. That’s also what **Section 21.4 **is about.
[bang bang]
I suppose it’s possible to do Bang Bang with a large P. Then once the speed meets or exceeds the target speed, the motor output would coast. I can’t say I tried using it in that fashion, if that works out then please share with the rest of the community.