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

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
Delete this message
Reply to this message
Author: Konrad Banachowicz
Date:  
To: Herman Bruyninckx, ros-users
CC: orocos-dev@lists.mech.kuleuven.be
Subject: Re: [ros-users] [Orocos-Dev] Control system design question.
Pozdrawiam
Konrad Banachowicz


2010/9/18 Herman Bruyninckx <>

> 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 <>
>> 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
>>
>> 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
>
> https://code.ros.org/mailman/listinfo/ros-users
>
>