I have an other concern, what will happen if processing of trajectory take more time than remaining to first point of new trajectory.<br><br clear="all">Pozdrawiam<br>Konrad Banachowicz<br>
<br><br><div class="gmail_quote">2010/9/17 Stuart Glaser <span dir="ltr"><<a href="mailto:sglaser@willowgarage.com">sglaser@willowgarage.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
On Fri, Sep 17, 2010 at 12:53 PM, Konrad Banachowicz <<a href="mailto:konradb3@gmail.com">konradb3@gmail.com</a>> wrote:<br>
> yes RT and non-RT work execute in separated threads but what about shared<br>
> data ? as far as i know there is some locking involved ?<br>
<br>
</div>The buffer used in the JointSplineTrajectoryController is called a<br>
RealtimeBox. It currently uses a mutex (locked for a guaranteed<br>
maximum number of instructions on a system that supports priority<br>
inheritance), though it can certainly switch to a lock-free buffer. <br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Communication between RT and non-RT threads is complex problem, but OROCOS<br>
> solves most problems. it use lock-free buffers for communication between<br>
> components. Currently in ROS joint_trajectory_action is whole non-RT and<br>
> JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT<br>
> work are moved into joint_trajectory_action. This make clear border between<br>
> RT and non-RT part.<br>
<br>
</div>Sounds like you've moved the non-realtime parts of the<br>
JointSplineTrajectoryController into your version of the<br>
joint_trajectory_action. That sounds like a reasonable solution.<br>
<br>
-Stu<br>
<div><div></div><div class="h5"><br>
><br>
> Pozdrawiam<br>
> Konrad Banachowicz<br>
><br>
><br>
> 2010/9/17 Stuart Glaser <<a href="mailto:sglaser@willowgarage.com">sglaser@willowgarage.com</a>><br>
>><br>
>> Hi Konrad,<br>
>><br>
>> There are no issues with breaking realtime constraints because the<br>
>> unsafe code is called from a non-realtime thread.<br>
>><br>
>> You're correct that the JointSplineTrajectoryController code performs<br>
>> several operation which are not realtime safe. These operations are<br>
>> performed not in the realtime loop but rather in the ROS subscriber<br>
>> callback, which is called from a non-realtime thread.<br>
>><br>
>> Your proposed solution is therefore quite similar to what already<br>
>> exists: the non-realtime portion of the<br>
>> JointSplineTrajectoryController reorders the joints and composes<br>
>> trajectories, and then sends it to the realtime portion which just<br>
>> performs interpolation.<br>
>><br>
>> There are a few faults with this system, and I'm interested in<br>
>> discussing solutions which address them:<br>
>> 1. Trajectories cannot be sent from within realtime--they only come<br>
>> from outside of realtime.<br>
>> 2. The current design has a great deal of complexity, particularly in<br>
>> taking care when transferring the trajectory to realtime, composing<br>
>> trajectories, and responding with a result to the action.<br>
>><br>
>> There's probably more.<br>
>><br>
>> That said, this interface allows us to comfortably separate the motion<br>
>> planning pipeline from the realtime loop. Once implemented, you can<br>
>> run much of the code that was developed to move the PR2 on your own<br>
>> robot.<br>
>><br>
>> Lastly, you may want to consider examining the<br>
>> JointTrajectoryActionController which combines the<br>
>> joint_trajectory_action and the JointSplineTrajectoryController.<br>
>><br>
>> -Stu<br>
>><br>
>> On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz <<a href="mailto:konradb3@gmail.com">konradb3@gmail.com</a>><br>
>> wrote:<br>
>> > Hi,<br>
>> > I'm working on integration of orocos RT-controller with ROS manipulation<br>
>> > pipeline.<br>
>> > I already done joint_state_publisher and oro_action_server. Next on my<br>
>> > list<br>
>> > are joint_trajectory_action and JointSplineTrajectoryController.<br>
>> > I have some concerns about real-time behaviours of those, and way of<br>
>> > implementation in orocos.<br>
>> ><br>
>> > joint_trajectory_action :<br>
>> > It receive goal containing trajectory (variable size, unbounded size),<br>
>> > then<br>
>> > check constraints and send to JointSplineTrajectoryController.<br>
>> ><br>
>> > JointSplineTrajectoryController:<br>
>> > It loop generating interpolated position for joint regulator.<br>
>> > When it receive new trajectory it reorder joints in received trajectory<br>
>> > (memory allocation, iterating on unknown size array) and try to compose<br>
>> > current trajectory with newly received (memory allocation, iterating on<br>
>> > unknown size array).<br>
>> > It have to by done between two sequential interpolations (in my system<br>
>> > 1ms).<br>
>> ><br>
>> > My solution :<br>
>> > Data transmited between joint_trajectory_action and<br>
>> > JointSplineTrajectoryController contains only single point (constant<br>
>> > size).<br>
>> ><br>
>> > joint_trajectory_action do joint reordering and compose trajectories and<br>
>> > is<br>
>> > feeding JointSplineTrajectoryController with trajectory points.<br>
>> ><br>
>> > JointSplineTrajectoryController interpolate between two points (have one<br>
>> > point buffer)<br>
>> ><br>
>> > This solution should work with trajectories when time between points is<br>
>> > >><br>
>> > 1ms.<br>
>> ><br>
>> > What do you think about doing this this way ?<br>
>> > What is alternative solutions ?<br>
>> > What do you think about re-usability of this solution in yours systems ?<br>
>> ><br>
>> > Pozdrawiam<br>
>> > Konrad Banachowicz<br>
>> ><br>
>> > _______________________________________________<br>
>> > ros-users mailing list<br>
>> > <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
>> > <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Stuart Glaser<br>
>> sglaser -at- willowgarage -dot- com<br>
>> <a href="http://www.willowgarage.com" target="_blank">www.willowgarage.com</a><br>
>> _______________________________________________<br>
>> ros-users mailing list<br>
>> <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
>> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
><br>
><br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Stuart Glaser<br>
sglaser -at- willowgarage -dot- com<br>
<a href="http://www.willowgarage.com" target="_blank">www.willowgarage.com</a><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br>