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
| Attachment | Size |
|---|---|
| joint_controller_manager.pdf | 27.38 KB |
[ros-users] Joint controller manager
On Mon, Jan 28, 2013 at 11:51 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> 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.
>
No, I agree entirely. I should have been more clear. When I refer to ROS
interfaces, I mean the interfaces that we can use to connect the operation
of these controllers to higher-level execution systems. In my experience,
moving to something more model-based and _not_ heavily multithreaded is
definitely the way to go.
> 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.
I agree, semantic information about the data is _critical_.
-j
[ros-users] Joint controller manager
On Mon, 28 Jan 2013, Jonathan Bohren wrote:
> On Mon, Jan 28, 2013 at 11:51 AM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
> 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.
>
>
> No, I agree entirely. I should have been more clear. When I refer to ROS interfaces, I
> mean the interfaces that we can use to connect the operation of these controllers to
> higher-level execution systems. In my experience, moving to something more model-based
> and _not_ heavily multithreaded is definitely the way to go.
>
> 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.
>
>
> I agree, semantic information about the data is _critical_.
Thank you for agreeing. The logical next step is to focus first on the
semantics, hence a "model". Unfortunately, this is not a common reflex in
the ROS/Orocos universe. But things are slowly changing; this concrete
topic could be a good start for a more visible effort in this direction.
Side note: within (but fully independent of) the Orocos context, Tinne De
Laet has made a complete "model-based stack", with a formal model that can
be connected to existing KDL code, while introducing checking of all
constraints in the model:
<http://www.orocos.org/wiki/geometric-relations-semantics-wiki>
She has also had summer interns that made two prototype tools, one in
Eclipse (via Xcore/Xtext and OCL), another one via Prolog (using the same
Xcore formal model). So, we know that it _can_ be done, bottom up, and with
C++-biased developers, and without loosing any runtime efficiency :-)
> -j
Herman
[ros-users] Joint controller manager
On Mon, Jan 28, 2013 at 5:10 PM, Edwards, Shaun M. <sedwards [..] ...>wrote:
> 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.
>
Hey Shaun,
MoveIt can use three ROS Services: [load|unload|switch]_controller in case
a different controller configuration is necessary. My understanding is that
this is an optional requirement. For triggering motions MoveIt uses the
FollowJointTrajectory action. If you provide these interfaces, MoveIt will
probably be happy. This is an example scenario where a generic manager
would make it very easy to expose all of these interfaces. It is one of the
most common examples I cite when explaining and justifying this work
package.
> ****
>
> ** **
>
> As far as your architecture, I notices that you are utilizing the ROS
> action interface.
>
The proposed architecture can use ROS actions, but does not require to.
It's up to you. In fact all ROS dependencies exist to provide common
interfaces to the outside world, but they are all in fact optional. You
could even deploy a system without any ROS dependencies if you wanted to.
> 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.
>
Yes!, the interface between the controllers and the manager is enforced,
while interface between the controller and its users is not. This is
already the case for the pr2_controller_manager, by the way.
If you see the clients in the diagram, the client-specific code lives in
the light-gray boxes. There goes whatever computation, configuration and
communication policies you see fit. For example, you might choose to
configure your controller from ROS parameters, Orocos properties, your
custom legacy xml format, it's entirely up to you. The same applies to the
interface you expose for controller commands. You might use actionlib, or
topics, or something entirely different. Furthermore, there are certain
controllers whose reference signal updates at rates that cannot be
deterministically serviced by ROS topics. In such cases you can choose to
use Orocos ports, shared memory, etc.
Cheers,