Joint controller manager

Hello ROS and Orocos users,

This is a call for feedback. I'm currently working on a "joint controller
manager", that is, a component that manages joint resources and exposes
them to control. For those familiar with the pr2_controller_manager, this
would provide similar functionality and interfaces, while relaxing some
constraints to allow easy porting to different hardware platforms. Exposing
hardware to control (and realtime control in particular) is still a big
hurdle, and it would be very desirable to make this at least an order of
magnitude easier. Once a minimal set of controller interfaces are made
available for a given platform (eg. mobile base controller, spline
interpolator, ...), a truckload of higher-level functionality becomes
available.

At the moment I have an existing in-house solution that from a ROS API
point of view looks pretty much like a pr2_controller_manager, and a design
of where I'd like things to go, which is attached to this message in pdf
form. As a next step I was planning on setting up a public repo and port
the existing design from Orocos 1.x to Orocos 2.x, which adds the
expressivity needed to address the missing features. But before that, I'd
like to make a pause and ask for some feedback.

- Is there interest in giving this topic a dedicated discussion place, like
a mailing list or a ROS special interest group?.

- If you take a look at the attached design, please be critic about it.
What would you add or remove?, what would you do differently?.

- What can you not accomplish (or have had trouble accomplishing) with the
tools you or your team have used so far?.

Finally, I'd like to be aware of any active and similarly scoped
initiative, so please let me know if you're working on the subject. Late
last week I found out almost by chance about the yet undocumented
ros_control [1] repository, which deferred the writing of this email a day
so I could familiarize with it. Its scope is very much aligned with my
current objectives, as it consists of a library offering functionality
similar to that of the pr2_controller_manager that can be adapted to other
robot platforms. I'm looking forward to sharing opinions and use cases with
all interested parties, and if possible map interest overlaps to common
code. Some questions that come to my mind after reviewing the code in [1]:

- Is it possible to have a controller with multiple interfaces (eg. send
position + velocity + effort commands)?.

- If I understand correctly, interfaces are limited by design to position,
velocity and effort, and adding a new one (fancy example: stiffness) is not
possible, correct?.

- Is it possible to chain controllers as in the attached figure
(r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
ie. without writing code?.

- Controllers running at lower frequency than the manager need to implement
this by doing work only one out of every n cycles, as separate controller
threads are not supported, correct?.

- Is there any work on decoupling the more common "workhorse" controllers
out of the pr2_controller_manager infrastructure (eg. a couple of mobile
base implementations, the FollowJointTrtajectory action)?. I've already
spent some time factoring out the spline splicing and interpolation code
from the FollowJointTrtajectory action, and was planning on writing some
unit tests on it. If not, I can also make this available once the cleanup
is complete.

That's it for now, thanks for reading.

[1] https://github.com/willowgarage/ros_control

AttachmentSize
joint_controller_manager.pdf27.38 KB

[ros-users] Joint controller manager

Hello everyone!

On Tue, Jan 29, 2013 at 12:04 AM, Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...> wrote:

> Hello ROS and Orocos users,
>
> This is a call for feedback. I'm currently working on a "joint controller
> manager", that is, a component that manages joint resources and exposes
> them to control. For those familiar with the pr2_controller_manager, this
> would provide similar functionality and interfaces, while relaxing some
> constraints to allow easy porting to different hardware platforms. Exposing
> hardware to control (and realtime control in particular) is still a big
> hurdle, and it would be very desirable to make this at least an order of
> magnitude easier. Once a minimal set of controller interfaces are made
> available for a given platform (eg. mobile base controller, spline
> interpolator, ...), a truckload of higher-level functionality becomes
> available.
>

First of all, I like to thank you, Adolfo, for getting this started! I also
see great potential in joining forces in this matter, since many robots
need or would benefit from it.

> At the moment I have an existing in-house solution that from a ROS API
> point of view looks pretty much like a pr2_controller_manager, and a design
> of where I'd like things to go, which is attached to this message in pdf
> form. As a next step I was planning on setting up a public repo and port
> the existing design from Orocos 1.x to Orocos 2.x, which adds the
> expressivity needed to address the missing features. But before that, I'd
> like to make a pause and ask for some feedback.
>
> - Is there interest in giving this topic a dedicated discussion place,
> like a mailing list or a ROS special interest group?.
>
> - If you take a look at the attached design, please be critic about it.
> What would you add or remove?, what would you do differently?.
>

Really pretty, I put it up on my wall. No wonder you are in a hurry now! ;-)

> - What can you not accomplish (or have had trouble accomplishing) with the
> tools you or your team have used so far?.
>
> Finally, I'd like to be aware of any active and similarly scoped
> initiative, so please let me know if you're working on the subject. Late
> last week I found out almost by chance about the yet undocumented
> ros_control [1] repository, which deferred the writing of this email a day
> so I could familiarize with it. Its scope is very much aligned with my
> current objectives, as it consists of a library offering functionality
> similar to that of the pr2_controller_manager that can be adapted to other
> robot platforms. I'm looking forward to sharing opinions and use cases with
> all interested parties, and if possible map interest overlaps to common
> code. Some questions that come to my mind after reviewing the code in [1]:
>
> - Is it possible to have a controller with multiple interfaces (eg. send
> position + velocity + effort commands)?.
>
> - If I understand correctly, interfaces are limited by design to position,
> velocity and effort, and adding a new one (fancy example: stiffness) is not
> possible, correct?.
>
> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
> ie. without writing code?.
>
> - Controllers running at lower frequency than the manager need to
> implement this by doing work only one out of every n cycles, as separate
> controller threads are not supported, correct?.
>
> - Is there any work on decoupling the more common "workhorse" controllers
> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> base implementations, the FollowJointTrtajectory action)?. I've already
> spent some time factoring out the spline splicing and interpolation code
> from the FollowJointTrtajectory action, and was planning on writing some
> unit tests on it. If not, I can also make this available once the cleanup
> is complete.
>

> That's it for now, thanks for reading.
>

> [1] https://github.com/willowgarage/ros_control

One topic I would like to add to the discussed:
Adolfo's diagram shows a transmission part for mapping from joint to
actuator space. We are currently working with a custom solution, which is
similar to the pr2_mechanism_model [1].
We implemented direct (1-to-1 mapping), revolute (angle wrapping),
prismatic and (active/passive) coupled transmissions.
It would be nice, if we can integrate something similar in the controller
or allow loading plugins which do that job.

Regards,
Marcus

PS: Since this design discussion will likely address multiple topics, I
wonder, if it wouldn't be a better idea to move this discussion to the SIG
and split it up in various topic-related threads. We could still leave the
orocos-dev list attached or even subscribe it to the SIG, if preferred.

[1] http://ros.org/wiki/pr2_mechanism_model

>
>
> --
> Adolfo Rodríguez Tsouroukdissian
> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> 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 <http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics>- PAL
> Robotics YouTube Channel <http://www.youtube.com/user/PALRobotics>
>
> 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.
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>

[ros-users] Joint controller manager

Replying to the SIG and Orocos-dev.

On Tue, Feb 5, 2013 at 7:01 AM, Marcus Liebhardt <
marcus [dot] liebhardt [..] ...> wrote:

> Hello everyone!
>
> On Tue, Jan 29, 2013 at 12:04 AM, Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...> wrote:
>
>> Hello ROS and Orocos users,
>>
>> This is a call for feedback. I'm currently working on a "joint controller
>> manager", that is, a component that manages joint resources and exposes
>> them to control. For those familiar with the pr2_controller_manager, this
>> would provide similar functionality and interfaces, while relaxing some
>> constraints to allow easy porting to different hardware platforms. Exposing
>> hardware to control (and realtime control in particular) is still a big
>> hurdle, and it would be very desirable to make this at least an order of
>> magnitude easier. Once a minimal set of controller interfaces are made
>> available for a given platform (eg. mobile base controller, spline
>> interpolator, ...), a truckload of higher-level functionality becomes
>> available.
>>
>
> First of all, I like to thank you, Adolfo, for getting this started! I
> also see great potential in joining forces in this matter, since many
> robots need or would benefit from it.
>
>
>> At the moment I have an existing in-house solution that from a ROS API
>> point of view looks pretty much like a pr2_controller_manager, and a design
>> of where I'd like things to go, which is attached to this message in pdf
>> form. As a next step I was planning on setting up a public repo and port
>> the existing design from Orocos 1.x to Orocos 2.x, which adds the
>> expressivity needed to address the missing features. But before that, I'd
>> like to make a pause and ask for some feedback.
>>
>> - Is there interest in giving this topic a dedicated discussion place,
>> like a mailing list or a ROS special interest group?.
>>
>> - If you take a look at the attached design, please be critic about it.
>> What would you add or remove?, what would you do differently?.
>>
>
> Really pretty, I put it up on my wall. No wonder you are in a hurry now!
> ;-)
>

Don't get too attached to it, though. As the discussion has shown, there
won't be all that data flow interfaces. I'm starting to use HiDOF's
implementation, which shares the same concepts to a large extent (good!).

>
>
>> - What can you not accomplish (or have had trouble accomplishing) with
>> the tools you or your team have used so far?.
>>
>> Finally, I'd like to be aware of any active and similarly scoped
>> initiative, so please let me know if you're working on the subject. Late
>> last week I found out almost by chance about the yet undocumented
>> ros_control [1] repository, which deferred the writing of this email a day
>> so I could familiarize with it. Its scope is very much aligned with my
>> current objectives, as it consists of a library offering functionality
>> similar to that of the pr2_controller_manager that can be adapted to other
>> robot platforms. I'm looking forward to sharing opinions and use cases with
>> all interested parties, and if possible map interest overlaps to common
>> code. Some questions that come to my mind after reviewing the code in [1]:
>>
>> - Is it possible to have a controller with multiple interfaces (eg. send
>> position + velocity + effort commands)?.
>>
>> - If I understand correctly, interfaces are limited by design to
>> position, velocity and effort, and adding a new one (fancy example:
>> stiffness) is not possible, correct?.
>>
>> - Is it possible to chain controllers as in the attached figure
>> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
>> ie. without writing code?.
>>
>> - Controllers running at lower frequency than the manager need to
>> implement this by doing work only one out of every n cycles, as separate
>> controller threads are not supported, correct?.
>>
>> - Is there any work on decoupling the more common "workhorse" controllers
>> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
>> base implementations, the FollowJointTrtajectory action)?. I've already
>> spent some time factoring out the spline splicing and interpolation code
>> from the FollowJointTrtajectory action, and was planning on writing some
>> unit tests on it. If not, I can also make this available once the cleanup
>> is complete.
>>
>
>> That's it for now, thanks for reading.
>>
>
>> [1] https://github.com/willowgarage/ros_control
>
>
> One topic I would like to add to the discussed:
> Adolfo's diagram shows a transmission part for mapping from joint to
> actuator space. We are currently working with a custom solution, which is
> similar to the pr2_mechanism_model [1].
> We implemented direct (1-to-1 mapping), revolute (angle wrapping),
> prismatic and (active/passive) coupled transmissions.
> It would be nice, if we can integrate something similar in the controller
> or allow loading plugins which do that job.
>

I haven't brought transmissions up for discussion because ideas are still
settling in my mind. I've been in fact working on that for the past couple
of days. I'll open a separate thread to discuss transmissions shortly.

>
> Regards,
> Marcus
>
> PS: Since this design discussion will likely address multiple topics, I
> wonder, if it wouldn't be a better idea to move this discussion to the SIG
> and split it up in various topic-related threads. We could still leave the
> orocos-dev list attached or even subscribe it to the SIG, if preferred.
>

So far the ros-robot-control-sig group is low-traffic, and with a limited
scope. I'd rather not dilute it more. Also consider that many of the topics
discussed here are also on orocos-dev. My 2 cents.

[1] http://ros.org/wiki/pr2_mechanism_model

>
>>
>> --
>> Adolfo Rodríguez Tsouroukdissian
>> Senior robotics engineer
>> adolfo [dot] rodriguez [..] ...
>> 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 <http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics>- PAL
>> Robotics YouTube Channel <http://www.youtube.com/user/PALRobotics>
>>
>> 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.
>> _______________________________________________
>> ros-users mailing list
>> ros-users [..] ...
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
>
> --
> 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 [dot] liebhardt [..] ...
> Phone: +82-70-46577073
>
> --
> 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+unsubscribe [..] ....
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

[ros-users] Joint controller manager

Hey Adolfo,

Thanks for this email. It brought out a good set of ideas on what we want
from a controller framework. I will try and address your points with
regards to [1] - the PR2 independent controller infrastructure that we have
been developing.

The main goal of this work is to develop a robot-agnostic version of the
PR2 controller infrastructure. In addition, we aim to develop a few
(limited set of) controllers (based on the current set of controllers we
have for the PR2) and release them as an open-source robot agnostic
library. The controller manager and the controllers are intended to be
usable with multiple realtime operating systems. A further part of this
project is to take some of the workhorse capabilities performed by some of
the controllers, e.g. the FollowJointTrajectory action and break them up
into more sensible libraries (in addition to an actual controller
implementation) that can be used across robots.

To answer some of your more direction questions:
- Is it possible to have a controller with multiple interfaces (eg. send
position + velocity + effort commands)?.
yes, you will have to implement an interface that incorporates all these
commands.
- If I understand correctly, interfaces are limited by design to position,
velocity and effort, and adding a new one (fancy example: stiffness) is not
possible, correct?.
Not true, you can implement other types of interfaces as well.
- Is it possible to chain controllers as in the attached figure
(r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
ie. without writing code?.
The follow joint trajectory controller will probably reuse the PID
controllers (if that's what you are asking), but directly in code. I think
I understand what you are referring to - we could design individual
controllers to be more flexible so they can do something like this but its
not something we have put much thought into yet.
- Controllers running at lower frequency than the manager need to implement
this by doing work only one out of every n cycles, as separate controller
threads are not supported, correct?.
The intention of this work is to provide a simple single-threaded
infrastructure. We are probably going to stay away from anything more (e.g.
multi-threading, etc.) mainly because there's other tools out there that
will provide some of those capabilities for you.
- Is there any work on decoupling the more common "workhorse" controllers
out of the pr2_controller_manager infrastructure (eg. a couple of mobile
base implementations, the FollowJointTrtajectory action)?. I've already
spent some time factoring out the spline splicing and interpolation code
from the FollowJointTrtajectory action, and was planning on writing some
unit tests on it. If not, I can also make this available once the cleanup
is complete.
Yes. We probably won't do the mobile base though.

This is a joint project with a spin-off from Willow Garage: HiDOF Inc. (
hidof.com). As the project matures, more documentation will be added to
make some of these things clearer.

Best Regards,
Sachin

On Mon, Jan 28, 2013 at 7:04 AM, Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...> wrote:

> Hello ROS and Orocos users,
>
> This is a call for feedback. I'm currently working on a "joint controller
> manager", that is, a component that manages joint resources and exposes
> them to control. For those familiar with the pr2_controller_manager, this
> would provide similar functionality and interfaces, while relaxing some
> constraints to allow easy porting to different hardware platforms. Exposing
> hardware to control (and realtime control in particular) is still a big
> hurdle, and it would be very desirable to make this at least an order of
> magnitude easier. Once a minimal set of controller interfaces are made
> available for a given platform (eg. mobile base controller, spline
> interpolator, ...), a truckload of higher-level functionality becomes
> available.
>
> At the moment I have an existing in-house solution that from a ROS API
> point of view looks pretty much like a pr2_controller_manager, and a design
> of where I'd like things to go, which is attached to this message in pdf
> form. As a next step I was planning on setting up a public repo and port
> the existing design from Orocos 1.x to Orocos 2.x, which adds the
> expressivity needed to address the missing features. But before that, I'd
> like to make a pause and ask for some feedback.
>
> - Is there interest in giving this topic a dedicated discussion place,
> like a mailing list or a ROS special interest group?.
>
> - If you take a look at the attached design, please be critic about it.
> What would you add or remove?, what would you do differently?.
>
> - What can you not accomplish (or have had trouble accomplishing) with the
> tools you or your team have used so far?.
>
> Finally, I'd like to be aware of any active and similarly scoped
> initiative, so please let me know if you're working on the subject. Late
> last week I found out almost by chance about the yet undocumented
> ros_control [1] repository, which deferred the writing of this email a day
> so I could familiarize with it. Its scope is very much aligned with my
> current objectives, as it consists of a library offering functionality
> similar to that of the pr2_controller_manager that can be adapted to other
> robot platforms. I'm looking forward to sharing opinions and use cases with
> all interested parties, and if possible map interest overlaps to common
> code. Some questions that come to my mind after reviewing the code in [1]:
>
> - Is it possible to have a controller with multiple interfaces (eg. send
> position + velocity + effort commands)?.
>
> - If I understand correctly, interfaces are limited by design to position,
> velocity and effort, and adding a new one (fancy example: stiffness) is not
> possible, correct?.
>
> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
> ie. without writing code?.
>
> - Controllers running at lower frequency than the manager need to
> implement this by doing work only one out of every n cycles, as separate
> controller threads are not supported, correct?.
>
> - Is there any work on decoupling the more common "workhorse" controllers
> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> base implementations, the FollowJointTrtajectory action)?. I've already
> spent some time factoring out the spline splicing and interpolation code
> from the FollowJointTrtajectory action, and was planning on writing some
> unit tests on it. If not, I can also make this available once the cleanup
> is complete.
>
> That's it for now, thanks for reading.
>
> [1] https://github.com/willowgarage/ros_control
>
> --
> Adolfo Rodríguez Tsouroukdissian
> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> 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 <http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics>- PAL
> Robotics YouTube Channel <http://www.youtube.com/user/PALRobotics>
>
> 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.
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>

[ros-users] Joint controller manager

Hello everyone!

On Tue, Jan 29, 2013 at 12:04 AM, Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...> wrote:

> Hello ROS and Orocos users,
>
> This is a call for feedback. I'm currently working on a "joint controller
> manager", that is, a component that manages joint resources and exposes
> them to control. For those familiar with the pr2_controller_manager, this
> would provide similar functionality and interfaces, while relaxing some
> constraints to allow easy porting to different hardware platforms. Exposing
> hardware to control (and realtime control in particular) is still a big
> hurdle, and it would be very desirable to make this at least an order of
> magnitude easier. Once a minimal set of controller interfaces are made
> available for a given platform (eg. mobile base controller, spline
> interpolator, ...), a truckload of higher-level functionality becomes
> available.
>

First of all, I like to thank you, Adolfo, for getting this started! I also
see great potential in joining forces in this matter, since many robots
need or would benefit from it.

> At the moment I have an existing in-house solution that from a ROS API
> point of view looks pretty much like a pr2_controller_manager, and a design
> of where I'd like things to go, which is attached to this message in pdf
> form. As a next step I was planning on setting up a public repo and port
> the existing design from Orocos 1.x to Orocos 2.x, which adds the
> expressivity needed to address the missing features. But before that, I'd
> like to make a pause and ask for some feedback.
>
> - Is there interest in giving this topic a dedicated discussion place,
> like a mailing list or a ROS special interest group?.
>
> - If you take a look at the attached design, please be critic about it.
> What would you add or remove?, what would you do differently?.
>

Really pretty, I put it up on my wall. No wonder you are in a hurry now! ;-)

> - What can you not accomplish (or have had trouble accomplishing) with the
> tools you or your team have used so far?.
>
> Finally, I'd like to be aware of any active and similarly scoped
> initiative, so please let me know if you're working on the subject. Late
> last week I found out almost by chance about the yet undocumented
> ros_control [1] repository, which deferred the writing of this email a day
> so I could familiarize with it. Its scope is very much aligned with my
> current objectives, as it consists of a library offering functionality
> similar to that of the pr2_controller_manager that can be adapted to other
> robot platforms. I'm looking forward to sharing opinions and use cases with
> all interested parties, and if possible map interest overlaps to common
> code. Some questions that come to my mind after reviewing the code in [1]:
>
> - Is it possible to have a controller with multiple interfaces (eg. send
> position + velocity + effort commands)?.
>
> - If I understand correctly, interfaces are limited by design to position,
> velocity and effort, and adding a new one (fancy example: stiffness) is not
> possible, correct?.
>
> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
> ie. without writing code?.
>
> - Controllers running at lower frequency than the manager need to
> implement this by doing work only one out of every n cycles, as separate
> controller threads are not supported, correct?.
>
> - Is there any work on decoupling the more common "workhorse" controllers
> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> base implementations, the FollowJointTrtajectory action)?. I've already
> spent some time factoring out the spline splicing and interpolation code
> from the FollowJointTrtajectory action, and was planning on writing some
> unit tests on it. If not, I can also make this available once the cleanup
> is complete.
>

> That's it for now, thanks for reading.
>

> [1] https://github.com/willowgarage/ros_control

One topic I would like to add to the discussed:
Adolfo's diagram shows a transmission part for mapping from joint to
actuator space. We are currently working with a custom solution, which is
similar to the pr2_mechanism_model [1].
We implemented direct (1-to-1 mapping), revolute (angle wrapping),
prismatic and (active/passive) coupled transmissions.
It would be nice, if we can integrate something similar in the controller
or allow loading plugins which do that job.

Regards,
Marcus

PS: Since this design discussion will likely address multiple topics, I
wonder, if it wouldn't be a better idea to move this discussion to the SIG
and split it up in various topic-related threads. We could still leave the
orocos-dev list attached or even subscribe it to the SIG, if preferred.

PPS: Sorry for replying to the wrong OROCOS list the first time.

[1] http://ros.org/wiki/pr2_mechanism_model

>
>
> --
> Adolfo Rodríguez Tsouroukdissian
> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> 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 <http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics>- PAL
> Robotics YouTube Channel <http://www.youtube.com/user/PALRobotics>
>
> 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.
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>

[ros-users] Joint controller manager

Adolfo,

When I originally read your email, I thought it was coming out of Willow. There are some aspects of the new arm path planning library (MoveIt) that point to a revamped controller manager. Unfortunately, I don't know any more than you do.

As far as your architecture, I notices that you are utilizing the ROS action interface. Is there any way to allow for a streaming interface. I'm thinking of a visual servo application, where you need to close the loop and adjust an actuator position based on some higher level information. The action interface does not allow for this.

Shaun Edwards
Senior Research Engineer
Manufacturing System Department

http://robotics.swri.org
http://rosindustrial.swri.org/
http://ros.swri.org<http://ros.swri.org/>
Join the ROS-Industrial Developers List<https://groups.google.com/group/swri-ros-pkg-dev/boxsubscribe>
Southwest Research Institute
210-522-3277

From: ros-users-bounces [..] ... [mailto:ros-users-bounces [..] ...] On Behalf Of Adolfo Rodríguez Tsouroukdissian
Sent: Monday, January 28, 2013 9:04 AM
To: orocos-users; ros-users
Subject: [ros-users] Joint controller manager

Hello ROS and Orocos users,

This is a call for feedback. I'm currently working on a "joint controller manager", that is, a component that manages joint resources and exposes them to control. For those familiar with the pr2_controller_manager, this would provide similar functionality and interfaces, while relaxing some constraints to allow easy porting to different hardware platforms. Exposing hardware to control (and realtime control in particular) is still a big hurdle, and it would be very desirable to make this at least an order of magnitude easier. Once a minimal set of controller interfaces are made available for a given platform (eg. mobile base controller, spline interpolator, ...), a truckload of higher-level functionality becomes available.

At the moment I have an existing in-house solution that from a ROS API point of view looks pretty much like a pr2_controller_manager, and a design of where I'd like things to go, which is attached to this message in pdf form. As a next step I was planning on setting up a public repo and port the existing design from Orocos 1.x to Orocos 2.x, which adds the expressivity needed to address the missing features. But before that, I'd like to make a pause and ask for some feedback.

- Is there interest in giving this topic a dedicated discussion place, like a mailing list or a ROS special interest group?.

- If you take a look at the attached design, please be critic about it. What would you add or remove?, what would you do differently?.

- What can you not accomplish (or have had trouble accomplishing) with the tools you or your team have used so far?.

Finally, I'd like to be aware of any active and similarly scoped initiative, so please let me know if you're working on the subject. Late last week I found out almost by chance about the yet undocumented ros_control [1] repository, which deferred the writing of this email a day so I could familiarize with it. Its scope is very much aligned with my current objectives, as it consists of a library offering functionality similar to that of the pr2_controller_manager that can be adapted to other robot platforms. I'm looking forward to sharing opinions and use cases with all interested parties, and if possible map interest overlaps to common code. Some questions that come to my mind after reviewing the code in [1]:

- Is it possible to have a controller with multiple interfaces (eg. send position + velocity + effort commands)?.

- If I understand correctly, interfaces are limited by design to position, velocity and effort, and adding a new one (fancy example: stiffness) is not possible, correct?.

- Is it possible to chain controllers as in the attached figure (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files, ie. without writing code?.

- Controllers running at lower frequency than the manager need to implement this by doing work only one out of every n cycles, as separate controller threads are not supported, correct?.

- Is there any work on decoupling the more common "workhorse" controllers out of the pr2_controller_manager infrastructure (eg. a couple of mobile base implementations, the FollowJointTrtajectory action)?. I've already spent some time factoring out the spline splicing and interpolation code from the FollowJointTrtajectory action, and was planning on writing some unit tests on it. If not, I can also make this available once the cleanup is complete.

That's it for now, thanks for reading.

[1] https://github.com/willowgarage/ros_control

--
Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
adolfo [dot] rodriguez [..] ...<mailto:adolfo [dot] rodriguez [..] ...>
http://www.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<http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics> - PAL Robotics YouTube Channel<http://www.youtube.com/user/PALRobotics>

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.

[ros-users] Joint controller manager

On Mon, Jan 28, 2013 at 11:28 PM, Sachin Chitta <sachinc [..] ...>wrote:

> Hey Adolfo,
>
> Hey Sachin,

> Thanks for this email. It brought out a good set of ideas on what we want
> from a controller framework. I will try and address your points with
> regards to [1] - the PR2 independent controller infrastructure that we have
> been developing.
>
> The main goal of this work is to develop a robot-agnostic version of the
> PR2 controller infrastructure. In addition, we aim to develop a few
> (limited set of) controllers (based on the current set of controllers we
> have for the PR2) and release them as an open-source robot agnostic library.

We seem to be pretty much on the same page.

> The controller manager and the controllers are intended to be usable with
> multiple realtime operating systems.

This statement makes me very happy, more below...

> A further part of this project is to take some of the workhorse
> capabilities performed by some of the controllers, e.g. the
> FollowJointTrajectory action and break them up into more sensible libraries
> (in addition to an actual controller implementation) that can be used
> across robots.
>

Yes!, about a year ago I spent many hours porting the FollowJointTrajectory
controller to our infrastructure. One pain point was comparing timestamps
generated in hard-rt and non-rt contexts [2]. Another one was separating
trajectory processing from PID control, as mentioned in an earlier post.
The downside of this effort was that I ended up with a separate codebase to
maintain, whose improvements cannot be readily merged upstream. The upside
was that I learned quite a bit by going down there :).

[2]
http://www.orocos.org/forum/orocos/orocos-users/comparing-timestamps-gen...

> To answer some of your more direction questions:
>
> - Is it possible to have a controller with multiple interfaces (eg. send
> position + velocity + effort commands)?.
> yes, you will have to implement an interface that incorporates all these
> commands.

> - If I understand correctly, interfaces are limited by design to position,
> velocity and effort, and adding a new one (fancy example: stiffness) is not
> possible, correct?.
> Not true, you can implement other types of interfaces as well.

Thanks for clarifying the two above points, this is great news!, so no
blockers here.

>
> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
> ie. without writing code?.
> The follow joint trajectory controller will probably reuse the PID
> controllers (if that's what you are asking), but directly in code. I think
> I understand what you are referring to - we could design individual
> controllers to be more flexible so they can do something like this but its
> not something we have put much thought into yet.

I'm very interested in having a FollowJointTrajectory controller that does
not output an effort command. Chaining controllers without writing code is
important for many use cases. A very simple one is a position-controlled
robot, whose hardware interface directly accepts position commands, but
whose simulated interface (because of simulator constraints) only accepts
effort commands.

>
> - Controllers running at lower frequency than the manager need to
> implement this by doing work only one out of every n cycles, as separate
> controller threads are not supported, correct?.
> The intention of this work is to provide a simple single-threaded
> infrastructure. We are probably going to stay away from anything more (e.g.
> multi-threading, etc.) mainly because there's other tools out there that
> will provide some of those capabilities for you.

If controllers can be triggered by timers that can be individually
configured, as Herman suggests in a previous post, your solution works just
fine. The other benefit of having stuff in separate threads is protection
against mode switches and overruns, but proper monitoring and supervision
allowing to be aware that these things are happening also works for me.
Food for a second iteration.

>
> - Is there any work on decoupling the more common "workhorse" controllers
> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> base implementations, the FollowJointTrtajectory action)?. I've already
> spent some time factoring out the spline splicing and interpolation code
> from the FollowJointTrtajectory action, and was planning on writing some
> unit tests on it. If not, I can also make this available once the cleanup
> is complete.
> Yes. We probably won't do the mobile base though.
>

> This is a joint project with a spin-off from Willow Garage: HiDOF Inc. (
> hidof.com). As the project matures, more documentation will be added to
> make some of these things clearer.
>

The copyright statements and commit logs indeed reflect that :)

Thanks for the very valuable feedback.

Adolfo.

[ros-users] Joint controller manager

On Mon, Jan 28, 2013 at 11:28 PM, Sachin Chitta <sachinc [..] ...>wrote:

> Hey Adolfo,
>
> Hey Sachin,

> Thanks for this email. It brought out a good set of ideas on what we want
> from a controller framework. I will try and address your points with
> regards to [1] - the PR2 independent controller infrastructure that we have
> been developing.
>
> The main goal of this work is to develop a robot-agnostic version of the
> PR2 controller infrastructure. In addition, we aim to develop a few
> (limited set of) controllers (based on the current set of controllers we
> have for the PR2) and release them as an open-source robot agnostic library.

We seem to be pretty much on the same page.

> The controller manager and the controllers are intended to be usable with
> multiple realtime operating systems.

This statement makes me very happy, more below...

> A further part of this project is to take some of the workhorse
> capabilities performed by some of the controllers, e.g. the
> FollowJointTrajectory action and break them up into more sensible libraries
> (in addition to an actual controller implementation) that can be used
> across robots.
>

Yes!, about a year ago I spent many hours porting the FollowJointTrajectory
controller to our infrastructure. One pain point was comparing timestamps
generated in hard-rt and non-rt contexts [2]. Another one was separating
trajectory processing from PID control, as mentioned in an earlier post.
The downside of this effort was that I ended up with a separate codebase to
maintain, whose improvements cannot be readily merged upstream. The upside
was that I learned quite a bit by going down there :).

[2]
http://www.orocos.org/forum/orocos/orocos-users/comparing-timestamps-gen...

> To answer some of your more direction questions:
>
> - Is it possible to have a controller with multiple interfaces (eg. send
> position + velocity + effort commands)?.
> yes, you will have to implement an interface that incorporates all these
> commands.

> - If I understand correctly, interfaces are limited by design to position,
> velocity and effort, and adding a new one (fancy example: stiffness) is not
> possible, correct?.
> Not true, you can implement other types of interfaces as well.

Thanks for clarifying the two above points, this is great news!, so no
blockers here.

>
> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
> ie. without writing code?.
> The follow joint trajectory controller will probably reuse the PID
> controllers (if that's what you are asking), but directly in code. I think
> I understand what you are referring to - we could design individual
> controllers to be more flexible so they can do something like this but its
> not something we have put much thought into yet.

I'm very interested in having a FollowJointTrajectory controller that does
not output an effort command. Chaining controllers without writing code is
important for many use cases. A very simple one is a position-controlled
robot, whose hardware interface directly accepts position commands, but
whose simulated interface (because of simulator constraints) only accepts
effort commands.

>
> - Controllers running at lower frequency than the manager need to
> implement this by doing work only one out of every n cycles, as separate
> controller threads are not supported, correct?.
> The intention of this work is to provide a simple single-threaded
> infrastructure. We are probably going to stay away from anything more (e.g.
> multi-threading, etc.) mainly because there's other tools out there that
> will provide some of those capabilities for you.

If controllers can be triggered by timers that can be individually
configured, as Herman suggests in a previous post, your solution works just
fine. The other benefit of having stuff in separate threads is protection
against mode switches and overruns, but proper monitoring and supervision
allowing to be aware that these things are happening also works for me.
Food for a second iteration.

>
> - Is there any work on decoupling the more common "workhorse" controllers
> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> base implementations, the FollowJointTrtajectory action)?. I've already
> spent some time factoring out the spline splicing and interpolation code
> from the FollowJointTrtajectory action, and was planning on writing some
> unit tests on it. If not, I can also make this available once the cleanup
> is complete.
> Yes. We probably won't do the mobile base though.
>

> This is a joint project with a spin-off from Willow Garage: HiDOF Inc. (
> hidof.com). As the project matures, more documentation will be added to
> make some of these things clearer.
>

The copyright statements and commit logs indeed reflect that :)

Thanks for the very valuable feedback.

Adolfo.

[ros-users] Joint controller manager

Sachin

Regarding the joint trajectory action work below. I have been working on a similar effort, although much simpler. Can you point me to your code? If it works for ros industrial I can probably offer up some time to write your unit tests.

- Is there any work on decoupling the more common "workhorse" controllers out of the pr2_controller_manager infrastructure (eg. a couple of mobile base implementations, the FollowJointTrtajectory action)?. I've already spent some time factoring out the spline splicing and interpolation code from the FollowJointTrtajectory action, and was planning on writing some unit tests on it. If not, I can also make this available once the cleanup is complete.

[ros-users] Joint controller manager

+100

On 01/28/2013 09:04 AM, Adolfo Rodríguez Tsouroukdissian wrote:
- What can you not accomplish (or have had trouble accomplishing) with the tools you or your team have used so far?.

I think we have all created something really similar to your diagram. In fact, I am staring at some code I threw together to map between the indices of vanilla Eigen vectors and names in JointState messages. It was an implementation of the mapping that I _think_ you are planning in your joint_controller_manager, albeit a much simpler version. A concern: Mapping, to me, implies overhead of things like hash tables in order to get data from client interfaces to their proper placement in a full robot description vector. Using callbacks available on event ports and some functors, the conversion could be "registered" at initialization of the client interface --- this might avoid explicit 'lookups'. What were your ideas on this?

- Is it possible to have a controller with multiple interfaces (eg. send position + velocity + effort commands)?.
I'm not addressing ros controller but really this proposal. As a first cut, limiting to one type per controller instantiation might not be a terrible restriction. One of the software constructs I am really impressed by is OMPL's space descriptions ( http://ompl.kavrakilab.org/spaces.html). I'm not saying you'd need to go to this level, but asking a controller to declare its range space with some detail would make integration easier. In the future, it might ease support for controllers that output in something else other than joint space. Things like "sensor_msgs::JointState" is rather ambiguous as to what its controlling without having to introspect the data in the message or see how its being written to in the source's code.

In general, I think this is a great start for a proposal. We are looking at doing something very similar and I would love to see if there is some point of collaboration. But we are under a similar time crunch.. ~6 wks to implementation would be _very_ desirable.

[ros-users] Joint controller manager

On Mon, Jan 28, 2013 at 7:23 PM, YAMOKOSKI, JOHN D. (JSC-ER)[OCEANEERING
SPACE SYSTEMS] <john [dot] d [dot] yamokoski [..] ...> wrote:

> +100
>
>
> On 01/28/2013 09:04 AM, Adolfo Rodríguez Tsouroukdissian wrote:
>
> - What can you not accomplish (or have had trouble accomplishing) with the
> tools you or your team have used so far?.
>
> I think we have all created something really similar to your diagram. In
> fact, I am staring at some code I threw together to map between the indices
> of vanilla Eigen vectors and names in JointState messages. It was an
> implementation of the mapping that I _think_ you are planning in your
> joint_controller_manager, albeit a much simpler version.
>
>
A concern: Mapping, to me, implies overhead of things like hash tables in
> order to get data from client interfaces to their proper placement in a
> full robot description vector. Using callbacks available on event ports and
> some functors, the conversion could be "registered" at initialization of
> the client interface --- this might avoid explicit 'lookups'. What were
> your ideas on this?
>

John,

All lookups and maps are cached, and are computed when a controller is
loaded. When running the controller, mapping from one vector to another is
O(1), like so:

controller_pos[i] = robot_pos[lookup[i]];

where lookup is a std::vector.

Higher-level streams on ROS topics might be subject to data with varying
size and order, especially when there are multiple writers where each sends
partial knowledge chunks. In this case lookups are needed at every update,
but this is fortunately not the case in the controller manager.

When a client is loaded, it specifies which joints and interfaces it
requires, including the ordering. This is something that does not change
during the lifetime of the controller, unless it is stopped, unloaded, and
re-loaded with a different configuration.

- Is it possible to have a controller with multiple interfaces (eg. send
position + velocity + effort commands)?.

I'm not addressing ros controller but really this proposal. As a first cut,
> limiting to one type per controller instantiation might not be a terrible
> restriction. One of the software constructs I am really impressed by is
> OMPL's space descriptions ( http://ompl.kavrakilab.org/spaces.html). I'm
> not saying you'd need to go to this level, but asking a controller to
> declare its range space with some detail would make integration easier. In
> the future, it might ease support for controllers that output in something
> else other than joint space. Things like "sensor_msgs::JointState" is
> rather ambiguous as to what its controlling without having to introspect
> the data in the message or see how its being written to in the source's
> code.
>

Sometimes you are constrained by your hardware vendor, and sometimes you
want to do just that; back to the fancy example: It makes sense to expose
both an effort and a stiffness interface for a variable-stiffness joint, as
these are two 'independent' control parameters.

> In general, I think this is a great start for a proposal. We are looking
> at doing something very similar and I would love to see if there is some
> point of collaboration. But we are under a similar time crunch.. ~6 wks to
> implementation would be _very_ desirable.
>

Great!. I did not fully understand the above statement, are you currently
working on this?. I can share the repository where I'll be working on --I'm
just setting it up-- but it'll take some weeks before something usable
starts to show up.

Cheers,

Adolfo.

>
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>

[ros-users] Joint controller manager

On 01/28/2013 12:55 PM, Adolfo Rodríguez Tsouroukdissian wrote:
> All lookups and maps are cached, and are computed when a controller is
> loaded. When running the controller, mapping from one vector to
> another is O(1), like so:
Perfect.
>
> Great!. I did not fully understand the above statement, are you
> currently working on this?. I can share the repository where I'll be
> working on --I'm just setting it up-- but it'll take some weeks before
> something usable starts to show up.
>
No more than that simple example I mentioned earlier that mapped between
different Eigen vectors and a common JointState msg.

Joint controller manager

On Mon, 28 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:

> Hello ROS and Orocos users,
>
> This is a call for feedback. I'm currently working on a "joint controller manager",
> that is, a component that manages joint resources and exposes them to control. For
> those familiar with the pr2_controller_manager, this would provide similar
> functionality and interfaces, while relaxing some constraints to allow easy porting to
> different hardware platforms. Exposing hardware to control (and realtime control in
> particular) is still a big hurdle, and it would be very desirable to make this at least
> an order of magnitude easier. Once a minimal set of controller interfaces are made
> available for a given platform (eg. mobile base controller, spline interpolator, ...),
> a truckload of higher-level functionality becomes available.

Agreed!

> At the moment I have an existing in-house solution that from a ROS API point of view
> looks pretty much like a pr2_controller_manager, and a design of where I'd like things
> to go, which is attached to this message in pdf form. As a next step I was planning on
> setting up a public repo and port the existing design from Orocos 1.x to Orocos 2.x,
> which adds the expressivity needed to address the missing features. But before that,
> I'd like to make a pause and ask for some feedback.

Very good attitude :-)

> - Is there interest in giving this topic a dedicated discussion place, like a mailing
> list or a ROS special interest group?.

I have seen too many laudable efforts like this one start with focusing on
the wrong thing, such as making a new communication channel... I suggest to
keep the existing ones, and only make a new one if the need is very clear.

> - If you take a look at the attached design, please be critic about it. What would you
> add or remove?, what would you do differently?.

> - What can you not accomplish (or have had trouble accomplishing) with the tools you or
> your team have used so far?.
>
> Finally, I'd like to be aware of any active and similarly scoped initiative,

There is an industry-standard around these things in the PLCopen world:
<http://www.plcopen.org/pages/tc2_motion_control/>.
It is rather focused on traditional "easy" industrial motion control, but
it is something, at least. (I do not like it too much, however, for the
reasons explained below: lack of standardized _semantics_ of essential
aspects such as Cartesian frames and motions.)

> so please
> let me know if you're working on the subject.

I have been working on this subject for more than 10 years :-) The bad news
is the lack of standardization in the modelling of all relevant concepts:
joints, chains, controller, motion, trajectories... I have learned that it
is important to _first_ agree on the "meta model" of all these things,
before spending effort on an _implementation_. I know that this is not the
mainstream of the ROS world, but I got very convinced that it is the only
approach with long-term viability: I have been bitten way too many times by
software that exchanges "topics" without a clear _computer verifiable_
model of the meaning of the data in the topic, leading to undebuggable
systems...

> Late last week I found out almost by
> chance about the yet undocumented ros_control [1] repository, which deferred the
> writing of this email a day so I could familiarize with it. Its scope is very much
> aligned with my current objectives, as it consists of a library offering functionality
> similar to that of the pr2_controller_manager that can be adapted to other robot
> platforms. I'm looking forward to sharing opinions and use cases with all interested
> parties, and if possible map interest overlaps to common code. Some questions that come
> to my mind after reviewing the code in [1]:
>
> - Is it possible to have a controller with multiple interfaces (eg. send position +
> velocity + effort commands)?.

It is, in my opinion, not a matter of asking whether it _is_ possible:
this_should_ be possible! But in this context I have also learned that the
mainstream software development in robotics is all about writing software
libraries with C++ code, while quite some other successful domains "out
there" don't write code, but generate it from models. Especially in the
context of this message: industrial control practice uses Simulink, 20Sim,
LabView or Modelica _models_, and _tools_ to generate the code. This helps
a lot in avoiding the problem of hand-writing APIs that support _all
possible_ relevant combinations of robot control capabilities; the latter
is just not maintainable. (I see the same problem occurring in our KDL
library, in the context of kinematics and dynamics algorithms.)

> - If I understand correctly, interfaces are limited by design to position, velocity and
> effort, and adding a new one (fancy example: stiffness) is not possible, correct?.

Why not? Stiffness control is (on any robot platform) a "layer" around the
real hardware actuator control.

> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files, ie. without
> writing code?.

In the "Model Driven Engineering" approach it is; in the "class library
API" world it is a lot more difficult. Your "configuration file" is
basically a "model in disguise" :-) So, it makes more sense to make that
model explicit, and agree on that first.

In many orocos applications that support motion control, people have made
the error to deploy the kind of architecture that you have in your drawing
("sinks" and "sources" connected via "topic" data flows) one on one on an
Orocos "TaskContext" component design, which is _very_ inefficient.
Since ages already, industry deploys such architectures into one single
thread or process, as different functions that access the "topics" as
shared memory; this is alot more efficient, especially since the
computations in the "components" are very simple, but a lot of data has to
be streamed around all the time. In addition, the Simulink, Modelica or
20Sim tools do the code generation from your kind of "model" to such
single-thread computations for you.

Another way of looking at this problem is as follows: ROS/Orocos "force"
developers to thing in the "component based" design paradigm in which all
computations are in (hidden in) components and the data is flowing around in "publish/subscribe" topics; however,
control functionalities have, since ages too already, best been done in a
"functional programming" paradigm, where the data are shared, never copied, and certainly
not streamed around between computations.

> - Controllers running at lower frequency than the manager need to implement this by
> doing work only one out of every n cycles, as separate controller threads are not
> supported, correct?.

This is something that the _software component platform_ infrastructure has to solve;
please, let's not bring in this complexity at the _software application
platform_ level. (Although in ROS or Orocos it is not so clear where one
stops and the other starts...)

> - Is there any work on decoupling the more common "workhorse" controllers out of the
> pr2_controller_manager infrastructure (eg. a couple of mobile base implementations, the
> FollowJointTrtajectory action)?. I've already spent some time factoring out the spline
> splicing and interpolation code from the FollowJointTrtajectory action, and was
> planning on writing some unit tests on it. If not, I can also make this available once
> the cleanup is complete.
>  
> That's it for now, thanks for reading.

Thanks for your nice preparation! My summary: the ROS/Orocos worlds are not
providing the right tools, concepts and primitives for doing efficient and
advanced (realtime) motion control for robots.

> [1] https://github.com/willowgarage/ros_control
>
> --
> Adolfo Rodríguez Tsouroukdissian

Herman

> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> http://www.pal-robotics.com

Joint controller manager

>
>
> Late last week I found out almost by
>> chance about the yet undocumented ros_control [1] repository, which
>> deferred the
>> writing of this email a day so I could familiarize with it. Its scope is
>> very much
>> aligned with my current objectives, as it consists of a library offering
>> functionality
>> similar to that of the pr2_controller_manager that can be adapted to
>> other robot
>> platforms. I'm looking forward to sharing opinions and use cases with all
>> interested
>> parties, and if possible map interest overlaps to common code. Some
>> questions that come
>> to my mind after reviewing the code in [1]:
>>
>>
Hey Herman,

Just to be clear, the questions in the below list are things I am expecting
from a controller manager implementation, but don't seem to be supported by
[1]. Unless convinced otherwise, I'd like an implementation that allows you
to do such things. The proposal attached in the original post does allow
them.

- Is it possible to have a controller with multiple interfaces (eg. send
>> position +
>> velocity + effort commands)?.
>>
>
> It is, in my opinion, not a matter of asking whether it _is_ possible:
> this_should_ be possible! But in this context I have also learned that the
> mainstream software development in robotics is all about writing software
> libraries with C++ code, while quite some other successful domains "out
> there" don't write code, but generate it from models. Especially in the
> context of this message: industrial control practice uses Simulink, 20Sim,
> LabView or Modelica _models_, and _tools_ to generate the code. This helps
> a lot in avoiding the problem of hand-writing APIs that support _all
> possible_ relevant combinations of robot control capabilities; the latter
> is just not maintainable. (I see the same problem occurring in our KDL
> library, in the context of kinematics and dynamics algorithms.)
>
>
> - If I understand correctly, interfaces are limited by design to
>> position, velocity and
>> effort, and adding a new one (fancy example: stiffness) is not possible,
>> correct?.
>>
>
> Why not? Stiffness control is (on any robot platform) a "layer" around the
> real hardware actuator control.
>
>
> - Is it possible to chain controllers as in the attached figure
>> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration
>> files, ie. without
>> writing code?.
>>
>
> In the "Model Driven Engineering" approach it is; in the "class library
> API" world it is a lot more difficult. Your "configuration file" is
> basically a "model in disguise" :-) So, it makes more sense to make that
> model explicit, and agree on that first.
>
> In many orocos applications that support motion control, people have made
> the error to deploy the kind of architecture that you have in your drawing
> ("sinks" and "sources" connected via "topic" data flows) one on one on an
> Orocos "TaskContext" component design, which is _very_ inefficient.
> Since ages already, industry deploys such architectures into one single
> thread or process, as different functions that access the "topics" as
> shared memory; this is alot more efficient, especially since the
> computations in the "components" are very simple, but a lot of data has to
> be streamed around all the time. In addition, the Simulink, Modelica or
> 20Sim tools do the code generation from your kind of "model" to such
> single-thread computations for you.
>

I picture the controller manager as being mostly single-threaded, where
clients are explicitly serialized in the manager's update cycle (using
slave activities in Orocos speak). This is in fact what I have now. An
example of where I'd like to have a separate thread is a joint_states
publisher, a sink-only client that publishes information like joint
positions and velocities at a lower frequency. I dislike bringing down the
update frequency of some module with code like:

void update()
{
if (count % 10 == 0) // Eyes start bleeding
{
// Do stuff
}
++count;
}

So, having most clients serialized for performance, and a few exceptions
spinning separate threads seems reasonable to me. I'm open to alternative
solutions, though.

The solution proposed in [1] (see original post for link) uses a plugin
mechanism for implementing controllers, which enforces single-threaded
execution and passing data by pointers. It just does not allow the use case
of clients running with different update policies (lower frequency,
non-periodic triggering). How would you go about this?. As Johnny 5 would
say: iiiiinput ;-)

> Another way of looking at this problem is as follows: ROS/Orocos "force"
> developers to thing in the "component based" design paradigm in which all
> computations are in (hidden in) components and the data is flowing around
> in "publish/subscribe" topics; however,
> control functionalities have, since ages too already, best been done in a
> "functional programming" paradigm, where the data are shared, never
> copied, and certainly
> not streamed around between computations.

When different tasks are serialized in a single thread, connection policies
that don't handle concurrency can be used. In such cases data can be passed
around as pointers or references. Unfortunately ROS and Orocos don't yet do
this for you. You could do it in the manager, though, the information is
there.

>
>
> - Controllers running at lower frequency than the manager need to
>> implement this by
>> doing work only one out of every n cycles, as separate controller threads
>> are not
>> supported, correct?.
>>
>
> This is something that the _software component platform_ infrastructure
> has to solve;
> please, let's not bring in this complexity at the _software application
> platform_ level. (Although in ROS or Orocos it is not so clear where one
> stops and the other starts...)
>

>
> - Is there any work on decoupling the more common "workhorse" controllers
>> out of the
>> pr2_controller_manager infrastructure (eg. a couple of mobile base
>> implementations, the
>> FollowJointTrtajectory action)?. I've already spent some time factoring
>> out the spline
>> splicing and interpolation code from the FollowJointTrtajectory action,
>> and was
>> planning on writing some unit tests on it. If not, I can also make this
>> available once
>> the cleanup is complete.
>>
>> That's it for now, thanks for reading.
>>
>
> Thanks for your nice preparation! My summary: the ROS/Orocos worlds are not
> providing the right tools, concepts and primitives for doing efficient and
> advanced (realtime) motion control for robots.

One further disclaimer: I'm aiming at having a prototype controller manager
in about six weeks, so I'm trying to make the best possible compromise
between what's already out there and what can be done in such a time frame.
I won't achieve peace on earth, but hopefully a solid step in the right
direction.

Cheers,

Adolfo.

>
>
> [1] https://github.com/**willowgarage/ros_control<https://github.com/willowg...
>>
>> --
>> Adolfo Rodríguez Tsouroukdissian
>>
>
> Herman
>
>

Joint controller manager

On Mon, 28 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:

>
> Late last week I found out almost by
> chance about the yet undocumented ros_control [1] repository,
> which deferred the
> writing of this email a day so I could familiarize with it. Its
> scope is very much
> aligned with my current objectives, as it consists of a library
> offering functionality
> similar to that of the pr2_controller_manager that can be
> adapted to other robot
> platforms. I'm looking forward to sharing opinions and use
> cases with all interested
> parties, and if possible map interest overlaps to common code.
> Some questions that come
> to my mind after reviewing the code in [1]:
>
> Hey Herman,
>
> Just to be clear, the questions in the below list are things I am expecting from a
> controller manager implementation, but don't seem to be supported by [1]. Unless
> convinced otherwise, I'd like an implementation that allows you to do such things.

What more arguments do you want to discuss whether [1] is a good basis to
build upon or not? Or rather, what do you like and not like about [1].
(Except for the "usleep(200)" calls that occur here and there in the code :-))

> The proposal attached in the original post does allow them.
>
> - Is it possible to have a controller with multiple interfaces
> (eg. send position +
> velocity + effort commands)?.
>
>
> It is, in my opinion, not a matter of asking whether it _is_ possible:
> this_should_ be possible!  But in this context I have also learned that the
> mainstream software development in robotics is all about writing software
> libraries with C++ code, while quite some other successful domains "out
> there" don't write code, but generate it from models. Especially in the
> context of this message: industrial control practice uses Simulink, 20Sim,
> LabView or Modelica _models_, and _tools_ to generate the code. This helps
> a lot in avoiding the problem of hand-writing APIs that support _all
> possible_ relevant combinations of robot control capabilities; the latter
> is just not maintainable. (I see the same problem occurring in our KDL
> library, in the context of kinematics and dynamics algorithms.)
>
> - If I understand correctly, interfaces are limited by design to
> position, velocity and
> effort, and adding a new one (fancy example: stiffness) is not
> possible, correct?.
>
>
> Why not? Stiffness control is (on any robot platform) a "layer" around the
> real hardware actuator control.
>
> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration
> files, ie. without
> writing code?.
>
>
> In the "Model Driven Engineering" approach it is; in the "class library
> API" world it is a lot more difficult. Your "configuration file" is
> basically a "model in disguise" :-) So, it makes more sense to make that
> model explicit, and agree on that first.
>
> In many orocos applications that support motion control, people have made
> the error to deploy the kind of architecture that you have in your drawing
> ("sinks" and "sources" connected via "topic" data flows) one on one on an
> Orocos "TaskContext" component design, which is _very_ inefficient.
> Since ages already, industry deploys such architectures into one single
> thread or process, as different functions that access the "topics" as
> shared memory; this is alot more efficient, especially since the
> computations in the "components" are very simple, but a lot of data has to
> be streamed around all the time. In addition, the Simulink, Modelica or
> 20Sim tools do the code generation from your kind of "model" to such
> single-thread computations for you.
>
>
> I picture the controller manager as being mostly single-threaded, where clients are
> explicitly serialized in the manager's update cycle (using slave activities in Orocos
> speak). This is in fact what I have now.

And this is in fact what I try to provide arguments against as a
"best practice".

> An example of where I'd like to have a
> separate thread is a joint_states publisher, a sink-only client that publishes
> information like joint positions and velocities at a lower frequency. I dislike
> bringing down the update frequency of some module with code like:
>
> void update()
> {
>   if (count % 10 == 0) // Eyes start bleeding
>   {
>     // Do stuff
>   }
>   ++count;
> }

If this is _generated_ code, I would not mind. (For the same reason that we
are not picky about whether generated assembly code looks ugly.)

> So, having most clients serialized for performance, and a few exceptions spinning
> separate threads seems reasonable to me. I'm open to alternative solutions, though.
>
> The solution proposed in [1] (see original post for link) uses a plugin mechanism for
> implementing controllers, which enforces single-threaded execution and passing data by
> pointers. It just does not allow the use case of clients running with different update
> policies (lower frequency, non-periodic triggering). How would you go about this?.

Add a timer input port to your component, and let the _scheduling_ be done
by the function you attach to that port.

> As Johnny 5 would say: iiiiinput ;-)
>
>
> Another way of looking at this problem is as follows: ROS/Orocos "force"
> developers to thing in the "component based" design paradigm in which all
> computations are in (hidden in) components and the data is flowing around
> in "publish/subscribe" topics; however,
> control functionalities have, since ages too already, best been done in a
> "functional programming" paradigm, where the data are shared, never copied,
> and certainly
> not streamed around between computations.
>
> When different tasks are serialized in a single thread, connection policies that don't
> handle concurrency can be used. In such cases data can be passed around as pointers or
> references. Unfortunately ROS and Orocos don't yet do this for you. You could do it in
> the manager, though, the information is there.

ROS and Orocos should not do this for us; a "Computational model" tool
should. And that tool should be independent of ROS or Orocos. Calling
something a "manager" is not really a good idea, since it invites people to
add any kind of functionality that other parts in the system can not deal
with in a good way. I am suggestion a design in which the "manager" is
doing the "Coordination & Configuration" of several new
complementary/decoupled responsibilities:
- timing port
- time interrupt handling: input to schedule function and to execution
function
- scheduling function to compute the to-be-serially-executed computations
- execution of these computations
- shared data resource management (e.g., via an "immutable data" policy).
This includes adding computations to the schedule for logging etc.

I see all of these already present in the material you provided, but I try
to add some structural design to couple them together in a configurable
way.

> - Controllers running at lower frequency than the manager need
> to implement this by doing work only one out of every n cycles, as separate
> controller threads are not
> supported, correct?.
>
> This is something that the _software component platform_ infrastructure has to
> solve;
> please, let's not bring in this complexity at the _software application
> platform_ level. (Although in ROS or Orocos it is not so clear where one
> stops and the other starts...)
>
> - Is there any work on decoupling the more common "workhorse"
> controllers out of the
> pr2_controller_manager infrastructure (eg. a couple of mobile
> base implementations, the
> FollowJointTrtajectory action)?. I've already spent some time
> factoring out the spline
> splicing and interpolation code from the FollowJointTrtajectory
> action, and was
> planning on writing some unit tests on it. If not, I can also
> make this available once
> the cleanup is complete.
>  
> That's it for now, thanks for reading.
>
> Thanks for your nice preparation! My summary: the ROS/Orocos worlds are not
> providing the right tools, concepts and primitives for doing efficient and
> advanced (realtime) motion control for robots.
>
> One further disclaimer: I'm aiming at having a prototype controller manager in about
> six weeks, so I'm trying to make the best possible compromise between what's already
> out there and what can be done in such a time frame. I won't achieve peace on earth,
> but hopefully a solid step in the right direction.

I understand, of course, that incremental developments make sense. But can
you explain what parts of your suggestion you consider to be "solid", and
which ones are "to be thrown away"? Because we should agree on the solid
parts, in order not to waste time on temporary stuff.

What I consider "solid" are the suggestions to develop a "computational
model" tool, including the above-mentioned functions and data structures to
be implemented inside a ROS node or Orocos component (without depending on
ROS or Orocos). We have work going on in this direction.

> Cheers,
>
> Adolfo.

Herman

Joint controller manager

> What more arguments do you want to discuss whether [1] is a good basis to
> build upon or not? Or rather, what do you like and not like about [1].
> (Except for the "usleep(200)" calls that occur here and there in the code
> :-))

Great that you brought this up, I'd love to get some input on this! I
realize it's bad practice to create a busy polling loop. You could
implement the same/better functionality by using a mutex/condition,
and you can even get the same code to work both in non-realtime and in
realtime by compiling with the posix skin of a realtime OS to get
access to a realtime version of the mutex/condition.

In the end we decided to still use a polling loop to make it possible
to use the same binaries in both realtime and non-realtime. This in
turn was a pragmatic decision because of the way the ROS buildfarm
only puts out one set of binaries. So we pretty much balanced between
the easy of use vs a nice design. I'd of course love to hear peoples
thoughts on this, and maybe even alternative solutions to this
problem.

Best,
Wim

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

Joint controller manager

On Mon, 4 Feb 2013, Wim Meeussen wrote:

>> What more arguments do you want to discuss whether [1] is a good basis to
>> build upon or not? Or rather, what do you like and not like about [1].
>> (Except for the "usleep(200)" calls that occur here and there in the code
>> :-))
>
> Great that you brought this up, I'd love to get some input on this! I
> realize it's bad practice to create a busy polling loop. You could
> implement the same/better functionality by using a mutex/condition,
> and you can even get the same code to work both in non-realtime and in
> realtime by compiling with the posix skin of a realtime OS to get
> access to a realtime version of the mutex/condition.
>
> In the end we decided to still use a polling loop to make it possible
> to use the same binaries in both realtime and non-realtime. This in
> turn was a pragmatic decision because of the way the ROS buildfarm
> only puts out one set of binaries. So we pretty much balanced between
> the easy of use vs a nice design. I'd of course love to hear peoples
> thoughts on this, and maybe even alternative solutions to this
> problem.
>

It is this kind of ROSification that gives the whole of ROS a very bad
image in industry... (I take this statement on my shouldrs since I do not
want to put words into the mouth of industry people:-)
The "alternative" solutions are best practice in industry for years
already, relying on an external trigger for timing hence eliminating all
timing visibility inside the controller code.

> Best,
> Wim

Herman

Joint controller manager

On Feb 5, 2013, at 3:32 AM, Herman Bruyninckx wrote:
> On Mon, 4 Feb 2013, Wim Meeussen wrote:
>>> What more arguments do you want to discuss whether [1] is a good basis to
>>> build upon or not? Or rather, what do you like and not like about [1].
>>> (Except for the "usleep(200)" calls that occur here and there in the code
>>> :-))
>>
>> Great that you brought this up, I'd love to get some input on this! I
>> realize it's bad practice to create a busy polling loop. You could
>> implement the same/better functionality by using a mutex/condition,
>> and you can even get the same code to work both in non-realtime and in
>> realtime by compiling with the posix skin of a realtime OS to get
>> access to a realtime version of the mutex/condition.
>>
>> In the end we decided to still use a polling loop to make it possible
>> to use the same binaries in both realtime and non-realtime. This in
>> turn was a pragmatic decision because of the way the ROS buildfarm
>> only puts out one set of binaries. So we pretty much balanced between
>> the easy of use vs a nice design. I'd of course love to hear peoples
>> thoughts on this, and maybe even alternative solutions to this
>> problem.
>>
>
> It is this kind of ROSification that gives the whole of ROS a very bad
> image in industry... (I take this statement on my shouldrs since I do not
> want to put words into the mouth of industry people:-)
> The "alternative" solutions are best practice in industry for years
> already, relying on an external trigger for timing hence eliminating all
> timing visibility inside the controller code.

I agree with Herman. Whatever the method, separating execution timing control from functionality is the best "alternative solution" to this problem that allows both real-time and non-real-time execution. It is unfortunately that ROS does not promote this model of development, but at least it doesn't forbid it, so I think you should try to use it.

Geoff

Joint controller manager

>
>> The solution proposed in [1] (see original post for link) uses a plugin
>> mechanism for
>> implementing controllers, which enforces single-threaded execution and
>> passing data by
>> pointers. It just does not allow the use case of clients running with
>> different update
>> policies (lower frequency, non-periodic triggering). How would you go
>> about this?.
>>
>
> Add a timer input port to your component, and let the _scheduling_ be done
> by the function you attach to that port.

Ah, yes, you got me there. A timer that triggers callbacks allows to keep a
plugin-based approach with all controllers serialized in a single thread,
yet also allows to have different duty cycles. Thanks for sticking my head
out of the component mindset here.

>
>
> As Johnny 5 would say: iiiiinput ;-)
>>
>>
>> Another way of looking at this problem is as follows: ROS/Orocos
>> "force"
>> developers to thing in the "component based" design paradigm in
>> which all
>> computations are in (hidden in) components and the data is flowing
>> around
>> in "publish/subscribe" topics; however,
>> control functionalities have, since ages too already, best been
>> done in a
>> "functional programming" paradigm, where the data are shared, never
>> copied,
>> and certainly
>> not streamed around between computations.
>>
>> When different tasks are serialized in a single thread, connection
>> policies that don't
>> handle concurrency can be used. In such cases data can be passed around
>> as pointers or
>> references. Unfortunately ROS and Orocos don't yet do this for you. You
>> could do it in
>> the manager, though, the information is there.
>>
>
> ROS and Orocos should not do this for us; a "Computational model" tool
> should. And that tool should be independent of ROS or Orocos. Calling
> something a "manager" is not really a good idea, since it invites people to
> add any kind of functionality that other parts in the system can not deal
> with in a good way. I am suggestion a design in which the "manager" is
> doing the "Coordination & Configuration" of several new
> complementary/decoupled responsibilities:
> - timing port
> - time interrupt handling: input to schedule function and to execution
> function
> - scheduling function to compute the to-be-serially-executed computations
> - execution of these computations
> - shared data resource management (e.g., via an "immutable data" policy).
> This includes adding computations to the schedule for logging etc.
>
> I see all of these already present in the material you provided, but I try
> to add some structural design to couple them together in a configurable
> way.

Nice summary.

>
>
>> One further disclaimer: I'm aiming at having a prototype controller
>> manager in about
>> six weeks, so I'm trying to make the best possible compromise between
>> what's already
>> out there and what can be done in such a time frame. I won't achieve
>> peace on earth,
>> but hopefully a solid step in the right direction.
>>
>
> I understand, of course, that incremental developments make sense. But can
> you explain what parts of your suggestion you consider to be "solid", and
> which ones are "to be thrown away"? Because we should agree on the solid
> parts, in order not to waste time on temporary stuff.
>
> What I consider "solid" are the suggestions to develop a "computational
> model" tool, including the above-mentioned functions and data structures to
> be implemented inside a ROS node or Orocos component (without depending on
> ROS or Orocos). We have work going on in this direction.
>

Agreed. Let's focus on that. More on the next post.

Adolfo

>
> Cheers,
>>
>> Adolfo.
>>
>
>

Joint controller manager

On Tue, 29 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:

> The solution proposed in [1] (see original post for link) uses
> a plugin mechanism for
> implementing controllers, which enforces single-threaded
> execution and passing data by
> pointers. It just does not allow the use case of clients
> running with different update
> policies (lower frequency, non-periodic triggering). How would
> you go about this?.
>
> Add a timer input port to your component, and let the _scheduling_ be done
> by the function you attach to that port.
>
> Ah, yes, you got me there. A timer that triggers callbacks allows to keep a
> plugin-based approach with all controllers serialized in a single thread, yet also
> allows to have different duty cycles. Thanks for sticking my head out of the component
> mindset here.

If that is the result of my "ranting", I am very happy! Because I have
learned that a real roboticist _has_ to work within several "paradigms",
and the component-based paradigm is only one of them :-) What I just
brought to your attention is from the "operating system paradigm", which
you are very probably familiar with; that paradigm "conforms to" the more
generic one of "shared resource management". I am interested in learning
whether there is het another "meta"-level on top of that :-)

> As Johnny 5 would say: iiiiinput ;-)
>
>       Another way of looking at this problem is as follows:
> ROS/Orocos "force"
>       developers to thing in the "component based" design
> paradigm in which all
>       computations are in (hidden in) components and the data
> is flowing around
>       in "publish/subscribe" topics; however,
>       control functionalities have, since ages too already,
> best been done in a
>       "functional programming" paradigm, where the data are
> shared, never copied,
>       and certainly
>       not streamed around between computations.
>
> When different tasks are serialized in a single thread,
> connection policies that don't
> handle concurrency can be used. In such cases data can be
> passed around as pointers or
> references. Unfortunately ROS and Orocos don't yet do this for
> you. You could do it in
> the manager, though, the information is there.
>
> ROS and Orocos should not do this for us; a "Computational model" tool
> should. And that tool should be independent of ROS or Orocos. Calling
> something a "manager" is not really a good idea, since it invites people to
> add any kind of functionality that other parts in the system can not deal
> with in a good way. I am suggestion a design in which the "manager" is
> doing the "Coordination & Configuration" of several new
> complementary/decoupled responsibilities:
> - timing port
> - time interrupt handling: input to schedule function and to execution
>   function
> - scheduling function to compute the to-be-serially-executed computations
> - execution of these computations
> - shared data resource management (e.g., via an "immutable data" policy).
>   This includes adding computations to the schedule for logging etc.
>
> I see all of these already present in the material you provided, but I try
> to add some structural design to couple them together in a configurable
> way.

Good, keep us posted! We happen to be doing the same thing in house the
last week(s)... More difficult than I thought at the beginning to get it
"right" _and_ "reusable" in more contexts than just this one of controller
management.

> Nice summary.

Thanks!

> One further disclaimer: I'm aiming at having a prototype
> controller manager in about
> six weeks, so I'm trying to make the best possible compromise
> between what's already
> out there and what can be done in such a time frame. I won't
> achieve peace on earth,
> but hopefully a solid step in the right direction.
>
> I understand, of course, that incremental developments make sense. But can
> you explain what parts of your suggestion you consider to be "solid", and
> which ones are "to be thrown away"? Because we should agree on the solid
> parts, in order not to waste time on temporary stuff.
>
> What I consider "solid" are the suggestions to develop a "computational
> model" tool, including the above-mentioned functions and data structures to
> be implemented inside a ROS node or Orocos component (without depending on
> ROS or Orocos). We have work going on in this direction.
>
> Agreed. Let's focus on that. More on the next post.

Thanks!

More of this will be discussed at the "MDE for robotics" workshop at the
upcoming European Robotics Forum in Lyon, on March 20th.

> Adolfo

Herman

Joint controller manager

On Tue, Jan 29, 2013 at 12:11 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:

> On Tue, 29 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:
>
> The solution proposed in [1] (see original post for link) uses
>> a plugin mechanism for
>> implementing controllers, which enforces single-threaded
>> execution and passing data by
>> pointers. It just does not allow the use case of clients
>> running with different update
>> policies (lower frequency, non-periodic triggering). How would
>> you go about this?.
>>
>> Add a timer input port to your component, and let the _scheduling_ be done
>> by the function you attach to that port.
>>
>> Ah, yes, you got me there. A timer that triggers callbacks allows to keep
>> a
>> plugin-based approach with all controllers serialized in a single thread,
>> yet also
>> allows to have different duty cycles. Thanks for sticking my head out of
>> the component
>> mindset here.
>>
>
> If that is the result of my "ranting", I am very happy!

It did not seem a rant, at least not this time ;-)

> Because I have
> learned that a real roboticist _has_ to work within several "paradigms",
> and the component-based paradigm is only one of them :-) What I just
> brought to your attention is from the "operating system paradigm", which
> you are very probably familiar with; that paradigm "conforms to" the more
> generic one of "shared resource management".

Indeed.

> I am interested in learning
> whether there is het another "meta"-level on top of that :-)
>
> Good, keep us posted! We happen to be doing the same thing in house the
> last week(s)... More difficult than I thought at the beginning to get it
> "right" _and_ "reusable" in more contexts than just this one of controller
> management.
>

So, are you also implementing something similar?. Are there any additional
valuable lessons that can be shared?.

>
> More of this will be discussed at the "MDE for robotics" workshop at the
> upcoming European Robotics Forum in Lyon, on March 20th.
>

Noted!.

>
> Adolfo
>>
>
> Herman

Joint controller manager

All,

Firstly I'd like to thank you all for the positive feedback the original
post received. As next steps, it seems that the Willow Garage / hiDOF
implementation is a good starting point, as it already allows:
- Loading controllers as plugins, and serializing their execution in a
single thread.
- Creating controllers with arbitrary hardware interfaces.

I'll be giving this a test-drive, with the immediate steps being to:
- Write an Orocos 2.6 based component that leverages the controller_manager
library.
- Trigger each controller with a dedicated, configurable timer event to
allow each controller to have its own update rate. This timer event should
be compatible with deployment in hard-realtime and simulated clock contexts.

Best,

[ros-users] Joint controller manager

On Tue, Jan 29, 2013 at 7:17 AM, Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...> wrote:

> Firstly I'd like to thank you all for the positive feedback the original
> post received. As next steps, it seems that the Willow Garage / hiDOF
> implementation is a good starting point, as it already allows:
> - Loading controllers as plugins, and serializing their execution in a
> single thread.
> - Creating controllers with arbitrary hardware interfaces.
>
> I'll be giving this a test-drive, with the immediate steps being to:
> - Write an Orocos 2.6 based component that leverages the
> controller_manager library.
> - Trigger each controller with a dedicated, configurable timer event to
> allow each controller to have its own update rate. This timer event should
> be compatible with deployment in hard-realtime and simulated clock contexts.
>

Adolpho,

If you're interested in help with integrating ros_control with orocos, I'd
be happy to contribute, as I was already planning on trying something
similar in a few weeks from now.

With respect to hard realtime (xenomai) and ROS sim time, I wrote a simple
tool as part of my own architecture about a year ago [1]. It's made to just
query the time, but I think something similar could be done to switch
between timers.

[1]
https://github.com/jhu-lcsr/lcsr_ros_orocos_tools/blob/master/rtt_ros_to...

Also, thanks for starting this conversation!

-jon

ps - I also ported the old PR2 JointSplineTrajectoryController into an
orocos environment last year [2], and it'd be interesting to compare ports!

[2]
https://github.com/jhu-lcsr/controllerman/blob/master/controllerman_cont...

[ros-users] Joint controller manager

On 01/29/2013 06:17 AM, Adolfo Rodríguez Tsouroukdissian wrote:
> I'll be giving this a test-drive, with the immediate steps being to:
> - Write an Orocos 2.6 based component that leverages the
> controller_manager library.
Are you posting this code somewhere public? And I haven't seen hiDOF's
code anywhere.. Sachin didn't post an link that I saw.

JD

[ros-users] Joint controller manager

On Tue, Jan 29, 2013 at 4:46 PM, YAMOKOSKI, JOHN D. (JSC-ER)[OCEANEERING
SPACE SYSTEMS] <john [dot] d [dot] yamokoski [..] ...> wrote:

> On 01/29/2013 06:17 AM, Adolfo Rodríguez Tsouroukdissian wrote:
> > I'll be giving this a test-drive, with the immediate steps being to:
> > - Write an Orocos 2.6 based component that leverages the
> > controller_manager library.
> Are you posting this code somewhere public? And I haven't seen hiDOF's
> code anywhere.. Sachin didn't post an link that I saw.
>

HiDOF's repositories:
https://github.com/willowgarage/ros_control
https://github.com/willowgarage/ros_controllers

I'll probably fork ros_control and do pull requests if I need to add/modify
something in their codebase. I've also created a repository (creatively)
named orocos_controller_manager in PAL Robotics' GitHub organization where
our Orocos wrapper will live. As of now it only contains the diagram
attached in the original post, so not much to see yet.

https://github.com/pal-robotics/orocos_controller_manager

Cheers,

Adolfo.

>
> JD
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>

[ros-users] Joint controller manager

Hi All,

Great to see so much interest in this topic!

> HiDOF's repositories:
> https://github.com/willowgarage/ros_control
> https://github.com/willowgarage/ros_controllers

There's also a wiki with some basic usage patterns here
<https://github.com/willowgarage/ros_control/wiki>. This should be a
good start for understanding the design a little better. As Sachin
mentioned earlier, the main idea behind this effort was to remove the
PR2 specific assumptions that went into the pr2_mechanism_controller.
The new framework itself does not try to impose or invent any specific
interface to your robot, but it does allow the community to come up
with a set of (domain specific) common interfaces that will make it
possible to share code/controllers more easily.

> I'll probably fork ros_control and do pull requests if I need to add/modify
> something in their codebase.

Sounds like a good plan. The development on the basic framework has
settled down, so this would be a great time to look at where we can
improve things. We're still actively working on the project, currently
verifying realtime safety of code. Our next task is to port some of
the most common controllers, and in the process pull out useful pieces
(such as the trajectory management) into separate libraries. From
this thread I see that we're not the first ones trying to separate out
the trajectory management code; I'd love to joint forces and end up
with a single code base we can maintain together. Which code base
would be the best starting point for this effort?

Best,
Wim

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

[ros-users] Joint controller manager

On Tue, Jan 29, 2013 at 8:03 PM, Wim Meeussen <wim [..] ...> wrote:

> Hi All,
>

Great to see so much interest in this topic!
>
>
> > HiDOF's repositories:
> > https://github.com/willowgarage/ros_control
> > https://github.com/willowgarage/ros_controllers
>
> There's also a wiki with some basic usage patterns here
> <https://github.com/willowgarage/ros_control/wiki>.

Hey Wim,

I wasn't aware of this resource, good!.

> This should be a
> good start for understanding the design a little better. As Sachin
> mentioned earlier, the main idea behind this effort was to remove the
> PR2 specific assumptions that went into the pr2_mechanism_controller.
> The new framework itself does not try to impose or invent any specific
> interface to your robot, but it does allow the community to come up
> with a set of (domain specific) common interfaces that will make it
> possible to share code/controllers more easily.
>
>
> > I'll probably fork ros_control and do pull requests if I need to
> add/modify
> > something in their codebase.
>
> Sounds like a good plan. The development on the basic framework has
> settled down, so this would be a great time to look at where we can
> improve things. We're still actively working on the project, currently
> verifying realtime safety of code.

We'll be running things on Xenomai, so this is high in our list as well.

> Our next task is to port some of
> the most common controllers, and in the process pull out useful pieces
> (such as the trajectory management) into separate libraries. From
> this thread I see that we're not the first ones trying to separate out
> the trajectory management code; I'd love to joint forces and end up
> with a single code base we can maintain together. Which code base
> would be the best starting point for this effort?
>

I just pushed a folder named legacy_code in [1] that contains our port of
the JointTrajectoryActionController, and the component that exposes the
pr2_controller_manager-like component. The only changes I added from our
internal codebase is the header license which was missing on a few files.

Something worth noting is that the trajectory manipulation parts are
factored out of the JointTrajectoryActionController. I remember not being
entirely happy of how I ended up cutting the cake there, but it's a start.
I've also added a README, which provides some guiding comments.

On another note, since a few people have shown an interest to participate
in this effort, how about keeping design discussions here, but using
the ROS/Orocos
Robot Control Special Interest Group [2] created by Jonathan to discuss the
who-does-what-and-when, and not spam this list as much?. So sign up if you
want to participate!.

...I'll now go back and do my part checking out the code Jonathan shared
yesterday.

Adolfo,

[1] https://github.com/pal-robotics/orocos_controller_manager
[2] https://groups.google.com/forum/?fromgroups#!forum/ros-robot-control-sig

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

[ros-users] Joint controller manager

On Wed, 30 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:

[...]
> On another note, since a few people have shown an interest to participate in this
> effort, how about keeping design discussions here, but using the ROS/Orocos Robot
> Control Special Interest Group [2]

A forum is an order of magnitude less reactive than a forum...

> created by Jonathan to discuss the
> who-does-what-and-when, and not spam this list as much?. So sign up if you want to
> participate!.

I don't see why this very technically grounded and socially well conducted
discussion can considered to be spam... The only suggestion I would make is
to continue on the -dev mailinglists, exactly because of the technicalities
and the focus on new developments.

> ...I'll now go back and do my part checking out the code Jonathan shared yesterday.
>
> Adolfo,
>
> [1] https://github.com/pal-robotics/orocos_controller_manager
> [2] https://groups.google.com/forum/?fromgroups#!forum/ros-robot-control-sig
>
> Best,
> Wim

Herman

[ros-users] Joint controller manager

Hi Herman,

On Wed, Jan 30, 2013 at 10:25 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:

> On Wed, 30 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:
>
> [...]
>
> On another note, since a few people have shown an interest to participate
>> in this
>> effort, how about keeping design discussions here, but using the
>> ROS/Orocos Robot
>> Control Special Interest Group [2]
>>
>
> A forum is an order of magnitude less reactive than a forum...
>
>
> created by Jonathan to discuss the
>> who-does-what-and-when, and not spam this list as much?. So sign up if
>> you want to
>> participate!.
>>
>
> I don't see why this very technically grounded and socially well conducted
> discussion can considered to be spam... The only suggestion I would make is
> to continue on the -dev mailinglists, exactly because of the technicalities
> and the focus on new developments.

Jon and Adolfo's suggestion is the ROS equivalent of a more classic -dev
list. Because of the wide variety of topic of interest to the greater ROS
community, we setup these special interest groups to help maintain focus
and allow people to choose to join conversations they care about, and not
fill everyone's inbox with long detailed discussions of topics not of
interest to them. Our choice to structure things this way is based on
feedback from the past that when the mailing list becomes too high volume
people unsubscribe, even core active developers would auto archive the
mailing list if not unsubscribe.

It might be good to switch to the SIG from ros-users and if the orocos
community would prefer we could use the orocos-dev mailing list as well.
Generally double posting conversations leads to accidentally only replying
to one of the forums leaving a bunch of people out of the loop until it's
noticed. Also it makes searching for content much harder as there ends up
requiring two places to look through the history in case something is
relevant but not crossposted.

Tully

>
>
> ...I'll now go back and do my part checking out the code Jonathan shared
>> yesterday.
>>
>> Adolfo,
>>
>> [1] https://github.com/pal-**robotics/orocos_controller_**manager<https://gi...
>> [2] https://groups.google.com/**forum/?fromgroups#!forum/ros-**
>> robot-control-sig<https://groups.google.com/forum/?fromgroups#!forum/ros-robot-control-sig>
>>
>> Best,
>> Wim
>>
>
> Herman
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>

[ros-users] Joint controller manager

On Wed, 30 Jan 2013, Tully Foote wrote:

> Hi Herman, 
>
> On Wed, Jan 30, 2013 at 10:25 AM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
> On Wed, 30 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:
>
> [...]
> On another note, since a few people have shown an interest to
> participate in this
> effort, how about keeping design discussions here, but using
> the ROS/Orocos Robot
> Control Special Interest Group [2]
>
>
> A forum is an order of magnitude less reactive than a forum...
>
> created by Jonathan to discuss the
> who-does-what-and-when, and not spam this list as much?. So sign up
> if you want to
> participate!.
>
>
> I don't see why this very technically grounded and socially well conducted
> discussion can considered to be spam... The only suggestion I would make is
> to continue on the -dev mailinglists, exactly because of the technicalities
> and the focus on new developments.
>
>
> Jon and Adolfo's suggestion is the ROS equivalent of a more classic -dev list.  Because
> of the wide variety of topic of interest to the greater ROS community, we setup these
> special interest groups to help maintain focus and allow people to choose to join
> conversations they care about, and not fill everyone's inbox with long detailed
> discussions of topics not of interest to them. Our choice to structure things this way
> is based on feedback from the past that when the mailing list becomes too high volume
> people unsubscribe, even core active developers would auto archive the mailing list if
> not unsubscribe.  
>
> It might be good to switch to the SIG from ros-users and if the orocos community would
> prefer we could use the orocos-dev mailing list as well.  

I would prefer that, indeed. And I just did replace the orocos-users
address by orocos-dev.

> Generally double posting
> conversations leads to accidentally only replying to one of the forums leaving a bunch
> of people out of the loop until it's noticed.  Also it makes searching for content much
> harder as there ends up requiring two places to look through the history in case
> something is relevant but not crossposted.  

So...? Inevitable, I think, when there is no obvious "best" place to have a
particular discussion...

> Tully 

Herman

> ...I'll now go back and do my part checking out the code
> Jonathan shared yesterday.
>
> Adolfo,
>
> [1] https://github.com/pal-robotics/orocos_controller_manager
> [2]
> https://groups.google.com/forum/?fromgroups#!forum/ros-robot-control-sig
>
>       Best,
>       Wim
>

[ros-users] Joint controller manager

All,

I'd like to bring up the subject of having controllers running at lower
rates than the controller_manager. I can think of two possible solutions:

1. Frequency divider:
- Individual controller configurations can specify an optional parameter
that states the desired frequency, or that work should be done only '1 out
of n' manager cycles.
- Pros: Easy to implement. It is specific to a particular controller
implementation, hence does not need to be part of the controller_manager
library. See [1] for an example.
- Cons: Desired controller update period is subject to an error of up to
one controller manager control period.

2. Individual/grouped controller updating:
- The controller manager allows the option of updating single controllers,
or groups of them. Triggering these updates is not handled by the manager.
- Pros: Desired controller update period is unaffected by the controller
manager's update period.
- Cons: This solution requires significant changes to the existing
controller_manager codebase:
- Extending the API to allow not only batch update()s, but also updates
to a subset of the running controllers. Resolving which controllers to
update should be a constant-time operation.
- Add protection against concurrent access to data (eg. simultaneous
read() and update()), possibly with lock-free data structures.
- Because of the above point, the chosen concurrency handling mechanism
might render reusing the existing standard hardware interfaces impossible
(lock-free structures usually expose data through accessors, not raw
pointers).

At the moment I'm leaning towards the frequency divider as it is sufficient
for our use cases. I wonder if someone has a use case that does not fit
well with this approach.

[1]
https://github.com/willowgarage/ros_controllers/blob/master/joint_state_...

[ros-users] Joint controller manager

> I'd like to bring up the subject of having controllers running at lower
> rates than the controller_manager. I can think of two possible solutions:
>
> 1. Frequency divider:
> ...

> 2. Individual/grouped controller updating:
> ...
>
> At the moment I'm leaning towards the frequency divider as it is sufficient
> for our use cases. I wonder if someone has a use case that does not fit well
> with this approach.

Some comments specifically targeted at the current implementation of
the controller manager:

While I see the frequency divider approach has a number of
limitations, it makes it very easy to implement the realtime loop
around the controller manager. It basically looks something like
this:

main()
{
MyRobot robot;
ControllerManager cm(&robot);

while (true)
{
robot.read();
cm.update(getTime(), period);
robot.write();
sleepRemainingPeriod();
}
}

When judging other approaches, it would be great if we can look back
and see how they affect the usage pattern of the controller manager.

When applying this test to the approach where each controller
specifies its required update rate, at first glance it looks like we
could keep the realtime loop pretty simple. Based on all the desired
update rates, the controller manager could compute the desired
sleep/wakeup time between different controller runs, and expose this
duration/time to the person writing the realtime loop. I'm not sure
yet what the exact implementation details would look like for
different realtime OS's, or when using the controller manager with
RTT. Could someone shed some light on how they intend to use the
controller manager with RTT?

Best,
Wim

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

[ros-users] Joint controller manager

On Mon, Feb 4, 2013 at 4:22 AM, Wim Meeussen <wim [..] ...> wrote:
>> I'd like to bring up the subject of having controllers running at lower
>> rates than the controller_manager. I can think of two possible solutions:
>>
>> 1. Frequency divider:
>> ...
>
>> 2. Individual/grouped controller updating:
>> ...
>>
>> At the moment I'm leaning towards the frequency divider as it is
sufficient
>> for our use cases. I wonder if someone has a use case that does not fit
well
>> with this approach.
>
> Some comments specifically targeted at the current implementation of
> the controller manager:
>
> While I see the frequency divider approach has a number of
> limitations, it makes it very easy to implement the realtime loop
> around the controller manager. It basically looks something like
> this:
>
> main()
> {
> MyRobot robot;
> ControllerManager cm(&robot);
>
> while (true)
> {
> robot.read();
> cm.update(getTime(), period);

what is the role of the additional period parameter above?.

> robot.write();
> sleepRemainingPeriod();
> }
> }
>
> When judging other approaches, it would be great if we can look back
> and see how they affect the usage pattern of the controller manager.
>
> When applying this test to the approach where each controller
> specifies its required update rate, at first glance it looks like we
> could keep the realtime loop pretty simple. Based on all the desired
> update rates, the controller manager could compute the desired
> sleep/wakeup time between different controller runs, and expose this
> duration/time to the person writing the realtime loop.
> I'm not sure yet what the exact implementation details would look like
for
> different realtime OS's, or when using the controller manager with
> RTT.

I'd stick with the current controller_manager design and not deal with
clock/timer issues, but rather push this responsibility downstream. It's
not trivial to provide a solution that works well across different
(realtime) OS's and simulation environments. Reference implementations of
common controller_manager use cases can be made available in the
documentation to assist prospective users in this respect.

As an alternative, I was thinking of adding an accessor to the
controller_manager that returns some sort of handle to a controller, which
allows to update it from the outside. One can then attach timer triggers to
controller updating callbacks. Code-wise, this could look like:

// Get handle: To be done at configuration time, as it's likely a
non-constant time operation
handle = cm.getControllerHandle(controller_id);
assert(handle && "Controller handle KO!");

//...

// Use handle: alternative 1
handle.update(time);

// Use handle: alternative 2
cm.update(time, handle);

Could someone shed some light on how they intend to use the
> controller manager with RTT?

I'll detail a bit more (my view of) the timer approach suggested by Herman.
Consider a system with two Orocos components (two threads):
- The controller_manager, whose thread is non-periodic, and has n
event-triggered input ports. When a port is triggered, it executes some
work (update a controller, read hardware ,etc.). Without external triggers,
the controller_manager component does nothing.

- An OCL Timer component [1] configured with n timers which trigger the
ports of the controller_manager. Note: You could also setup non-periodic
update policies here if it made sense to your application.

An important thing to note with this setup is that although triggers come
from outside the controller_manager, the actual work is executed _in_ the
controller_manager thread, so no concurrency handling is required. I
overlooked this benefit in my previous post (!!!). Relating to Jonathans's
question on parallelism: there is none here, work is still done
sequentially inside the controller_manager.

Another relevant remark is that with such a setup, the controller_manager
and its controllers remain agnostic of the update policy (periodic, batch
or individual update, ...), which IMO is good.

Now, if someone comes up with a different setup in which external thread(s)
not only trigger controllers, but actually execute controller update code,
then you _do_ need concurrency handling, and you can have parallel code
execution. At any rate, the controller_manager implementation should stay
simple and not do any concurrency handling itself, but clearly document its
guarantees.

[1]
http://www.orocos.org/stable/documentation/ocl/v2.x/api/html/classOCL_1_...

Adolfo.

>
> Best,
> Wim

[ros-users] Joint controller manager

>> while (true)
>> {
>> robot.read();
>> cm.update(getTime(), period);

> what is the role of the additional period parameter above?.

We pass in two times into the update method to deal with the
difference between the system clock and the monotonic realtime clock.
The first argument is the (estimated) non-monotonic system time, which
the controller can use to stamp data it sends out to other components,
and to compare with timestamps of incoming data from other components.
But since the system time is non-monotonic (it can be modified by
e.g. an ntp daemon), it can't be used to compute e.g. the time
difference between different update cycles. So therefore the
controller also need access to a monotonic clock. To make it very
difficult to mix up the system clock and the monotonic realtime clock,
we pass the system time in as a ros::Time, and the monotonic realtime
time as a ros::Duration -- which maps on two common uses of the two
clocks: stamping data and computing the time difference between two
update cycles.

> I'd stick with the current controller_manager design and not deal with
> clock/timer issues, but rather push this responsibility downstream. It's not
> trivial to provide a solution that works well across different (realtime)
> OS's and simulation environments. Reference implementations of common
> controller_manager use cases can be made available in the documentation to
> assist prospective users in this respect.

Sounds like a good plan for now.

> An important thing to note with this setup is that although triggers come
> from outside the controller_manager, the actual work is executed _in_ the
> controller_manager thread, so no concurrency handling is required. I
> overlooked this benefit in my previous post (!!!). Relating to Jonathans's
> question on parallelism: there is none here, work is still done sequentially
> inside the controller_manager.

I'm very much in favor of keeping the controller manager sequentially.

> Another relevant remark is that with such a setup, the controller_manager
> and its controllers remain agnostic of the update policy (periodic, batch or
> individual update, ...), which IMO is good.

+1

-Wim

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

[ros-users] Joint controller manager

On Mon, 4 Feb 2013, Wim Meeussen wrote:

>> I'd like to bring up the subject of having controllers running at lower
>> rates than the controller_manager. I can think of two possible solutions:
>>
>> 1. Frequency divider:
>> ...
>
>> 2. Individual/grouped controller updating:
>> ...
>>
>> At the moment I'm leaning towards the frequency divider as it is sufficient
>> for our use cases. I wonder if someone has a use case that does not fit well
>> with this approach.
>
> Some comments specifically targeted at the current implementation of
> the controller manager:
>
> While I see the frequency divider approach has a number of
> limitations, it makes it very easy to implement the realtime loop
> around the controller manager. It basically looks something like
> this:
>
> main()
> {
> MyRobot robot;
> ControllerManager cm(&robot);
>
> while (true)
> {
> robot.read();
> cm.update(getTime(), period);
> robot.write();
> sleepRemainingPeriod();
> }
> }
>
> When judging other approaches, it would be great if we can look back
> and see how they affect the usage pattern of the controller manager.
>
> When applying this test to the approach where each controller
> specifies its required update rate, at first glance it looks like we
> could keep the realtime loop pretty simple. Based on all the desired
> update rates, the controller manager could compute the desired
> sleep/wakeup time between different controller runs, and expose this
> duration/time to the person writing the realtime loop. I'm not sure
> yet what the exact implementation details would look like for
> different realtime OS's, or when using the controller manager with
> RTT. Could someone shed some light on how they intend to use the
> controller manager with RTT?

A TaskContext with a "timer port", and running the scheduler inside.

> Best,
> Wim

Herman

[ros-users] Joint controller manager

On Thu, Jan 31, 2013 at 6:55 AM, Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...> wrote:

> All,
>
> I'd like to bring up the subject of having controllers running at lower
> rates than the controller_manager. I can think of two possible solutions:
>
> 1. Frequency divider:
> - Individual controller configurations can specify an optional parameter
> that states the desired frequency, or that work should be done only '1 out
> of n' manager cycles.
> - Pros: Easy to implement. It is specific to a particular controller
> implementation, hence does not need to be part of the controller_manager
> library. See [1] for an example.
> - Cons: Desired controller update period is subject to an error of up to
> one controller manager control period.
>
> 2. Individual/grouped controller updating:
> - The controller manager allows the option of updating single controllers,
> or groups of them. Triggering these updates is not handled by the manager.
> - Pros: Desired controller update period is unaffected by the controller
> manager's update period.
> - Cons: This solution requires significant changes to the existing
> controller_manager codebase:
> - Extending the API to allow not only batch update()s, but also updates
> to a subset of the running controllers. Resolving which controllers to
> update should be a constant-time operation.
> - Add protection against concurrent access to data (eg. simultaneous
> read() and update()), possibly with lock-free data structures.
> - Because of the above point, the chosen concurrency handling mechanism
> might render reusing the existing standard hardware interfaces impossible
> (lock-free structures usually expose data through accessors, not raw
> pointers).
>
> At the moment I'm leaning towards the frequency divider as it is
> sufficient for our use cases. I wonder if someone has a use case that does
> not fit well with this approach.
>
> [1]
> https://github.com/willowgarage/ros_controllers/blob/master/joint_state_...

So this also seems like it's a decision between serial (1) or parallel (2)
computation of different components of the final output signal. Is that
correct?

On Fri, Feb 1, 2013 at 3:48 AM, Carles Lopez <carles [dot] lopez [..] ...>
wrote:

> My two cents: maybe allowing single controllers to return the expected
> time they want to be updated given their own internal state. With this
> information control manager will adapt its own rate depending on the
> earliest deadline of the controllers it manages.
>

I like this bottom-up strategy, since it would also help debug
timing-related problems since the system will know at what rates each
components needs to run.

-j

[ros-users] Joint controller manager

On Fri, Feb 1, 2013 at 6:08 PM, Jonathan Bohren
<jonathan [dot] bohren [..] ...> wrote:
>
> On Thu, Jan 31, 2013 at 6:55 AM, Adolfo Rodríguez Tsouroukdissian
> <adolfo [dot] rodriguez [..] ...> wrote:
>>
>> All,
>>
>> I'd like to bring up the subject of having controllers running at lower
>> rates than the controller_manager. I can think of two possible solutions:
>>
>> 1. Frequency divider:
>> - Individual controller configurations can specify an optional parameter
>> that states the desired frequency, or that work should be done only '1 out
>> of n' manager cycles.
>> - Pros: Easy to implement. It is specific to a particular controller
>> implementation, hence does not need to be part of the controller_manager
>> library. See [1] for an example.
>> - Cons: Desired controller update period is subject to an error of up to
>> one controller manager control period.
>>
>> 2. Individual/grouped controller updating:
>> - The controller manager allows the option of updating single controllers,
>> or groups of them. Triggering these updates is not handled by the manager.
>> - Pros: Desired controller update period is unaffected by the controller
>> manager's update period.
>> - Cons: This solution requires significant changes to the existing
>> controller_manager codebase:
>> - Extending the API to allow not only batch update()s, but also updates
>> to a subset of the running controllers. Resolving which controllers to
>> update should be a constant-time operation.
>> - Add protection against concurrent access to data (eg. simultaneous
>> read() and update()), possibly with lock-free data structures.
>> - Because of the above point, the chosen concurrency handling mechanism
>> might render reusing the existing standard hardware interfaces impossible
>> (lock-free structures usually expose data through accessors, not raw
>> pointers).
>>
>> At the moment I'm leaning towards the frequency divider as it is
>> sufficient for our use cases. I wonder if someone has a use case that does
>> not fit well with this approach.
>>
>> [1]
>> https://github.com/willowgarage/ros_controllers/blob/master/joint_state_...
>
>
> So this also seems like it's a decision between serial (1) or parallel (2)
> computation of different components of the final output signal. Is that
> correct?
>
> On Fri, Feb 1, 2013 at 3:48 AM, Carles Lopez <carles [dot] lopez [..] ...>
> wrote:
>
>> My two cents: maybe allowing single controllers to return the expected
>> time they want to be updated given their own internal state. With this
>> information control manager will adapt its own rate depending on the
>> earliest deadline of the controllers it manages.
>
>
> I like this bottom-up strategy, since it would also help debug
> timing-related problems since the system will know at what rates each
> components needs to run.

Indeed, that was the main reason for this approach in our motors
manager, for instance when the hardware is not responding fast enough
or your bus is not reliable.
Also this event driven approach needs only one single thread so (i) no
concerns about concurrent access, (ii) it serves controllers as fast
as they require and (iii) it yields the CPU if you set the appropriate
timeouts in your I/O operations (i.e. a little bit before your next
deadline)

>
> -j
>
>
> --
> Jonathan Bohren
> PhD Student
> Dynamical Systems and Control Laboratory
> Laboratory for Computational Sensing and Robotics
> The Johns Hopkins University
>
> (707) 520-4736
> jbo [..] ...
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

--
Carles Lopez
Software Engineer

carles [dot] lopez [..] ...
http://www.pal-robotics.com

Pal Robotics, S.L.
c/ Pujades 77-79, 4t 4a
08005 Barcelona
Tel: +34 93 414 53 47
Fax: +34 93 209 11 09
Skype: carles.pal-robotics

Facebook http://www.facebook.com/palrobotics1

Twiter http://twitter.com/#%21/palrobotics

PAL robotics http://www.youtube.com/user/PALRobotics
channel

AVÍS DE CONFIDENCIALITAT: Aquest missatge i els seus documents adjunts
poden contenir informació privilegiada i/o confidencial que va
dirigida exclusivament al seu destinatari. Si vostè rep aquest
missatge i no és el destinatari assenyalat, o la persona encarregada
de l'entrega a la susdita persona, si us plau, notifiqui-ho
immediatament i remeti el missatge original a l'adreça de correu
electrònic indicada. Qualsevol còpia, ús o distribució no autoritzats
d'aquesta comunicació és estrictament prohibida.

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.

[ros-users] Joint controller manager

My two cents: maybe allowing single controllers to return the expected
time they want to be updated given their own internal state. With this
information control manager will adapt its own rate depending on the
earliest deadline of the controllers it manages.

On Thu, Jan 31, 2013 at 12:55 PM, Adolfo Rodríguez Tsouroukdissian
<adolfo [dot] rodriguez [..] ...> wrote:
> All,
>
> I'd like to bring up the subject of having controllers running at lower
> rates than the controller_manager. I can think of two possible solutions:
>
> 1. Frequency divider:
> - Individual controller configurations can specify an optional parameter
> that states the desired frequency, or that work should be done only '1 out
> of n' manager cycles.
> - Pros: Easy to implement. It is specific to a particular controller
> implementation, hence does not need to be part of the controller_manager
> library. See [1] for an example.
> - Cons: Desired controller update period is subject to an error of up to one
> controller manager control period.
>
> 2. Individual/grouped controller updating:
> - The controller manager allows the option of updating single controllers,
> or groups of them. Triggering these updates is not handled by the manager.
> - Pros: Desired controller update period is unaffected by the controller
> manager's update period.
> - Cons: This solution requires significant changes to the existing
> controller_manager codebase:
> - Extending the API to allow not only batch update()s, but also updates to
> a subset of the running controllers. Resolving which controllers to update
> should be a constant-time operation.
> - Add protection against concurrent access to data (eg. simultaneous
> read() and update()), possibly with lock-free data structures.
> - Because of the above point, the chosen concurrency handling mechanism
> might render reusing the existing standard hardware interfaces impossible
> (lock-free structures usually expose data through accessors, not raw
> pointers).
>
> At the moment I'm leaning towards the frequency divider as it is sufficient
> for our use cases. I wonder if someone has a use case that does not fit well
> with this approach.
>
> [1]
> https://github.com/willowgarage/ros_controllers/blob/master/joint_state_...
>
>
> --
> Adolfo Rodríguez Tsouroukdissian
> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> 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.
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Joint controller manager

On Tue, 29 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:

> All,
>
> Firstly I'd like to thank you all for the positive feedback the original post received.
> As next steps, it seems that the Willow Garage / hiDOF implementation is a good
> starting point, as it already allows:
> - Loading controllers as plugins, and serializing their execution in a single thread.
> - Creating controllers with arbitrary hardware interfaces.
>
> I'll be giving this a test-drive, with the immediate steps being to:
> - Write an Orocos 2.6 based component that leverages the controller_manager library.

This will be a good test of the intended "platform independence"; I have
confidence that this will work :-)

> - Trigger each controller with a dedicated, configurable timer event to allow each
> controller to have its own update rate. This timer event should be compatible with
> deployment in hard-realtime and simulated clock contexts.
>
> Best,
>
> --
> Adolfo Rodríguez Tsouroukdissian

Herman

> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> 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.
>

--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

Joint controller manager

On Tue, 29 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:

>
>
> On Tue, Jan 29, 2013 at 12:11 PM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
> On Tue, 29 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:
>
>             The solution proposed in [1] (see original post for
> link) uses
>             a plugin mechanism for
>             implementing controllers, which enforces
> single-threaded
>             execution and passing data by
>             pointers. It just does not allow the use case of
> clients
>             running with different update
>             policies (lower frequency, non-periodic
> triggering). How would
>             you go about this?.
>
> Add a timer input port to your component, and let the
> _scheduling_ be done
> by the function you attach to that port.
>
> Ah, yes, you got me there. A timer that triggers callbacks
> allows to keep a
> plugin-based approach with all controllers serialized in a
> single thread, yet also
> allows to have different duty cycles. Thanks for sticking my
> head out of the component
> mindset here.
>
>
> If that is the result of my "ranting", I am very happy!
>
>
> It did not seem a rant, at least not this time ;-)
>
>  
> Because I have
> learned that a real roboticist _has_ to work within several "paradigms",
> and the component-based paradigm is only one of them :-) What I just
> brought to your attention is from the "operating system paradigm", which
> you are very probably familiar with; that paradigm "conforms to" the more
> generic one of "shared resource management".
>
>
> Indeed.
>  
> I am interested in learning
> whether there is het another "meta"-level on top of that :-)
> Good, keep us posted! We happen to be doing the same thing in house the
> last week(s)... More difficult than I thought at the beginning to get it
> "right" _and_ "reusable" in more contexts than just this one of controller
> management.
>
> So, are you also implementing something similar?.

yes! Azamat is taking the lead in this effort, and he showed me some
prototype. It is not yet clear when something workable can be released.

> Are there any additional valuable lessons that can be shared?.
I don't know what you call 'valuable' but the main reason that started
Azamat's work is to get a computational support for "tree-structured
algorithms with multiple sweeps", such as:
- Model-Predictive Control
- Bayesian networks, Markov random fiels, Factor graphs
- control diagrams
- tree-structured dynamical systems
The common thing behind all these use cases are the things I mentioned:
separating the schedule from the model and the execution; generate code
from a domain-independent 'template implementation' with domain-dependent
plug-in functions; (immutable) data management; deployment onto various
software "containers".

> More of this will be discussed at the "MDE for robotics" workshop at the
> upcoming European Robotics Forum in Lyon, on March 20th.
>
> Noted!.
>
> Adolfo

Herman

Joint controller manager

>
>> I am interested in learning
>> whether there is het another "meta"-level on top of that :-)
>> Good, keep us posted! We happen to be doing the same thing in house the
>> last week(s)... More difficult than I thought at the beginning to get it
>> "right" _and_ "reusable" in more contexts than just this one of controller
>> management.
>>
>> So, are you also implementing something similar?.
>>
>
> yes! Azamat is taking the lead in this effort, and he showed me some
> prototype. It is not yet clear when something workable can be released.
>
>
> Are there any additional valuable lessons that can be shared?.
>>
> I don't know what you call 'valuable' but the main reason that started
> Azamat's work is to get a computational support for "tree-structured
> algorithms with multiple sweeps", such as:
> - Model-Predictive Control
> - Bayesian networks, Markov random fiels, Factor graphs
> - control diagrams
> - tree-structured dynamical systems
> The common thing behind all these use cases are the things I mentioned:
> separating the schedule from the model and the execution; generate code
> from a domain-independent 'template implementation' with domain-dependent
> plug-in functions; (immutable) data management; deployment onto various
> software "containers".

I'll keep an open eye on his work. The scope of his work is much broader
than what I'm attempting here.

Adolfo.

Joint controller manager

On Tue, 29 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:

>       I am interested in learning
>       whether there is het another "meta"-level on top of that
> :-)
> Good, keep us posted! We happen to be doing the same thing in
> house the
> last week(s)... More difficult than I thought at the beginning
> to get it
> "right" _and_ "reusable" in more contexts than just this one of
> controller
> management.
>
> So, are you also implementing something similar?.
>
>
> yes! Azamat is taking the lead in this effort, and he showed me some
> prototype. It is not yet clear when something workable can be released.
>
> Are there any additional valuable lessons that can be shared?.
>
> I don't know what you call 'valuable' but the main reason that started
> Azamat's work is to get a computational support for "tree-structured
> algorithms with multiple sweeps", such as:
> - Model-Predictive Control
> - Bayesian networks, Markov random fiels, Factor graphs
> - control diagrams
> - tree-structured dynamical systems
> The common thing behind all these use cases are the things I mentioned:
> separating the schedule from the model and the execution; generate code
> from a domain-independent 'template implementation' with domain-dependent
> plug-in functions; (immutable) data management; deployment onto various
> software "containers".
>
>
> I'll keep an open eye on his work. The scope of his work is much broader than what I'm
> attempting here.

That is _exactly_ why we are doing it: nobody in the robotics community
seems to want to spend the effort to think (a lot) broader and further than
one's own "itch" :-) But if you do, as we did, you quickly find out that
_many_ sub-problems are basically the same.

BTW, this is the topic of the European PhD School in Robotics, that just
went on for the second time last week, and in which I try to educate the
participants with this mindset. And it works, tremendously well even! :-)

> Adolfo.

Herman

[ros-users] Joint controller manager

On Mon, Jan 28, 2013 at 11:41 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:

> On Mon, 28 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:
>
>> so please
>> let me know if you're working on the subject.
>>
>
> I have been working on this subject for more than 10 years :-) The bad news
> is the lack of standardization in the modelling of all relevant concepts:
> joints, chains, controller, motion, trajectories... I have learned that it
> is important to _first_ agree on the "meta model" of all these things,
> before spending effort on an _implementation_. I know that this is not the
> mainstream of the ROS world, but I got very convinced that it is the only
> approach with long-term viability: I have been bitten way too many times by
> software that exchanges "topics" without a clear _computer verifiable_
> model of the meaning of the data in the topic, leading to undebuggable
> systems...
>
>
> Late last week I found out almost by
>> chance about the yet undocumented ros_control [1] repository, which
>> deferred the
>> writing of this email a day so I could familiarize with it. Its scope is
>> very much
>> aligned with my current objectives, as it consists of a library offering
>> functionality
>> similar to that of the pr2_controller_manager that can be adapted to
>> other robot
>> platforms. I'm looking forward to sharing opinions and use cases with all
>> interested
>> parties, and if possible map interest overlaps to common code. Some
>> questions that come
>> to my mind after reviewing the code in [1]:
>>
>> - Is it possible to have a controller with multiple interfaces (eg. send
>> position +
>> velocity + effort commands)?.
>>
>
> It is, in my opinion, not a matter of asking whether it _is_ possible:
> this_should_ be possible! But in this context I have also learned that the
> mainstream software development in robotics is all about writing software
> libraries with C++ code, while quite some other successful domains "out
> there" don't write code, but generate it from models. Especially in the
> context of this message: industrial control practice uses Simulink, 20Sim,
> LabView or Modelica _models_, and _tools_ to generate the code. This helps
> a lot in avoiding the problem of hand-writing APIs that support _all
> possible_ relevant combinations of robot control capabilities; the latter
> is just not maintainable. (I see the same problem occurring in our KDL
> library, in the context of kinematics and dynamics algorithms.)

- Is it possible to chain controllers as in the attached figure
>>
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
>> ie. without
>> writing code?.
>>
>
> In the "Model Driven Engineering" approach it is; in the "class library
> API" world it is a lot more difficult. Your "configuration file" is
> basically a "model in disguise" :-) So, it makes more sense to make that
> model explicit, and agree on that first.
>
> In many orocos applications that support motion control, people have made
> the error to deploy the kind of architecture that you have in your drawing
> ("sinks" and "sources" connected via "topic" data flows) one on one on an
> Orocos "TaskContext" component design, which is _very_ inefficient.
> Since ages already, industry deploys such architectures into one single
> thread or process, as different functions that access the "topics" as
> shared memory; this is alot more efficient, especially since the
> computations in the "components" are very simple, but a lot of data has to
> be streamed around all the time. In addition, the Simulink, Modelica or
> 20Sim tools do the code generation from your kind of "model" to such
> single-thread computations for you.
>

Herman,

Is there any sort of happy medium you know of between the current
component-based C++-code-writing and having to learn either a new
declarative modeling language or own a piece of proprietary software for
visual block-diagram design? Maybe some balance where the functional
interfaces of a given block are associated with more semantic information
than just a data type, but the actual computation is still written out in
an imperative language like c++?

-j

[ros-users] Joint controller manager

On Mon, 28 Jan 2013, Jonathan Bohren wrote:

> On Mon, Jan 28, 2013 at 11:41 AM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
> On Mon, 28 Jan 2013, Adolfo Rodríguez Tsouroukdissian wrote:
> so please
> let me know if you're working on the subject.
>
>
> I have been working on this subject for more than 10 years :-) The bad news
> is the lack of standardization in the modelling of all relevant concepts:
> joints, chains, controller, motion, trajectories... I have learned that it
> is important to _first_ agree on the "meta model" of all these things,
> before spending effort on an _implementation_. I know that this is not the
> mainstream of the ROS world, but I got very convinced that it is the only
> approach with long-term viability: I have been bitten way too many times by
> software that exchanges "topics" without a clear _computer verifiable_
> model of the meaning of the data in the topic, leading to undebuggable
> systems...
>
> Late last week I found out almost by
> chance about the yet undocumented ros_control [1] repository, which
> deferred the
> writing of this email a day so I could familiarize with it. Its scope
> is very much
> aligned with my current objectives, as it consists of a library
> offering functionality
> similar to that of the pr2_controller_manager that can be adapted to
> other robot
> platforms. I'm looking forward to sharing opinions and use cases with
> all interested
> parties, and if possible map interest overlaps to common code. Some
> questions that come
> to my mind after reviewing the code in [1]:
>
> - Is it possible to have a controller with multiple interfaces (eg.
> send position +
> velocity + effort commands)?.
>
>
> It is, in my opinion, not a matter of asking whether it _is_ possible:
> this_should_ be possible!  But in this context I have also learned that the
> mainstream software development in robotics is all about writing software
> libraries with C++ code, while quite some other successful domains "out
> there" don't write code, but generate it from models. Especially in the
> context of this message: industrial control practice uses Simulink, 20Sim,
> LabView or Modelica _models_, and _tools_ to generate the code. This helps
> a lot in avoiding the problem of hand-writing APIs that support _all
> possible_ relevant combinations of robot control capabilities; the latter
> is just not maintainable. (I see the same problem occurring in our KDL
> library, in the context of kinematics and dynamics algorithms.)
>
>
> - Is it possible to chain controllers as in the attached figure
>
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration
> files, ie. without
> writing code?.
>
>
> In the "Model Driven Engineering" approach it is; in the "class library
> API" world it is a lot more difficult. Your "configuration file" is
> basically a "model in disguise" :-) So, it makes more sense to make that
> model explicit, and agree on that first.
>
> In many orocos applications that support motion control, people have made
> the error to deploy the kind of architecture that you have in your drawing
> ("sinks" and "sources" connected via "topic" data flows) one on one on an
> Orocos "TaskContext" component design, which is _very_ inefficient.
> Since ages already, industry deploys such architectures into one single
> thread or process, as different functions that access the "topics" as
> shared memory; this is alot more efficient, especially since the
> computations in the "components" are very simple, but a lot of data has to
> be streamed around all the time. In addition, the Simulink, Modelica or
> 20Sim tools do the code generation from your kind of "model" to such
> single-thread computations for you.
>
>
> Herman,
>
> Is there any sort of happy medium you know of between the current component-based
> C++-code-writing and having to learn either a new declarative modeling language or own
> a piece of proprietary software for visual block-diagram design? Maybe some balance
> where the functional interfaces of a given block are associated with more semantic
> information than just a data type, but the actual computation is still written out in
> an imperative language like c++? 

I don't know what exactly your definition of "happy" is, but there is
already a lot out there in open source: OpenModelica, Scilab/Scicos, BRIDE,
RODIN, etc.; they all do modelling and code generation, to different
extends. Are this kind of projects really completely unknown in the ROS
universe...?

But we _will_ have to learn "new declarative modeling languages", because
that's the only way to standardize, on semantics and syntax; the advantage
of such languages is that one is not bound by one particular syntax, or
rather, two implementations with different syntax can still communicate
with each other via "model-to-model" transformations.

Side note: as soon as one accepts such a MDE approach, C++ all of a sudden
becomes a much less attractive language, while languages such as (System)C
come into the picture because of their appropriateness for code generation
to _all_ hardware (also the ones not supporting C++ runtimes): indeed, the code
generation ("model-to-text compilation") does not much more than filling in
plain computational functions and generated data structs.

> -j

Herman

[ros-users] Joint controller manager

On Mon, Jan 28, 2013 at 8:05 PM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Mon, 28 Jan 2013, Jonathan Bohren wrote:
>
>> On Mon, Jan 28, 2013 at 11:41 AM, Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...> wrote:
...
>> In many orocos applications that support motion control, people have made
>> the error to deploy the kind of architecture that you have in your drawing
>> ("sinks" and "sources" connected via "topic" data flows) one on one on an
>> Orocos "TaskContext" component design, which is _very_ inefficient.
>> Since ages already, industry deploys such architectures into one single
>> thread or process, as different functions that access the "topics" as
>> shared memory; this is alot more efficient, especially since the
>> computations in the "components" are very simple, but a lot of data has to
>> be streamed around all the time. In addition, the Simulink, Modelica or
>> 20Sim tools do the code generation from your kind of "model" to such
>> single-thread computations for you.
>>
>>
>> Herman,
>>
>> Is there any sort of happy medium you know of between the current
>> component-based
>> C++-code-writing and having to learn either a new declarative modeling
>> language or own
>> a piece of proprietary software for visual block-diagram design? Maybe
>> some balance
>> where the functional interfaces of a given block are associated with more
>> semantic
>> information than just a data type, but the actual computation is still
>> written out in
>> an imperative language like c++?
>
>
> I don't know what exactly your definition of "happy" is, but there is
> already a lot out there in open source: OpenModelica, Scilab/Scicos, BRIDE,
> RODIN, etc.;

Rock - www.rock-robotics.org

> they all do modelling and code generation, to different
> extends. Are this kind of projects really completely unknown in the ROS
> universe...?

Ironically, you skipped the one closest to your habitat and closest to
robotics, although this might have been due to an implicit meta-model
:-)

>
> But we _will_ have to learn "new declarative modeling languages", because
> that's the only way to standardize, on semantics and syntax; the advantage
> of such languages is that one is not bound by one particular syntax, or
> rather, two implementations with different syntax can still communicate
> with each other via "model-to-model" transformations.
>
> Side note: as soon as one accepts such a MDE approach, C++ all of a sudden
> becomes a much less attractive language, while languages such as (System)C
> come into the picture because of their appropriateness for code generation
> to _all_ hardware (also the ones not supporting C++ runtimes): indeed, the
> code
> generation ("model-to-text compilation") does not much more than filling in
> plain computational functions and generated data structs.
>
>> -j
>
>
> Herman

Peter

[ros-users] Joint controller manager

On Mon, 28 Jan 2013, Peter Soetens wrote:

> On Mon, Jan 28, 2013 at 8:05 PM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Mon, 28 Jan 2013, Jonathan Bohren wrote:
>>
>>> On Mon, Jan 28, 2013 at 11:41 AM, Herman Bruyninckx
>>> <Herman [dot] Bruyninckx [..] ...> wrote:
> ...
>>> In many orocos applications that support motion control, people have made
>>> the error to deploy the kind of architecture that you have in your drawing
>>> ("sinks" and "sources" connected via "topic" data flows) one on one on an
>>> Orocos "TaskContext" component design, which is _very_ inefficient.
>>> Since ages already, industry deploys such architectures into one single
>>> thread or process, as different functions that access the "topics" as
>>> shared memory; this is alot more efficient, especially since the
>>> computations in the "components" are very simple, but a lot of data has to
>>> be streamed around all the time. In addition, the Simulink, Modelica or
>>> 20Sim tools do the code generation from your kind of "model" to such
>>> single-thread computations for you.
>>>
>>>
>>> Herman,
>>>
>>> Is there any sort of happy medium you know of between the current
>>> component-based C++-code-writing and having to learn either a new
>>> declarative modeling language or own a piece of proprietary software
>>> for visual block-diagram design? Maybe some balance where the
>>> functional interfaces of a given block are associated with more
>>> semantic information than just a data type, but the actual computation
>>> is still written out in an imperative language like c++?
>>
>> I don't know what exactly your definition of "happy" is, but there is
>> already a lot out there in open source: OpenModelica, Scilab/Scicos, BRIDE,
>> RODIN, etc.;
>
> Rock - www.rock-robotics.org
>
>> they all do modelling and code generation, to different
>> extends. Are this kind of projects really completely unknown in the ROS
>> universe...?
>
> Ironically, you skipped the one closest to your habitat and closest to
> robotics, although this might have been due to an implicit meta-model
> :-)

Rock is one of the most rock-solid tool chains for _component_ based
programming but not for _computational_ models. In other words, I do not
see it play in the league of the tools I mentioned. And that is not a
criticism, because it is not designed to be a computational toolchain that
optimizes efficiency and code generation to the "bare metal". :-)

[...]

> Peter

Herman

[ros-users] Joint controller manager

2013/1/28 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
> Hello ROS and Orocos users,
>
> This is a call for feedback. I'm currently working on a "joint controller
> manager", that is, a component that manages joint resources and exposes them
> to control. For those familiar with the pr2_controller_manager, this would
> provide similar functionality and interfaces, while relaxing some
> constraints to allow easy porting to different hardware platforms. Exposing
> hardware to control (and realtime control in particular) is still a big
> hurdle, and it would be very desirable to make this at least an order of
> magnitude easier. Once a minimal set of controller interfaces are made
> available for a given platform (eg. mobile base controller, spline
> interpolator, ...), a truckload of higher-level functionality becomes
> available.
>
> At the moment I have an existing in-house solution that from a ROS API point
> of view looks pretty much like a pr2_controller_manager, and a design of
> where I'd like things to go, which is attached to this message in pdf form.
> As a next step I was planning on setting up a public repo and port the
> existing design from Orocos 1.x to Orocos 2.x, which adds the expressivity
> needed to address the missing features. But before that, I'd like to make a
> pause and ask for some feedback.
>
> - Is there interest in giving this topic a dedicated discussion place, like
> a mailing list or a ROS special interest group?.
>
> - If you take a look at the attached design, please be critic about it. What
> would you add or remove?, what would you do differently?.
>
> - What can you not accomplish (or have had trouble accomplishing) with the
> tools you or your team have used so far?.
>
> Finally, I'd like to be aware of any active and similarly scoped initiative,
> so please let me know if you're working on the subject. Late last week I
> found out almost by chance about the yet undocumented ros_control [1]
> repository, which deferred the writing of this email a day so I could
> familiarize with it. Its scope is very much aligned with my current
> objectives, as it consists of a library offering functionality similar to
> that of the pr2_controller_manager that can be adapted to other robot
> platforms. I'm looking forward to sharing opinions and use cases with all
> interested parties, and if possible map interest overlaps to common code.
> Some questions that come to my mind after reviewing the code in [1]:
>
> - Is it possible to have a controller with multiple interfaces (eg. send
> position + velocity + effort commands)?.
>
> - If I understand correctly, interfaces are limited by design to position,
> velocity and effort, and adding a new one (fancy example: stiffness) is not
> possible, correct?.
>
> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
> ie. without writing code?.
>
> - Controllers running at lower frequency than the manager need to implement
> this by doing work only one out of every n cycles, as separate controller
> threads are not supported, correct?.
>
> - Is there any work on decoupling the more common "workhorse" controllers
> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> base implementations, the FollowJointTrtajectory action)?. I've already
> spent some time factoring out the spline splicing and interpolation code
> from the FollowJointTrtajectory action, and was planning on writing some
> unit tests on it. If not, I can also make this available once the cleanup is
> complete.
>
> That's it for now, thanks for reading.
>
> [1] https://github.com/willowgarage/ros_control
>
> --
> Adolfo Rodríguez Tsouroukdissian
> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> 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.
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>

I don't have anything to say on the subject, but your pdf is really
lovely. How do you do this ?

[ros-users] Joint controller manager

> I don't have anything to say on the subject, but your pdf is really
> lovely. How do you do this ?
>

Hello Willy,

I used Inkscape. There's no fancy auto-generation behind, it was done by
hand.

Adolfo.

[ros-users] Joint controller manager

On Mon, Jan 28, 2013 at 4:41 PM, Jonathan Bohren
<jonathan [dot] bohren [..] ...>wrote:

> Adolpho,
>
>
Hey Jonathan,

I'm putting orocos-users back on the sender list so they don't miss updates
of the thread.

> This is great stuff!
>
> I've also been working on an orocos-based controller manager that has a
> similar interface to the ROS PR2 controller manager. The system I put
> together a year ago is really rough around the edges and could be designed
> much better, though. I was already planning on jumping into a rewrite and
> it'd be great to brainstorm ideas and put together something that can be
> used by the community.
>

Great news!, I'm curious about your experience and results.

>
> One thing that I think the ros-orocos integration needs is better support
> for actionlib for calling orocos operations over ROS.
>

Some time ago there was a discussion on the orocos list about exposing
services and actions. What I remember from it was that the mapping between
the ROS and Orocos worlds was not as straightforward as that between topics
and ports.

- Orocos operations are a superset of ROS services, so I don't see any
blockers in exposing OwnThread operations --via call()-- as ROS services.
- Actions seem a bit trickier. Maybe an OwnThread operation invoked via
send() (as opposed to call() above) and some additional topics for managing
the status and feedback streams.

All in all, it seems that the main blocker is the lack of a motivated
developer willing to take on this rather than technical issues.

>
> Another thing that I'd like to ensure is that the controller
> infrastructure integrates well with the gazebo simulator, either via
> plugins or just over the gazebo ROS interfaces.
>

Indeed. That's one of the things I'd like to improve in my existing
implementation, where I took the latter approach. I'd prefer to have the
manager integrated inside Gazebo as a plugin. So far it looks feasible, but
haven't gotten down and dirty with it yet.

>
> There's a lot more that I think we should talk about, maybe we should
> create a ros-robot-control-sig?
>

One of the purposes of this thread is to determine if there is critical
mass to keep it alive. My +1 is there.

Adolfo

>
> best,
> -jon
>
>

[ros-users] Joint controller manager

Based on this thread, and from what I know about other efforts going on in
the community, I just went ahead and created a google group called
"ros-robot-control-sig" [1].

My thought is that purpose of this group should be to coordinate efforts on
a common interface for robot control in a ROS-based system as well as a
common realtime-friendly and simulation-friendly controller architecture.
While different platforms will always call for different architectures, it
would be great if the different systems spoke the same ROS interfaces, and
if similar computation platforms could use the same libraries for control.

If you are working on such an architecture, please sign up and post a link
to your project and please share your experiences. It's open for anyone to
join!

Please also don't hesitate to join the list and tell us all that such an
effort is futile, and why you think so ;)

[1] https://groups.google.com/forum/?fromgroups#!forum/ros-robot-control-sig

-jon

On Mon, Jan 28, 2013 at 11:11 AM, Willy Lambert <lambert [dot] willy [..] ...>wrote:

> 2013/1/28 Jonathan Bohren <jonathan [dot] bohren [..] ...>:
> > Adolpho,
> >
> > This is great stuff!
> >
> > I've also been working on an orocos-based controller manager that has a
> > similar interface to the ROS PR2 controller manager. The system I put
> > together a year ago is really rough around the edges and could be
> designed
> > much better, though. I was already planning on jumping into a rewrite and
> > it'd be great to brainstorm ideas and put together something that can be
> > used by the community.
> >
> > One thing that I think the ros-orocos integration needs is better support
> > for actionlib for calling orocos operations over ROS.
>
> +1
>
> >
> > Another thing that I'd like to ensure is that the controller
> infrastructure
> > integrates well with the gazebo simulator, either via plugins or just
> over
> > the gazebo ROS interfaces.
> >
> > There's a lot more that I think we should talk about, maybe we should
> create
> > a ros-robot-control-sig?
> >
> > best,
> > -jon
> >
> >
> > On Mon, Jan 28, 2013 at 10:04 AM, Adolfo Rodríguez Tsouroukdissian
> > <adolfo [dot] rodriguez [..] ...> wrote:
> >>
> >> Hello ROS and Orocos users,
> >>
> >> This is a call for feedback. I'm currently working on a "joint
> controller
> >> manager", that is, a component that manages joint resources and exposes
> them
> >> to control. For those familiar with the pr2_controller_manager, this
> would
> >> provide similar functionality and interfaces, while relaxing some
> >> constraints to allow easy porting to different hardware platforms.
> Exposing
> >> hardware to control (and realtime control in particular) is still a big
> >> hurdle, and it would be very desirable to make this at least an order of
> >> magnitude easier. Once a minimal set of controller interfaces are made
> >> available for a given platform (eg. mobile base controller, spline
> >> interpolator, ...), a truckload of higher-level functionality becomes
> >> available.
> >>
> >> At the moment I have an existing in-house solution that from a ROS API
> >> point of view looks pretty much like a pr2_controller_manager, and a
> design
> >> of where I'd like things to go, which is attached to this message in pdf
> >> form. As a next step I was planning on setting up a public repo and
> port the
> >> existing design from Orocos 1.x to Orocos 2.x, which adds the
> expressivity
> >> needed to address the missing features. But before that, I'd like to
> make a
> >> pause and ask for some feedback.
> >>
> >> - Is there interest in giving this topic a dedicated discussion place,
> >> like a mailing list or a ROS special interest group?.
> >>
> >> - If you take a look at the attached design, please be critic about it.
> >> What would you add or remove?, what would you do differently?.
> >>
> >> - What can you not accomplish (or have had trouble accomplishing) with
> the
> >> tools you or your team have used so far?.
> >>
> >> Finally, I'd like to be aware of any active and similarly scoped
> >> initiative, so please let me know if you're working on the subject. Late
> >> last week I found out almost by chance about the yet undocumented
> >> ros_control [1] repository, which deferred the writing of this email a
> day
> >> so I could familiarize with it. Its scope is very much aligned with my
> >> current objectives, as it consists of a library offering functionality
> >> similar to that of the pr2_controller_manager that can be adapted to
> other
> >> robot platforms. I'm looking forward to sharing opinions and use cases
> with
> >> all interested parties, and if possible map interest overlaps to common
> >> code. Some questions that come to my mind after reviewing the code in
> [1]:
> >>
> >> - Is it possible to have a controller with multiple interfaces (eg. send
> >> position + velocity + effort commands)?.
> >>
> >> - If I understand correctly, interfaces are limited by design to
> position,
> >> velocity and effort, and adding a new one (fancy example: stiffness) is
> not
> >> possible, correct?.
> >>
> >> - Is it possible to chain controllers as in the attached figure
> >> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration
> files,
> >> ie. without writing code?.
> >>
> >> - Controllers running at lower frequency than the manager need to
> >> implement this by doing work only one out of every n cycles, as separate
> >> controller threads are not supported, correct?.
> >>
> >> - Is there any work on decoupling the more common "workhorse"
> controllers
> >> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> >> base implementations, the FollowJointTrtajectory action)?. I've already
> >> spent some time factoring out the spline splicing and interpolation code
> >> from the FollowJointTrtajectory action, and was planning on writing some
> >> unit tests on it. If not, I can also make this available once the
> cleanup is
> >> complete.
> >>
> >> That's it for now, thanks for reading.
> >>
> >> [1] https://github.com/willowgarage/ros_control
> >>
> >> --
> >> Adolfo Rodríguez Tsouroukdissian
> >> Senior robotics engineer
> >> adolfo [dot] rodriguez [..] ...
> >> 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.
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users [..] ...
> >> https://code.ros.org/mailman/listinfo/ros-users
> >>
> >
> >
> >
> > --
> > Jonathan Bohren
> > PhD Student
> > Dynamical Systems and Control Laboratory
> > Laboratory for Computational Sensing and Robotics
> > The Johns Hopkins University
> >
> > (707) 520-4736
> > jbo [..] ...
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users [..] ...
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>

[ros-users] Joint controller manager

On Mon, 28 Jan 2013, Jonathan Bohren wrote:

> Based on this thread, and from what I know about other efforts going on in the
> community, I just went ahead and created a google group called "ros-robot-control-sig"
> [1].
> My thought is that purpose of this group should be to coordinate efforts on a common
> interface for robot control in a ROS-based system as well as a common realtime-friendly
> and simulation-friendly controller architecture. While different platforms will always
> call for different architectures, it would be great if the different systems spoke the
> same ROS interfaces, and if similar computation platforms could use the same libraries
> for control.

Allow me to disagree... Putting the design of interfaces (and "topic" data
structures) at the level of a programming language as the most important
design decision is wrong: robotics is one of the few technology domains
(together with computer vision and machine learning) where software and
systems are made 100% by compilers and hand-written libraries; other
domains (automative, aerospace, mechatronics and control,...) start with
standardizing _models_ (and their semantics), and _generate_ code from
there.

What I now see happening all the time (and especially in the context of
so-called "hackathons") is that developers _have_ to look at each others'
implementations in order to make components/nodes work together, since the
_meaning_ of the topics is not ambiguously defined. (Similar problems occur
at the level of the "actions": too many configuration parameters are in the
"code" and not in the "model".)

And finally, the data topics on their own never fully represent an
_interface_ between two concurrent activities: there just represent functional
data flow, but also discrete coordination, bi-lateral QoS
adaptations, introspection, and data buffering policies are parts of the
interaction between components.

> If you are working on such an architecture, please sign up and post a link to your
> project and please share your experiences. It's open for anyone to join!
>
> Please also don't hesitate to join the list and tell us all that such an effort is
> futile, and why you think so ;)
>
> [1] https://groups.google.com/forum/?fromgroups#!forum/ros-robot-control-sig
>
> -jon

Herman

>
> On Mon, Jan 28, 2013 at 11:11 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
> 2013/1/28 Jonathan Bohren <jonathan [dot] bohren [..] ...>:
> > Adolpho,
> >
> > This is great stuff!
> >
> > I've also been working on an orocos-based controller manager that has a
> > similar interface to the ROS PR2 controller manager. The system I put
> > together a year ago is really rough around the edges and could be
> designed
> > much better, though. I was already planning on jumping into a rewrite and
> > it'd be great to brainstorm ideas and put together something that can be
> > used by the community.
> >
> > One thing that I think the ros-orocos integration needs is better support
> > for actionlib for calling orocos operations over ROS.
>
> +1
>
> >
> > Another thing that I'd like to ensure is that the controller infrastructure
> > integrates well with the gazebo simulator, either via plugins or just over
> > the gazebo ROS interfaces.
> >
> > There's a lot more that I think we should talk about, maybe we should create
> > a ros-robot-control-sig?
> >
> > best,
> > -jon
> >
> >
> > On Mon, Jan 28, 2013 at 10:04 AM, Adolfo Rodríguez Tsouroukdissian
> > <adolfo [dot] rodriguez [..] ...> wrote:
> >>
> >> Hello ROS and Orocos users,
> >>
> >> This is a call for feedback. I'm currently working on a "joint controller
> >> manager", that is, a component that manages joint resources and exposes them
> >> to control. For those familiar with the pr2_controller_manager, this would
> >> provide similar functionality and interfaces, while relaxing some
> >> constraints to allow easy porting to different hardware platforms. Exposing
> >> hardware to control (and realtime control in particular) is still a big
> >> hurdle, and it would be very desirable to make this at least an order of
> >> magnitude easier. Once a minimal set of controller interfaces are made
> >> available for a given platform (eg. mobile base controller, spline
> >> interpolator, ...), a truckload of higher-level functionality becomes
> >> available.
> >>
> >> At the moment I have an existing in-house solution that from a ROS API
> >> point of view looks pretty much like a pr2_controller_manager, and a design
> >> of where I'd like things to go, which is attached to this message in pdf
> >> form. As a next step I was planning on setting up a public repo and port the
> >> existing design from Orocos 1.x to Orocos 2.x, which adds the expressivity
> >> needed to address the missing features. But before that, I'd like to make a
> >> pause and ask for some feedback.
> >>
> >> - Is there interest in giving this topic a dedicated discussion place,
> >> like a mailing list or a ROS special interest group?.
> >>
> >> - If you take a look at the attached design, please be critic about it.
> >> What would you add or remove?, what would you do differently?.
> >>
> >> - What can you not accomplish (or have had trouble accomplishing) with the
> >> tools you or your team have used so far?.
> >>
> >> Finally, I'd like to be aware of any active and similarly scoped
> >> initiative, so please let me know if you're working on the subject. Late
> >> last week I found out almost by chance about the yet undocumented
> >> ros_control [1] repository, which deferred the writing of this email a day
> >> so I could familiarize with it. Its scope is very much aligned with my
> >> current objectives, as it consists of a library offering functionality
> >> similar to that of the pr2_controller_manager that can be adapted to other
> >> robot platforms. I'm looking forward to sharing opinions and use cases with
> >> all interested parties, and if possible map interest overlaps to common
> >> code. Some questions that come to my mind after reviewing the code in [1]:
> >>
> >> - Is it possible to have a controller with multiple interfaces (eg. send
> >> position + velocity + effort commands)?.
> >>
> >> - If I understand correctly, interfaces are limited by design to position,
> >> velocity and effort, and adding a new one (fancy example: stiffness) is not
> >> possible, correct?.
> >>
> >> - Is it possible to chain controllers as in the attached figure
> >> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
> >> ie. without writing code?.
> >>
> >> - Controllers running at lower frequency than the manager need to
> >> implement this by doing work only one out of every n cycles, as separate
> >> controller threads are not supported, correct?.
> >>
> >> - Is there any work on decoupling the more common "workhorse" controllers
> >> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> >> base implementations, the FollowJointTrtajectory action)?. I've already
> >> spent some time factoring out the spline splicing and interpolation code
> >> from the FollowJointTrtajectory action, and was planning on writing some
> >> unit tests on it. If not, I can also make this available once the cleanup is
> >> complete.
> >>
> >> That's it for now, thanks for reading.
> >>
> >> [1] https://github.com/willowgarage/ros_control
> >>
> >> --
> >> Adolfo Rodríguez Tsouroukdissian
> >> Senior robotics engineer
> >> adolfo [dot] rodriguez [..] ...
> >> 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.
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users [..] ...
> >> https://code.ros.org/mailman/listinfo/ros-users
> >>
> >
> >
> >
> > --
> > Jonathan Bohren
> > PhD Student
> > Dynamical Systems and Control Laboratory
> > Laboratory for Computational Sensing and Robotics
> > The Johns Hopkins University
> >
> > (707) 520-4736
> > jbo [..] ...
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users [..] ...
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>
>
>
> --
> Jonathan Bohren
> PhD Student
> Dynamical Systems and Control Laboratory
> Laboratory for Computational Sensing and Robotics
> The Johns Hopkins University
>
> (707) 520-4736
> jbo [..] ...
>
>

--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>