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

[Jonathan Bohren]

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

-j

-- 
Jonathan Bohren
PhD Student
Dynamical Systems and Control Laboratory
Laboratory for Computational Sensing and Robotics
The Johns Hopkins University

(707) 520-4736
jbo at jhu.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130128/13a3ccac/attachment-0004.html>