|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
Talon SRX Encoder Signal Processing Trouble
Recently my team has decided to switch to Talon SRX controllers. I've been moving slowly towards working with the PID controls on them, but I have a problem. Whenever I run the motors forward, the encoder counts backwards. When I run the motors in reverse, the encoder counts up. The CTR Reference Manual labels this as a problem if I want to use the closed loop features. I have attempted to use the SetReference.vi as suggested in the manual with no success. I am using a Grayhill 63R 256 count digital encoder. The wiring has been done correctly from the Grayhill to the breakout board.
http://www.grayhill.com/assets/1/7/Opt_Encoder_63R.pdf |
|
#2
|
||||
|
||||
|
Re: Talon SRX Encoder Signal Processing Trouble
Can you check the self test to see if the reverse-setting is taking effect (see screenshot in Section 7.4. Reversing sensor direction, best practices.). Is the Selected Sensor Pos the inverse or equal to the Quad Pos?
Be sure enable the robot (even briefly) to allow settings to pass into Talon. See Section 16.2 for details. |
|
#3
|
||||
|
||||
|
Re: Talon SRX Encoder Signal Processing Trouble
I just noticed your third screenshot. Pull out "Sensor Position" from the "unbundle by name" object instead of "Quad Position". Section 16.9 explains it better, but "Sensor Position" is what is used in the internal closed-loop.
|
|
#4
|
||||
|
||||
|
Re: Talon SRX Encoder Signal Processing Trouble
A hardware fix: It is a little messy but you could swap the A & B input wires? I prefer to fix thing like this in software & leave the hardware standard, but there are other view points.
|
|
#5
|
|||
|
|||
|
Re: Talon SRX Encoder Signal Processing Trouble
Quote:
|
|
#6
|
||||
|
||||
|
Re: Talon SRX Encoder Signal Processing Trouble
(For completeness-) Or switch the motor leads.
|
|
#7
|
|||
|
|||
|
Re: Talon SRX Encoder Signal Processing Trouble
I finally found the problem this morning.
My original problem was that I didn't know the Talon Set Reference vi doesn't come with a Talon Send vi inside of it, and you need the Send vi to save any changes, such as the Reverse Feedback Sensor setting. In some of my earlier attempts to fix this issue on my own, I placed a SetReference in disabled to try and update the value outside of Begin.vi. It didn't work when I set it to true and I didn't know why. I found out later when Omar Zrien pointed out Section 21.20 of the CTR Software Manual to me, but at that time, I thought setting the value to false might fix it somehow. It didn't, so I promptly forgot about it and let it sit as a false constant. While working with Omar, I learned about Section 21.20, so I added the Talon Send vi in the Set Reference vi and placed it in Teleop to constantly update the value. I noticed something was fighting it, as if there was another value being sent to it (Hello Disabled!). I did a search, found my chunk of code in Disabled, and quickly removed it. Another redeployment confirmed that my problem was solved. Thanks so much to everyone for helping out, and special thanks to Omar Zrien for working directly with me to figure it out! |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|