pantor
commented
2 years ago Hey @xp-development,
I'm not exactly sure what you are calculating here, but I'm assuming you want to calculate a time-optimal trajectory while being already on a time-optimal trajectory to the same target state. This is a very fundamental instability of trajectory generation, as the system doesn't have any margins for speeding up or slowing down when moving on the time-optimal trajectory. In your case, the system would need to swing back to get enough position difference to be able to accelerate to the given target velocity and acceleration. This error will persist with any finite number representations (e.g. long double).
The easy way to fix that would be to slightly increase the kinematic limits each step (e.g. by 1e-12 so you could repeat that hack without any real-world influence). The "correct" answer however is that you should try to avoid this specific calculation in your algorithm. Ruckig has already calculated a time-optimal trajectory (and you can get all the states and durations from the Trajectory class), so there shouldn't be a need to recalculate that. Maybe you can tell me a bit more about your use-case and algorithm so we can find ways to mitigate this issue.
Hi,
I have a problem with the imprecision of an double. I calculate trajectoies and take five points every x ms ( x = fulltime / 5 ). Next step I use the intermediate values of position, velocity and acceleration for a new trajectory calculation, but sometimes I cannot reach the destination in x ms.
In my first case I move from 0 to 41.450731359441193 and always works fine. I reach my destination in 0.042064172201862454 seconds. But if I use the distance 41.450731359441136 the move needs 0.3877058942204869 seconds.
It is possible to scale the results of a trajectory calculation so that if I use the previous result for my next calculation all works fine? Or is there another way to ignore the imprecision?