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?
> Pozdrawiam
> Konrad Banachowicz
Herman
>
> 2010/9/18 Herman Bruyninckx <Herman [dot] 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
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> 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] Control system design question.
Pozdrawiam
Konrad Banachowicz
2010/9/18 Herman Bruyninckx <Herman [dot] 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.
>
> Tel: +32 16 328056
> Pozdrawiam
>> Konrad Banachowicz
>>
>
> Herman
>
>
>
>> 2010/9/18 Herman Bruyninckx <Herman [dot] 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
>> ros-users [..] ...
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>>
>>
>>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc
> 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 [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>