Hi Herman,

> KDL has already some of these, and more are coming. So, instead of starting
> yet another library, why not improve what KDL has already?
> We are now working on a hybrid dynamics solver, which goes a step further
> than the traditional Featherstone-based algorithms, in that partial
> acceleration constraints can be taken into account in linear time.

This would not be starting another library - the library already exists 
and is based on code that has been extensively tested. It's just not 
public yet because we wish to complete the contact modeling before its 
release. In fact, we have the full functionality of kinematic and dynamic 
solvers and the current expansion is simply adding LCP contact resolution 
which is to be completed in a few weeks. So, the real question is which 
library to extend?

I had followed KDL for some time and was intent on using it a while ago, 
however the dynamics solvers did not exist (or were not documented). Have 
they been tested and used in systems? The solvers in our library are based 
on code that has been tested for some time in computer animation and we 
anticipate equally reliable performance in robotics.

On another note, our library also has various extensions like 
compatibility with human motion capture data and algorithms for motion 
trajectory optimization - soon to be connected with motion planning.

Overall, I think this a great discussion topic for the SIG and probably 
that's exactly why these SIGs exist. You're welcome to join the SIG and we 
can work out the answers to these questions together!

> I hope that your vision on "integration" means that you keep the algorithms
> as separate and independent as possible, and try to find consensus on how

Absolutely! Personally, I'm very "tool" minded. In my ideal world there 
exists a common data structure (to get rid of data copying, heap 
allocation and other inefficiencies). The library encodes this data 
structure and provides functionality for basics like forward/inverse 
dynamic/kinematic solvers. The tools built on top of this are totally 
modular since they just link to the library and use it any way they like.

> to compose them. For example, adding collision information to a dynamics
> algorithm in order to do, for example, force or impedance control, should
> not be done by extending the dynamics algorithm with collision data
> structures, but via the external force or Cartesian (velocity,
> acceleration) constraints, in combination with a contact dynamics impedance

Exactly, so I would consider a force/impedance controller to be a tool 
that may benefit from the dynamics of the library or the collision 
checking library or neither or both. I see no reason to force the tools 
(algorithms) built on top of the basic solvers to be constrained in any 
particular way.

Herman - seriously, join the SIG and lets figure out the best way to do 
this!

Mike