# simulation/analysis of motorized shooter

*I coded a very simple dynamic model of a motorized shooter wheel. The model has constant kinetic friction and RPM-dependent drag, but no mechanical free play between motor and wheel. The model has no sensor noise or phase lag. I’m running the model at 1 microsecond steps.

Here’s the model. p1 thru p4 are tuning parameters:

``````*
*[strike]if (PWM=0) accel=0; else accel=p2*PWM*(1-RPM/(p1*PWM));[/strike]
accel=p2*(PWM-RPM/p1);    // assume linear speed vs torque motor curve
if (accel<0) accel=0;     // assume no regen braking
if (RPM<=0) decel=0; else decel=p3*RPM+p4;
accel -= decel;
``````

I tuned the model to behave somewhat like the real world open-loop with a 0 to +1 PWM step input and a +1 to 0 PWM step input.

I then ran the model with 3 different speed controllers running at 10ms iteration rate:

1. Bang-Bang

2. Integration Only

3. Take-Back-Half

The results were interesting, but I’m not sure the model is good enough to trust the results.

So… has anyone done a more comprehensive simulation of the motorized shooter and studied the behavior of various speed control algorithms for spinup response, recovery response (disturbance rejection), accuracy, and stability?

Especially interesting would be the effect on the different control algorithms of sensor noise and phase lag, and mechanical free play between the motor and wheel.

Curious, in your accel equation, “PWM” cancels out in numerator and denominator - so it would have no effect on accel. It looks like you are trying to estimate torque based on a delta to final speed?

Personal preference, I would prefer to see an inertia term in there explicitly so you have some relation to the physical world instead of just p1 / p2, so you can sort of check whether the parameters you end up with are realistic.

I’m curious enough to try this myself, if you can explain your accel reasoning (I think you know far more about motor modeling than I!)

I think it’s just an artifact of the formatting. See attached.  It doesn’t cancel out, the PWM is still there when you multiply it out:

accel = p2PWM(1-RPM/(p1PWM)) = p2(PWM-RPM/p1)

It probably would have been better to formulate it like that, because there would be no problem with divide-by-zero and I could have removed the conditional logic.

It looks like you are trying to estimate torque based on a delta to final speed?

That simple formula predicts the motor torque available for a given RPM and voltage (PWM), assuming a linear motor torque vs speed curve. You can think of p2 as the stall torque, and p1 as the free speed.

Personal preference, I would prefer to see an inertia term in there explicitly so you have some relation to the physical world instead of just p1 / p2, so you can sort of check whether the parameters you end up with are realistic.

Yeah, if I were going to spend more time on this I would get all the units right and do it the way you suggested, for the reason you stated. But I knew ahead of time I was just going to tweak parameters to get to “roughly” model the real world, so I kept it simple (and admittedly somewhat obscure).

I’m curious enough to try this myself, if you can explain your accel reasoning (I think you know far more about motor modeling than I!)

I think you’re on the right track. Do you have access to a proper modeling environment? Please share your results if you decide to pursue this. FWIW, I’ve posted C-code for the Take-Back-Half algorithm.

Thanks for the clarification, operator precedence got me.

I do have a couple environments I can try, I will do so and let you know the results (may be a couple days though).

FWIW I would normally model speed-dependent friction as a square of speed term instead of linearly. It would probably change one’s decision on which code is best, at least if you didn’t have decent (ballpark) gains to start with.

I was thinking more about vibration than windage. I wasn’t sure off-hand whether vibration would be linear or square (it’s probably neither - peaks at resonance more likely). I didn’t use the p3 term anyway for my quick tuning so it was a moot point for me.

I will do so and let you know the results (may be a couple days though).

Excellent.

Hi Mark,

Is this still on your plate?

I built the model but not yet the controller. Can you share your model parameters? I don’t have a good frame of reference for what a reasonable response time should be (I work with dynamic systems that are much, much, much larger than FRC robots… big yellow and black machines :).

*Mark,

For rough ballpark: assume load moment of inertia of a 3 pound 6" dia uniform disk. Assume CIM shaft coupled directly to wheel. 5300 RPM free speed, 343 ounce-inches stall torque, linear. At setpoint of 4000 RPM, tune so decel (motor command = 0) is 1/3(?) of accel (motor command = 1).

Controller:

bang-bang needs no explanation.

TakeBackHalf can be found here.