Load trace.csv, navvis artifact.

[pablospe]

From: https://knowledge.navvis.com/docs/mapping-path

For every dataset, the file trace.csv contains position, orientation, and magnetic field information in frequent intervals. Example:

#nsecs,  x, y, z,  ori_w, ori_x, ori_y, ori_z,  mag_x, mag_y, mag_z
1478254247676381327, 8.84298e-07, 1.28572e-06, -0.2, 0.999992, 0.000376351, 0.00401342, 1.90039e-07,  -6.51576e-07, -3.18442e-06, -3.36381e-05
1478254247783401487, 0.00150315, 0.000978242, -0.2, 0.999992, 0.000330729, 0.00398468, -6.80018e-05,  -1.30323e-06, -3.18672e-06, -3.33109e-05

[mihaidusmanu]

Are we sure about the convetion used for this file? (i.e., rig to world vs world to rig). Should the trace "sensor" be added to the rig?

[mihaidusmanu]

Ah nevermind, just saw the documentation above (maybe worth adding that link to the parsing fo trace in the navvis class)

[pablospe]

yes, I need to re-iterate on this PR, I will mark it as draft for the moment, apologies. Thanks for noticing this.

[pablospe]

The conversion in this file was actually imu to world! I fixed it in the commits now. It should be ready for review again

[pablospe]

Should the trace "sensor" be added to the rig?

I was moving everything suck that the trace entry in the trajectory matches to the "navvis_rig" sensor (when we export as rig). So "trace" is the same as "navvis_rig" but I changed the name so we can filter it (the trace data are a lot of entries). I don't know if this is the best option, perhaps @MarioGini can comment here.

Maybe you are right in adding a new sensor to the rig. I can actually add all the cameras now since we read the sensor_frame.xml so I could create the rig based on this file, rather than faking it from the first frame (the rig now is defined in the cam0, calculated in the first frame).

[pablospe]

I fixed some issues with cam0 (upright problems and tile_id 0 is not actually identity, so I needed to apply this rotation only to the trace data, if I wanted to put in the same reference frame).

[pablospe]

This was merged without squash, I will revert and merged again to keep the git history short.

[sarlinpe]

Yes please! You could disable merge commits (I don't have permission to do so).

[pablospe]

The github button for reverting simply create a new PR reverting the changes, which won't remove the commits from history. I will have to probably do "hard reset" and then "force push" to remove from history from main. Any other alternative?

[sarlinpe]

You can squash the N commits introduced by the PR (with interactive rebase) and force push - you might need to temporarily disable the branch protection.

[pablospe]

Done.

Steps:

  1. # Remove the rules for the main protection (allowing temporally force pushes).
  2. git checkout main
  3. git merge --squash pablo/trace
  4. git commit -m "Load trace.csv, navvis artifact. (#58)"
  5. # Disable force push in main again.

[pablospe]

And final step, now we only "Allow squash merging".