This page contains a list of desired features and development directions for KDL future releases. Feel free to contribute your own, or comment --in favor or against-- existing ones.

Rely more on upstream projects for geometry and algebra computations.

KDL has rolled its own representations for data structures like rigid transformations, and algorithms like the SVD. Maybe some of these choices was justified back in the day when KDL was young, but I doubt the argument still holds for most of them. The benefits of transitioning to rely more on upstream projects (Eigen, in KDL's case) are twofold:

• Less code to maintain.
• By contributing improvements upstream, a larger community can use, test, and help maintain them.

There's also potential performance benefits from using algorithms written by experts in the field. Of course, before any such commitment, benchmarks should show that there is indeed no negative performance or rt-safe losses.

Allow more general data types.

KDL uses Eigen data structures for many (but not all) of its own data structures, but uses the very specific [Matrix|Vector]Xd typedefs. It would be benefitial if KDL should assume less about, and allow mixtures of:

• Floating-point representation.
• Matrix storage order (col- vs. row-major).
• Memory layout.

Eigen already offers this level of generality, so it would be a matter of taking the effort to "bubble-up" this generality to KDL's API. This would allow for performance gains and less data copying when integrating KDL with 3rd party code.

Redesign interface to solvers

The idea is to allow composability of reusable building blocks to create custom solvers without code duplication or API explosion.

It has been proposed to redesign solver APIs, and allow for data-flow programming. Exploit complementarity between object-oriented and component-based models. See this thread for more info.

This should be achieved imposing as little as possible of the used data flow implementation, as commiting to a specific data flow implementation might be a showstopper for some users.

Second order inverse kinematics

Create building blocks for second-order inverse kinematics (e.g., recursive, closed-form computation of the time derivative of a frame's Jacobian).

KDL-iTaSC

There have been arguments on the list regarding whether a certain functionality should live in KDL or in iTaSC. KDL should have the building blocks, and iTaSC is an example of how to use them. Currently the concerns between the two are not well separated, as there are functional blocks that do not fit well in either (see here for an example). Future versions of iTaSC might serve as a good use case to test proposed improvements.

Conformity between chains and trees

The functions you have on the one, should be a subset of the other. Of course, a chain has no ordering anymore, but there are still some inconsistencies:

• • chain: void addSegment (const Segment &segment)
  • tree: bool addSegment (const Segment &segment, const std::string &hook_name)=> why different return value?
• You can't get the segment name of a chain by name (while for a tree you can)
• ...

More general method name for IK calls

KDL's IK solvers were originally thought to solve for cartesian task spaces, hence the restrictively named CartToJnt() methods. Probably differential IK solvers should share a common infrastructure that deals with more general joint to task space maps (as defined by the Jacobian matrix). I propose the simple solve(), but I'm open to other suggestions.

Legacy code could still be supported by exposing today's solvers as wrappers around a more consistent API.