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

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