[ros-users] [Orocos-users] Joint controller manager

[Herman Bruyninckx]

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.rodriguez at pal-robotics.com
> http://www.pal-robotics.com