2010/9/18 Herman Bruyninckx <Herman.Bruyninckx@mech.kuleuven.be>

On Fri, 17 Sep 2010, Konrad Banachowicz wrote:

Hi,
I'm working on integration of orocos RT-controller with ROS manipulation pipeline.
I already done joint_state_publisher and oro_action_server. Next on my list are
joint_trajectory_action and JointSplineTrajectoryController.
I have some concerns about real-time behaviours of those, and way of implementation
in orocos.

joint_trajectory_action :
It receive goal containing trajectory (variable size, unbounded size), then check
constraints and send to JointSplineTrajectoryController.

JointSplineTrajectoryController:
It loop generating interpolated position for joint regulator.
When it receive new trajectory it reorder joints in received trajectory (memory
allocation, iterating on unknown size array) and try to compose current trajectory
with newly received (memory allocation, iterating on unknown size array).
It have to by done between two sequential interpolations (in my system 1ms).

My solution :
Data transmited between joint_trajectory_action and JointSplineTrajectoryController
contains only single point (constant size).

joint_trajectory_action do joint reordering and compose trajectories and is feeding
JointSplineTrajectoryController with trajectory points.

JointSplineTrajectoryController interpolate between two points (have one point
buffer)

This solution should work with trajectories when time between points is >> 1ms.

What do you think about doing this this way ?
What is alternative solutions ?
What do you think about re-usability of this solution in yours systems ?

I do not know whether I fully understand your approach and solution, but
here are some comments nevertheless about what I have learned about
trajectories the last 20 years:
- if you have a system with hard realtime constraints to connect
trajectories together within 1ms, it makes sense to add another level of
trajectory generation, in the form of a "trajectory joining" component.
That component can do the joining already before the trajectory is
finished, in a separate thread/process. It will not be a trivial
extension to the current approach, though.
- do you really the kind of joint space trajectories that are currently
being used? With 1ms latency, it seems that you are looking for
trajectories that can be joined also at non-zero velocity, in contrast to
our current implementations...
If you have indeed a need for other trajectory types, please start a
discussion on this topic, since one of our PhD students. Wilm Decré, is
doing his research on this topic; and he has already some results, but
they have not yet been integrated in Orocos code.

Herman
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users