Cascading controllers with ros_control

[Jonathan Bohren]

@Adolfo

In the diagram you originally posted [1], you had controllers cascaded into a pipelines like:

ROS API --(joint traj)--> r_arm_follow_joint_traj --(pos,vel)--> r_arm_pid_controller --(effort)--> ...

Most of the existing PR2 controllers are set up to be a single block that has a ROS interface on one end and an controller effort interface on the other, and so that said block occupies a given joint resource. Have you experimented with breaking things into more general purpose blocks like those in your diagram and still managing their interfaces with the controller manager?

[1]

 joint_controller_manager.pdf

-j

--

Jonathan Bohren

Laboratory for Computational Sensing and Robotics

http://dscl.lcsr.jhu.edu/People/JonathanBohren

[Adolfo Rodríguez Tsouroukdissian]

On Fri, Feb 8, 2013 at 8:43 PM, Jonathan Bohren <jonatha...@gmail.com> wrote:

@Adolfo

In the diagram you originally posted [1], you had controllers cascaded into a pipelines like:

ROS API --(joint traj)--> r_arm_follow_joint_traj --(pos,vel)--> r_arm_pid_controller --(effort)--> ...

Most of the existing PR2 controllers are set up to be a single block that has a ROS interface on one end and an controller effort interface on the other, and so that said block occupies a given joint resource. Have you experimented with breaking things into more general purpose blocks like those in your diagram and still managing their interfaces with the controller manager?

Jonathan,

I have not yet attempted to fit this use case into ros_control's controller manager. To do this right, I think we're missing something to represent computational graphs that can be dynamically modified and executed in a single thread. This goes beyond the scope of the controller_manager. The diagram I proposed tried to stretch component-based design to this purpose, but is not a perfect match either.

For the time being, a compromise would be to make the computation of a controller independent of the controller_manager plugin system, so composing multiple computational modules into a single controller requires only a thin layer of glue code, ie. chaining controllers yourself with (hard)code.

I can't provide a better solution now, as my immediate objective is to try to get a simple pipeline from actuators to controller running, and I'm focusing more on blocker features. Food for future thought.

FYI, at LAAS the is a project called dynamic_graph that seems to implement the computational graph idea. I'll have an intern in a couple of months that will have to use it for the purpose of whole body control, so I might be able to provide some feedback on it.

Adolfo.

[1]

 joint_controller_manager.pdf

-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-robot-contro...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Yamokoski]

I am interested in getting this cascading controllers to work as well. I would agree that the quick fix is to do this outside of the reach of the controller_manager class. But much of the design of the rest of ros_control could be brought to bear.

Has anyone studied VTK's source code? They implemented a computation pipeline architecture that might have some ideas worth borrowing.

http://www.aosabook.org/en/vtk.html (sec 24.2.3)

To unsubscribe from this group and stop receiving emails from it, send an email to ros-robot-control-sig+unsub...@googlegroups.com.

[Adolfo Rodríguez Tsouroukdissian]

On Wed, Mar 13, 2013 at 4:33 PM, John Yamokoski <yamo...@gmail.com> wrote:

I am interested in getting this cascading controllers to work as well. I would agree that the quick fix is to do this outside of the reach of the controller_manager class. But much of the design of the rest of ros_control could be brought to bear.

Has anyone studied VTK's source code? They implemented a computation pipeline architecture that might have some ideas worth borrowing.

http://www.aosabook.org/en/vtk.html (sec 24.2.3)

I finally got to reading the VTK overview. A nice read indeed, thanks for sharing. I have no practical experience with VTK, but I take the developer's word that implementing the computational graph (data flow pipeline in their wording) has been non-trivial, and continues to be an ongoing and challenging effort.

Other efforts that seem related to the idea of a computational graph are:
- Ecto [1], coming from a perception background.
- Dynamic graph [2], coming from a realtime control background.

I (also) have no experience with them, but I'll be getting an intern to work on whole-body control, and the software we'll be using relies heavily on dynamic-graph. I might have something to say on the topic in some months.

[1] http://plasmodic.github.com/ecto/
[2] http://jrl-umi3218.github.com/dynamic-graph/doxygen/HEAD/

Cheers,

Adolfo.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-robot-contro...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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 Mon, Mar 18, 2013 at 7:32 PM, Adolfo Rodríguez Tsouroukdissian <adolfo.r...@pal-robotics.com> wrote:

On Wed, Mar 13, 2013 at 4:33 PM, John Yamokoski <yamo...@gmail.com> wrote:

I am interested in getting this cascading controllers to work as well. I would agree that the quick fix is to do this outside of the reach of the controller_manager class. But much of the design of the rest of ros_control could be brought to bear.

Has anyone studied VTK's source code? They implemented a computation pipeline architecture that might have some ideas worth borrowing.

http://www.aosabook.org/en/vtk.html (sec 24.2.3)

I finally got to reading the VTK overview. A nice read indeed, thanks for sharing. I have no practical experience with VTK, but I take the developer's word that implementing the computational graph (data flow pipeline in their wording) has been non-trivial, and continues to be an ongoing and challenging effort.

Other efforts that seem related to the idea of a computational graph are:
- Ecto [1], coming from a perception background.
- Dynamic graph [2], coming from a realtime control background.

I (also) have no experience with them, but I'll be getting an intern to work on whole-body control, and the software we'll be using relies heavily on dynamic-graph. I might have something to say on the topic in some months.

[1] http://plasmodic.github.com/ecto/
[2] http://jrl-umi3218.github.com/dynamic-graph/doxygen/HEAD/

+1 to taking a closer look into those framework and tools.

However, I suggest we implement a first version of the controller manager with known and already in-use techniques and tools, e.g. nodelets, to get the implementation & testing started quickly. Otherwise I fear this whole endeavour might get lost in technical discussions and motivation and support vanishes.

Marcus

[John Yamokoski]

I haven't checked in on Ecto (and frankly had simply forgotten about it) in a while. It certainly has matured. I hadn't seen dynamic-graph before. Neat. Any reasons why you are favoring dynamic-graph over ecto? More familiarity? Features? Just curious. We've already got a lot invested in Python and ROS for rapid application development. At first glance, it appears that ecto would fit the rest of our ecosystem better because of that. 

Marcus, I agree about getting something down quickly - and I partially agree that you could extend some of the existing patterns in ros_control to get cascading controllers. But I like the idea of leaving hardware resource allocation to ros_control and then another system to present ros_control with DAG's that represent a 'controller'. In my opinion, this leaves the scope of the libraries well defined.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-robot-control-sig+unsubscri...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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-robot-control-sig+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Adolfo Rodríguez Tsouroukdissian]

On Tue, Mar 19, 2013 at 3:09 AM, John Yamokoski <yamo...@gmail.com> wrote:

I haven't checked in on Ecto (and frankly had simply forgotten about it) in a while. It certainly has matured. I hadn't seen dynamic-graph before. Neat. Any reasons why you are favoring dynamic-graph over ecto? More familiarity? Features? Just curious. We've already got a lot invested in Python and ROS for rapid application development. At first glance, it appears that ecto would fit the rest of our ecosystem better because of that. 

I don't favor any one candidate, at least for now, as I have zero practical experience with them. It's just that the specific whole-body control implementation we'll be test-driving (LAAS' stack of tasks, or SoT) is tightly integrated with dynamic-graph, so the situation lends itself for us to give it a try. I'd also like to have the opportunity to do some hands-on development with some other implementation to compare.

@Marcus. The focus of this thread has shifted more towards exploring possible alternatives for future development. The core of ros_control is pretty usable as it currently stands. At this moment, ros_controllers is probably what should start getting some more love. I'll be getting back on this in some weeks.

Adolfo

To unsubscribe from this group and stop receiving emails from it, send an email to ros-robot-contro...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.