[ros-users] Control system design question.

[Konrad Banachowicz]

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.

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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100917/67f56926/attachment-0003.html>