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.