[ros-users] [Orocos-Dev] Control system design question.

Konrad Banachowicz konradb3 at gmail.com
Sat Sep 18 13:25:01 UTC 2010


Pozdrawiam
Konrad Banachowicz


2010/9/18 Herman Bruyninckx <Herman.Bruyninckx at mech.kuleuven.be>

> On Sat, 18 Sep 2010, Konrad Banachowicz wrote:
>
>  My solution splits the trajectory generation into two parts.
>> One part is hard-RT and do interpolation between two points (with non zero
>> velocity
>> at both ends). It can be used with sensor feedback (servo vision).
>> Second part is feeding first one with points along complex trajectory, it
>> do all
>> "trajectory joining", joints reordering ...
>>
>
> Ok, that sounds ok. From the software point of view, at least. But what is
> the use of the "complex trajectory" if you have to react to visual data in
> realtime?
>
Second part would be used for interfacing with ROS node like move_arm.
For reacting to  visual data in realtime first component is all you need.

>
>  Pozdrawiam
>> Konrad Banachowicz
>>
>
> Herman
>
>
>
>> 2010/9/18 Herman Bruyninckx <Herman.Bruyninckx at mech.kuleuven.be>
>> On Fri, 17 Sep 2010, 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 ?
>>
>>
>> I do not know whether I fully understand your approach and solution, but
>> here are some comments nevertheless about what I have learned about
>> trajectories the last 20 years:
>> - if you have a system with hard realtime constraints to connect
>>  trajectories together within 1ms, it makes sense to add another level of
>>  trajectory generation, in the form of a "trajectory joining" component.
>>  That component can do the joining already before the trajectory is
>>  finished, in a separate thread/process. It will not be a trivial
>>  extension to the current approach, though.
>> - do you really the kind of joint space trajectories that are currently
>>  being used? With 1ms latency, it seems that you are looking for
>>  trajectories that can be joined also at non-zero velocity, in contrast to
>>  our current implementations...
>>  If you have indeed a need for other trajectory types, please start a
>>  discussion on this topic, since one of our PhD students. Wilm Decré, is
>>  doing his research on this topic; and he has already some results, but
>>  they have not yet been integrated in Orocos code.
>>
>> Herman
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>>
>>
>>
> --
>  K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
>    <http://people.mech.kuleuven.be/~bruyninc<http://people.mech.kuleuven.be/%7Ebruyninc>>
> Tel: +32 16 328056
>  EURON Coordinator (European Robotics Research Network) <
> http://www.euron.org>
>  Open Realtime Control Services <http://www.orocos.org>
>  Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
>
> _______________________________________________
> 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/20100918/9c6c54f1/attachment-0003.html>


More information about the ros-users mailing list