lots of jitter on step movements

[3ricj]

Hi there,

I was having problems running this as a service at 6khz pulses. There was breaks in the pulses nearly 20ms (6-10ms typical) long! That made for very rough movement of the stage at times... it would jitter and chatter.. not to mention cause vibration.

I've started to try and optimize this a bit. It's much better now -- pretty stable pulses. I'm still seeing some minor bugaboos (slow fall times?) randomly seeing 1ms pulse lengths on the step line. But much much better now.

Before:
https://www.dropbox.com/s/arb881iok61ibbv/stock.png?dl=0
https://www.dropbox.com/s/1k708hg0hwj6nsq/stock2.png?dl=0

After:
https://www.dropbox.com/s/5knigkzt73tjq9a/changes.png?dl=0

Here's what I changed:

    disableCore0WDT(); // we have to disable the Watchdog timer to prevent it from rebooting the ESP all the time another option would be to add a vTaskDelay but it would slow down the stepper
    disableCore1WDT(); // we have to disable the Watchdog timer to prevent it from rebooting the ESP all the time another option would be to add a vTaskDelay but it would slow down the stepper
    xTaskCreatePinnedToCore(
        ESP_FlexyStepper::taskRunner, /* Task function. */
        "FlexyStepper",               /* String with name of task (by default max 16 characters long) */
        2000,                         /* Stack size in bytes. */
        this,                         /* Parameter passed as input of the task */
        1,                            /* Priority of the task, 1 seems to work just fine for us */
        &this->xHandle,              /* Task handle. */
        1  /*  what core? */
    );                          

This forces the step processing onto core1 -- it seems pretty happy there. This may have other bad side effects -- not sure.

Finally, there are some faster digital pin options on the ESP32 -- bitmask style. here's some info on that:

https://www.instructables.com/Faster-ESP32/

It may help drive things even faster.

Best I can tell the library is doing a bunch of stuff between the rising and falling edge of the pulse. Something in here may be causing the existing jitter, but I'm not sure how to best find it.

  // execute the step on the rising edge
  digitalWrite(stepPin, HIGH);

  // update the current position and speed
  currentPosition_InSteps += directionOfMotion;
  currentStepPeriod_InUS = nextStepPeriod_InUS;

  // remember the time that this step occured
  lastStepTime_InUS = currentTime_InUS;

  // figure out how long before the next step
  DeterminePeriodOfNextStep();

  // return the step line low
  digitalWrite(stepPin, LOW);

Here you can see the 1m pause between rising and falling:
https://www.dropbox.com/s/n9lzfshqx4ar0r1/screenshot.png?dl=0

Thanks for the library, it's awesome.

Best,
-3ric Johanson

[3ricj]

Is there any specific reason why it's doing all that work between the rising and falling edge of a short pulse? Maybe move the HIGH/LOW to be back to back, and process when waiting anyway? It looks like the DeterminePerdiodOfNextSlep is a bit heavy -- maybe include the clocks taken to process that in the delay for more stable frequency? But that's a guess.

[pkerspe]

Thank you @3ricj for the effort you put into analyzing the signals and your inputs on this topic.

Your change moves the update task on core 1, but as far as I know this is also the core where the standard arduino function setup and loop are running. So when you move it there, it might interfere with some heavy work on core 1 from your loop().
Did you test what the jitter looks like if you perform some major operations in your main loop() function?

You should also try to disable the ESP Flexy Stepper service which will avoid the opening of a separate task completely and solely run in the main loop. Of Course then you cannot have other logic in the main loop that might cause jitter.

Can you please post your complete program you used while measuring the jitter?
Do you use any Wifi functionality during the test?
The RF radio stack Stack runs by default on Core 0. So in your case it could be, that you are using Wifi or Bluetooth at the same time, causing this jitter. If you move to core 1 you actually avoid this but you interfere with the Arduino functions and general other Libraries you might use.
Try disabling wifi / BLE completely in your code to see if the jitter goes away.

As for your question of the pulse duration: The pulse duration (or even a variation of the length) should not matter to drivers that are triggered on the rising edge of the pulse.
Additional drivers do have a minimum pulse length. Since this library is universal setting the pin/low in just two following cycles might cause the pulse to not be long enough. Using a fixed delay between high and low of the pin will waste CPU time with now benefit, thus the calculation is done in between to make best use of the CPU Time.
Indeed quite some logic is happening in this DeterminePerdiodOfNextSlep function but it is necessary for the functionality.

As for the logic to set the Pins high and low: you are right this might be quicker, but the jitter is not caused by using the Arduino digitalWrite functions. These functions need the same time with every call, they do not need sometimes longer and sometimes shorter (unless interrupted by some wifi / rf stack logic on the same core, which of course is more likely the longer the function runs).
It sure is worth a try to further optimize the code, but I am not sure it will fix the general jitter issue.

[pkerspe]

@3ricj can you provide feedback on the above comment?
I assume it is a CPU core related issue as indicated before. Currenlty there is a pull request that allows to define the core on which the service is running, maybe this will help if you use the 1 for the service once this pull request has been merged. It will be available in the next release 1.4.4 but your input on above questions would be helpfull

[Humanoidx]

I also encounter an exteme and constant amount of jitter... sometimes it stops for half a second in the middle of a move. Moves fine using other libraries. Any thoughts?

[pkerspe]

@Humanoidx please provide some more details on your setup and code.
500ms breaks are very unusual and do not seem to have the same cause as the previously reported issues. 500ms is kind of an eternity for an ESP32 running at full speed.

[Humanoidx]

@pkerspe

ESP32-Wroom-32D
https://www.amazon.com/gp/product/B0811LGWY2/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Nema 34 12nm Closed Loop Stepper
https://www.amazon.com/Nema-Closed-Loop-Stepper-Motor-Driver/dp/B081N9FPRM/ref=sr_1_27?dchild=1&keywords=nema+34+stepper+motor+12nm&qid=1612650156&sr=8-27

Here is a video if it working smoothly with FastAccelStepper Library
https://youtu.be/hPxJekex5zM

And here is the jittery ESP-FlexyStepper Library
https://youtu.be/cA70uUXMIp0

Both Videos are 400 steps per revolution

16,000 steps per second max speed
2000 steps per second per second
Move 160,000 steps

Depending on the settings sometimes it just stops all together even at low speed,s

[pkerspe]

@Humanoidx thx for the hardware details, yet I was more referring to the software code and setup of esp FlexyStepper though :-)
Can you please post your code?

[Humanoidx]

:)
@pkerspe

#include <ESP_FlexyStepper.h>

// IO pin assignments
const int MOTOR_STEP_PIN = 12;
const int MOTOR_DIRECTION_PIN = 14;

// create the stepper motor object
ESP_FlexyStepper stepper;

void setup() 
{
  Serial.begin(115200);
  // connect and configure the stepper motor to its IO pins
  stepper.connectToPins(MOTOR_STEP_PIN, MOTOR_DIRECTION_PIN);
}

void loop() 
{
  //
  // Note 1: It is assumed that you are using a stepper motor with a 
  // 1.8 degree step angle (which is 200 steps/revolution). This is the
  // most common type of stepper.
  //
  // Note 2: It is also assumed that your stepper driver board is  
  // configured for 1x microstepping.
  //
  // It is OK if these assumptions are not correct, your motor will just
  // turn less than a full rotation when commanded to. 
  //
  // Note 3: This example uses "relative" motions.  This means that each
  // command will move the number of steps given, starting from it's 
  // current position.
  //

  // set the speed and acceleration rates for the stepper motor
  stepper.setSpeedInStepsPerSecond(16000);
  stepper.setAccelerationInStepsPerSecondPerSecond(2000);

  // Rotate the motor in the forward direction one revolution (200 steps). 
  // This function call will not return until the motion is complete.
  stepper.moveRelativeInSteps(160000);
  delay(1000);


}

[Humanoidx]

@pkerspe
Same issues with ESP-Stepper-Motor-Server

[pkerspe]

Did you try running the FlexyStepper stepper as a service as in example 5?
Also please try with some less aggressive values in acceleration and speed first, something like 2000 steps/second and acceleration of 200 steps/s/s

I know it works with the other library, but we need to narrow down the cause of the problem.

[Humanoidx]

@pkerspe

Just tried it with the less aggressive values, and it is still jerky

Tried example 5 and it is still jerky (particularly when it accelerates or decelerates). But it seemed smooth when it reached the maximum speed.

[pkerspe]

Thanks for the feedback.
Can you try to figure out if your stepper driver reacts on a rising edge or a falling edge on the step input?
So does it require a transition from 0 to 3.3V (rising edge) to send a step to the stepper motor or a transition from 3.3V to 0V (falling edge)?
Since the ESP FlexyStepper stepper library performs quite some calculations between the signal changes this might make a difference.
Currently the library expects a driver that fires on a rising edge step signal.

[pkerspe]

Also one important question: did you connect to the ESP32 with a serial monitor to check if it crashes and performs a reboot/reset? This would explain the very long pauses you experienced before.