Re: Orocos meeting: hotel reservations

You mentioned that reporting is a problem. I agree to that. Although MRROC++
has not solved the problem completly it is not at all bad in that respect.
The system is divided into separate processes. Each process can be viewed as
a finate state automaton. Within each "state" of the automaton some actions
are performed that can lead to abnormal situations that have to be reported.
In that case an exception is thrown and subsequently caught at the uppermost
level (the automaton level). From there the report is sent to the System
Response Process (SRP) that visualises the message on the screen. Standard
status messages can also be sent to the SRP, but here you can do it from any
level of the process structure. After reportiing an error the automaton is
being reset to a state that it can handle new commands (dialogue with other
processes). It should be noted that after throwing an exception it can be
caught at some intermediate level and handled adequately. In that case the
exception does not reach the uppermost level, thus the remedied problems are
not reported - unless necessary. The programmer is free to either use the
general method or to override it with local remedies. I think that something
similar could be used within the OROCOS project. We can talk about that at
the meeting.
Cezary

----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Sent: Tuesday, October 22, 2002 10:40 PM
Subject: Re: [Orocos] Orocos meeting: hotel reservations


> On 22 Oct 2002 [email protected] wrote:
>
> [...]
> > > And there will be the source code, of course :-)
> >
> > Yippee. I was supposed to be releasing some robot code and Free hardware
that
> > runs on top of RTAI and makes your robot look (more) like part of
> > Unix. However, I'm not sure (a) of the level of interest, and (b) of
> > whether I can make it OROCOS-compatible. Is there any code more recent
> > than 0.0.2/0.1.0?
> >
> Not really in tarball form :-( But we are working very hard to release
> a version before the November meeting. Don't hold your breath though!
>
> This new version should be the first one which is really useable in a
> robotic system, but will still be missing important features.
>
> I am completely for an open development method, but I learned (a bit to
> my own surprise) that making a _coherent_ framework is very tough to
> do in a distributed, piece-wise, incremental way... All things are so
> terribly coupled, from a project management perspective, at least.
> _NOT_ from a software engineering perspective, because that sort of
> loose coupling is exactly one of our major design goals :-)
>
> An example? Reporting. How does one introduce a reporting system that
> works with every kind op object and component in the whole system?
> That can be reconfigured at run-time but is still efficient and hard
> to abuse. The coupling comes from the fact that all components  and
> objects must be ready to be reported. So accepting bits and pieces
> from various contriutors simply will not work, because they will lack
> the coherence of a "centrally engineered" design.
> (PS Reporting = collecting information about the current "state" of the
> framework's component, objects and the application, and send them to
> the user's ``outside world'').
>
> Another lesson (which I haven't learned because I was already aware of
> it before I started with the project) is that one gets tremendously
> few feedback and contributions at the early stages of a project.
> People only begin to bother or to think about suggestions once you can
> give them something concrete to play with. And I realise very well that
> we have not yet reached that state :-) That's also the reason why the
> external financing (by the EU and some companies) is very much
> appreciated, and very much a necessary condition, in order to bring a
> significant innovation in an open source fashion. (At least I hope
> Orocos will bring some innovation :-)
> The Bazaar only begins to work once there are enough shops there that
> people find interesting...
>
> The "innovations" we think the project brings (in the long term) are:
> - the "codel" approach to task execution and monitoring (existed in
>   LAAS already, but is now re-engineered and generalized to all levels
>   of the control).
> - the "software patterns" for robot control. Which is also generalised
>   to cover _all_ control and signal processing applications.
> - the high distributability and scalability. An important part of this
>   is achieved because source code is available. But an even more
>   important part (I think) comes from the design, that explicitly
>   contains lots of well-defined and documented "cut points" that are
>   natural candidates for distribution and/or scaling.
>   But also the software pattern is important: it proves that the whole
>   functionality can be configured to run in one single interrupt
>   routine or even without an operating system (if you like). And it
>   puts structure into the whole control design, which allows for lots of
>   efficiency optimizations without compromising flexibility. (The
>   event handling system is the basis of this efficiency, and of the
>   very small OS dependencies.)
> - loose coupling, as our holy grail of component and object design.
> - flexibility in motion/trajectory generation, allowing a decoupling
>   between setpoint generation ("feedforward") and setpoint control.
> - a kinematics and dynamics library, that covers _all_ possible lumped
>   parameters systems (also from non-mechanical domains), of any
>   topology and complexity.
> - a design that is ready to be encapsulated in a CORBA standard for
>   control.
>
> Hopefully these statements are sufficiently bold to generate some
> discussion on the mailinglist :-) And sufficiently stimulating also to
> invite people to attend the November meeting :-)
>
> Herman
>
> --
>   K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos