Low level access

[PitMaker]

Hi,
I' am building an omnidirectionnal robot for fun, based on esp32 and linked to unreal engine with web sockets.
My goal is to place the robot in the same position as the 3D object in Unreal (that is moving obviously).
So thanks to this amazing library, I'm able to drive the robot with acceleration and speed updates and runforward/backward.
But for precision I would like to drive it with steps precision.
Here is my problem :
I'm working with fixed updates in unreal (60 frames/s), so if I use the move commands my 4 steppers are not in sync and I get a strange behavior due to the Ramp generated for every frame (I can't predict the final position of the object).
So I think that I need to use the low level access to put commands in queue every frame, am I right?
I am using addQueueEntry(&command, true) , but I don't really understand this :

struct stepper_command_s {
  uint16_t ticks;
  uint8_t steps;
  bool count_up;
};

Is ticks the duration of the movement?
Steps looks like a number of steps to travel and count_up is CW or CCW?
I get results but not really as expected so I guess that I missed something.
Any hint would be really appreciated.

[gin66]

If you go low level, then there is no acceleration/deceleration available from the lib. So the main question is: Do you get from the Unreal engine the absolute position to move to ? Perhaps this could be a possible starting point. If not, you still may loose synchronicity between robot and unreal engine character pose.

In the above struct the meaning is:

• ticks = time in multiple of 1/TICKS_PER_S = 1/16MHz = 0.0625us
• minimum value for ticks * steps = MIN_CMD_TICKS = 8000 = 500us
• maximum value for ticks = 65535 = ~4095 us

Each command either generates a PAUSE of 500...4095us length (if steps = 0), or generate (steps) steps with a time distance between two steps defined by ticks. Examples:

• steps = 10, ticks = 1600 will generate 10 steps at 10.000 steps/s
• steps = 30, ticks = 64000 will generate 30 steps at 250 steps/s.

The max value of ticks has the consequence: if the stepper needs to run slower than ~250 steps/s, then pause commands need to be added to the queue.

If you anyway have an update rate of 60 frames/s, then best to not create commands longer than 16ms (using large values of steps). If the robot should not move between two frames, need to add five pauses to the queue.

One problem you may encounter is, that 60 frames/s will not be in sync with the time base of the esp32. Example: If the robot should not move for e.g. one minute and for every frame you just add five pauses to the queue, then there may be two cases happening: If the esp32 is slightly faster than the frames, the stepper will run out of commands. In case the esp32 is slightly slower, then the stepper queue will be full.

General advise:

• If you use low level control for more than one stepper, then best to not use direction and enable delay, because 'addQueueEntry()` may otherwise add pauses into the queue, which will add to time deviation between steppers.
• Always check the return value of addQueueEntry()
• First fill the queue with second parameter false, and then followed by true after one or two queue entries have been added. Or call with addQueueEntry(NULL, true) to start a prefilled queue.
• Please search for closed issues with addQueueEntry in this forum for more info

[PitMaker]

Thanks a lot for this explanation!
Yes I'm sending absolute positions from Unreal Engine to touch designer. But one of my many mistakes must be that the ESP32 is doing all the vector calculations, I will try calculations in touch designer and just send steps and frame frequency to the esp32. (I can lower the frame rate from touch if needed).
My goal is not to be 100% accurate with Unreal but to have multiple robots in total sync.
I'm going to try a few things before diving into low level (like using move by acceleration and check current position).
I'll let you know!

[gin66]

Perhaps you need to modify speed/acceleration to have the motors arrive at the target position at the same time. Please check #129 for reference