"time_from_start" not working

[garyedwards]

Hi, I am having issues getting the driver to respect the "time_from_start" part of the JointTrajectory message. I am publishing directly to the "/joint_controller_1/command" and have tried JointTrajectory messages with single and multiple JointTrajectoryPoint points and the "time_from_start" does not seem to effect the speeds.

I am used to using FollowJointTrajectoryAction actions with dynamixels so may be approaching this wrong. In the test code below the servos just move to the 1 position. Any help would be much appreciated.

Test code: https://s3-eu-west-1.amazonaws.com/data.re.je/tuck_arm.py

[mattrichard]

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?

[tonybaltovski]

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.

[garyedwards]

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.

[mattrichard]

The changes have been merged into the master branch.