Bypass ramp generator

[AntoineGR]

Hello Gin66,
would you consider implementing a native command to run moves without ramp generator ?

The idea came up in previous use cases (#110 #288 #86) where motion planning is computed by an external software (3D, animation, robotic).
FastAccelStepper is then used to run many small consecutive motions (from an array in memory or streamed on the fly).
This allow for clean and time-constrained motion paths to be executed.

To bypass the current ramp generator some users tried setting the acceleration to max value (not 100% precise and use CPU ressources) or implemented their own low-level routine and queue management.

So the proposal would be to have two new commands that run in a given time without accel/decel :
moveTimed(steps, duration) and moveToTimed(steps, duration)
Duration could be in ticks or seconds or milliseconds.

[gin66]

Thanks for the proposal. Sounds easy, but solution is a bit more complex.

Assume duration is 5ms and 50kSteps/s. Then steps = 250 and duration 5ms. Step rate is 20us. Easy. Can be done by simple translation into queue commands.

Now consider 251steps and duration 5ms. Step rate should be 19,92us. But the next lower step rate is 19.9375us and 251 steps with this rate is 5,004ms. So 4us deviation. With 252steps the actual duration is 4,99275ms and 8us deviation. Sounds small, but after 1000 commands of 5ms, there can be already 4-8ms deviation, which is a complete command. so ~250 steps more or less at nearly the same time.

Correction can be done only up to 4 times per ms and the deviation may not be possible to perfectly compensate. Shall this be corrected by the new function or by the caller ?

[AntoineGR]

Thank you for the quick and thoughtful answer

You're making a good point on this quantization issue, I'm pondering what could be the most elegant solution,
will report back here soon !

[AntoineGR]

Ok so in the spirit of my proposal the important point is to have time-constrained commands.
Therefore the proposed functions should respect the desired duration and would sometime need to :

• accomplish less steps (to avoid overflowing the target duration)
• and wait at the end of the command (to reach the target duration)

So when using moveTimed(steps, duration) or moveToTimed(steps, duration) I guess the functions should return droppedSteps to let the user know the delta and add it to the next function call.
Does that make sense ?

PS : I created a python script to loop through all stepping rates and check how many steps need to be dropped and how long is the remaining wait time, let me know if you'd like to have it.

[gin66]

Thanks for the proposal.

Based on the existing implementation of the queue another approach seems to be more straightforward: The queue tracks very well the actual position at queue end. What is currently not available, is the time at queue end. This should be comparably easy to be maintained. Queue end time can be reset to 0 at start of the queue. Now the consecutive function calls would need to maintain their own set of target steps and target time. By comparing to the queue end time/steps, the correction should happen quite naturally.

Hope I have explained my idea good enough. What do you think?

[AntoineGR]

Hi !
Sound alright but I'm not sure I understand all the implications : would the functions then return an absolute position + elapsed queue duration ? (maybe if you can give an example that could clear it out for me)

Continuously correcting for time might get tricky, especially with several motors working together.
I think the main use case of these functions would be to run preplanned moves (or pathtables) entirely computed beforehand.

[gin66]

first implementation is available. Instead of maintaining time on FastAccelStepper, the current function provides back the actual time. The application just need to add the delta time just to the next command and then it should even out over time.

If you like, you can give it a try. I will provide the one or other feature update/improvement in due time.

[gin66]

Implementation is released in 0.31.5

[Matoseb]

Hello!

I'm trying to understand the moveTimed example.

If i set the TIMESTEP_TICKS to a lower value, for instance feeding the frames at a lower 60hz interval, it seems i'm losing steps.

Do I have to fiddle with task_rate and setForwardPlanningTimeInMs to avoid a queue starvation?

[gin66]

what do you mean with „losing steps“ ? Does the motor stops during the motion ?

[Matoseb]

I think I figured it out, I wasn't printing some error, I was getting "Device Not Ready"

Had to adjust the empty queue at the beginning:

// 60fps
#ifndef TIMESTEP_TICKS
#define TIMESTEP_TICKS (TICKS_PER_S / 60)
#endif

// Empty queue
stepperX->moveTimed(0, TICKS_PER_S / 240, NULL, false);

---

what do you mean with „losing steps“ ? Does the motor stops during the motion ?

Ah my bad! It's another code where the "phi" is incremented by an elapsed time instead of being controlled by moveTimed.
Ideally, frames would be streamed via Serial at roughly 60hz.
And I'm losing steps here, the stepper drifts over time. And feels jittery.

Would having a temporary "framebuffer" be the way to go? Or a way to add lost steps?

Here is the loop where phi is incremented externally:

#define UPDATE_INTERVAL_US 16667

void loop() {
  uint32_t current_micros = micros();
  uint32_t elapsed = current_micros - controlX.last_update_micros;
  
  if (elapsed >= UPDATE_INTERVAL_US) {
    controlX.phi += 1;  // Increment phi by 1 degree
    controlX.last_update_micros = current_micros;
  }

  moveStepper(stepperX, &controlX);
}

[gin66]

thanks for explanation, but I still do not get it. Anyway, lost steps by the driver should not happen at all. Can happen only, if the timing between direction change and next step is too short, or the stepper stalls due to too high load or too high speed.

Calling move stepper in every loop() invocation may not be, what you want. Perhaps include it inches if{} branch.