Orocos roadmap

One big thing I see missing from Orocos is a lack of a roadmap, or any
kind of indication of future plans. I think what has been done to
date with Orocos is fantastic, and I'm looking forward to putting
Orocos to good use on a couple of robotics projects. I am simply very
curious as to where the powers-to-be are thinking of taking things,
and what level of effort can/will be applied in the near future?

Cheers
Stephen

Orocos roadmap

On Friday 25 April 2008 15:39:27 S Roderick wrote:
> One big thing I see missing from Orocos is a lack of a roadmap, or any
> kind of indication of future plans. I think what has been done to
> date with Orocos is fantastic, and I'm looking forward to putting
> Orocos to good use on a couple of robotics projects. I am simply very
> curious as to where the powers-to-be are thinking of taking things,
> and what level of effort can/will be applied in the near future?

The main resource for future 'projects' on our map is/has been Bugzilla.
(search for Severity: Project )
However, only little projects are open now, and as Herman said, we're mainly
in a 'fix/improve what users report'-mode instead of the 'adding features and
see if people want them'-mode.

That aside, there are plenty of places for improvement. My list is
twofold: 'usability' and 'implementation'. This list is also known as
the 'RTT 2.0' list.

Usability:

1. Threads should *really* be an afterthought.
Today, you must attach a thread if you want your component to process
commands or events (unless you have expert knowledge of SlaveActivity)
That's not a userfriendly default. We should only have two kinds of
components: threaded ('active') and, as default, not threaded ('sequential').
The first kind executes commands/events/... in a thread in a
PeriodicActivity/NonPeriodicActivity, the second kind is an improved RTT
SlaveActivity implementation, which executes commands/events/... as they come
in (i.e. 'sequentially').

2. Be gone with Periodic/NonPeriodic activity.
The distinction between periodic and non periodic activities is made by
setting the period to '0'. Also, periods should be adaptable at thread
execution time (which is not possible now).

3. Be gone with users deciding upon syn/asyn events.
If a component is 'active', the event is delivered asynchronously, if a
component is 'sequential' the event is delivered synchronously. The framework
can detect this itself, the user should only worry about connecting a
callback function.

4. Macros for RTT interface definitions
In order to avoid typing work, we could simplify the
command/method/property/... definitions with some C macros.

5. Natural signal/slots with events and methods
If you have defined a Method m in A and an
Event e in B, why can't you write :
B.e.connect( &A.m, &A );
Which means, if event 'e' happens, call method 'm' (and also take into account
item 3 above).

6. Yes a GUI.
Components? Check. Browsable Interface? Check. Dynamically loadable?
Check. Remote connection? Check. GUI to do all this? Fail. I understand
people have difficulty contributing to the RTT, but any Java/C++ student can
write up an improved version of the taskbrowser or KTaskBrowser applications
which let you drag and drop an application and write out/read in the XML
file.

7. Clean up/improve commands interface/usage
They are useful in a number of cases, but quite complex to understand for the
beginner. Why is a completion condition mandatory ? What is the difference
with asynchronous events ? Can't a command be emulated with a 'command'
(A->B) event and a 'completed' (B->A) event ? How to react to a finished
command in a state machine script or C++ code without polling ? Commands try
to solve a real problem: execute and track actions that take time. The
question is if they could do it better/cleaner.

8. Clean up/improve state machine interface/usage
The state machine scripts in Orocos are to complex to write (entry, handle,
run, exit, transition, transitions, preconditions,... anyone?) and to
control. They should be as close to UML hierarchical statemachines (and they
are) quite in implementation) from a user perspective. Thus clear substate
definitions, OR and AND states, etc. UML statemachines are well defined and
universally readable, so why didn't we implement one ?

I'll stop at a holy number (for a Japanese, that is) for usability
improvements, but there remain implementation improvements as well:

1. Greatly simplify the ExecutionEngine (EE)
There is the EE and 4 processors (command, event, program, state), each having
one or more execution lists or queues. This can be simplified into one class
(the EE) with only one execution list (scripts, peers,...) and one execution
queue (commands, events). The current modularity is nice from a design
perspective, but burdens implementation and the user by exposing this
modularity.

2. real-time mallocs
Instead of pre-allocating lots of data for real-time communication, why don't
we use a bounded time rt-malloc implementation? Xenomai and RTAI provide one
already and a OS independent library is available [1]. One reason not to use
the rt-malloc is that concurrent access needs to be locked, hence, undoing
all the 'lock-free' effort. But for low-concurrent, small-memory
applications, it should be an option to have it the other way. A
lock-free-rt-malloc anyone ?

3. CORBA ExecutionAccess
A helper class not directly available when using a component over CORBA
Requires ExecutionAccessI and ExecutionAccessProxy classes.

4. CORBA Events
A TaskContext interface not available when using a component over CORBA

5. Improved Ports implementation
Hey...we already did that !

6. Reduced templates footprint
There are to many template functions doing the same/equivalent things for
commands, events, methods etc. Relying on a basic foundation and reusing that
in every primitive might greatly reduce footprint.

7. Reduced scripting footprint
2MB code (without symbols) for parsing such a simple language ? Why
Boost::Spirit? Why !?

8. Run general purpose components on any Linux RTOS flavor.
You need to recompile your component for each RTOS (Xenomai, RTAI, Linux,...)
We already got OS_AGNOSTIC and a clear fosi.h and fosi_internal.hpp. With
adding a few opaque pointers, the liborocos-rtt.so is RTOS independent and
the Linux users could switch between Linux RT kernels just by dynamically
linking with a different liborocos-rtt-os-target.so library. Would greatly
reduce development time on Linux platforms.

Let's say that's enough as well. Except, I didn't include any OCL roadmap yet
(which is actually more interesting to users). I can only say that OCL is at
the moment even more user-request driven. Have a good idea, and see people
jump on it, I'd say (which reminds of the unanswered JR3 question this week
[2]. I have never used/looked at that code.) I wonder which development model
would encourage people to submit components for the OCL. I know they are out
there, but everyone finds their component 'to ugly' to submit publicly....

As one guy said before, YMMV :-)
Peter

[1] http://rtportal.upv.es/rtmalloc/
[2] http://www.orocos.org/node/650

Orocos roadmap

On Fri, 25 Apr 2008, S Roderick wrote:

> One big thing I see missing from Orocos is a lack of a roadmap, or any kind
> of indication of future plans. I think what has been done to date with
> Orocos is fantastic, and I'm looking forward to putting Orocos to good use on
> a couple of robotics projects. I am simply very curious as to where the
> powers-to-be are thinking of taking things, and what level of effort can/will
> be applied in the near future?

We have been talking about roadmaps several times. But then found out that
(i) orocos has been designed to be a set of toolkits, with very many
possible applications for many different people, and hence a roadmap would
be so huge as to be practically useless;
(ii) we have no guarantee to have the funds to pay developers to realise
such roadmaps.

But these things aside, here is my personal roadmap, i.e. things that I am
actively trying to find people and funding for, but not in any particular
order of priority:
- Making Orocos RTT 2.0 fit within the Model-Driven Engineering approach,
such as developed by Eclipse based projects as Topcased.org and
OpenEmbedd.org
(I might have a PhD student on this topic in the near future; and I have
submitted two EU proposals in this direction...)
- Interfacing Orocos with graphical toolkits such as Blender (for 3D) or
CLAM (for 2D, data visualisation, graphical programming, etc.)
(I have master students looking at these things at the moment; seems
possible and exciting, but they are not good enough to do the development
themselves....)
- extending KDL to the best possible library in its sort. I have all ideas
and knowledge to make the code for any kind of robotic system, including
humanoids with N-arms and M-legs, but I "just" need a good programmer
to realise these ideas.
- dito for BFL.
- introducing a SCL (Systems & Control Library) containing control
algorithms, signal processing filters, etc.
(The group around Klas Nilsson at the Lund Technical University has
very good ideas and (preliminary) code in this direction, and we
would like to start cooperation in this domain.)
- Internally at our robotics group in Leuven, KDL is being used extensively
as the foundation for a very generic task specification framework, that
integrates instantaneous motion specification, with estimation and control.
(See J. De Schutter, T. De Laet, J. Rutgeerts, W. Decré R. Smits, E.
Aertbeliën, K. Claes, and H. Bruyninckx, "Constraint-based task
specification and estimation for sensor-based robot systems in the presence
of geometric uncertainty", International Journal of Robotics Research, vol.
26, no. 5, 2007, pp. 433-455.)
Ruben's PhD will bring more of this within reach for Orocos users.
- making sure Orocos can lead in standardization efforts, such as
www.robot-standards.org. I am actively involved as an external expert in
this project, but it doesn't go fast enough in my opinion :-)
The Orca project is also setting steps in this direction.

I am pretty sure Peter will have other wishes....

So what would _you_ like to see in the roadmap? :-)

Best regards,

Herman
-

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Orocos roadmap

> So what would _you_ like to see in the roadmap? :-)

I guess posing a question like "Roadmap?" should really be called
opening Pandora's Box!?! :-)

I can talk some to tactical level changes, but can't talk to strategy
much due to being a new user and not fully understanding the system
yet. Having said that, a few things you and Peter mentioend definitely
resonate with me.

> - extending KDL to the best possible library in its sort. I have all
> ideas

Definitely add alternative orientation representations (notably
quaternions).
Extend to deal with (as you said) serialized leg, body, arm concepts.
More online examples
Take DH parameters directly (original and modified). I don't know if
it currently does this?

> 6. Yes a GUI.

Most definitely. Providing adaptors/shims/framework-connections to
standard GUI toolkits would be very useful, as we all end up doing
this anyway when using a product like Orocos.

> - introducing a SCL (Systems & Control Library) containing control
> algorithms, signal processing filters, etc.

Yes.

> 1. Threads should *really* be an afterthought.

Yes, would definitely save some unnecessary typing ...

> 8. Clean up/improve state machine interface/usage

Definitely bring into line with UML, or note the differences and how
to deal with them.

Some larger scale additions I could see ...

a. Safety. Add some components that deal with safety in a couple of
standard ways. This can be as simple as watchdogs that hit the
existing Emergency Stop component, through to full implementations of
Safey Executives and redundant safety monitoring channels. If one of
my projects starts using Orocos, we'll have to do this anyway.

b. Port to Mac. Well, this leads to Peter's "8. Run general purpose
components on any Linux RTOS flavor.". Having a Orocos-RTT OS-agnostic
library, along with a tiny OS abstraction layer underneath would
simplify development and porting.

c. Make communication and remote control more independant from the
communication mechanism. What about use of say ICE instead of CORBA?
What about controlling over Firewire or 1553?

d. Extract the "OCL list" out of Peter ...

e. Be open and accepting of other people's developments (and I am
__not__ saying that you currently aren't!). This points at Peter's
comment of

> [2]. I have never used/looked at that code.) I wonder which
> development model
> would encourage people to submit components for the OCL. I know they
> are out
> there, but everyone finds their component 'to ugly' to submit
> publicly....

I think that the only thing you can do is to encourage people to
submit, and help them clean up their code if they do. And where you
have the ability, strong arm a few people to start the process and
then see if it gains momentum ... without this general principle,
Orocos will dwindle to a JALRCF (Just Another Lab's Robot Control
Framework). Sad sad sad .... why do we keep reinventing the wheel ...?
I have much better things to do than rounding metal into circles ...

HTH
S

>

Orocos roadmap

On Tue, 29 Apr 2008, Stephen Roderick wrote:

>> So what would _you_ like to see in the roadmap? :-)
>
> I guess posing a question like "Roadmap?" should really be called opening
> Pandora's Box!?! :-)

:-)

[...]
> c. Make communication and remote control more independant from the
> communication mechanism. What about use of say ICE instead of CORBA? What
> about controlling over Firewire or 1553?

I would strongly insist to keep communication middleware outside of Orocos!
(Peter doesn't want to listen, I am afraid...) Otherwise we will be dealing
only with communication code and everyone's favourite fieldbus or protocol...

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Orocos roadmap

On Tuesday 29 April 2008 14:46:17 Herman Bruyninckx wrote:
> On Tue, 29 Apr 2008, Stephen Roderick wrote:
> >> So what would _you_ like to see in the roadmap? :-)
> >
> > I guess posing a question like "Roadmap?" should really be called opening
> > Pandora's Box!?! :-)
> >
> :-)
>
> [...]
>
> > c. Make communication and remote control more independant from the
> > communication mechanism. What about use of say ICE instead of CORBA? What
> > about controlling over Firewire or 1553?
>
> I would strongly insist to keep communication middleware outside of Orocos!
> (Peter doesn't want to listen, I am afraid...) Otherwise we will be dealing
> only with communication code and everyone's favourite fieldbus or
> protocol...

I'm listening... but we have to manage opposing forces. One one hand, you have
efficiency and real-time, on the other hand transparant network distribution.
Orocos is this advanced that by default, the efficient, real-time
implementation is chosen for any object, and that if 'communication
middleware' is detected, a suitable implementation is attached. However this
adds considerable complexity to the implementation.

The CORBA protocol layer is completely opt-in. Any component can be 'raised'
to the CORBA level at run-time. The interface to the middleware layer is
completely CORBA independent (do a grep of 'CORBA' in rtt/src/* ), and you
can have ICE, sockets,... whatever implementation instead, without having to
recompile your component.

I guess that if I hadn't cared much about performance (or had known better?),
I would have used socket-based communication (Unix and TCP/IP) from the
start, because they are the basic foundations of middleware. Unix sockets
seem to be real-time btw.
If CORBA would have had a clean interface and be lean and small (like ICE!),
the RTT would have been written in CORBA completely. We considered that, and
our sister project, ORCA-Robotics, even tried it. Unfortunately, CORBA is
ugly and ICE would make the RTT completely GPL. For ORCA, the GPL was no
objection, and they moved from CORBA to ICE
(). ORCA had no 'strong' intentions to
design for real-time however and put networking up front.

There must be something better, but there isn't.

Peter

Orocos roadmap


[...]

c. Make communication and remote control more independant from the communication mechanism. What about use of say ICE instead of CORBA? What about controlling over Firewire or 1553?


I would strongly insist to keep communication middleware outside of Orocos!
(Peter doesn't want to listen, I am afraid...) Otherwise we will be dealing
only with communication code and everyone's favourite fieldbus or protocol...


That was what I was getting at. The ability to "plug-in" (*) your comm's protocol of choice, rather than spinning your own connection into Orocos. 


Similarly, you don't want to deal with everyone's personal choice of GUI and supporting that within Orocos. But having some "generalized GUI connection framework" that allows your average GUI to connect, makes Orocos more readily useable. To take it a step further, this is the same type of problem with making the OS abstraction layer - you are providing a generalized OS for the Orocos side of things, and then providing functionality to connect that abstract OS to the actual OS.

S

(*) Like it's ever that easy!

Orocos roadmap

On Tue, 29 Apr 2008, Stephen Roderick wrote:

>> [...]
>> > c. Make communication and remote control more independant from the
>> > communication mechanism. What about use of say ICE instead of CORBA? What
>> > about controlling over Firewire or 1553?
>>
>> I would strongly insist to keep communication middleware outside of Orocos!
>> (Peter doesn't want to listen, I am afraid...) Otherwise we will be dealing
>> only with communication code and everyone's favourite fieldbus or
>> protocol...
>
> That was what I was getting at. The ability to "plug-in" (*) your comm's
> protocol of choice, rather than spinning your own connection into Orocos.

So, Orocos' data ports and event support should be all you need for such
plug-ins... (Complemented by some state machine event handling for the more
tricky protocols.)

> Similarly, you don't want to deal with everyone's personal choice of GUI and
> supporting that within Orocos. But having some "generalized GUI connection
> framework" that allows your average GUI to connect, makes Orocos more readily
> useable.

The "reporting" and "command" interfaces are such generic GUI connectors...
But I think people really want more, even if this implies some sort of
lock-in into a GUI framework...

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm