Calculate time to make a movement

[Colin K]

I have an application where I want to know how long it will take a motor to make a certain movement. In other words, given a movement of N steps, with a maxSpeed of S, and acceleration A, how long will it take to complete the movement? 

I've been calculating this without accounting for acceleration (i.e. simply dividing N by S), and it's giving me results that are not quite right. It seems like it should be straightforward to solve, but my brain is failing me at the moment.

This is what I'm working on ;)

https://www.youtube.com/watch?v=7jHsWTpkuLs

Thanks in advance!

[Mike McCauley]

Hi,

It should be a simple parallelogram of speed versus time, integrating to
distance travelled.

dont forget you will have to take into account that if the move is short, it
may not reach max speed before decelerating.

The case where the target is changed while it is already moving towards a
target is even more complicated :-(

Cheers.

--
Mike McCauley VK4AMM mi...@airspayce.com
Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.airspayce.com
Phone +61 7 5598-7474

[Colin K]

Thanks Mike! Fortunately I do not have to solve the situation where the target changes in mid flight. 

While I understand your answer in the abstract it's been about 20 years since I integrated anything--if anyone could point me towards something that spells it out a little more explicitly I will happily bang my head against the wall from there. 

Basically what I'm trying to do is get roughly-coordinated motion across a series of robotic joints. Each joint is sent a destination position and a speed, with the speeds set proportionally so that all joints should arrive at their position at about the same time. I definitely do not need perfect synchronization--if they arrive within a second of each other that might be just fine. I'm able to start them simultaneously (there's a signal line that each joint listens to that gets pulled high to trigger motion) so that's solved. In the worst case, I'm planning to just measure actual travel times for increments of 10 degrees and use a lookup table as a first approximation.

[gregor]

I think this is what the MultiStepper class is for: http://www.airspayce.com/mikem/arduino/AccelStepper/classMultiStepper.html

[Colin K]

Thanks--Considered it, but I already ruled that out for a few reasons:

1. No acceleration support--my largest motor is delivering torque in excess of 400kg-cm so ramped acceleration is absolutely necessary.

2. Need to coordinate 6 motors with very fast step rates - some of my axes take 130,000 steps to complete one rotation. Running one axis on the Teensy 3.1 which has a 96MHz Cortex M4 I can get very high step rates.

3. I actually want the joints to be fully independent of each other so that they can be used individually or combined in different ways. Essentially the idea is for each joint to be an I2C "appliance" which anyone could use--for instance I could take four of these joints and build a SCARA robot with them without having to change the joints themselves.

[Mike McCauley]

Hi,

I like your arm.

So there are 2 cases:

1. If the distance is so short that it wont reach max speed, then the
speed/time plot is a triangle: /\

2. Else the speed/time plot is a like a symmetrical truncated pyramid:
/-----\

So the algorithm might be (untested pseudocode):

let max be the max speed configured for the stepper in steps per sec
let accel be the acceleration configured in steps/sec/sec
let steps be the total number of steps required

so the time t in seconds required for the whole move of steps steps:

if ((max * max / accel) > steps)
{
// truncated pyramid
// first the sloping ends
t = 2 * max / accel; // for accel and decel phases
steps -= (max * max / accel);
// then the rectangular centre
t += (steps / max);
}
else
{
// triangle
t = sqrt(steps / accel));
}

return t;

[Colin K]

Mike, thanks for that. I tried this out over last two evenings here, and it's not really matching up with real world results in any way that makes sense :-P

As an example, I have one joint which is set to a max speed of 35000 and acceleration of 2500. To move it 90° takes 22500 steps, and takes around 10-15 seconds (I can time it exactly, working from memory here after a long night of trying different settings).

When I work the numbers through on paper I get:

1. if ((max * max / accel) > steps)  => if ((35000 * 35000 / 2500) > 22500) => if ((490,000) > 22500) => TRUE

2. t = 2 * max/accel => 2 * 14 => 28 seconds of acceleration

3. steps -= (max * max / accel) => 22500 -= (35000 * (35000/2500)) => 22500 -= (35000 * (14)) => 22500 -= 490,000  => -467500 steps remaining (!!)

That's a nonsense result, so at that point I wondered if the greater-than in step 1 should be a less-than. If I plugged that in, I got:

t = sqrt(steps / accel)); => t = sqrt(22500/2500) => t = sqrt(9) => 3 seconds 

If it would help to measure exact run times for any specific configurations of step rate/steps/accel I have a sketch that does that and could post results. 

FWIW the steps seem very clean and well-timed and take the same time every time. 

Thanks again!

[Mike McCauley]

Hi Colin,

is it possible that the stepper is not actually achieving the top speed you
think it is? If the CPU is maxed out, then it might be stepping evenly but
less quickly than you think. 35000 is a *lot* for AccelStepper.

Cheers.

[Mike McCauley]

Hi again,

more on this.
there is an error in my algorithm.

For the triangular case where max speed is not reached, it should be:

t = 2*sqrt(steps / accel));

For your move of 35000 steps at 2500 steps/sec/sec
expect 7.4 seconds.

So, perhaps the stepper is not moving as fast as you think?
Cheers.

[Colin Kingsbury]

Mike, that's a good question about how fast the steppers are *really* going. I might try checking it empirically sometime with a sketch that times some different step-rate scenarios. The positioning is repeatable and accurate so I think it's going the proper number of steps. The Teensy is running a Cortex M4 at 96MHz so it's got a lot more horsepower than an Uno.  

Anyway, I modified the algorithm (the if-test greater-than and your tweak to the triangle case) and they're definitely closer than they've been with any previous method, and solidlyin the good-enough-for-now column. Thanks for answering my somewhat dumb questions :)

--
You received this message because you are subscribed to the Google Groups "accelstepper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to accelstepper...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.