Guys I think we're spending way to much time trying to decide if we should do it and not enough time saying "Screw it!" and doing it anyway. - Jalerre [more]
 Chief Delphi Encoder decoding factors & the Talon SRX
 User Name Remember Me? Password
 CD-Media CD-Spy
 portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 Thread Tools Rate Thread Display Modes
#1
09-06-2018, 10:16 PM
 bishbot Registered User FRC #4913 Join Date: Sep 2018 Location: Huntington Beach, CA, US Posts: 2
Encoder decoding factors & the Talon SRX

So I'm confused about the decoding factors. So if I wire up an encoder to the roboRIO and decide to program with Java, then I need to use the Encoder class from wpilibj. However, I don't understand decoding factors. So if you instantiate an encoder, if you don't specify the decoding factor (like 1X, 2X, or 4X), then the encoder, by default, uses 4X decoding. If this post is too long, then please bare with me, because I'm so confused

So if I use a PG71 motor and I use the encoder that comes with the PG71, the encoder makes 497 counts per revolution of the shaft at the end of the gearbox. Let's say that I don't specify the decoding factor when I instantiate it and, as a result, the encoder uses the default decoding factor (which is 4X). And I choose the unit for distance as a revolution of the shaft at the end of the PG71 gearbox. My understanding of the decoding factor is that each of the "counts" in the 497 counts/rev is really an encoder cycle, so if decoding factor is 4X, then all 4 edges of each encoder cycle is counted, and so the actual number of counts/rev is 497 x 4 = 1988 counts/rev. So, when I use setDistancePerPulse(), do I do setDistancePerPulse(1/497)? or do I do setDistancePerPulse(1/1988)? Does changing the decoding factor affect the double that you put in the setDistancePerPulse() method?

Also, what's the difference between the get() and getRaw() methods? Does getRaw() only get you the number of encoder cycles, and get() will get the actual counts by multiplying the number of encoder cycles by the decoding factor?

Now, as for programming an encoder when it's wired to a Talon SRX. The Talon SRX always does 4X decoding, right? And let's say that I use the set(ControlMode mode, double value) method. Let's say that I, again, use the PG71 motor, and I wire the encoder from the PG71 to the Talon SRX, and that the control mode I wanna use is Position, so the output value is in encoder "ticks". If I want to make the shaft at the end of the PG71 motor turn 1 full revolution, and the Talon SRX always does 4X decoding, do I do set(ControlMode.Position, 497) or set(ControlMode.Position, 1988)?

Also, can I use a Talon SRX with an encoder wired to it without specifying a PID loop and the PID gains? By that, I mean that can I do something like set(ControlMode.Position, 497) and when I run it, the PG71 will turn until 497 encoder ticks has been made and that in the event that it overshoots, it will rotate backwards until the encoder ticks go to 497 when I don't specify any PID loop and PID gains whatsoever?
#2
09-10-2018, 07:13 AM
 gerthworm Making the 1's and 0's FRC #1736 (Robot Casserole) Team Role: Mentor Join Date: Jan 2015 Rookie Year: 2015 Location: Peoria, IL Posts: 645
Re: Encoder decoding factors & the Talon SRX

Don't loose hope, you can learn!

Quadrature encoders produce two square waves, offset by a "phase angle" of 90 degrees.

"Decoding Factor" refers to the fact that in every period of a quadrature encoder has four edges you could potentially count:

For most FRC applications, choose 4x. Then, any time you convert from "encoder edges" to some other unit, remember there are 4 counts per period.

Now, as you mentioned, manufactures will publish some info on what the encoder resolution is. I have seen "counts" be ambiguous sometimes. I've seen datasheets both were it refers to the number of periods per revolution or number of edges per revolution. I'm not 100% sure which it is for the PG71. However, you know you will either be correct or off by a factor of 4. Historically, when setting setDistancePerPulse(), we've just figured it out by trial and error.

FYI, the following documentation for setDistancePerPulse() is provided in a recent version of wpilibj:

Code:
``` /**
* Set the distance per pulse for this encoder. This sets the multiplier used to determine the
* distance driven based on the count value from the encoder. Do not include the decoding type in
* this scale. The library already compensates for the decoding type. Set this value based on the
* encoder's rated Pulses per Revolution and factor in gearing reductions following the encoder
* shaft. This distance can be in any units you like, linear or angular.
**/```
Per the code comments in a recent wpilibj commit, the following functions return:

getRaw() - encoder edge count
get() - period count (edges, but accounts for decoding factor)
getDistance() - meaningful unit (accounts for setDistancePerPulse)

For the talon, it uses separate encoder processing from wpilib content, so assumptions will not necessarily transfer. I think the behavior depends on the firmware version of the SRX. I recall in 2018 we ended up doing some conversion for velocity units in our code (SRX had a per/100ms factor baked in to their desired units, I think). I haven't done position control on these however, someone else would be better to answer with experience.

As to your final PID gains spec, unfortuantely the answer is no, today. What you're describing is a sort of bang-bang controller (full command to push the actuator toward the setpoint at all times). This is still a closed loop system, just with a different controller than a PID. As far as I know, right now, Talon SRX's do not support bang-bang as the feedback controller. However...

A bang-bang controller as you describe is actually a PID with gains
P = SUPER HUGE
I = 0
D = 0

So indirectly yes, you can do what you're asking (since I have specified the PID gains, you don't have to ).
#3
09-13-2018, 03:58 AM
 bishbot Registered User FRC #4913 Join Date: Sep 2018 Location: Huntington Beach, CA, US Posts: 2
Re: Encoder decoding factors & the Talon SRX

Thanks. That help cleared up some confusion. So I need to keep in mind whether the counts or distance are off by a factor of 4 if I'm using get(), getRaw(), getDistance(), and setDistancePerPulse(), right? And also, since your team historically had some trial and error every time they used setDistancePerPulse(), my team will also go through some trial and error with setDistancePerPulse() and figure out which ratio that's off by a factor of 4 to use, if we decide to use wpilibj and wire the encoder to the roboRIO.

Judging by the comments on setDistancePerPulse(), though, which said "Do not include the encoding type," I guess that if I use "revolution" as the unit for "distance" and I use a PG71, then I would need to do setDistancePerPulse(1/497) rather than setDistancePerPulse(1/1988) because the former doesn't include the encoding type. That's only my guess, though.

Your comments about the difference between get() and getRaw() are super helpful, btw. I have a much better idea of what the difference between the 2 methods are now. So getRaw() is basically the number of periods from get() multiplied by the decoding type, right? So if we use the default decoding type (4X), then the value we get from getRaw() is basically the number of periods multiplied by 4, right?

Also, as for programming an encoder that's connected to a Talon SRX and PID gains, since you said that the Talon SRX probably doesn't support that kind "bang-bang" control, that would mean that I need to specify the PID gains and a PID loop, right? My team is preparing to test an encoder on a PG188 and we're planning to wire the encoder to a Talon SRX. You really saved us time on figuring out whether we need to specify PID gains or a PID loop.

Thanks for the help ! None of the programmers on my team know what an encoder is until 2 weeks ago. So, we're a bit uninformed on encoders, to say the least. Your comments are sorely needed
#4
09-16-2018, 01:24 PM
 gerthworm Making the 1's and 0's FRC #1736 (Robot Casserole) Team Role: Mentor Join Date: Jan 2015 Rookie Year: 2015 Location: Peoria, IL Posts: 645
Re: Encoder decoding factors & the Talon SRX

No prob, glad to help! The nuances of working with encoders are often glossed over in documentation, so glad this brought some clarity.

I too would guess that a setting of setDistancePerPulse(1/497) should get ya to be measuring number of gearbox output shaft resolutions. Furthermore, reading a bit into andymark's documentation, the comment of "pulses per revolution" implies each signal (A or B by themselves) will output 497 pulses per output shaft rotation. That means there will also be 497 total electrical periods (or 1988 edges) per revolution.

As far as software terminology goes, the "Raw" portion of the function name generally implies you're reading values straight from the hardware with no modification to make the value more useful. For this reason, it makes sense that the "Raw" value wouldn't account for encoding, under the presumption that the encoder reading hardware (inside the FPGA) is just counting edges.

For the SRX, yea, program it just like you're setting up a normal PID. Note that the trick of "Just use giant P" works only because the system under control isn't very sensitive to inputs. What "Sensitive to input" means can get a bit harry (mathematically speaking). A rule of thumb is is that if hooking a full 12V up to the motor for more than a second or two causes bad things to happen, you probably need something a bit more nuanced than bang-bang control. For example, our elevator this year had a top-to-bottom traversal time of about 7 seconds while loaded. Bang-bang worked great for it. 254's elevator (and many others) had a traversal time closer to 1 second. Bang Bang would have ended very poorly here. Of course, all this is much less about encoders and much more about just general closed-loop control.

One thing you may not have seen yet - to get the WPILib or SRX built-in closed loop algorithms to work, you have to get everything configured such that positive control effort (ie motor command values > 0) cause the sensor value to increase. SRX provides some API's to invert the sensor read direction ("Phase", I think is what they call it?). I recommend checking this before running closed loop by just commanding motor values and seeing which way the sensor value changes. If this is backward, your system will rail the output command at the opposite value of what it should be and keep it there till you disable.

 Thread Tools Display Modes Rate This Thread Linear Mode Rate This Thread: 5 : Excellent 4 : Good 3 : Average 2 : Bad 1 : Terrible

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts vB code is On Smilies are On [IMG] code is On HTML code is Off
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Announcements     User Announcements FIRST     General Forum         FIRST E-Mail Blast Archive     Rumor Mill     Career     Robot Showcase Technical     Technical Discussion     Robotics Education and Curriculum     Motors     Electrical         CAN     Programming         NI LabVIEW         C/C++         Java         Python     Control System         FRC Control System         Sensors     Pneumatics     Kit & Additional Hardware     CAD         Inventor         SolidWorks         Creo     IT / Communications         3D Animation and Competition         Website Design/Showcase         Videography and Photography         Computer Graphics     National Instruments LabVIEW and Data Acquisition         LabView and Data Acquisition Competition     Unsung FIRST Heroes     Awards         Chairman's Award     Rules/Strategy         Scouting         You Make The Call     Team Organization         Fundraising         Starting New Teams         Finding A Team         College Teams     Championship Event     Regional Competitions     District Events     Off-Season Events     Thanks and/or Congrats     FRC Game Design     OCCRA         OCCRA Q&A         OCCRA Programming Other     Chit-Chat         Games/Trivia             Fantasy FIRST     Car Nack's Corner     College & University Education     Dean Kamen's Inventions     FIRST-related Organizations         Western Region Robotics Forum         Southern California Regional Robotics Forum         The Blue Alliance             Video Archives     FIRST In the News...     FIRST Lego League         Lego Mindstorm Discussion     FIRST Tech Challenge     VEX         VEX Robotics Competition         VEX IQ     Televised Robotics     Math and Science         NASA Discussion ChiefDelphi.com Website     CD Forum Support     Extra Discussion

All times are GMT -5. The time now is 04:25 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.

 -- English (12 hour) -- English (24 hour) Contact Us - Chief Delphi - Rules - Archive - Top

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi