How to use encoders

FIRST General Forum
#1

My team has never used encoders. This year our robot has a throwing arm (catapult) that we are driving with a toughbox and 2 CIMs. We have an encoder on the TB. My question is how do we use it. Our goal is to determine the position of the arm. Is it possible to determine absolute position using encoders? Sort of like the insides of a servo?

We use LabView to program and I’m not sure what the encoder connects to physically so that we can read it in LV. I know you can connect it directly to a Jaguar but since we have 2 CIMS we have to use 2 controllers and we were planning to use 2 Talons.

Any suggestions? My students are asking questions and I don’t have any answers.

Thanks.

#2

As a team that just started integrating sensors 2 years ago, these are our first trial and errors:

For an absolute position, there are absolute encoders, but I cannot tell you where to find any. How we do absolute position is by using limit switches to reset a relative position anytime a limit switch is hit. This year we are using a gear tooth counter on our arm, because of the way we are running it, with two limit switches on either side to set the limit angles, and also prevent from over-rotating.

You will get a chance to show your students how math is used with the encoder on your toughbox, because you want to find out mathematically what your ratio will be of how fast the encoder spins to how much the angle changes (assuming you are using optical or any shaft based encoder). Try not to do it experimentally, because with encoders, the mathematical formulas are more often than not more accurate than anything you can measure. (Took us a whole season to learn that lesson).

Anything else you need I am sure all of us at Chief Delphi have answers for you. :slight_smile:

#3

If you’re going a few rotations, you can use a potentiometer. They are sold at DigiKey (http://digikey.com) under ‘linear potentiometers’. They come in 1-turn (most are actually 270 degrees), 3 turn, 5 turn, and 10 turn. They are connected to an analog breakout and give a voltage between 0 and 5v (it’s actually a variable resistor, so it’s a ratio between the ground and power you feed it, which is 5v from the analog breakout).

If you need an absolute encoder, I’ve heard good things about DigiKey 987-1393-ND (360 degree absolute encoder) from Chief. We bought a bunch, and I will report their performance later.

#4

The attached link seems to be incorrect, the site is about optic fibre cable manufacturing, rather then encoders

#5

Start Labview.
Click “Support”
Click “Find FRC Examples”
Under “Sensors” Find the “Motor with Encoder” Project.

The front panel shows the wiring for the example, this is with a two channel incremental encoder.

Incremental encoders, give a count that is equal to the resolution of the encoder, usually stated as PPR, pulses per revolution, or counts per revolution.

Review the labview code, ask questions here.

Let us know what encoder you are using, and where in the gear train it is mounted.

#6

Do the methods in the Labview examples work the same if the encoder is connected via a Talon SRX encoder input?
My teams programmers have been struggling to get these encoders on our drive system working since the start of the season. :frowning:

#7

The example I listed does not deal with that application but there is an example called “CAN Talon Speed Control Encoder” that does address that. The front panel in the labview VI has the instructions.

Just a reminder, when you run these examples, even though you may not have a full robot hooked up, you still need to run a drivers station and enable teleop for them to work. It is in the instructions, but many people seem to overlook this step.

EDIT: this example can be found under the “CAN” sub-folder for the roborio.

#8

Thanks for you help, the broken link that I was referencing was actually on a post which has now vanished, it did seem suspicious (probably removed by the moderators)

#9

Hey Chris,
Since you are using the Talon’s sensor features I would start by looking at our Talon SRX software reference manual…
http://www.ctr-electronics.com/talon-srx.html#product_tabs_technical_resources

Section 2.4 goes over the roboRIO web-based config which is an easy way to get the sensor value so you can sanity check the position/velocity. This works even with no code deployed because the Talon is always decoding sensor signals. Also the web page lets you set settings without having to write code, which is great for getting started and quick tweaking. All the settings in the web page are persistent.

Section 5.1 has a LabVIEW example on un-bundling signals including Sensor Position and Sensor Velocity.

Section 7.1 has a LabVIEW example on selecting the sensor type, be sure to direct the sensor to be in phase with the motor if you want to use the internal closed-loop features (section 7.4).

Section 13 has examples for setting the sensor position, great for zero-ing all your sensors.

Section 16.9 has some good stuff on processing the sensor data yourself if you don’t want to the Talon to closed-loop for you. You can control how fast the Talon sends sensor pos/velocity to the RIO so you can choose how much you want to offload to the Talon. This is neat because each Talon effectively gives you an additional 1x analog input, 1x quad input, 2 digital inputs (you can use limit switch inputs just for measurement if you want), and 1x pulse width decoder.

The sensor position and velocity were all in native-units last season, which is explained in section 17.

Scott’s mentioned example is a good one too. Has the PIDF gains broken out in a VI for easy tweaking.

#10

Thanks both of you, all this information is very helpful

I believe our programming lead did look into running the encoders through the Talons directly, but she has been having some issues getting the web interface to actually come up for some reason (not sure if it’s an issue with our computer, the CAN setup, or something else).

Programming is a bit outside of my area and my Labview is a bit rusty, but it seems like I may have to force myself to re-learn it to finally figure these things out, since our programmers have been unable to for the last 6 months. :frowning:

#11

If you can describe the symptoms we can likely help. One thought is that Chrome does not support Silverlight. I recommend using internet explorer or mozilla-firefox.

#12

Encoders are scary at first, but really are not difficult. Basically, an encoder of the type I think you have (you don’t state it, but connected to a TB is likely a US Encoder) gives out X number of pulses for each revolution, from 2 different outputs. You count pulses to determine movement, limited by the number of pulses per revolution*

2 outputs allow you to determine direction, not just movement.

Counting the pulses and comparing that to time allows you to determine speed.

It is possible to count the pulses, including the direction information, and know the absolute position of the arm. I think a Potentiometer may be a better choice, however, since it is better suited to position sensing because of its greater sensitivity to small movements and its lack of dependence upon counting (which, if fouled up, becomes inaccurate). Also, see the * note for a discussion of resolution. A potentiometer is also simpler to program, since it uses an analog input, the voltage being related to the arm position. The downside is you mount it on the arm, not the gearbox.

As for programming, there is sample code as others mentioned, but basically you count pulses and keep track it them. I can’t help you with Talon programming; I suggest you use the Talons as motor controllers only until you get some experience, since LV is more easily troubleshot.

*If you have an encoder that delivers 128 pulses per revolution (PPR), the best you can get is to detect 1/128th of a revolution. This may limit what you can accomplish.
2 outputs are not in-phase with each other, but they are digital pulses, so if one output signals before the other, you are sure it is going in one direction, and if the other output signals before the first, then it is going in the other direction. This works pretty well, by the way.

Try things, explain the problems encountered here, we’ll help.

#13

I feel like I should mention the OP is from February 2014, almost two years ago. Your post is very helpful, but I’m not sure the OP will see it.

#14

Ha, Ha, oops, details… :slight_smile:

#15