How is velocity control supposed to work on the Talon SRX?

[Kevin Sevcik]

I'd just like to add that if you have a fixed target speed, or at least a known maximum speed, that's what you should tune your FF at. There's inevitably going to be some non-linearities in the system, so if you know what your target or range will be, it makes more sense to minimize your FF error there.

[Ether]

Originally Posted by Kevin Sevcik

I'd just like to add that if you have a fixed target speed, or at least a known maximum speed, that's what you should tune your FF at. There's inevitably going to be some non-linearities in the system, so if you know what your target or range will be, it makes more sense to minimize your FF error there.

Excellent point. I was assuming that would be inferred. Never assume.

[ajlapp]

Does using this strategy prevent the controller from requesting max duty cycle when starting from zero?

What I'm currently seeing is my FF go to the requested value and stay there until near the target speed....the P term does not seem to boost the duty cycle request to max at startup as I initially expected.

[Kevin Sevcik]

Originally Posted by ajlapp

Does using this strategy prevent the controller from requesting max duty cycle when starting from zero?

What I'm currently seeing is my FF go to the requested value and stay there until near the target speed....the P term does not seem to boost the duty cycle request to max at startup as I initially expected.

It depends on your P and D terms and ramp rates. P works off the error in velocity, so is P is small, P*error might not be large enough to get 100% throttle. D works from change in error per cycle. It typically works against P. If your error is decreasing rapidly, D*err/time is negative, which reduces your throttle command from what P + FF would set. Too big a D term could limit how fast you come up to speed because of this. Finally, voltage ramp rate and closed loop ramp rate limit how fast the output can change. Your ramp rate has to be faster than the physical acceleration of the system, or by the time 100% output is allowed by the ramping, the error is too low for 100% output to be required.

What are your FF P and D terms, and target speed in encoder counts per second? (srx mag encoder is 4096 counts per rev, other encoders are 4 x CPR counts per rev)

[efoote868]

Originally Posted by ajlapp

Does using this strategy prevent the controller from requesting max duty cycle when starting from zero?

What I'm currently seeing is my FF go to the requested value and stay there until near the target speed....the P term does not seem to boost the duty cycle request to max at startup as I initially expected.

Not necessarily, it depends what your P term and your set point are.

[ajlapp]

I'll double check everything in a bit....but I'm not using any ramp rate or any D...

I tried large P gains, so I thought, but saw almost no effect.

Perhaps they weren't large enough.

[Paul Copioli]

Originally Posted by ajlapp

Does using this strategy prevent the controller from requesting max duty cycle when starting from zero?

What I'm currently seeing is my FF go to the requested value and stay there until near the target speed....the P term does not seem to boost the duty cycle request to max at startup as I initially expected.

Anthony,

I use I for that. I know 254 and even the SRX manual says go FF - P - D, but I am a purist. Note that if you use motion profile (externally) it will also get you what you desire.

For everyone else, real robot companies basically do this:

1. Tune FF (which is usually variable depending on desired speed) More on this later.

2. Tune I (this helps acceleration to desired speed)

3. Tune P (oscillations, blah, blah)

4. Tune D, if necessary

Note that if you are using an external motion profile generator (see 3310's code for the 2015 robot on Github) then you don't really need to tune I and tuning P/D is fine as the motion generator sets command velocity at each time step and the change in command is very low.


OK, let's demystify Feed Forward. It is really quite simple. FF is the command voltage (PWM duty cycle, whatever your team calls it when you give different voltages to the motor from the speed controller) it would take if everything is perfect with no friction, etc.

Some of us calculate that using the motor equations that relate voltage, current, rotational velocity, etc. but this is really not necessary.

Experimentally, you give the speed controller different open loop PWM commands until it goes to the speed you need with no other devices running (Jared spoke of this earlier). Record that voltage, do the unit conversions required for the Talon and now you get your multiplier (aka, FF gain).

From a pure control theory point of view, I gain for speed control is the same as P gain for position control. If you ONLY use P gain, then you will get to only about 50 - 60% of your desired speed. When you use FF gain, then this does not apply and eliminating I gain is fine for most.

However, I gain will help accelerate a little faster than just FF gain alone if your FF gain isn't already at max voltage (Which I do not recommend. Pick a desired wheel speed that is significantly slower than motor free speed so you have headroom for disturbances)

Paul