understanding position control with encoders

[Jeringo]

Greetings I am trying to program for a shooter that has a variable tilt from anywhere between 0 and 80 degrees. we are using a talonSRX with an encoder on it (http://www.vexrobotics.com/217-5046.html). My question is how exactly does position control work? We have set the feedback device to Quad Encoder and changed the control mode to position. From there we set the encoder counts per rev to many numbers currently 45, set the encoder position to 0. Now here is where the confusing part comes in Do I need to use SetPID and if so how do I use it. Is there a way to set the max velocity or slow the motor down? Is there any good way to calibrate the code so that I can set(10) and get 10 degrees? Thanks.

[Ether]

Originally Posted by Jeringo

My question is how exactly does position control work?

While you are waiting for other responses, download the Talon SRX Software Reference Manual from the manufacturer's website. Everything you need to know is in there, including examples.

Also these:

http://link.vex.com/vexpro/pdf/217-5046-instructions

http://link.vex.com/vexpro/pdf/217-5049-user-guide

[Camilo86]

What you need to do is create a command that initializes the talon's srx PID. Since you have it in position mode, the setPoint is going to be the distance you want the arm to go to. You will need to set a constant that relates degrees to ticks. You can use the configEncoderCodesPerRev() to do so (this is assuming the encoders are connected directly to the talon srx). We do something similar. https://github.com/FRC125/NU16/blob/...sitionCmd.java

[virtuald]

Originally Posted by Jeringo

Greetings I am trying to program for a shooter that has a variable tilt from anywhere between 0 and 80 degrees. we are using a talonSRX with an encoder on it (http://www.vexrobotics.com/217-5046.html). My question is how exactly does position control work? We have set the feedback device to Quad Encoder and changed the control mode to position. From there we set the encoder counts per rev to many numbers currently 45, set the encoder position to 0. Now here is where the confusing part comes in Do I need to use SetPID and if so how do I use it. Is there a way to set the max velocity or slow the motor down? Is there any good way to calibrate the code so that I can set(10) and get 10 degrees? Thanks.

It's probably too late, but for future reference you're often better off using a potentiometer or absolute encoder for a task where you need to use a motor to move something to a specific position.

The key challenge here (which it appears you've identified) is that you need a consistent zero position in order for the encoder to work reliably (eg, if you want to say "go to X"). Often, this is a consistent starting position (where the shooter is at rest) or you can use a limit switch to identify the position more precisely. Once this is good...

Then you have to do two things. First, you need to set the P, I, D parameters (setPID). You can either call setPID, or you can set it via the web dashboard. Often, you can get by with just a P (search for forums for more about PID tuning). I usually just set P to an arbitrary number (1), and keep incrementing it until it starts moving, then I adjust the value using binary search until it gets to where the value is reliable. There are more precise ways to do this, the TalonSRX reference manual has some examples.

For limiting the speed of the arm, check out the closed loop ramp rate, which can be set via the web dashboard or via setCloseLoopRampRate.

There are a bunch of code examples that CTRE provides, I recommend checking them out: https://github.com/CrossTheRoadElec/FRC-Examples . Additionally, the TalonSRX softwware reference manual has a lot of good explanation+documentation available.

[Ether]

Originally Posted by virtuald

It's probably too late, but for future reference you're often better off using a potentiometer or absolute encoder

...

[virtuald]

Originally Posted by Ether

...

That sounds like an awesome product, didn't realize it existed.

[virtuald]

Oh. Ha. Ok. Yes, it is an absolute encoder. Ignore what I said then. As I sadi above, didn't realize that it existed, so when I saw 'encoder' without absolute I made assumptions.

Kids, this is why you don't assume. Otherwise, Ether points out your follies.

[Alan Anderson]

Originally Posted by virtuald

That sounds like an awesome product, didn't realize it existed.

It's the encoder the original poster identified as what he is using. Ether has a habit of offering up raw information without extra explanation. I think he wants to give the reader the opportunity to figure out why it might be relevant.