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
>
>

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
>
>

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.

+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.

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

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 ?