[ros-users] Control system design question.

[Stuart Glaser]

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