On Fri, 17 Sep 2010, Konrad Banachowicz wrote:

> yes RT and non-RT work execute in separated threads but what about shared data ? as
> far as i know there is some locking involved ?
> 
> Transmitting trajectories in real time is problematic, but i don't think it is really
> necessary. Generation of trajectories doesn't have strong time constraints, so there
> is no point of executing it in real-time.

That depends on the time frame spanned by your trajectory: in many
sensor-based applications, trajectory generation can be as dynamic as once
every 1/30th of a second (e.g., visual servoing), where a trajectory must
be generated for a motion controller that runs at 250Hz or so.

> Communication between RT and non-RT threads is complex problem, but OROCOS solves
> most problems. it use lock-free buffers for communication between components.
> Currently in ROS joint_trajectory_action is whole non-RT and
> JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT work are
> moved into joint_trajectory_action. This make clear border between RT and non-RT
> part.
> 
> Pozdrawiam
> Konrad Banachowicz
> 
> 
> 2010/9/17 Stuart Glaser <sglaser@willowgarage.com>
>       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
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
> 
> 
> 
>

--
   K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
   EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
   Open Realtime Control Services <http://www.orocos.org>
   Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>