[ros-users] Fuerte SIG 2.10: Efficient Simulation/Control of Articulated Robots

[Herman Bruyninckx]

On Wed, 14 Sep 2011, Mike Stilman wrote:

> 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?

Indeed. But rather, it is not about "extending", but integrating two (or
more) different sets of functionalities.

> 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 you ever asked about it? Or made suggestions? That's how open source
projects work :-)

I react to your posting, and the same thing could/should happen for you
with things KDL might or might not provide in the future.

> 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.

If you have unit test cases, and want to share them with others, that
would be a nice contribution to the community.

> 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.

These are _integration_ issues, which should not be done by extending one
single library. Otherwise, we end up where we have ended up for decades
already: huge monolithic libraries that are not interoperable.

> 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.

I'm looking forward to these things. Within KDL we are now trying to use
Collada the standard data format to represent kinematic chains. (And to
couple it to other functionalities such as controllers.)

>> 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.

Agreed!

> Herman - seriously, join the SIG and lets figure out the best way to do
> this!
What does "join the SIG means"? Yet another mailinglist?

> Mike

Herman