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
(text/plain)