Usage of moveTimed - Still unable to get it dialed :(

[RoboCrafty]

Hey mate!
Link to my code
First of all, I’d really like to thank you for making this library for the ESP32. It’s honestly really powerful, especially considering how well it makes use of the hardware.

I’ve been trying to implement synchronized motion for my 6-DOF robot arm. Right now, I’m only testing with a single stepper because I’m already running into issues even with that setup.

I’m bypassing the internal ramp generator because I want to use my own trajectory generation with Ruckig for 2 reasons, 1- I want s-curve as opposed to the default trapezoidal motion profile and 2- I need to move six motors synchronized in order for the robot to follow a certain trajectory in the cartesian space. My current approach is to generate trajectories externally with ruckig on core1 (in the main loop), fill a queue with 10 ms worth of motion data, and then have a separate loop running on another core that feeds the stepper using moveTimed() at 1000 Hz.

The problem is that the resulting motion is not smooth at all, and overall I feel like the architecture around these sections isn’t very robust yet. The code is definitely messy right now, but specifically I’d really appreciate feedback on the loop() function and the feeder function.

From my understanding, the important thing is making sure the queue never runs dry. I try to guarantee that by generating 10 trajectory points ahead while only executing 1 ms worth of motion at a time.

Eventually, I want to extend this to all six steppers. The idea is somewhat shown in the test4() function (although it’s incorrect right now as it isnt using the feeder architecture I made today). My goal is basically to time-parameterize the IK output and then feed synchronized motion commands to all six motors through moveTimed().

I’d really appreciate it if you could take a look and tell me what I’m doing wrong, or if there’s a better way I should be architecting this kind of system.

Thank you.

[RoboCrafty]

Another thing I'd like to mention is the internal ramp generator runs the motor so much smoother (with moveto) for the exact same speeds and microstepping so there's definitely something wrong with my implementation because I actually checked the trajectory that ruckig generates and that also follows an S curve so that's not an issue but my logic of actually feeding the queues is messed up

[gin66]

Sounds like an interesting application.

Keeping six queues simultaneously not running out of commands is tricky. I have not yet understood, how the test4(), feeder() and handleSerial() working together. But from what I see, I would guess, that all the Serial,prints and DEBUG_PRINTLN kill the performance (10Bytes at 115200Baud is nearly 1ms delay…). You should check for the return code MOVE_TIMED_EMPTY. If this is hit, while the steppers are expected to run, the synchronization is already gone.

[RoboCrafty]

Thanks for the quick response. You can take your time, but here’s a video where I was using FluidNC, and it handles synchronized movement of six steppers very robustly. So I believe it should definitely be possible on the ESP32 to queue six motors properly, assuming the code is written correctly.

I also tried completely removing the print statements, as well as reducing them to only print once every second by using counters. However, that barely changes the behavior, so it doesn’t seem like the print statements are the main issue here.

According to AI suggestions, the issue may be related to quantization — for example, during a 1 ms period, if the commanded motion corresponds to something like 1.5 steps, it gets rounded down to 1 step, which could accumulate into visible synchronization errors. I have based a block of part of the answer from Gemini :)

The problem arises because stepper motors can only execute integer steps. If your trajectory demands a velocity of 1,500 steps per second, your 1ms control loop needs to output exactly 1.5 steps per frame. Since it can't, the kinematics solver and queue are forced to alternate: Frame 1: 1 step (effectively 1,000 steps/sec) Frame 2: 2 steps (effectively 2,000 steps/sec) Frame 3: 1 step (effectively 1,000 steps/sec) Your ESP32's MCPWM hardware executes this perfectly. As a result, the motor is violently accelerating and decelerating by 100% of its velocity every single millisecond. The mechanical system filters this out as motion, but it manifests as harsh acoustic noise, vibration, and "roughness."

As for the test4(), it's not being used right now, but it just shows that in every loop of the iteration, I would advance the trajectory one step and run the inverse kinematic solver, and the target positions of those would be sent to move timed but I moved on to the new architecture which uses the feeder and essentially in the main loop a trajectory is generated using ruckig as fast as possible till the steeperQueue is full (depth 10) while the feeder on core1 checks if there is anything in the queue, and if there is it then execute moveTimed() in theory move time should never run out mid because I have the 10 depth buffer. I think AI is giving the right reason here but I'm not really sure what the robust way to fix it would be.

What do you think?

[gin66]

OK. Looking at feeder I see the following issues:

• the drift calculation is missing. see (examples/MoveTimed/MoveTimed.ino) for reference. Without it the synchronicity will be lost between commands. Rationale: moveTimed will rarely append exactly 1ms. On average it may be, but the application is expected to adapt to the tick exact timing.
• If one stepper fails to append moveTimed, the queue will retry and on the next loop iteration add just a millisecond pause to the other steppers (sync lost). For each stepper need a bool array for success. If command was successfully appended, then avoid trying again to add a command. If all six were successfully added, reset the bools and retrieve the next command from the queue.

[gin66]

The llm comment is another issue. Just the solution is more complex.

In the doc this is mentioned as a problem, too:

  // The current implementation immediately starts with a step, if there should
  // be one. Perhaps performing the step in the middle of the duration is more
  // appropriate ?

The middle of duration is not correct either, but correct position in time is needed. In the moment, the app would need to add pauses for placing the pulse within the one millisecond framing.

The main point, why the ramp generator controlled movement is much smoother: The step frequency is near exact without much „time/frequency noise“.

[RoboCrafty]

Interesting! other than the 2 issues you mentioned in the feeder() does it seem all correct? How do I handle the idle state? i.e movement is complete and the trajectory from ruckig is complete. Should I be filling queue with 0 step moves constantly while in this else block? and how big should queue buffer be? right now its 10 steps

As for the main point why the internal ramp generator is much smoother, I dont understand that. How is it possible that one is able to generate near exact frequency? What rate does the internal ramp generator run at? Like here in my case I am sending steps every 1000us, so my trajectory is being discretized into 1ms steps. How is it for the internal one?

[gin66]

The ramp generator runs every 4ms and fills the pipeline for the next 10 to 20ms, so that the queue will never be empty (as long as the ramp is running). The actual commands are not timeboxed in something like 1ms frame. In addition the acceleration ramp profile gives a direct relation between steps and speed during acceleration and decelerationThe ramp generator controls the speed and eventually generate the ramp as expected (timewise). Difficulty is more to predict, how much time the ramp will take for acceleration+coasting+deceleration.

As AI has already stated: if any stepper should run at 1500Hz, then with 1ms frames the first moveTimed() will create 1kHz step rate and the next frame will be 2kHz step rate. In case the stepper still follows, it will run quite noisy. Best would be to relax the 1ms fixed frame and adapt to the actual speed. For this the current speed would be needed in addition. This makes multiaxis so complex, because ideally the trajectory should provide position and speed for every point in time. If now at time step n the speed 1500Hz is needed, then using moveTimed() output 2 steps with approx.2*666us duration. At the next timestep n+1, the stepper is actually 332us ahead. If still 1500Hz is needed, just append 1 step with 666us. The forward planning is always covering more than the next 1ms. In your queue you can plan actually pretty long time ahead. I think the esp32 Stepper queue is 32 deep. For sure this is way more complex approach, but this way the speed control of stepper is best.

[RoboCrafty]

Could you please explain how you mean we should adapt to the actual speed? like my trajectory regenerator can generate the position that the stepper needs to be at every millisecond so my thought process was to feed the queue with those target steps for every millisecond to be executed for the next 1 ms using moveTimed. I think I am a bit of a beginner so it's a bit hard to comprehend this to be honest.

[gin66]

difficult to explain by chat. In a nutshell: control the stepper using speed and not position. Commands are not 1ms frames, but step separated.

Your trajectory planner need to output speed @ position.

[RoboCrafty]

difficult to explain by chat. In a nutshell: control the stepper using speed and not position. Commands are not 1ms frames, but step separated.

Your trajectory planner need to output speed @ position.

So I ran some tests in simulation with Wokwi and analysed pules with vaporview + a python script and the issues are a lot clearer. I am hoping you could suggest how I can go about fixing this in the best possible manner. I did run through with Claude and it suggested fixing the quantization issue by batching/accumulation of steps. It made a good number of changes but let me start from 0. Please take your time to read through this when you get a chance.

In this plot the 2 ramps until 5 seconds are from the internal ramp generator, perfectly smooth. and the mess on the right is from the current code on my main branch.

now zooming into my mess

Here you can clearly see that it keeps going between around 0.6 steps/sec to 2. Which perfectly explains the rough/noisy movement.

Moving on to the more interesting bit -->

Now I did some more digging and after applying some fixes with claud, namely this commit, which adds batching, things were a whole lot better, the jitter of switching and the rough movements completely gone. You can have a look at the exact changes over main to see what calude suggested. (I understand its overall architectural change but not fully the code tbh)

Some analysis:

The 2 ramps till 10 seconds are from the internal ramp generator. In the plots prior I was only moving 100 with the internal ramp generator steps, here I moved 30k to clearly see the trapazoidal profile from the internal ramp generator. Zooming into the internal ramp gen it does show some jumps too but overall the motors I believe move very smoothly.

This is the internal ramp zoomed in, as you can there is some stepping that starts after 2.4 sec but no jitter.

Now comparing that to my trajecotry that was generated by ruckig:

Here you can see there is still some quantization going on i guess? But still its way better from the changes that one commit brought.

Could you please suggest if this is the right way to go about it because I think it introduces the delays if I need to track trajectories in real time later on so I'm not sure if this is the best architecture from what I understand we just need to make sure that there is never a non-integer member of steps being targeted with the move time command is that correct? The thing is, let's say my trajectory says the motor needs to move 0.5deg on the output (at 8 microstepping and 10:1 reduction) in 1 ms, which turns into X integer number of steps, lets say 20 steps. Now, since when moveTimed is called that 20 is going to be divided by 1000 im not sure how this plays out, when does it cause quantization issues? What would be the fix as opposed to the accumulation that claud suggested? How does the internal ramp generator do this so well? I guess it uses the even more lower level addToQueue? But why does that allow it to bypass these quantisation issues?

Lastly: I I'm starting to think wouldnt writing a custom DDS be a better approach to all this? Have you looked into those? I believe that's what libraries like fluidNC or grblHal use no? I'm not sure why nobody has ever written it before other than these professional CNC libraries

[RoboCrafty]

Another thing I noticed was, even with the batching Fix from Claude for longer moves where the maximum velocity is actually achieved for the S curve, there is the same quantization error. So it definetely isnt the robust fix. I would really love to get multi axis moveTimed() moves smooth and robust. Zoomed in below.

[gin66]

DDS stands for what?

The prime moveTimed with pauses is good to provide a good start. Even better to start the queues in a loop, after the pauses are filled.

As I said before: the stepper should be controlled by speed and not by steps. Apparently ruck can provide this - at least what Claude said to the repository of ruck:

OutputParameter<DOFs> output(dofs);
while (ruckig.update(input, output) == Result::Working) {
    auto& vel = output.new_velocity;  // std::array or vector, one value per axis
    // vel[0] = axis 0 velocity, vel[1] = axis 1, etc.
    output.pass_to_input(input);
}

[RoboCrafty]

Yeah I am aware ruckig gives new postions, velocities and accelerations at every iteration of the control loop. But how does the velocity help here? Even if I convert that to target velocity in steps/sec, the moveTimed takes in distance or steps, so where would the velocity help?

DDS (Direct Digital Synthesis) is a fundamentally different technique which can be used for driving steppers. I dont fully get it either but I will try to implement it once I get some time. Here is what AI says about it:

A DDS (Direct Digital Synthesis) stepper controller does not generate steps by waiting a fixed delay between pulses. Instead, it runs at a high-frequency timer interrupt and maintains a phase accumulator. On every timer tick, a velocity value is added to the accumulator, and whenever the accumulator overflows, a step pulse is generated. Compared to the traditional delay-based method (where each step is followed by a calculated delay), DDS produces smoother motion, allows precise fractional step rates, and makes acceleration changes easier because the velocity can be updated continuously without recalculating timer delays. It also avoids quantization errors and timing jitter that become significant at high speeds or when following complex trajectories.

[gin66]

Thanks for the clarification for DDS. The answer to why this is not in place: for a decent performance this would require to e..g. once every us run, the full velocity calculation only to generate steps. I doubt the ESP32 is fast enough. Besides, any interrupt may cause issues..

Using moveTimed() you can achieve similar performance without the need for high frequency timer.

moveTimed() uses steps and duration. If e.g. steps > 1, then the duration directly translates to speed: steps/duration = step speed. So need to use ruck velocity and calculate duration between pulses. If this duration is smaller than 1ms, then need to issue more than one step. If it is much slower than 1ms, need to issue one step of 1ms duration followed by pauses. This needs further bookkeeping how much pauses are due to the next step. The internal ramp generator just works like this. As speed control may lead to over/underrun the position in multiaxis application, a feedback loop is needed using the actual position at queue end. Perhaps the ruck pass_to_input() can be involved. For the internal ramp generator the over/underrun of a position does not happen, but it is difficult to guarantee/predict the exact time of arrival - which is needed for multi-axes symmetric movement.

As I have said, this is complex but doable and should yield similar smooth performance as the internal ramp generator.

[RoboCrafty]

Interesting!
Actually with the DDS the velocity calculation (Ruckig) only runs at 1000 Hz (every 1000 µs) in the main loop. The only thing that runs at the high frequency (e.g., 40,000 Hz / every 25 µs) is accumulator += velocity. It is a single integer addition (for each axis). Perhaps that makes it better? I believe FluidNC and GRBL_ESP32 do this already but their whole architecture is around Gcode.

I will try to understand all the bookkeeping needed for getting it to work with moveTimed(), as you stated the if all the axis wont share the same master clock i.e 1ms they might got out of sync. Is there any examples perhaps of the approach you have described already in the library?