Talon SRX Encoder Breakout

[amesmich]

I had a question about the SRX breakout board for the new talon. Located here http://www.vexrobotics.com/217-4398.html

TChey way I understand it is you could add an encoder right to the tallon and it woudl process the signal on to the CAN bus.

Correct me if I am wrong, the encoder would still be on the mechanical side to monitor the actual movement of the saft it will just feed data to directly the controller instead of directly to the myrio.

[nickmcski]

Yes i believe your right but I with this I believe you can also just have the PID control on the motor controller itself (eg keep a wheel spinning at 70 rpm)

[FrankJ]

The reason to run the encoder to the talon is the same for the Jags. You would run the PID in the Talon. Otherwise you would run the encoder into the RoboRio.

[Thad House]

The reason to run the encoder to the talon is the same for the Jags. You would run the PID in the Talon. Otherwise you would run the encoder into the RoboRio.

Also, because you can get the raw encoder values at any time, you can plug the encoder into the talon, then still do the PID calculation on the roboRIO. This has some interesting use cases, and could both simplify wiring, and require less IO's to be used for encoders.

[amesmich]

Wow, ok that makes sense. Its uses the encoder for the onboard PID. Nice. Originally I was thinking it would save an I/O and some wire but now I understand the PID can be offloaded from the myrio to the controller. I knew the new talon had PID but I never put the two together.


Thanks for the help all.

[adciv]

Also, because you can get the raw encoder values at any time, you can plug the encoder into the talon, then still do the PID calculation on the roboRIO. This has some interesting use cases, and could both simplify wiring, and require less IO's to be used for encoders.

From a controls standpoint, I wouldn't recommend this for most cases. There will be an increased time delay between getting the encoder value from the Talon to the RIO and sending back the new control command. If you're going to use processing on the RIO, it's better to have the encoder wired to the RIO and use PWM. This is all to maintain the minimum possible time lag in the system.

[ozrien]

The Talon SRX reports the sensor position and sensor velocity every 20ms. The control frame to the Talon is sent every 10ms.

If you are using C++/Java you can change these time periods. If you do this be sure to check the CAN metrics in the DS tab.

See sections 20.5 and 20.7 in the Talon SRX Software Reference Manual for details. Also section 15 for measuring CAN performance.

"Talon SRX Software Reference Manual 2014-12-26 (.pdf)"
http://www.crosstheroadelectronics.com/control_system.html

[Thad House]

From a controls standpoint, I wouldn't recommend this for most cases. There will be an increased time delay between getting the encoder value from the Talon to the RIO and sending back the new control command. If you're going to use processing on the RIO, it's better to have the encoder wired to the RIO and use PWM. This is all to maintain the minimum possible time lag in the system.

Even if running 10ms loops on the RoboRIO, you will be at max 10ms behind the actual sensor. Thats not that much, and just like ozrien said above, we can speed up the controls to lower that to even less. I don't believe latency across the CAN line would account to more then 1ms, which is negligible.

The Talon SRX reports the sensor position and sensor velocity every 20ms. The control frame to the Talon is sent every 10ms.

If you are using C++/Java you can change these time periods. If you do this be sure to check the CAN metrics in the DS tab.

See sections 20.5 and 20.7 in the Talon SRX Software Reference Manual for details. Also section 15 for measuring CAN performance.

"Talon SRX Software Reference Manual 2014-12-26 (.pdf)"
http://www.crosstheroadelectronics.com/control_system.html

Is there any timeline for when that functionality will be added to LabVIEW? That could be something good to have.

[Foster]

From a controls standpoint, I wouldn't recommend this for most cases. There will be an increased time delay between getting the encoder value from the Talon to the RIO and sending back the new control command. If you're going to use processing on the RIO, it's better to have the encoder wired to the RIO and use PWM. This is all to maintain the minimum possible time lag in the system.

Can I get some more details about this?

From what I read the values come back every 20ms. You get new values 50 times a second (20*50=1000ms=1 second)

The update rate is at 10ms, so you can update it 100 times a second, You are using slightly stale data.

At 10 fps (random robot speed that seemed reasonable) you will travel ~2.5 inches per 20ms period.

But you are not going to stop on a dime ( or turn on one) since your 120lb robot moving 10 fps has a lot of momentum.

Are the drive trains / actuators that sensitive to need higher update rates?

Or is this just a case of faster is always better?

[KrazyCarl92]

See sections 20.5 and 20.7 in the Talon SRX Software Reference Manual for details. Also section 15 for measuring CAN performance.

"Talon SRX Software Reference Manual 2014-12-26 (.pdf)"
http://www.crosstheroadelectronics.com/control_system.html

These links are dead for me; they redirect to the Talon SR product page. When I try to right click and save as to recover the .pdf files, it says that the files are damaged or unrecognizable upon attempting to open them. Our team would be interested in the information in these documents, but we are unable to access them.

In particular we are interested in how many pulses per second the Talon SRX is capable of reading from a quadrature encoder in CAN.

[ozrien]

Just to be clear you went to ....

http://www.crosstheroadelectronics.com/control_system.html

...and clicked on the "Talon SRX Software Reference Manual 2014-12-26 (.pdf)" hyperlink at the bottom and it redirected to Talon SR?

These links are dead for me; they redirect to the Talon SR product page. When I try to right click and save as to recover the .pdf files, it says that the files are damaged or unrecognizable upon attempting to open them. Our team would be interested in the information in these documents, but we are unable to access them.

In particular we are interested in how many pulses per second the Talon SRX is capable of reading from a quadrature encoder in CAN.

[KrazyCarl92]

Just to be clear you went to ....

http://www.crosstheroadelectronics.com/control_system.html

...and clicked on the "Talon SRX Software Reference Manual 2014-12-26 (.pdf)" hyperlink at the bottom and it redirected to Talon SR?

Exactly. When I hover over that link, it displays:
"www.crosstheroadelectronics.com/Talon SRX Software Reference Manual.pdf"
in the lower left corner of my browser (Google Chrome) in a gray box.

Then I click it and I end up here:
http://www.crosstheroadelectronics.com/Talon%20SRX%20Software%20Reference%20Manual.pdf

I'm no expert, but it might be helpful to change the " " (space) character in the file name and directory to an "_" (underscore). My browser seems to replace the space with a percent symbol and then direct me to the wrong page as a result.

[Bob Steele]

Where does this take you?:

http://content.vexrobotics.com/vexpro/pdf/217-8080-Talon-SRX-Software-Reference-Manual-20141226.pdf


It should take you to the software manual directly.

[ozrien]

That's correct, space ' ' is encoded as %20.
Yeah I don't get it, both style paths seem to work for me, iexplorer and chrome.

crosstheroadelectronics.com/Talon SRX Software Reference Manual.pdf
crosstheroadelectronics.com/Talon%20SRX%20Software%20Reference%20Manual.pdf

Anyone else having trouble?

You can also just google Talon SRX Software Reference Manual.
Also it's on vex's site
http://www.vexrobotics.com/217-8080.html

[KrazyCarl92]

I am able to access it from the vexpro site, thanks for pointing that out.

[nixiebunny]

We just got 10 Talon SRXs in the mail. I had to take one of them apart. It has the requisite 4 MOSFETs and a PIC dsp33EP128 something.

As far as closing a PID loop via the roboRIO, why bother if you can do it in the Talon itself? Latency is key to good PID behavior. Letting the Talon do the work is the logical method.

[SoftwareBug2.0]

Are the drive trains / actuators that sensitive to need higher update rates?

Or is this just a case of faster is always better?

Faster updates may allow not only "slightly better" results from a control system, but actually allow different algorithms to be used. For example, it might allow you to switch from PID to bang bang.

In 2013 there were a lot of shooters that had a CIM turning a single small wheel. This is basically the formula for having a twitchy system - a lot of power and little momentum. I bet a lot of those would have benefitted from faster updates.

[cbale2000]

Out of curiosity, does using the Talons to handle the encoders and PID free up processing power on the roboRIO or is it still dependent on the control system?

[richwong]

Out of curiosity, does using the Talons to handle the encoders and PID free up processing power on the roboRIO or is it still dependent on the control system?

It frees up the roboRIO.