In the meeting today we talked about how objects are represented in the planning scene. This relates to the issue I'm trying to find a solution for (#1974) with subframes.

If the planning scene represented every object in the planning scene in a tree structure where an attached one was wrt the link it was attached to and unattached ones were wrt world it would make the code that calculates transforms to arbitrary objects clearer. Right now there is a bunch of confusing repeated code.

The current structure is based around optimizing allocating all the space needed for run-time fixed length arrays of transforms (robot_state) separately from run time dynamic lengths (collision objects). One way I see of combining these in a nice way would be to handle all memory allocation for planning scenes in a memory arena (protobuf has this feature implemented itself: https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.arena). Another thing it is called is a memory pool (boost library: https://valelab4.ucsf.edu/svn/3rdpartypublic/boost/libs/pool/doc/index.html). If we go this way I'd suggest we use the boost library. This would have the added benefit of allowing users to tune the tradeoff between memory allocation and run-time performance for their application and how much memory they expect to need for each planning_scene and how many they expect to need in a given program.

If we transitioned to a memory pool for allocation of the internal state of the planning scene we could have a simpler, more intuitive internal structure of it that would be easier to use.

@felixvd I think it was you that mentioned another library that had a nicer internal representation of the collision scene. Is that something you could post a link to?