On Wednesday 23 July 2008 15:43:40 Herman Bruyninckx wrote:
> For all its classes, KDL will have two complementary APIs:
> - Semantic: reflects the physics, so doesn't show mathematical
> representation ("coordinates"), and doesn't show the dimension of the
> space (2D, 3D, 6D). Mostly used for symbolic preprocessing and during
> configuration and deployment.
> - 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, ...

Off all things, this is a burden and PITA. Choose double, it has been shown
before that float is in the end numerically insufficient. IF someone really
needs float for a deeply embedded device, he can just compile the library
with #define double float and have the burden of maintaining this
implementation. Trust me on this, It won't be 1% of your users. Even embedded
devices tend to grow larger every year.

[...]
>
> Since we want to use Solvers in realtime now and them, all algorithms
> should be "realtime safe". Simply put: no dynamic memory allocation! Even
> simpler put: allocate all temporary variables before you call a solver.

See my previous mail about this. If you disallow malloc, you'll be throwing
away most algorithms used today. You can allow mallocs as long as they are
not a fundamental part of your library and just the property of a specific
implementation.

For the rest of the proposal, I can actually understand most of it and I find
the names well chosen. It has clearly potential.

Peter

I agree with the proposed set of object classes as I think it will make the
addition of new features - dynamics, controllers etc. cleaner.

I'm willing to re-factor my implementation of inverse dynamics that I had sent
in an earlier email (based on iterative newton euler as presented in the book
Robot Modeling and Control by Spong, Hutchinson and Vidyasagra) to both
make it real-time safe and fit with the proposed structure.

I also think it would be nice to see the proposal as actual C++ header files as
this would expose some of the finer details, such as how exactly joint
limits and
other constraints will be handled.

Advait

--
Willow Garage Inc.
(http://www.willowgarage.com)

On Wed, Jul 23, 2008 at 6:43 AM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> Dear KDL friends,
>
> This message contains a _proposal_ (that can be discussed!) about the
> set of object classes that I think KDL needs to have (in the medium 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. I know that this proposal is not yet "perfect", so please be
> critical and creative in your reactions! :-)
>
> The design considerations behind this suggestion are:
> - optimal decoupling: trying to design libraries that are as small as
> possible and still create added value.
> - 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.
> - 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.
> - 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,
> 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"), and doesn't show the dimension of the
> space (2D, 3D, 6D). Mostly used for symbolic preprocessing and during
> configuration and deployment.
> - 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:
> - 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.
> - 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 useable without
> state information.
>
> - (Instantaneous)Motion:
> - represents (artificial!) instantaneous constraints on a Chain, to make it
> move.
> - specifies motion by adding virtual "joints" to a physical
> Chain and to specify desired motions of those joints.
> - (hence) introduces extra Chain and State objects with which to specify
> the motion task.
> - depends on Body, Chain and State.
>
> - Solver:
> - transforms an in-State of a Chain into an out-State, taking into
> account the desired Motion task.
> - depends on Body, Chain, State and Motion.
>
> - Simulation:
> - adds time integration.
> - adds Events and FSM, for scheduling of (or, switching between) Solvers
> (all previous classes only need Methods and Properties, including
> their Configuration methods).
> - depends on Body, Chain, State, Motion and Solver.
>
> - Controller:
> - is a special case of Solver (an interactive one)
> - adds extra control error states.
> - adds Commands (to support Service-Oriented Architecture).
> - adds DataPorts (to support asynchronous interaction with "environment").
> - (hence) adds Activity to a Simulation.
> - can be implemented in all various types of Components as defined, for
> example, in the CORBA Component Model.
> - a realtime Controller is requiress realtime activity to schedule its
> Solver computations.
>
> Since we want to use Solvers in realtime now and them, all algorithms
> should be "realtime safe". Simply put: no dynamic memory allocation! Even
> simpler put: allocate all temporary variables before you call a solver.
>
> So, please comment on how well or bad this "roadmap" fits with yours, and
> where your priorities lie. Roughly said, we will prefer to cooperate on
> contributions that fit into this roadmap :-)
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>