2010/9/18 Herman Bruyninckx
<Herman.Bruyninckx@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 ...
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@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@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