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
283 stars 67 forks source link

Glitchy getCurrentSpeed results #208

Closed AndBondStyle closed 7 months ago

AndBondStyle commented 7 months ago

Trying to run some basic movement using moveTo and plotting live values of getCurrentPosition, getCurrentSpeedInMilliHz (velocity) and getCurrentAcceleration. Looks like velocity (red line) is reported incorrectly near zero-crossings. I think those "glitchy" values somehow get the wrong sign: if you invert them, the plot looks much better (little green dots, painted by hand). Any idea what's going on? Using FAS 0.30.4 on ESP32. image

gin66 commented 7 months ago

Good finding. I will need to make a test case for this, before I fix it.

gin66 commented 7 months ago

Just have pushed a new version, not yet released. Please give this a try. Moreover check the updated interface for getCurrentSpeedInMilliHz(bool realtime = true)

AndBondStyle commented 7 months ago

@gin66 now it's much better, thank you for a such quick fix! I'm a little confused about the naming of realtime argument, at first I assumed it should be true to get more accurate results. Here is before and after:

realtime = true (legacy mode)

image

realtime = false (new mode)

image

gin66 commented 7 months ago

FastAccelStepper uses a queue of commands, which either defines a pause or 1-255 steps at a specific rate. Any command is around 1-2ms and FastAccelStepper plans around 10ms into the future. realtime == true tries to determine from the current stepper command the actual speed. This does not work at low speeds. In this case the speed at the end of the queue is used, which is approx. 10ms in the future. This means at a certain speed, the reported speed will have a jump (value at beginning versus end of the queue).

For realtime==false, only the speed from the end of the queue is used. So no jump, but the reported speed is approx. 10ms in the future.

I expect, that the change between beginning versus end of queue should happen somewhere around 250-750 steps/s (have not checked this).