Annotation format / language

[Kynneb]

One of the main questions regards the format (language) of the annotations Possibilities include:

• yml: easy to read and parse especially in python
• json: language/platform independet, many parsers but a yet another format in addition to already used yml and xml
• xml: less easy to (human) read and parse, but still quite easy
• aadl: great for taste, bad for everything else

[Kynneb]

(Pseudo) Format could be:

<component>
  <requires from="camera" to="world" />
</component>

<component>
  <provides name="camera_fixture" from="robot_base" to="camera" type="static" default="[0,0,0,0,0,0]"/>
</component>

  <component>
    <provides name="odometry" from="world" to="robot_base" type="dynamic" default="0,0,0,0,0,0]"/>
  </component>  

[saarnold]

I would prefer XML, but would be ok with yml or json as well. I think the definition of a static and a dynamic transformation should be separated. A static transformation dosn't need a component and a dynamic dosn't need a default value. Also I'm not sure if we need to define required transformations, this should be identified when they are applied.

[Kynneb]

You are obviously right that static transformations would not be (neccessarily at least) bound to a component -> this would speak for a single global transformation modeling file which complements the files coming with each component.

In the case of esrocos the provision of required transformations would be neccessary as I see no other way to identify them. How would you do it in rock?

In my head a default starting / initial value makes sense for dynamic transformations as well - how would you separate them? Using different tags?

[saarnold]

How would you do it in rock?

In rock we could get the required transformation chains from the orogen definition and configured frames. But I'm not sure if this is intended.

In my head a default starting / initial value makes sense for dynamic transformations as well - how would you separate them? Using different tags?

I would use different tags yes. Default values for dynamic transformations sound potentially dangerous. For instance a GPS providing the position on the surface of the earth. A default value would probably provide a wrong initial guess.

[maltewi]

Ein weiterer Vorschlag:

component_1

<TransformationRequest>
  <ComponentReference>component1</ComponentReference> <!-- also allow port references here optionally -->
<!--
     * Given a source and target frame, this structure expresses the _frame
     * change_ between these two frames. In effect, it represents the state of
     * the source frame expressed in the target frame.
     *
     * Per [Rock's conventions](http://rock.opendfki.de/wiki/WikiStart/Standards), you
     * should use a X-forward, right handed coordinate system when assigning
     * frames to bodies (i.e.  X=forward, Y=left, Z=up). In addition,
     * world-fixed frames should be aligned to North (North-West-Up, aka NWU)
     *
     * For instance, if sourceFrame is "body" and targetFrame is "world", then
     * the RigidBodyState object is the state of body in the world frame
     * (usually, the world frame has an arbitrary origin and a North-West-Up
     * orientation).-->
  <Target>camera</Target>  <!-- Option 1 -->
  <Source>world</Source>

   <TransformationHeader target="odometry" expressed_in="world" />    <!-- Option 2 -->
</TransformationRequest>

component_2

<StaticTransformation name="id"> <!-- name is optional, will be auto-generated otherwise as e.g. from2to, if they are required at all -->
   <TransformationDefinition>
       <TransformationHeader target="odometry" expressed_in="world" /> 
       <PostitionVector x=0, y=0, z=0 />
       <Quaternion w=1, x=0, y=0, z=0/>  <!-- Optionally specify via quat or rpy -->
       <RPY r=0, p=0, y=0 />                     <!-- Optionally specify via quat or rpy -->
   </Transformation>
</StaticTransformation>

<GeneratedTransformation>
  <PortReference component_name="component_2", port_name="bla" />
  <TransformationHeader target="odometry" expressed_in="world" />   <!-- Option 4, obigen Varianten bei den Namen -->
</GeneratedTransform>