That thread talks about the need for motion planning, instead of just changing the desired position. That should be less of an issue with klipper integration, because klipper is doing the motion planning, including acceleration planning and limits.
The problem is that instead of giving us that info, it’s giving us the step pattern to implement the resulting movement and we need to derive position, speed, and acceleration from what it’s providing. We are better off than step/direction in that we get this info ahead of time, rather than having to just chase the position the way step/dir does
I can understand the math to derive these from the info that klipper provides, but what’s the best way to have simplefoc know what is intended?
In an ideal world, what we want is a ‘at time T1 you should be at position P1 speed S1, move to position P2, accelerating at A2 to speed S2, which should take you to time T2’ followed by ‘at time T2 you should be at position P2 going speed S2, move to position P3, accelerating at A3 to speed S3 which should take you to time T3’, etc.
with the most important points being hitting the position and time (and should raise a flag if it deviates too much from the acceleration/speed requests. I believe that the acceleration is all going to be at a constant (max configured) rate
Since klipper is doing trapezoidal movement planning, we should be able to reverse engineer this and get acceleration sections and constant speed sections.
per that thread, it sounds like the acceleration data won’t be used by simpleFOC right now.