sdotdot not equal to zero at start and end of trajectory?

[yakunsjtu]

I used the C++ API and found the second derivative of the path parameter is not equal to zero at the start and end of the computed trajectory which is not friendly to the acceleration feedforward control. At the initial and end of the trajectory, the joint acceleration is not equal to zero. I'm wondering if there is any chance to enforce the sdotdot to zero as the boundary conditions?

[hungpham2511]

It is certainly possible. Basically, you need to create a path-dependent acceleration constraint that "tapers" to zero at the beginning and the end of a path.

[yakunsjtu]

Hi @hungpham2511 , I tried to add varying acceleration constraints at the beginning and the end of the path (5% length of the path interval). And I ramped the acceleration from zero to max at the beginning and from max to zero at the end. while in the middle, the constant acceleration was used. However, the computed trajectory was very slow. Not sure what went wrong.

Also, I tried to use a cubic spline to smooth the s param and enforce the acceleration/velocity to be zero at the boundary. But this would cause overshoot in the acceleration profile.

Because I'm using the computed torque control method, so the acceleration jump will cause a torque jump at the beginning and end of the path, say, from 0 to 50N.m, which is not desirable.

[hungpham2511]

Do you have any code examples or plots?

[yakunsjtu]

@hungpham2511 , I tried to modify the LinearJointAcceleration.hpp and LinearJointAcceleration.cpp to consider the varying constraints. But the topp failed to compute and returned a total duration of inf. Could it be a problem if the initial acceleration constraint is Zero?

LinearJointAcceleration.cpp.txt
LinearJointAcceleration.hpp.txt

[jmirabel]

It's rather hard to help you with only those files. Can you provide a repeatable example ?

[mrunaljsarvaiya]

I'm running into the same issue where I'd like the start and end of the trajectory to have zero accelerations. Are there any updates on this? I wonder if we could enforce jerk constraints to solve this more generally

[hungpham2511]

Unfortunately, I have not had the chance to revisit this problem (many have asked for it).

The simplest option is to fit a spline on the output trajectory with a continuous 2nd derivative constraint. Not the most principled option but it's gonna work 😉