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 > Hi, > > On Fri, Sep 17, 2010 at 12:53 PM, 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 ? > > 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 > >> > >> 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 > > >> 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 > > > > > > _______________________________________________ > > 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 >