CAN mode question

[VEI Dude]

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.

See here... http://content.vexrobotics.com/vexpr...t-20140819.pdf

[Poseidon5817]

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.

[Kevin Sevcik]

Originally Posted by Poseidon1671

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.

[ozrien]

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.

If you really want the details checkout the Talon user's guide and Talon software ref manual at....
http://www.crosstheroadelectronics.c...ol_system.html
Also the FRC screensteps page has lots of good info...
http://wpilib.screenstepslive.com/s/...ribution-panel

Originally Posted by Kevin Sevcik

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.

[Poseidon5817]

To be fair, most of those complications you mention are completely optional.

Well put.

[marshall]

Originally Posted by ozrien

-boot-loaders for all new CAN nodes gracefully handle bad firmware files, losing power/CAN in middle of flash, flashing wrong product firmware, etc...

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.

By the way, Omar is the man. It's a fact.

[Kevin Sevcik]

Originally Posted by ozrien

If you really want the details checkout the Talon user's guide and Talon software ref manual at....
http://www.crosstheroadelectronics.c...ol_system.html
Also the FRC screensteps page has lots of good info...
http://wpilib.screenstepslive.com/s/...ribution-panel

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:

1. 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.
2. Analog filtering. Either same 2^n rolling average, or a simple exponential filter to deal with a noisy signal.
3. 1/period velocity feedback. It's a lot more accurate at low speeds/counts, and sometimes even better for flywheel feedback.

[Thad House]

Originally Posted by Kevin Sevcik

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:

1. 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.
2. Analog filtering. Either same 2^n rolling average, or a simple exponential filter to deal with a noisy signal.
3. 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.

[Ken Streeter]

Originally Posted by Thad House

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.

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.

[ozrien]

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