[ros-users] Control system design question.

Fri Sep 17 21:52:01 UTC 2010

I have an other concern, what will happen if processing of trajectory take
more time than remaining to first point of new trajectory.

Pozdrawiam
Konrad Banachowicz

2010/9/17 Stuart Glaser <sglaser at willowgarage.com>

> Hi,
>
> On Fri, Sep 17, 2010 at 12:53 PM, Konrad Banachowicz <konradb3 at gmail.com>
> 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 ?
>
> The buffer used in the JointSplineTrajectoryController is called a
> RealtimeBox.  It currently uses a mutex (locked for a guaranteed
> maximum number of instructions on a system that supports priority
> inheritance), though it can certainly switch to a lock-free buffer.
>

> > 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.
>
> Sounds like you've moved the non-realtime parts of the
> JointSplineTrajectoryController into your version of the
> joint_trajectory_action.  That sounds like a reasonable solution.
>
> -Stu
>
> >
> > Pozdrawiam
> > Konrad Banachowicz
> >
> >
> > 2010/9/17 Stuart Glaser <sglaser at 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 at 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 at 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 at code.ros.org
> >> https://code.ros.org/mailman/listinfo/ros-users
> >
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users at 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 at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100917/ce4f6019/attachment-0003.html>