pantor / ruckig

Motion Generation for Robots and Machines. Real-time. Jerk-constrained. Time-optimal.
https://ruckig.com
MIT License
634 stars 155 forks source link

Maybe a bug with synchronization None #113

Closed stefanbesler closed 2 years ago

stefanbesler commented 2 years ago

Hi!

I continued to port some of your code to structured text - I am a bit behind and just ported 4af5a3970 and 32086dd1 , but the change that was introduced here is still present in HEAD

After this commits, in your "Known examples" unittest, example 15 (the one with duration 8.8739464323) for input.synchronization = ruckig::Synchronization::Time the duration of the trajectory is 8.87s (so the test passes), but for input.synchronization = ruckig::Synchronization::None the duration of the trajectory is 2.34s and the test fails.

Before these commits both sychronization types respected the blocked interval for profile 2. I guess the new method to calculate the trajectory for sychronization = None should respect this interval as well?

pantor commented 2 years ago

No, I think the new behavior is correct. The None synchronization implies that every DoF should move to its target state as fast as possible individually (so without waiting for other DoFs), and therefore each DoF will use the fastest profile from the Step1 calculation (which is saved in the blocks[dof].p_min variable with corresponding duration blocks[dof].t_min). The whole issue of blocked intervals exists solely because of synchronizing multiple DoFs with non-zero velocity or acceleration target states, but we can ignore all that with the None synchronization. So without synchronization, the trajectory duration will always be equal or less than the duration with time synchronization.

I hope that clears that up a bit.