Current state

The transformer information is currently local to the ruby script that started the system. It has two drawbacks:

  • starting a system using two scripts requires to have the exact same setup. Trivial for the transformer configuration itself, less trivial for things like port-to-frame associations.
  • The only part of Rock that requires the same information is vizkit. For this purpose, we created a "transformer broadcaster" task that gets started by Orocos.transformer.setup and is basically used solely as a way to store and expose the transformer information


The transformer broadcaster is obviously a single point of failure. Updating it in a distributed manner (think having multiple syskit engines / multiple ruby scripts starting a rock system) while ensuring consistency is very fragile. In addition, just making sure that it gets started only once *but* is teared down when nobody needs it is just plain difficult.

In summary: Rock is really a distributed system, and things like the transformer broadcaster are breaking that.


Matthias and I introduced a while back the orogen_metadata extension, which allows to store 'metadata' on a per-task or per-interface-object (port, property, ...) basis. This would be a very natural place to store the information that is currently stored in the transformer_broadcaster. It would ensure that anyone who want to use a running component would have the related transformer information (!). The only downside would be that vizkit would have to run an async trigger to discover all tasks and gather all the available transformer information from all of them


Two type of information needs to be stored:

  • a list of frame transformations (from:to) for RigidBodyState ports which provide a transformation
  • a list of frames for any other port

List of frames would be formatted as a comma-separated list of strings. A frame pair (for a frame transformation) would be from_name:to_name.

The metadata keys would be:

  • rock_transformer_transforms
  • rock_transformer_frames

Both the ruby scripting and syskit plugin would need to be modified to store the information in the metadata instead of storing it in the transformer_broadcaster

As mentioned, Vizkit would have to be modified. Note that given a certain data stream, what vizkit needs is to build the transform from an arbitrary frame in the world to the data stream's frame. We should therefore probably also store that information in the port's metadata. The simplest is to probably store the whole list of producers and static transformations in the task context's metadata directly.

Summary: added metadata

  • port metadata:
    • rock_transformer_transforms: list of transformations generated by this port as from_frame_name:to_frame_name[,from_frame_name:to_frame_name[,...]]
    • rock_transformer_frames: list of frames in which the data produced by this port is expressed as frame_name[,frame_name[,...]]
  • task context metadata
    • rock_transformer: the complete list of transformation producers and static transformations as a comma-separated list of:
      • static:(0;1;2);(3;4;5;6;7) where the first three values represent the translation and the last three the rotation (as a quaternion - order to be checked but should match the order in the transformer configuration file)
      • dyn:from:to:port_uri

This adds the (currently not existing) constraint that frame names should not contain commas and colons. I would straight go for constrainting them to \w+$ (i.e. alphanumeric, _ and /]. The slash will be needed as some point for the purpose of building a hierarchical frame namespace.

Last modified 7 years ago Last modified on 12/20/14 23:02:25