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

[Herman Bruyninckx]

On Mon, 28 Jan 2013, Jonathan Bohren wrote:

> On Mon, Jan 28, 2013 at 11:41 AM, Herman Bruyninckx
> <Herman.Bruyninckx at mech.kuleuven.be> 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