[Dprglist] motion profiling with stepper motors
Ron Grant
deltagraph at aol.com
Sun Mar 25 10:25:09 PDT 2018
Makus,
Something to keep in mind. If a pulse gets generated at some count of a timer with say 1usec resolution, and an interrupt is programmed to occur at that time you will have (should have) the ability to program the next edge (and output pulse edge) to happen at exactly some given count in the future taking care to generate counts that use same word size as timer to match timer wrap around properties, e.g. if an interrupt is programmed to happen at 65500 on a 16 bit timer you would of course want to add value say 200 to that using 16 bit unsigned word to get correct answer to plug into timer compare register. e.g. 164 or whatever the correct answer is. (I have done this type of thing a number of times to create arbitrary waveform that has exactly the pulse widths I wanted - at timer resolution).
Oh, and on deceleration. I am talking about stopping with inclusion of your calculated deceleration ramp, not just stopping.
Also, Most times I am coordinating two motors, but CNC laser patterns I cut using DC servo motors is only real proof of my competence. I guess I do vary step rates on stepper motor line following robot.
One thing with step counting, as you ramp up you can ask questions like. Have I exceeded max velocity (VMAX) , if so clip to that rate. Also you can ask questions like have I crossed total count / 2 point if so and your deceleration rate is same you can mirror your actions and end up very close to your end point at nearly zero velocity. Of course if your run is short you many never reach VMAX before reaching midpoint. Long runs will reach VMAX then stay at that velocity for a given number of counts before reaching midpoint...
All of this is just me talking. I found it very satisfying to figure this out for myself where as PID controller ideas I had to just copy others work because beyond scope of my understanding except for some of the general concepts...
As for much more than 10K steps, I would think 100K steps/second would be within reason of a "fast" microcontroller, e.g. 100 MHz range commonly available with ARM based controllers these days... Too much for 16MHz AVR I would say..
How many axes are you trying to coordinate?
Ron
-----Original Message-----
From: markus <markus at bibi.ca>
To: Ron Grant <deltagraph at aol.com>
Cc: dprglist <dprglist at lists.dprg.org>
Sent: Sat, Mar 24, 2018 9:50 pm
Subject: Re: [Dprglist] motion profiling with stepper motors
Hi Ron,
that makes sense and I see the wisdom behind your approach. The problem
is I need stepper frequencies way beyond 10kHz and I have multiple
steppers which will have to work in concert. Basically controlling
multiple axis of a CNC machine.
Coming to a stop at a specific location with a set deceleration is what
I'm looking for. The important part is that the "stopping" should
happen in a fully controlled manner - aka. smooth. So it doesn't just
matter where I end up, it also matters how I got there.
I had missed your question:
> > >> 1ms later we could/should set the frequency to 10Hz but that's
> > >> not possible because the period of one 5Hz cycle is 200ms.
> > You mean 10ms later... right?
Unfortunately I did mean 200ms - which is the crux of the problem.
Issuing a single 5Hz pulse takes 200ms which means I can't set a new
value before those 200ms are up.
But maybe I'm overthinking the problem.
Markus
On Sat, 24 Mar 2018 21:24:36 -0400
Ron Grant <deltagraph at aol.com> wrote:
> Markus, coming to a stop at a specific point (or count) is the beauty
> of the high frequency interrupt routine approach that I use. The
> routine decides if it is going to take a step and in a final ramp
> down it can ask if it has reached its terminal count. If so, the
> motion is done.
>
> In your case, might get a bit tricky. At a given update you might
> have to ask the question. Where will I be next update and what I need
> to do to insure the correct count? Hmm.
>
> In my step rate world, I can simply apply linear ramp functions to
> like StepRate+=Accel at given time step and also ask questions like
> have I exceeded max velocity, if so clip StepRate or have I passed
> 1/2 way point to terminal count or have I reached count where I need
> to start decelerating step rate to reach correct terminal count at
> about correct time with final fudge near end to drop velocity to zero
> when I have reached final count.
>
> OK, that begs the question, if you setup (or have) an interrupt
> routine fire when counter generates step pulse. You could have that
> routine ask, am I at the final step count. If so, don't allow anymore
> steps. This will eliminate the headache of trying to calculate
> exactly what to do with your deceleration or so I say.
>
> Ron Grant
>
>
>
>
>
>
> -----Original Message-----
> From: markus <markus at bibi.ca>
> To: Ron Grant <deltagraph at aol.com>
> Cc: dprglist <dprglist at lists.dprg.org>
> Sent: Sat, Mar 24, 2018 7:40 pm
> Subject: Re: [Dprglist] motion profiling with stepper motors
>
> Jose, Ron, thanks for your feedback those are great implementation
> pointers.
>
> I did implement both approaches but have trouble with the wall clock
> approach (update the frequency periodically regardless if the
> previous update has ever been applied). Accelerating is fine the
> issue is with deceleration and coming to a halt at a specific point.
>
> In the linear world the distance where I have to start constant
> deceleration is defined by: S = V^2 / (2 * a)
>
> V ... current velocity
> A ... constant deceleration
>
> And again this works fine as long as the update frequency is faster
> than the step frequency, but once the step frequency drops below the
> update frequency I can't reduce the speed fast enough (because the
> timer only updates on overflow).
>
> What happens is that the stepper is still turning quite fast by the
> time the robot reaches its target position.
>
> Does anybody know how the math works here?
>
> Any pointers appreciated, thanks,
> Markus
>
>
>
> On Tue, 20 Mar 2018 16:36:02 -0400
> Ron Grant <deltagraph at aol.com> wrote:
>
> > Markus,
> > I am not a stepper expert by any means...
> >
> > >> 1ms later we could/should set the frequency to 10Hz but that's
> > >> not possible because the period of one 5Hz cycle is 200ms.
> > You mean 10ms later... right?
> >
> > I think you might be having trouble due to (as you realize) trying
> > to vary a speed where number of steps per update interval is very
> > low (less than one in your case).
> >
> > Wonder if you could be helped by using micro-stepping to increase
> > apparent stepper resolution? OR are you already micro-stepping? If
> > not, your 5Hz cycle might become with 16X microstep 80 Hz giving you
> > ability to control slower rates more gracefully even if stepper does
> > not perfectly track the micro step positions -- fancy controllers
> > and encoders help do that as far as I know.
> >
> > Maybe there is an elegant solution to calculate just what your
> > interval needs to be.
> >
> > My first thought would be to linearly ramp your expected pulse
> > timing every 10ms then force a step if need be. That is at time
> > zero you set 100 ms as the width but at update 1 (10ms later) your
> > goal is 50 ms pulse width (with 5Hz/10ms accel. rate), so you force
> > a step and reset timer. At update 2 your goal would be 25ms but
> > only 10 ms elapsed so no intervention...
> >
> > Just for fun (whether right or wrong way to do things) :
> >
> > My preferred way to handle steppers is with a 10 KHz interrupt that
> > can decide what the step frequency is going to be with 1Hz
> > resolution. Grainy when step rates are very low, but seems to work
> > well. 10 KHz might be too much for slower clock speed / 8 bit MCU,
> > not using any fancy timer stuff (just periodic interrupt)
> >
> > code for part of 10KHz interrupt routine - for left motor below
> > Note TimeL is 32 bit int
> >
> > using step and direction driver, e.g. something like DRV8825
> > not show is update that calculated StepRateL(and R) for differential
> > drive robot at say 100 Hz.
> >
> > TimeL += abs(StepRateL);
> > if (TimeL>10000)
> > {
> > TimeL -= 10000;
> > StepMotorDirL = (StepRateL>0); // set DIR pin REVERSE L
> > if (StepRateL<0) MotorL--; else MotorL++; // virtual encoder
> > count (volatile long int) StepMotorStepL =
> > 1; // manually generate a step
> > pulse wait_us(4); StepMotorStepL = 0;
> > }
> >
> > Of course you could use a timer to implement step rate, but take
> > care in adjusting rates where you might shorten an interval to a
> > count that the counter is beyond...
> >
> > Ron Grant
> >
> >
> >
> > -----Original Message-----
> > From: markus <markus at bibi.ca>
> > To: DPRG <dprglist at lists.dprg.org>
> > Sent: Tue, Mar 20, 2018 12:53 pm
> > Subject: [Dprglist] motion profiling with stepper motors
> >
> > I started playing around with motion profiling and thought using a
> > stepper was easier for experimenting. I've implemented "constant
> > acceleration" and started to wonder what the correct implementation
> > is when the stepper frequency is below the update frequency.
> >
> > Let's say motion profiling updates the frequency every 10ms and the
> > acceleration limit is set to 5Hz/10ms. So at the initial update the
> > frequency is set to 5Hz - 1ms later we could/should set the
> > frequency to 10Hz but that's not possible because the period of one
> > 5Hz cycle is 200ms.
> >
> > So the question I have is what is the correct value to update the
> > timer at the end of those 200ms?
> > - 10Hz
> > - 100Hz
> >
> > Both seem wrong, if I set it to 10Hz it's not really "constant
> > accelleration" at low speeds from a wall clock perspective. And if I
> > set it to 100Hz I might exceed the "constant accelleration" from the
> > motors perspective.
> >
> > Comments, thoughts?
> > Markus
> > _______________________________________________
> > DPRGlist mailing list
> > DPRGlist at lists.dprg.org
> > http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20180325/18062569/attachment-0001.html>
More information about the DPRGlist
mailing list