Dont allow zeros in time_from_start to prevent the use of time_from_s…

[MauleshSTrivedi]

…tart in end_time in follow_controller.py

This hack gets my PhantomX Pincher arm to work with the turtlebot_arm package (ver. 0.4) with the Pick and Place demo. This is because the time_from_start starts with zero in the trajectory message; and all the trajectory points have zero velocities in the beginning; and there is an extra joint for the gripper which throws off an "Invalid Joint Trajectory.. " error.

[croesmann]

Thank you for the pull request.
I am currently thinking about the requirement of both modes that I've introduced.
After your changes, the second mode (asynchronous) can only be selected in case of negative time,
which would be okay, but not desired intentionally.
But in general, we should better get rid of the second mode completely:
The asynchronous motion can also be defined using the standard trajectory message (by just adding some intermediate joint configurations).
Further, we should adapt the trajectory representation to the one also used by ros_control:

• If only the joint positions are specified: use a linear interpolation (this is the current implementation)
• If both joint positions and velocities are specified: use a cubic interpolation (continuous velocity profile)
• If joint positions, velocities and accelerations are specified: use a quintic interpolation (continuous acceleration profile)

Do you have some thoughts about that?

ps: (not related to the pull request) I am using the arbotix board with a phantom x pincher and my arm transitions are highly jerky.
In addition to the arbotix_pkg approach, I am currently implementing a c++ based interface that supports ros_control. I am going to try different controllers and settings in order to run my robot smoothly. Maybe I can afterwards improve the arbotix_pkg with that insights.

[MauleshSTrivedi]

Hey, Thanks for the reply.. So me and my friend here (@kbogert) were trying to think of a solution to this problem.. One way, like you suggestd could be to completely remove the asynchronous mode and just leave it at that.. On the other hand, we could run through the entire list of messages to see which of them have zero velocities.. If all of them are zeroes then we could do the follow_time_mode, otherwise we could go ahead with the second follow_velocity_mode..

We used your code with Windowx arm and it worked perfectly.. In case of the Phantomx arm, we are facing the same issue like you.. pretty jerky movements.. I guess its just a hardware issue more than anything else.. Were you able to get better results with different controllers?!