<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Late last week I found out almost by<br>
chance about the yet undocumented ros_control [1] repository, which deferred the<br>
writing of this email a day so I could familiarize with it. Its scope is very much<br>
aligned with my current objectives, as it consists of a library offering functionality<br>
similar to that of the pr2_controller_manager that can be adapted to other robot<br>
platforms. I'm looking forward to sharing opinions and use cases with all interested<br>
parties, and if possible map interest overlaps to common code. Some questions that come<br>
to my mind after reviewing the code in [1]:<br>
<br></blockquote></div></blockquote><div><br>Hey Herman,<br><br>Just to be clear, the questions in the below list are things I am expecting from a controller manager implementation, but don't seem to be supported by [1]. Unless convinced otherwise, I'd like an implementation that allows you to do such things. The proposal attached in the original post does allow them.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

- Is it possible to have a controller with multiple interfaces (eg. send position +<br>
velocity + effort commands)?.<br>
</blockquote>
<br></div>
It is, in my opinion, not a matter of asking whether it _is_ possible:<br>
this_should_ be possible!  But in this context I have also learned that the<br>
mainstream software development in robotics is all about writing software<br>
libraries with C++ code, while quite some other successful domains "out<br>
there" don't write code, but generate it from models. Especially in the<br>
context of this message: industrial control practice uses Simulink, 20Sim,<br>
LabView or Modelica _models_, and _tools_ to generate the code. This helps<br>
a lot in avoiding the problem of hand-writing APIs that support _all<br>
possible_ relevant combinations of robot control capabilities; the latter<br>
is just not maintainable. (I see the same problem occurring in our KDL<br>
library, in the context of kinematics and dynamics algorithms.)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- If I understand correctly, interfaces are limited by design to position, velocity and<br>
effort, and adding a new one (fancy example: stiffness) is not possible, correct?.<br>
</blockquote>
<br></div>
Why not? Stiffness control is (on any robot platform) a "layer" around the<br>
real hardware actuator control.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Is it possible to chain controllers as in the attached figure<br>
(r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files, ie. without<br>
writing code?.<br>
</blockquote>
<br></div>
In the "Model Driven Engineering" approach it is; in the "class library<br>
API" world it is a lot more difficult. Your "configuration file" is<br>
basically a "model in disguise" :-) So, it makes more sense to make that<br>
model explicit, and agree on that first.<br>
<br>
In many orocos applications that support motion control, people have made<br>
the error to deploy the kind of architecture that you have in your drawing<br>
("sinks" and "sources" connected via "topic" data flows) one on one on an<br>
Orocos "TaskContext" component design, which is _very_ inefficient.<br>
Since ages already, industry deploys such architectures into one single<br>
thread or process, as different functions that access the "topics" as<br>
shared memory; this is alot more efficient, especially since the<br>
computations in the "components" are very simple, but a lot of data has to<br>
be streamed around all the time. In addition, the Simulink, Modelica or<br>
20Sim tools do the code generation from your kind of "model" to such<br>
single-thread computations for you.<br></blockquote><div><br>I picture the controller manager as being mostly single-threaded, where clients are explicitly serialized in the manager's update cycle (using slave activities in Orocos speak). This is in fact what I have now. An example of where I'd like to have a separate thread is a joint_states publisher, a sink-only client that publishes information like joint positions and velocities at a lower frequency. I dislike bringing down the update frequency of some module with code like:<br>
<br><span style="font-family:courier new,monospace">void update()<br>{<br>  if (count % 10 == 0) // Eyes start bleeding<br>  {<br>    // Do stuff<br>  }<br>  ++count;<br>}<br><br><span style="font-family:arial,helvetica,sans-serif">So, having most clients serialized for performance, and a few exceptions spinning separate threads seems reasonable to me. I'm open to alternative solutions, though.<br>
<br>The solution proposed in [1] (see original post for link) uses a plugin mechanism for implementing controllers, which enforces single-threaded execution and passing data by pointers. It just does not allow the use case of clients running with different update policies (lower frequency, non-periodic triggering). How would you go about this?. As Johnny 5 would say: iiiiinput ;-)<br>
<br></span></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another way of looking at this problem is as follows: ROS/Orocos "force"<br>
developers to thing in the "component based" design paradigm in which all<br>
computations are in (hidden in) components and the data is flowing around in "publish/subscribe" topics; however,<br>
control functionalities have, since ages too already, best been done in a<br>
"functional programming" paradigm, where the data are shared, never copied, and certainly<br>
not streamed around between computations.</blockquote><div><br>When different tasks are serialized in a single thread, connection policies that don't handle concurrency can be used. In such cases data can be passed around as pointers or references. Unfortunately ROS and Orocos don't yet do this for you. You could do it in the manager, though, the information is there.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Controllers running at lower frequency than the manager need to implement this by<br>
doing work only one out of every n cycles, as separate controller threads are not<br>
supported, correct?.<br>
</blockquote>
<br></div>
This is something that the _software component platform_ infrastructure has to solve;<br>
please, let's not bring in this complexity at the _software application<br>
platform_ level. (Although in ROS or Orocos it is not so clear where one<br>
stops and the other starts...) <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Is there any work on decoupling the more common "workhorse" controllers out of the<br>
pr2_controller_manager infrastructure (eg. a couple of mobile base implementations, the<br>
FollowJointTrtajectory action)?. I've already spent some time factoring out the spline<br>
splicing and interpolation code from the FollowJointTrtajectory action, and was<br>
planning on writing some unit tests on it. If not, I can also make this available once<br>
the cleanup is complete.<br>
 <br>
That's it for now, thanks for reading.<br>
</blockquote>
<br></div>
Thanks for your nice preparation! My summary: the ROS/Orocos worlds are not<br>
providing the right tools, concepts and primitives for doing efficient and<br>
advanced (realtime) motion control for robots.</blockquote><div><br>One further disclaimer: I'm aiming at having a prototype controller manager in about six weeks, so I'm trying to make the best possible compromise between what's already out there and what can be done in such a time frame. I won't achieve peace on earth, but hopefully a solid step in the right direction.<br>
<br>Cheers,<br><br>Adolfo.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[1] <a href="https://github.com/willowgarage/ros_control" target="_blank">https://github.com/<u></u>willowgarage/ros_control</a><br>
<br>
--<br>
Adolfo Rodríguez Tsouroukdissian<br>
</blockquote>
<br></div><span class="HOEnZb"><font color="#888888">
Herman</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div><br><br>