When utilizing a Talon SRX in position mode with a QuadEncoder…
is that desired position a specific set point of the encoder ticks? Is the position mode smart enough to drive backwards if the ticks are beyond it?
Or is that position argument a relative value, and its saying from this point rotate X ticks?
You probably need to start with their documentation to understand how it all bundles together.
From their docs:
The Position Closed-Loop control mode can be used to abruptly servo
to and maintain a target position.
The set point refers to the cumulative encoder ticks . If the encoder is at 1000 and you set your controller to 3000 in position mode, it will try to move 2000 ticks in whatever is your positive direction.
If the set point is less than the current position it will move in your negative direction .
Definitely check out the documentation and the CTRE GitHub examples.
Ah there is my issue.
If I am using the encoder on a turret that is constantly commanding a rotation error, if it was going to an absolute position on the axis, then it would work… but if I keep commanding that position (and then smaller angles as it gets closer) it will oversteer it…if that makes sense
I understand that portion… but it seems like the position controller points towards a relative rotation from your current point?
You might want to check out Motion Magic. It basically changes the setpoint as you get close so that it lands right on target.
Motion magic would definitely help with the overshooting , but you still need to feed it updated position set point . Motion magic will automatically give you a smooth velocity curve (speeding up and slowing down) as your turret travels to the target.
Oh I misunderstood. You’re constantly updating the setpoint not for smoothing but because the system never holds still long enough to reach its target. Right?
No, not quite.
Quadrature encoders are indeed relative sensors, but they are not relative from where you are. They are relative from the time they were initially set to zero.
So, for example, if in your Turret constructor you call talon.setSelectedSensorPosition(0), and NEVER call setSelectedSensorPosition(0) again, then it will relative to your original starting position for the remainder of time.
This is not true. The set point ONLY changes when you have set a new set point. If you repeatedly call talon.set(ControlMode.MotionMagic, setPoint) and never again modify setPoint, your mechanism should servo at the setPoint position until you change it. The difference between MotionMagic and Positional PID is generating the smooth acceleration, deceleration and velocity values.
Okay explain to me please. I thought mm varied velocity setpoint to smoothly get to a position
Yes, that is the # of encoder ticks.
For example, our 2019 elevator was 0 to 100,000 ticks. We set 50,000 ticks and it would do a typical PID loop to go to 50k ticks. If it went over, it would reduce power to move back down to 50k ticks.
It’s exactly what you think it is
MotionMagic generates a trapezoidal motion profile to get to a desired set point.
The ClosedLoopError is still going to be calculated as the feedback Setpoint - Currpoint which will be in encoder ticks, not velocity.
I will test this again tomorrow to make sure I’m not mis-remembering, but I’m pretty sure that plotting the closed loop error throughout MM is still the difference between eventual encoder ticks and the current.
So I played with the encoder/talon turret tonight.
Watching the gear that the encoder was attached to, and printing out sensor position, I moved the gear about a full rotation and only saw my sensor position increment by 200. Does that make sense? The encoder moved by 200 ticks? I was under the impression 1 rotation of the encoder was supposed to be 4096 ticks or so.
Then when setting the talon in position mode, with my value being 200 (which I thought would represent the amount of ticks), when I expected the motor to just go one rotation and then stop, it just ran continuously, way more than 1 rotation of the gear.
Clear I am just not understanding something. Is there something glaring that I am doing wrong?
First off make sure that gear to encoder ration is 1 to 1. Obviously if they are not 1 to 1, the amount of rotation between the two will differ. Quad encoders should read 4096 per rotation.
Motion magic and position control both requires PID in order to run, so if you PID is not tuned correctly you will not be getting any desired value that you want.
Without knowing exactly what you did, these two are the only thing that I can think of.
First off you need to make sure that motors and sensors are in phase with each other. In terms of the Talons, that means that when the LEDs are blinking green, that your encoder is going in a positive direction and when your LEDs are blinking red, your encoder is going in a negative direction.
None of this will work until you’ve gone through the entire Bring-Up Process that CTRE documents.
Once you have finished that, meaning you started from the beginning and didn’t skip any steps, then you are ready to start closed-loop control modes.
The next thing you need to understand is the physical mechanism between the encoder, and the actual thing you want to turn. For example, here’s how I would formulate the calculation to rotate my drive train wheel one time, in encoder ticks:
We use a 4 CIM motor setup, with ball shifting gear boxes. So, we actually have to account for two different stages from where our shaft encoder is plugged in, to actually spinning the wheels. The encoders plugged into that gearbox are Greyhill 63R-128. The 128 represents the number of cycles in one rotation.
The math lays out like this:
ticks per axle rotation * 3rd stage gear reduction * 1st stage gear reduction = encoder ticks per wheel rotation.
For our setup
128 cycles per rotation = 512 (4 edges per cycle with the quadrature encoder)
3rd stage gear reduction = 36/12 (ask your mechanical team about the gear reductions in the mechanism if you don’t know)
1st stage gear reduction = 64/20
Putting that all together = (512 * (36/12) * (64/20)) = 4915 ticks per wheel rotation.
To convert to a distance (however you measure, metric or imperial) we take 4915 / measurement.
In the case of a turret you may want to convert ticks to degrees or something, so 4915 / 360 would give you how many encoder ticks represent 1 degree of rotation.
This all makes sense. And then you would pass in that value to your set position method?
I am right now that that method is just move a number of ticks?
Not exactly. Your setpoint is not relative to the current position, but to the “zero” position. If you want to move the motor a certain number of ticks relative to where it is now, you can do something like talon.set(ControlMode.Position, talon.getSelectedSensorPosition() + setpoint).
Part of our robot startup procedure is to get the mechanism in what we want to call the zero position and then set the encoder count to zero.
For our elevator that means driving the elevator to the bottom and te-zeroing. During practice we call a method that drives the elevator down until it hits the lower limit switch and then zero the encoder there (setting a current limit serves as backup protection against overdriving in that case.
In competition we just make sure the elevator starts at bottom and rezero the encoder on startup.
For your turret you could do a similar thing - manually rotate the turret to where you want zero to be, then reset the encoder.
and that setpoint should just be the position, aka ticks? I feel like when I tried after my encoder was zero’ed, that didn’t work