On Wed, Aug 26, 2009 at 7:19 PM, Wim Meeussen<meeussen [..] ...> wrote:
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=700
>
>           Summary: Walking through a Tree is too hard
>           Product: KDL
>           Version: kdl-trunk
>          Platform: All
>        OS/Version: All
>            Status: NEW
>          Severity: enhancement
>          Priority: P3
>         Component: Kinematic chains
>        AssignedTo: orocos-dev [..] ...
>        ReportedBy: meeussen [..] ...
>                CC: orocos-dev [..] ...
>   Estimated Hours: 0.0
>
>
> I was writing documentation on how to access the elements in a KDL Tree, and
> found it much harder than is should be. Right now, a Tree is formed by
> TreeElements. Each TreeElement refers to its children, by means of iterators to
> map<string, TreeElement>. This means, when you e.g. want to get Segment the
> first child of a segment, your code looks something like this:
>
> my_tree_element_it->second.children[0]->second.segment
>
> And getting to the name of a Segment can be done in two ways:
>
> my_tree_element_it->first
> or
> my_tree_element_it->second.segment.getName()
>
>
>
> The map container was chosen in the past because a Segment did not contain its
> own name. But since that has changed, we can actually get rid of the map, and
> make walking through a tree much easier.

I do not agree, the map as a representation was not only chosen
because of the lack of a name attribute in the segment class but also
because of its very efficient way of finding an arbitrary element in
the map. This is used for the forward position solver of the tree.

> Accessing the first child of a segment
> could look like this:
>
> my_tree_element.children[0].segment
>
> and getting the name of a segment can only be done in one way:
>
> my_tree_element.segment.getName()
>
>
>
> I can write a patch to do this, but then again this would not be backwards
> compatible. So before starting to code, I wanted to see what other people think
> about this.

Maybe we can add helper functions for Tree traversal instead of
changing the internal representation of the TreeElement?

The only internal change I'm willing to accept is the change to a real
graph representation (like boost::graph), so we could recycle
graph-traversal/search algorithms. That however would really be KDL
2.0 stuff.

Ruben