"time_from_start" not working about lynxmotion_ssc32u HOT 4 CLOSED

I apologize for being absent for so long. The driver previously did not use "time_from_start" nor did it use more than 1 position from the JointTrajectory message. I have updated the driver to support both "time_from_start" and more than 1 position. The changes are currently in the dev branch.

I wasn't exactly sure how to interpret "time_from_start" so I ended up implementing it as the expected completion time from when the message was received of the current position command. So, using your code as an example, in the tuck function the first set of positions would execute for 5 seconds, the second set of postions would execute for 3 seconds after the first set was finished, and finally the third set would execute for 3 seconds after the second set was complete. Are these the expected results?

from lynxmotion_ssc32u.

The definition of "time_from_start" is explained well here. Which the way you interpreted but each same has to be greater then one before. I also hacked together a way to use that data to ramp up to the joint rather than to instantly jump to it here but I did not use the true definition of time_from_start. I suppose your trajectory planner should generate a series of positions, velocities and accelerations to form a continuous spline however, there hasn't been much development for these manipulators.

from lynxmotion_ssc32u.

Hi, thank you both for looking into this I have done some initial tests and the driver seems to function in a more familiar way now that it supports multi points and the time_from_start parts of JointTrajectory messages. I will be using it more in the coming weeks so will let you know if I find any issues.

from lynxmotion_ssc32u.

The changes have been merged into the master branch.

from lynxmotion_ssc32u.