search

gin66 / FastAccelStepper

A high speed stepper library for Atmega 168/328p (nano), Atmega32u4, Atmega 2560, ESP32, ESP32S2, ESP32S3, ESP32C3 and Atmel SAM Due
MIT License
282 stars 67 forks source link

Execution frequency #241

Closed programmeddeath1 closed 1 month ago

programmeddeath1 commented 3 months ago

I am trying to run my motors for a robot through this library, I am sending the trajectory to the esp with control cycle of 0.04, which means it sends around 25 points every second. with a control cycle of 0.01, it sends 100 msgs a second or 1 traj msg every 10ms. Will the library be able to generate and execute these different velocity/acceleration/position values every 10ms and send it to the driver?

gin66 commented 3 months ago

If you send a trajectory with 10ms resolution, then the ramp generation from FastAccelStepper is not relevant. For that use case, it is better to employ the low level interface.

gin66 commented 3 months ago

Answering your question: The stepper task is run every 4ms and will fill the command queue up to 20ms into the future (pre-planning). Existing commands in the queue will not be changed anymore e.g. by new values for position/speed/acceleration.

programmeddeath1 commented 2 months ago

@gin66 when you say the ramp generation from FastAccelStepper is not relevant, does it mean it will not have an effect on the 10ms executions? Is the PWM signal generation time insignificant for FastAccelStepper?

1) I am trying to run a servo motor at high speeds upto 1500 RPM and acceleration defined by the Motion Planner Algorithm. Will the control cycle of 0.01 be achievable? If I bring down my communication time to 1ms, will the signal generation from FastAccelStepper happen in the next 2 to 3ms for a 10ms resolution time to be achieved.

2) My current achievable control cycle due to communication delays is 0.04secs. When I run the Planner with lower control cycles of about 0.02 or less, it basically jumps to execute the next points in the servo before the previous motions are completed. I am updating the communication protocol for faster speed.

gin66 commented 2 months ago

I mean, if the trajectory is fully controlled by the application, then the ramp generator has nothing to do.

For better reaction time, #253 is added to adjust forward planning time

gin66 commented 1 month ago

Implementation released in 0.30.13