Hi Konrad,

There are no issues with breaking realtime constraints because the
unsafe code is called from a non-realtime thread.

You're correct that the JointSplineTrajectoryController code performs
several operation which are not realtime safe.  These operations are
performed not in the realtime loop but rather in the ROS subscriber
callback, which is called from a non-realtime thread.

Your proposed solution is therefore quite similar to what already
exists: the non-realtime portion of the
JointSplineTrajectoryController reorders the joints and composes
trajectories, and then sends it to the realtime portion which just
performs interpolation.

There are a few faults with this system, and I'm interested in
discussing solutions which address them:
1. Trajectories cannot be sent from within realtime--they only come
from outside of realtime.
2. The current design has a great deal of complexity, particularly in
taking care when transferring the trajectory to realtime, composing
trajectories, and responding with a result to the action.

There's probably more.

That said, this interface allows us to comfortably separate the motion
planning pipeline from the realtime loop.  Once implemented,  you can
run much of the code that was developed to move the PR2 on your own
robot.

Lastly, you may want to consider examining the
JointTrajectoryActionController which combines the
joint_trajectory_action and the JointSplineTrajectoryController.

-Stu

On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz <konradb3@gmail.com> 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 ?
>
> Pozdrawiam
> Konrad Banachowicz
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>



-- 
Stuart Glaser
sglaser -at- willowgarage -dot- com
www.willowgarage.com