RVIZ transform mocap pose conflict

[knmcguire]

I noticed that when I got the pose logging enabled (to check if Mocap data was actually sent through to the Crazyflie), that the transform for Mocap (with rigid bodies) and Pose transform has the same name. MoCaps' rigid body names needs to be same as crazyflie.yaml in order for the motion capture package to interpret that to be the right rigidbody/ marker for the Crazyflie and it will make sense for the transform directly from the server to be the same name as well, but currently in RVIZ you'll see 'cf1' constantly swift between the MoCap contributed transform and the Pose logging contributed transform.

I would imagine that we would like to distinguish external positioning from the internal estimated positioning or... ? And if we want to change the naming, which transform name should we augment (or both?)

[whoenig]

One idea:

1. Use cfname in odom frame for the on-board data we get via logging
2. Use cfname in mocap frame for the transformation we get from the motion capture
3. Have some logic in the launch file that has a static transformation publisher world<->odom and/or world<->mocap (based on the operation mode).

I think the term mocap could refer to motion capture, lighthouse, or LPS. However, this might be confusing, in which case we could use eps (external positional system) or similar term to indicate that we talk about a common, external coordinate frame.

Any thoughts @knmcguire ? I think you are also more familiar in which cases odom is used, so your input would be super valuable here:-)

[knmcguire]

hi!

Yeah it is good to seperate them in transforms, but the problem is that usually visually, these transforms are very close to eachother.

That is a good question... we could use 'ext' or 'global', or 'gt' for ground truth. Odom would be used in terms of estimated position usually from non-global position estimates, like wheel odometry or flow, but as soon as the external position measurements come in, the estimated position and the position that is put in will be very much the same.

Let me try to think about this a bit and see how others do it.

[whoenig]

Did you have any more ideas @knmcguire ?

Another use-case to consider could be two CFs with flow decks attached and no external positioning system. Both will believe that they are initially at the same spot. Then, a transform to world_<cfname> might make sense, or odom_<cfname>, since we have to separate that each of them might have their own local world frame and the mapping of the local world frame to the global world frame might or might not be known.

Visualization in rviz will be tricky this way, since we would need static transforms for each world* to world...