Joint trajectory action controller

[Adolfo Rodríguez Tsouroukdissian]

All,

I'm about to start porting the JointTrajectoryActionController [1] to ros_control. The current incantation of the controller supports three ROS interfaces:

1. Topic: trajectory_msgs/JointTrajectory.

2. Action interface: JointTrajectory.

3. Action interface: FollowJointTrajectory.

For ros_control's implementation, I plan on supporting 3. and drop 2 (IIUC it's deprecated). Supporting 1. comes almost for free, so I have no strong preference there.

Let me know if somebody has a different opinion on which interfaces to support.

Cheers,

Adolfo.

[1] http://www.ros.org/wiki/robot_mechanism_controllers/JointTrajectoryActionController

--
Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
adolfo.r...@pal-robotics.com
http://www.pal-robotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4º4ª
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
Skype: adolfo.pal-robotics
Facebook - Twitter - PAL Robotics YouTube Channel

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.

[Jonathan Bohren]

On Mon, Jul 1, 2013 at 10:22 AM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

I'm about to start porting the JointTrajectoryActionController [1] to ros_control. The current incantation of the controller supports three ROS interfaces:

1. Topic: trajectory_msgs/JointTrajectory.

2. Action interface: JointTrajectory.

3. Action interface: FollowJointTrajectory.

For ros_control's implementation, I plan on supporting 3. and drop 2 (IIUC it's deprecated). Supporting 1. comes almost for free, so I have no strong preference there.

Let me know if somebody has a different opinion on which interfaces to support.

I just put together a joint trajectory controller based on the reflexxes Type II motion libraries [1] over this past weekend. This controller currently supports (1) and I was going to implement (3) today. The nice thing about using reflexxes is that you can command it with _very_ sparse trajectories and they will all be synchronized and observe velocity and acceleration limits, and we don't need to worry about doing all the interpolation. I was also thinking about having a simple single-joint-set-point interface for testing purposes.

 One question I have is what behavior we want to have when a new trajectory is commanded during the execution of an active trajectory. The current behavior that I've implemented (and am testing right now) simply replaces the active trajectory, but we could do something more sophisticated where it only replaces the points of the active trajectory which would occur during the new trajectory.

[1] http://www.reflexxes.com/

--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren

[Adolfo Rodríguez Tsouroukdissian]

On Mon, Jul 1, 2013 at 4:55 PM, Jonathan Bohren <jonatha...@gmail.com> wrote:

On Mon, Jul 1, 2013 at 10:22 AM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

I'm about to start porting the JointTrajectoryActionController [1] to ros_control. The current incantation of the controller supports three ROS interfaces:

1. Topic: trajectory_msgs/JointTrajectory.

2. Action interface: JointTrajectory.

3. Action interface: FollowJointTrajectory.

For ros_control's implementation, I plan on supporting 3. and drop 2 (IIUC it's deprecated). Supporting 1. comes almost for free, so I have no strong preference there.

Let me know if somebody has a different opinion on which interfaces to support.

I just put together a joint trajectory controller based on the reflexxes Type II motion libraries [1] over this past weekend. This controller currently supports (1) and I was going to implement (3) today. The nice thing about using reflexxes is that you can command it with _very_ sparse trajectories and they will all be synchronized and observe velocity and acceleration limits, and we don't need to worry about doing all the interpolation. I was also thinking about having a simple single-joint-set-point interface for testing purposes.

So Reflexxes is doing limits-aware interpolation, correct?. If the time-to-waypoint is less than what the user specified, are you warping the resulting trajectory so that it takes longer?.

Is the code somewhere public for inspection?.

I have also considered using Reflexxes at least as part of the implementation. The downside of using it without an additional spline interpolator are that with the current implementation you can choose to specify:

- Positions-only, resulting in a linear piecewise trajectory (not nice for sending to actuators). I wonder if we should still support this.

- Position+velocity, resulting in cubic splines. Reflexxes Type II would be a good replacement for this usecase.

- Position+velocity+acceleration, resulting in quintic splines. Reflexxes Type II can't help us here. One could resort to the Type IV library, but it's not open source, and you need an acceleration estimate + jerk limits.

I'd really like to not sacrifice the last scenario above (pos, vel, acc waypoints). An alternative would be to combine the existing spline interpolators with a Reflexxes Type II post-processing step for enforcing limits.

 

 One question I have is what behavior we want to have when a new trajectory is commanded during the execution of an active trajectory. The current behavior that I've implemented (and am testing right now) simply replaces the active trajectory, but we could do something more sophisticated where it only replaces the points of the active trajectory which would occur during the new trajectory.

I would keep the goal-processing logic similar to what the existing controller does. Since the new trajectory might start in the future (as specified in the header stamp), one should:

- Keep the current trajectory until the new trajectory start time.

- Compute a new segment bridging the old and new trajectories.

- Replace old trajectory segments that overlap with new one.

This is one of the best-kept secrets of the existing implementation, which almost nobody seems to use, but I've found to be just great. It's also tricky to implement, and has had important bugs in the past, so it needs good testing.

Adolfo.

[1] http://www.reflexxes.com/

--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren

--
You received this message because you are subscribed to the Google Groups "ROS/Orocos Robot Control Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jonathan Bohren]

On Mon, Jul 1, 2013 at 11:30 AM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

On Mon, Jul 1, 2013 at 4:55 PM, Jonathan Bohren <jonatha...@gmail.com> wrote:

On Mon, Jul 1, 2013 at 10:22 AM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

I'm about to start porting the JointTrajectoryActionController [1] to ros_control. The current incantation of the controller supports three ROS interfaces:

1. Topic: trajectory_msgs/JointTrajectory.

2. Action interface: JointTrajectory.

3. Action interface: FollowJointTrajectory.

For ros_control's implementation, I plan on supporting 3. and drop 2 (IIUC it's deprecated). Supporting 1. comes almost for free, so I have no strong preference there.

Let me know if somebody has a different opinion on which interfaces to support.

I just put together a joint trajectory controller based on the reflexxes Type II motion libraries [1] over this past weekend. This controller currently supports (1) and I was going to implement (3) today. The nice thing about using reflexxes is that you can command it with _very_ sparse trajectories and they will all be synchronized and observe velocity and acceleration limits, and we don't need to worry about doing all the interpolation. I was also thinking about having a simple single-joint-set-point interface for testing purposes.

So Reflexxes is doing limits-aware interpolation, correct?. If the time-to-waypoint is less than what the user specified, are you warping the resulting trajectory so that it takes longer?.

Yeah, you can achieve this with: http://www.reflexxes.com/software/typeiirml/v1.2.4/docs/class_r_m_l_input_parameters.php#a742353512f88356028dbc20b76fd71f6

 

Is the code somewhere public for inspection?.

 

I have also considered using Reflexxes at least as part of the implementation. The downside of using it without an additional spline interpolator are that with the current implementation you can choose to specify:

- Positions-only, resulting in a linear piecewise trajectory (not nice for sending to actuators). I wonder if we should still support this.

 

Yeah, I'm pretty sure I'd never use this.

- Position+velocity, resulting in cubic splines. Reflexxes Type II would be a good replacement for this usecase.

Yeah.

 

- Position+velocity+acceleration, resulting in quintic splines. Reflexxes Type II can't help us here. One could resort to the Type IV library, but it's not open source, and you need an acceleration estimate + jerk limits.

 

I'd really like to not sacrifice the last scenario above (pos, vel, acc waypoints). An alternative would be to combine the existing spline interpolators with a Reflexxes Type II post-processing step for enforcing limits.

We could try that, what was attractive about reflexxes was just that it was hardened and maintained. 

 

 One question I have is what behavior we want to have when a new trajectory is commanded during the execution of an active trajectory. The current behavior that I've implemented (and am testing right now) simply replaces the active trajectory, but we could do something more sophisticated where it only replaces the points of the active trajectory which would occur during the new trajectory.

I would keep the goal-processing logic similar to what the existing controller does. Since the new trajectory might start in the future (as specified in the header stamp), one should:

- Keep the current trajectory until the new trajectory start time.

- Compute a new segment bridging the old and new trajectories.

- Replace old trajectory segments that overlap with new one.

This is one of the best-kept secrets of the existing implementation, which almost nobody seems to use, but I've found to be just great. It's also tricky to implement, and has had important bugs in the past, so it needs good testing.

Yeah, I implemented similar behavior here, forked from the current trajectory controller (separated from the pr2 stuff) to work with some experimental orocos-rtt-based controllers: https://github.com/jhu-lcsr/controllerman/blob/master/controllerman_controllers/src/trajectory_dispatcher.cpp

This implementation uses a binary search to insert the new trajectory, instead of a linear search, and it also scales trajectories to satisfy velocity limits.

I definitely think this could be cleaned up though.

-j

[Adolfo Rodríguez Tsouroukdissian]

- Position+velocity+acceleration, resulting in quintic splines. Reflexxes Type II can't help us here. One could resort to the Type IV library, but it's not open source, and you need an acceleration estimate + jerk limits.

 

I'd really like to not sacrifice the last scenario above (pos, vel, acc waypoints). An alternative would be to combine the existing spline interpolators with a Reflexxes Type II post-processing step for enforcing limits.

We could try that, what was attractive about reflexxes was just that it was hardened and maintained. 

I can think of no other alternative if we want to support (pos, vel, acc) waypoints and stick to open source dependencies. The spline interpolation code is quite small, so maintaining it should not be a large burden. I'm more concerned with the logic for processing new commands, which is messier and needs a cleanup.

 

 

 One question I have is what behavior we want to have when a new trajectory is commanded during the execution of an active trajectory. The current behavior that I've implemented (and am testing right now) simply replaces the active trajectory, but we could do something more sophisticated where it only replaces the points of the active trajectory which would occur during the new trajectory.

I would keep the goal-processing logic similar to what the existing controller does. Since the new trajectory might start in the future (as specified in the header stamp), one should:

- Keep the current trajectory until the new trajectory start time.

- Compute a new segment bridging the old and new trajectories.

- Replace old trajectory segments that overlap with new one.

This is one of the best-kept secrets of the existing implementation, which almost nobody seems to use, but I've found to be just great. It's also tricky to implement, and has had important bugs in the past, so it needs good testing.

Yeah, I implemented similar behavior here, forked from the current trajectory controller (separated from the pr2 stuff) to work with some experimental orocos-rtt-based controllers: https://github.com/jhu-lcsr/controllerman/blob/master/controllerman_controllers/src/trajectory_dispatcher.cpp

This implementation uses a binary search to insert the new trajectory, instead of a linear search, and it also scales trajectories to satisfy velocity limits.

Getting rid of that linear search was on my TODO list :-)

@jbohren, what are your immediate plans with your implementation?. I'm thinking of attacking the problem in a bottom-up approach, starting with separating and testing the different building blocks: Spline sampler, command processing, RT-friendly action goal handle, etc. Hopefully combining these blocks to form the controller will result in something succinct and readable. I'm very much looking forward into incorporating Reflexxes into the mix.

Adolfo

 

I definitely think this could be cleaned up though.

-j

--

You received this message because you are subscribed to the Google Groups "ROS/Orocos Robot Control Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dave Coleman]

I think its great you guys are working on this, having a good JointTrajectoryActionController is a very important for integrating MoveIt! with ros_control. However, hasn't MoveIt! already been used with ros_control by the guys at HiDof - meaning they already have a joint trajectory controller?

If you go with using reflexxes then Type II is definitely the only license we can use. 

I'm interested in helping/testing with this initiative. 

:: dave | 251.463.2345 c

[Jonathan Bohren]

On Mon, Jul 1, 2013 at 1:21 PM, Dave Coleman <davetc...@gmail.com> wrote:

I think its great you guys are working on this, having a good JointTrajectoryActionController is a very important for integrating MoveIt! with ros_control. However, hasn't MoveIt! already been used with ros_control by the guys at HiDof - meaning they already have a joint trajectory controller?

 

@wim Do they?

If you go with using reflexxes then Type II is definitely the only license we can use.

The nice thing about reflexxes is that if someone _does_ have Type IV (easy if you're in academia), they can optionally link against it.

-j

[Marcus Liebhardt]

Interesting topic!

I haven't use this ros controller myself, so my comments are based on what I have read here so far.

(Does anyone have a link to the original source code?)

On Tue, Jul 2, 2013 at 3:22 AM, Jonathan Bohren <jonatha...@gmail.com> wrote:

On Mon, Jul 1, 2013 at 1:21 PM, Dave Coleman <davetc...@gmail.com> wrote:

I think its great you guys are working on this, having a good JointTrajectoryActionController is a very important for integrating MoveIt! with ros_control. However, hasn't MoveIt! already been used with ros_control by the guys at HiDof - meaning they already have a joint trajectory controller?

 

@wim Do they?

If you go with using reflexxes then Type II is definitely the only license we can use.

The nice thing about reflexxes is that if someone _does_ have Type IV (easy if you're in academia), they can optionally link against it.

I would love to see a modular approach, i.e. to make it easy to swap different interpolation methods and maybe even different controller methods (feed-forward vs. feed-back).

We have a custom controller here, which uses the same interface (FollowJointTrajectory) and does pretty much the same (interpolation, feedforward control). We are using our (Daniel's) open-source library ECL [1], which contains various spline interpolations, e.g. smooth linear (quinitic + linear), quintic + cubic and tension spline interpolation.

What's your time schedule on this, Adolfo (and everyone else who likes to join)?

Cheers,

Marcus

[1] https://github.com/stonier/ecl_manipulation/blob/groovy-devel/ecl_manipulators/include/ecl/manipulators/trajectory.hpp

-j

--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren

--
You received this message because you are subscribed to the Google Groups "ROS/Orocos Robot Control Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Marcus Liebhardt 
Control Engineer
Yujin Robot
주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023.
Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu, Seoul, 153-023, Republic of Korea
Website: http://www.yujinrobot.com
Email: marcus.l...@yujinrobot.com
Phone: +82-70-46577073

[Adolfo Rodríguez Tsouroukdissian]

On Tue, Jul 2, 2013 at 1:57 AM, Marcus Liebhardt <marcus.l...@yujinrobot.com> wrote:

Interesting topic!

I haven't use this ros controller myself, so my comments are based on what I have read here so far.

(Does anyone have a link to the original source code?)

On Tue, Jul 2, 2013 at 3:22 AM, Jonathan Bohren <jonatha...@gmail.com> wrote:

On Mon, Jul 1, 2013 at 1:21 PM, Dave Coleman <davetc...@gmail.com> wrote:

I think its great you guys are working on this, having a good JointTrajectoryActionController is a very important for integrating MoveIt! with ros_control. However, hasn't MoveIt! already been used with ros_control by the guys at HiDof - meaning they already have a joint trajectory controller?

 

@wim Do they?

If you go with using reflexxes then Type II is definitely the only license we can use.

The nice thing about reflexxes is that if someone _does_ have Type IV (easy if you're in academia), they can optionally link against it.

I would love to see a modular approach, i.e. to make it easy to swap different interpolation methods and maybe even different controller methods (feed-forward vs. feed-back).

We have a custom controller here, which uses the same interface (FollowJointTrajectory) and does pretty much the same (interpolation, feedforward control). We are using our (Daniel's) open-source library ECL [1], which contains various spline interpolations, e.g. smooth linear (quinitic + linear), quintic + cubic and tension spline interpolation.

What's your time schedule on this, Adolfo (and everyone else who likes to join)?

Schedule: Start this week, finish when it's done ;-). I anticipate it could take about a month to have something solid.

Cheers,

Marcus

[1] https://github.com/stonier/ecl_manipulation/blob/groovy-devel/ecl_manipulators/include/ecl/manipulators/trajectory.hpp

-j

--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren

--
You received this message because you are subscribed to the Google Groups "ROS/Orocos Robot Control Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Marcus Liebhardt 
Control Engineer
Yujin Robot
주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023.
Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu, Seoul, 153-023, Republic of Korea
Website: http://www.yujinrobot.com
Email: marcus.l...@yujinrobot.com
Phone: +82-70-46577073

[Adolfo Rodríguez Tsouroukdissian]

On Tue, Jul 2, 2013 at 10:34 AM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

On Tue, Jul 2, 2013 at 1:57 AM, Marcus Liebhardt <marcus.l...@yujinrobot.com> wrote:

Interesting topic!

I haven't use this ros controller myself, so my comments are based on what I have read here so far.

(Does anyone have a link to the original source code?)

On Tue, Jul 2, 2013 at 3:22 AM, Jonathan Bohren <jonatha...@gmail.com> wrote:

On Mon, Jul 1, 2013 at 1:21 PM, Dave Coleman <davetc...@gmail.com> wrote:

I think its great you guys are working on this, having a good JointTrajectoryActionController is a very important for integrating MoveIt! with ros_control. However, hasn't MoveIt! already been used with ros_control by the guys at HiDof - meaning they already have a joint trajectory controller?

 

@wim Do they?

If you go with using reflexxes then Type II is definitely the only license we can use.

The nice thing about reflexxes is that if someone _does_ have Type IV (easy if you're in academia), they can optionally link against it.

I would love to see a modular approach, i.e. to make it easy to swap different interpolation methods and maybe even different controller methods (feed-forward vs. feed-back).

We have a custom controller here, which uses the same interface (FollowJointTrajectory) and does pretty much the same (interpolation, feedforward control). We are using our (Daniel's) open-source library ECL [1], which contains various spline interpolations, e.g. smooth linear (quinitic + linear), quintic + cubic and tension spline interpolation.

What's your time schedule on this, Adolfo (and everyone else who likes to join)?

Schedule: Start this week, finish when it's done ;-). I anticipate it could take about a month to have something solid.

I hit send too fast. My primary objective is to have something similar to the existing JointTrajectoryActionController in terms of functionality. If time permits to achieve this with some level of generality, so that one can customize parts of the controller, great, but it's not the primary objective. Coming up with such flexible interfaces can have a big impact on development time, and it's something that can be done once a baseline implementation is in place, as the client-facing ROS interface (action, topic) remains the same. At any rate, I have my eyes on ECL and Reflexxes.

Cheers,

Adolfo.

[Jonathan Bohren]

I just created a proposal for a trajectory_interface on github: https://github.com/ros-controls/ros_control/issues/74

Take a look and tell me what you think.

-j

[Wim Meeussen]

>> I think its great you guys are working on this, having a good
>> JointTrajectoryActionController is a very important for integrating MoveIt!
>> with ros_control. However, hasn't MoveIt! already been used with ros_control
>> by the guys at HiDof - meaning they already have a joint trajectory
>> controller?
>
> @wim Do they?

At hiDOF we've been using MoveIt! in combination with ros_control on a
hard realtime system. And while I wish we had some secret trajectory
controller code laying around, the usecases we've been working on have
required specialized controllers and API's that didn't map on the
trajectory interface.

Wim


--
Wim Meeussen
CTO, hiDOF Inc.
650-529-4522
http://hidof.com

[Jonathan Bohren]

On Tue, Jul 2, 2013 at 3:21 PM, Wim Meeussen <w...@hidof.com> wrote:

At hiDOF we've been using MoveIt! in combination with ros_control on a
hard realtime system.   And while I wish we had some secret trajectory
controller code laying around, the usecases we've been working on have
required specialized controllers and API's that didn't map on the
trajectory interface.

Interesting, care to give some feedback on this proposal idea?

https://github.com/ros-controls/ros_control/issues/74

[Adolfo Rodríguez Tsouroukdissian]

Hi all,

Yesterday I pushed a changeset to the branch where the controller is being developed that deserves some mention. What follows is the associated commit message:

Drop usage of system clock in controller loop.
   
    Internal trajectory representation is no longer parameterized on the system
    clock, but on a monotonically increasing variable representing controller uptime
    (the base is irrelevant, the important thing is that it's monotonically
    increasing).
   
    This solves the problem that if the system time changes during controller
    operation, the result is a potentially dangerous discontinuity in the joint
    commands. It's true that one should not perform abrupt time changes during
    operation, and only do very small corrections (eg. NTP slew), but it stands
    to reason (and to the principle of least surprise) that already queued
    commands should not be affected by an external influence like a time change.
   
    When a new trajectory command arrives, it will be immediately transformed to the
    monotonic reference. In this way, system time changes affect only new commands
    arriving _after_ the change, and not already queued ones.

Additional comment: By using a limits-aware interpolator, like a Reflexxes-based one, trajectory discontinuities will be smoothed out, but the central issue that an external influence is affecting already queued commands still remains.

Would there be any objections against parameterizing trajectories using a monotonically increasing time source?.

Cheers,

[Adolfo Rodríguez Tsouroukdissian]

All,

Starting from ros_controllers 0.5.3 (Hydro only), there now exists the joint_trajectory_controller package that implements a controller for executing joint-space trajectories on a group of joints. For those familiar with the PR2 coontrollers, this is ros_control's equivalent of the JointTrajectoryActionController. A brief summary of its main features follows:

ROS API
- Commands:
  - FollowJointTrajectory action
  - trajectory_msgs::JointTrajectory topic
  - Support for the deprecated JointTrajectory action has been dropped

- Controller state querries:

  - Current state is available in a control_msgs::JointTrajectoryControllerState topic.
  - State at any future time can be queried through a control_msgs::JointTrajectoryControllerState service.

Features
- Trajectory segment type
  - Controller is templated on the segment type.
  - Multi-dof quintic spline segment implementation provided by default.

- Hardware interface type
  - Controller is templated on the hardware interface type.
  - Position and effort control joint interfaces provided by default.

- Realtime-safe.

- Proper handling of wrapping (continuous) joints.

- Online trajectory replacement: New commands are smoothly combined with currently executed trajectory.

- Discontinuous system clock changes do not cause discontinuities in the execution of already queued trajectory segments.

- Complete test suite

TODO

- Uer-facing documentation is currently missing. I hope to address this in the coming weeks.

Testing it
- Binary package: ros-hydro-joint-trajectory-controller.

- Source repository: https://github.com/ros-controls/ros_controllers

As always, feedback is welcome.

P.S. CCing moveit-users

Best,

--
Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
adolfo.r...@pal-robotics.com
http://www.pal-robotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4º4ª
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
Skype: adolfo.pal-robotics
Facebook - Twitter - PAL Robotics YouTube Channel

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.-

[Marcus Liebhardt]

On Tue, Sep 10, 2013 at 6:09 PM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

All,

Starting from ros_controllers 0.5.3 (Hydro only), there now exists the joint_trajectory_controller package that implements a controller for executing joint-space trajectories on a group of joints. For those familiar with the PR2 coontrollers, this is ros_control's equivalent of the JointTrajectoryActionController. A brief summary of its main features follows:

ROS API
- Commands:
  - FollowJointTrajectory action
  - trajectory_msgs::JointTrajectory topic
  - Support for the deprecated JointTrajectory action has been dropped

- Controller state querries:

  - Current state is available in a control_msgs::JointTrajectoryControllerState topic.
  - State at any future time can be queried through a control_msgs::JointTrajectoryControllerState service.

What about a lazy publisher for the controller state?

[Adolfo Rodríguez Tsouroukdissian]

On Tue, Sep 10, 2013 at 11:20 AM, Marcus Liebhardt <marcus.l...@yujinrobot.com> wrote:

On Tue, Sep 10, 2013 at 6:09 PM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

All,

Starting from ros_controllers 0.5.3 (Hydro only), there now exists the joint_trajectory_controller package that implements a controller for executing joint-space trajectories on a group of joints. For those familiar with the PR2 coontrollers, this is ros_control's equivalent of the JointTrajectoryActionController. A brief summary of its main features follows:

ROS API
- Commands:
  - FollowJointTrajectory action
  - trajectory_msgs::JointTrajectory topic
  - Support for the deprecated JointTrajectory action has been dropped

- Controller state querries:

  - Current state is available in a control_msgs::JointTrajectoryControllerState topic.
  - State at any future time can be queried through a control_msgs::JointTrajectoryControllerState service.

What about a lazy publisher for the controller state?

Sure, open an issue here please so we keep track of it:

https://github.com/ros-controls/ros_controllers/issues?state=open
 

...or even better a pull request with the feature. This is not yet documented, but you can additionally specify through a parameter the publish frequency of this topic. It defaults to 50Hz.

--