Motorised fader seek algorithm

Playing around with a motor fader (Alps "K" type conductive plastic). Currently can store a random value and seek that stored value (a PIC and an L293D "H" bridge) but looking for a better way of "hitting the target" - currently the inertia in the system causes a bit of oscillation around the endpoint before the system stabilises (will no doubt get worse with the additional weight of a knob). How do the "big boy" console makers do it ?. Full steam ahead until within, say, 5% of the endpoint, then reduce current to the motor and creep the last bit ?. Any other ways ?.
M

Would a pwm rate based on the distance from target work?

I've never done one but I guessing you have full speed up, full speed down, or off... and read a linear pot for feedback?

I would be inclined to do some research to see what the overshoot is from different distances but a simple algorithm that should work is just move half way there each time.  Say you have a 20 increment move, first target 10 increments or half way there... It you overshoot to say 12 ticks split the 8 ticks remaining and target the next 4 tick step, read where you really end up and move another half way there... in a modest number of iterations you should get there without overshooting, and if your processor service is fast enough, it will all appear seamless...

or not, just how I would approach this.

JR

I don't write codes as I work with two good programmers  but it is called acceleration/descelleration.

On start you ramp up, reach to the maximum speed, then ramp down and stop at the destination.

Since the resistance track of the fader is likely audio taper, a non-linear accel/decel might be audibly weird. I would be inclined to just add constant delays in-between every step linearly for smooth transitions. Create a fader up and a fader down function for instance, in the faderup in pseudocode:

FaderUp(unsigned int newfaderposition)
{
while (currentfaderposition != newfaderposition)
++currentfaderposition;
delayms(10);
}

Something like that. Tweak, revise, repeat.
If it works the way you want it to, you could later refine it to just one fadermove function with signed integers for both up and down.

How about varying the delay by distance left to travel?

What you need is a "controller". There are different types, you want one that does reach the target without overshoot.

http://en.wikipedia.org/wiki/Controller_(control_theory)
http://en.wikipedia.org/wiki/Control_theory

http://en.wikipedia.org/wiki/PID_controller


Finding the perfect coefficients is not trivial though, there are several methods to get there. One is making some educated guesses and adjust from there . For algorithms look online, as usual you don't need to do all the work yourself.

Ethan said:

Since the resistance track of the fader is likely audio taper, a non-linear accel/decel might be audibly weird. I would be inclined to just add constant delays in-between every step linearly for smooth transitions. Create a fader up and a fader down function for instance, in the faderup in pseudocode:
..........

Click to expand...

Ethan,

The feedback track resistance will likely to be linear. I'll need to check the Alps I have.

The feedback track resistance will likely to be linear. I'll need to check the Alps I have.

Click to expand...

Ah! Well, then maybe logarithmic accel/deccel delay steps are needed. A little added complexity, but maybe some added fun.

Volker is bang on the money with his PID controller suggestion.

Rochey said:

Volker is bang on the money with his PID controller suggestion.

Click to expand...

I agree. At the moment I would guess your algorithm is simply proportional  (first order system) which is bound to overshoot in a second order (inertial) system). So you need the integral term too. Presumably you sample the pot value at fixed time intervals and use your algorithm to compute the motor voltage by comparing the current pot value with the required pot value. By saving the previous pot value and comparing it with the current pot value you can derive an integral term.

Can you post your current algorithm?

Cheers

Ian

It would also be useful to know how many faders are being controlled...

With variable drive voltage you could make a proportional controller that would be reasonably damped using one of the several PWM outputs of the PIC, and just tweak the speed based on remaining distance with every absolute position sample. I was ASSuming a simpler full speed forward/full back motor drive. You could also make a crude PWM with a smaller range of duty cycles, say 1/4s or 1/8s.

Like I said with my earlier answer, I'd start banging this thing and see how it acts... If driving a large bank of faders you probably don't want to involve too much complexity in the control, the PICs only have a few PWMs in firmware but you could always roll your own if this is all the PIC is doing.

Note you will have a sampling error situation, if you are sampling position while it is moving, by definition you will always over shoot if you don't stop the motor until after you reach your target. Perhaps real time sampling to get 90%(?)  there, then small finite pulses to step the rest of the way.

Or something entirely different  8)

JR 

Just a thought, but could you apply a quick "reverse motor" pulse when you reach the value, to act as a kind of magnetic clutch, thereby stopping the mechanism from shooting past due to inertia?

No. You don't do things like that. In fact that makes it even worse.

Basically you just can't stop at full speed. You have to ramp down and gently come to a stop.

However, that can be used for holding if there is no electromechanical break.

You should have some way to generate a fixed delay, perhaps a software idle loop? Or just count multiple calls to the AD that will take finite time for each call.  256 AD calls could give you a useful time interval with good resolution

Start by reading the AD and compare the result to your target then turn on the motor for X time intervals. This X time, should be less than predicted to get completely to the target which you will need to figure out empirically your starting rate. 

then take another reading, determine how far you still have left to travel and set another fixed time interval to run the motor.

At some point going a fraction each time, you will get very close to target and run the motor for the minimum length tick to get there.

This may seem lumpy in software, but the micro will be doing all this in microseconds or milliseconds so appear smooth.

There may be some start up friction issues that will establish a minimum reliable step size... for the motor fader combination


JR

PS:  to be clever you can adaptively learn the fader's response by logging how far it actually travelled for each time interval command and use that to more accurately predict future move commands.  if you always undershoot on purpose with progressively smaller steps you will be unlikely to overshoot and hunt around.  With a newer PIC you could save this learned response into flash memory, for a simple PIC you will need to learn it each time you turn it on, but could be a fast learner.

Thanks for the PID suggestions, guys, seems like I'm doing what a zillion toy robot builders have been doing (and documenting) for decades.
Cheers
M

The ICS are so cheap these days that you could put one per fader. Msp430g2xxx are small devices with timers.
You could use a 5cm x 5cm cheep pcb house like seed studio.
Use a dip switch to set I2c address and a hbridge to set direction.

Cute project.

mobyd said:

Playing around with a motor fader (Alps "K" type conductive plastic). Currently can store a random value and seek that stored value (a PIC and an L293D "H" bridge) but looking for a better way of "hitting the target" - currently the inertia in the system causes a bit of oscillation around the endpoint before the system stabilises (will no doubt get worse with the additional weight of a knob). How do the "big boy" console makers do it ?. Full steam ahead until within, say, 5% of the endpoint, then reduce current to the motor and creep the last bit ?. Any other ways ?.
M

Click to expand...

Basically, you need to do a trapezoidal velocity profile. You can't set the velocity at full tilt boogie from a dead start, nor can you come to a dead stop in zero time. So you gradually ramp up the speed until you're going as fast as possible. And then you need to know when to start decelerating so by the time you're at your desired stop position, your velocity is near zero, too.

This Silicon Labs app note has a really good explanation of the problem.

Here's the interesting part of the problem. The profile tells you, essentially, the velocity as a function of position. That means that when you're at position X you're moving some particular speed. That's all well and good, but think about how you'd actually implement that using a micro controller.

See, when you drive a stepper motor, the only control you have is the time between steps. As you speed up, you decrease the time between steps until it is some minimum and then you're slewing. At some point you have to start decelerating, which you do by gradually increasing the time between steps.

The trick, then, is to pre-calculate the step time ramp (assume that acceleration and deceleration have the same profile) and store the time steps in a lookup table. When you're told to move, you load your timer with an initial step interval. The timer expires, triggering an interrupt, and in the ISR you move one step, bump to the next index in the lookup table, get the new interval, load it into the timer, and restart the timer.

This continues until you've done all entries in the ramp table, at which point you're moving at full speed. That is, in your ISR you do the step and then reload the counter with the smallest interval (time between steps).

When you reach the number of steps after which you have to start decelerating, you index through the lookup table in the opposite direction. And finally you're done.

You need at least one position sensor, so you know if you're "home" because you need a reference. Of course, if you have something that tells you the absolute position, then you always know where you are.

-a

Andy Peters said:

See, when you drive a stepper motor, the only control you have is the time between steps. As you speed up, you decrease the time between steps until it is some minimum and then you're slewing. At some point you have to start decelerating, which you do by gradually increasing the time between steps.

Click to expand...

I may be wrong but I thought these motorised faders used simple permanent magnet dc motors?

Cheers

Ian

ruffrecords said:

Andy Peters said:

See, when you drive a stepper motor, the only control you have is the time between steps. As you speed up, you decrease the time between steps until it is some minimum and then you're slewing. At some point you have to start decelerating, which you do by gradually increasing the time between steps.

Click to expand...

I may be wrong but I thought these motorised faders used simple permanent magnet dc motors?

Click to expand...

I honestly don't know, either, but it seems to me that a stepper might be simplest. Or not!

-a