CAN mode question

[RaiderRobotics]

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?

Thanks!

[Christopher149]

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.

Was this clear?

[Ariane Nazemi]

Do you happen to know if the new Talon has both a CAN port and a PWM wire?

[Poseidon5817]

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?

Yes, it's your choice.

[Joe Ross]

Originally Posted by Ariane Nazemi

Do you happen to know if the new Talon has both a CAN port and a PWM wire?

As shown in the Talon user's guide, it has two wires which are used for either CAN or PWM.

[RaiderRobotics]

Originally Posted by Poseidon1671

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

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.

We haven't figured out PID loops yet.

Thanks for the very clear answer.

[s1900ahon]

Originally Posted by RaiderRobotics

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.

I wouldn't say that.

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:
1. Less processing run on the main robot controller means more cycles for other things.
2. 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.

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