[ros-users] [Orocos-Dev] Control system design question.

[Herman Bruyninckx]

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