Dear colleagues,

This message contains an updated proposal (with respect to the first
proposal, of July 23, 2008:
),
about the set of object classes and components that I think KDL needs to
have (in the long term) to achieve its goal of being able to represent, to
specify, to compute, to simulate and to control _all_ kinds of robotic
devices, in realtime if desired. The updates come from feedback on the
Orocos-dev mailinglist, and from my own further thinking. Of course, also
this updated proposal can still be discussed!

(Ruben will shortly post more information about concrete releases and
concrete new functionalities. This document is more about giving a somewhat
broader, long-term perspective spanning multiple releases.)

The updates with respect to the older version, are, in summary:
- Solvers need not _all_ be realtime safe; some are, some are not. This
property of a Solver should be clearly documented, and browsable at
runtime. The same holds for other Solver properties such as: "stop
anytime" capability; lack of argument checking to improve speed; etc.
- introduced the "interconnection structure" of a Chain as an explicit
class.
- more focus on desirable properties of Solvers etc, such as robustness,
numerical behaviour, etc.
- identified commonalities between KDL and BFL (Bayesian Filtering Library)
and the (not yet existing) SCL (Systems and Control Library), in order to
make the various Orocos projects easier to integrate and to understand.
- some more examples here and there.

The design considerations behind this design and development roadmap are:
- optimal decoupling: trying to design libraries that are as small as
possible and still create added value by itself.
- coping with the reality that different people/applications require
different mathematical and/or numerical representations, as well as
different algorithms to solve the same problems.
- restricted to lumped-parameter systems: KDL will be able to work with all
mechanical structures that consist of ideal rigid body links and joints,
coupled with localized stiffnesses and damping.
So, for example, no aerodynamics or hydrodynamics forces are considered,
or not continuous elasticity.
- serial, tree and graph structures will be supported.
- SOA: eventually, KDL should be able to be used in a "service oriented
architecture", where each "client" can request services with customized
quality of service. The most visible results of this requirement are that
(i) the "state" of a kinematic/dynamic system must be a class on its own
(allowing re-entrancy, thread-safety), and
(ii) KDL distinguishes between solvers, simulations and controllers, as
three semantically different kind of kinematics & dynamics algorithm
"services".

For all its classes, KDL will have two complementary APIs:

- Semantic: reflects the physics, so doesn't show mathematical
representation ("coordinates"), doesn't show the dimension of the
space (2D, 3D, 6D), and doesn't show the solver implementation.
Mostly used for symbolic preprocessing and during configuration,
deployment and online browsing.

- Mathematical:
- coordinate representations of physics (vector coordinates, matrix
coordinates, ...).
- offers transformations between mathematical representations:
- between coordinate reference frames.
- between physical units, e.g, radians - degrees, meters - inches, ...
- between coordinate representation choices (e.g., quaternions, Euler
angles, place of angular components vs linear components in 6D.
- between computer hardware representation choices: float, double, ...

So, here is a brief description of the suggested classes:

- Body ("Body" at semantic level, "Frame" at mathematical level):
- represents pose and instantaneous motion (velocity, acceleration) of
rigid body.
- represents forces on rigid body.
- represents physical force/motion mappings: Stiffness (position -
force), Damping (velocity -force), Inertia (acceleration - force).

- Chain:
- represents Joints and Segments, and their interconnections:
- a Segment is a Body with a number of named reference Frames (=
locations to place Joints).
- a Joint represents the (physical!) motion constraints between
Segments
- Joints are located at the named Frames of a Segment.
- the interconnection has specific structure (such as "serial", "tree",
"graph", or a more specific one), and can have one or more "iteration
schedules" (= _serial_ sequence according to which an algorithm
travels over the interconnection structure).
- depends on Body.

- (Chain)State:
- represents physical state of Chain: F, X, \dot{X}, \ddot{X},
\tau, q, \dot{q}, \ddot{q}.
- depends on Body and Chain.
- is kept separate from Chain, because Chain should be usable without
state information. For example: to use the Chain interconnection
structure for symbolic preprocessing of computations in a Solver; to
analyse topological properties of the Chain, such as movability
indices.

- (Instantaneous)Motion:
- represents (artificial, i.e., non-physical, "soft") instantaneous
constraints on a Chain, to make it move:
- desired motion of (virtual or real) joints in the Chain.
Often, this can be in the form of "no desired motion" in some
directions.
- desired forces on Segments or on Joint axes.
- (hence) introduces extra Chain and State objects with which to specify
the motion task.
- depends on Body, Chain and State.
- Reference:
De Schutter, J., De Laet, T., Rutgeerts, J., Decre, W., Smits, R.,
Aertbelien, E., Claes, K. and Bruyninckx, H.
Constraint-Based Task Specification and Estimation for Sensor-Based
Robot Systems in the Presence of Geometric Uncertainty.
The International Journal of Robotics Research, 26(5):433-455, 2007.

- Solver:
- transforms an in-State of a Chain into an out-State, taking into
account the desired Motion task.
- implements _one_ particular way of this transformation.
- defines a "computation serialization": an serial iteration over the
Chain structure, hooking code to each 'entry' and 'exit' of an
interconnection between Joint and Segment.
- depends on Body, Chain, State and Motion.

- Simulation:
- executes the iterations defined by a Solver in its computation
serialization.
- brings algorithms for time integration, more in particular to integrate
accelerations into velocities and velocities into positions.
- adds Events and FSM, for scheduling of (or, switching between) Solvers
- is an Orocos component: can be deployed, has an Activity, and (hence)
can be (re)configured on-line.
All previous classes only need Methods and Properties (including
their Configuration methods) but not an Activity.
- adds Commands (to support being used in a Service-Oriented Architecture).
- adds DataPorts (to support asynchronous interaction with "environment").
- can be implemented in all various types of Components as defined, for
example, in the CORBA Component Model.
- depends on Body, Chain, State, Motion and Solver.

- Controller:
- is a wrapper around one or more Simulators:
- it runs one or more Simulators inside itself.
- it adds interaction with the real world
(hardware, time, physical constraints).
Hence, it is an orocos application = it has _several_ components!
- adds extra control error states.
- a realtime Controller requires a realtime activity to run its
Simulator.
- depends on Simulator _only_: it doesn't have to know about what is
inside of the Simulator that it connects to the real world.

Since we want to use Controllers in realtime now and them, the code inside
their Solvers and Simulators should be "realtime safe". Simply put: they
should have no dynamic memory allocation, but rather allocate all temporary
variables before they enter their realtime domain. Non-realtime safe
solvers are allowed, but this property should be clearly documented, and
browsable at runtime.

The graph of the kinematic chain is available as a graph in the semantic
API of a Chain; in the mathematical API, this structure is not available
separately, since it is encoded into the interconnections of Segments, and
in the iteration with which a Solver runs over the chain.

Orocos contributions should address the following desired properties of
Solvers, Simulator and Controllers:
- robustness ("stability"): how does code react under specified failure modes?
- stop anytime: can an algorithm provide a feasible solution at any time
its clients want an answer?
- autonomy: (this is a property of Components, not of algorithms) Can a
component survive even if one or more of the other Components it works
with break down?
All the properties should be accessible in computer-readable form in the
semantic APIs, e.g., as RDF or OWL constraints, or in a way similar to what
the RTT TaskBrowser allows now.

Robustness has a different meaning for Solver, Simulator and Controller.
Solver robustness:
-robustness against numerical failures: representation singularities,
numerical conditioning, lack of convergence, checking of input arguments,
...
- instrumentation support for timing and debugging (should be configurable
out at compile time, or at runtime via Properties).
- States should remain within specified bounds.
A Solver does not need "FSM" to do its error handling in a
synchronous way, i.e., synchronized with its own code. All Solvers should
have a definition of what safe and acceptable States are. They should make
Properties available via which the failure modes can be inspected.

Simulator robustness:
- time integration failures:
- transition dynamics problems when going from one Solver to another.
A Simulator can have an "synchronous FSM" to do error handling in
an synchronous way with its own code

Controller robustness:
- robustness against failure of the other Components that the Controller
has to work with.
A Controller can have an "asynchronous FSM" to do error handling, i.e., it
fires (handles) events to (from) other Components to inform them (be
informed) about occuring errors.

Commonalities with BFL (Bayesian Filtering Library) and (the not yet
existing) SCL (Systems and Control Library):
- State, Solver, Simulation and Controller: come back unchanged in
Bayesian networks and control loops.
- interconnectivity structures also are the basis for "computation
serialization".
- the Body, Segment, Joint, and Motion classes do not appear in BFL or SCL,
since they are KDL specific. They are replaced by:
- BFL: Probability Density Function, Node, Arrow, Query respectively,
and with Bayes rule, marginalization, ... as the major algorithms in a
Solver.
- SCL: Constitutive Relationship, Node, Bond, Artificial Constraints
respectively, and with state integration as major algorithm in a Solver.

I would like to ask you again to comment on how well or bad this "roadmap"
fits with yours, and where your priorities lie. We also have to define what
the minimum set of properties are that we expect from code contributions.
For example: algorithms should already use the Chain, Solver and State
classes; each Solver should have Properties; ...

Herman