Components Generated by Maintainer Scripts

This section records dataset components that are effectively part of the dataset according to the maintainers’ papers and/or repos but need to be generated from the downloaded data using maintainer scripts. All such generated data is in the retained run artifacts of the maintainer-script regeneration. The wrappers used to generate the data are the maintainer-script wrapper code.

Note that we only generate dataset components using maintainer-provided scripts when it would introduce something that is not already present, at least in a functionally equivalent form, in the dataset download.

This is why you will not see Kalibr outputs promoted here or among the regenerated maintainer-script results: the download already ships camera_calibration_klu1.yaml, camera_calibration_klu2.yaml, and camera_calibration_mars.yaml under insane_sensor_calib_preprocessed/, with the nav and stereo camera intrinsics/extrinsics.

The one real exception is timeshift_cam_imu: it ships only for the Mars nav-camera raw bundle, not for klu1/klu2 nav-cam or stereo.

The regeneration still leaves Kalibr out because this page is focused on the maintainer-side transition marker workflow and its directly relevant derived products.

The promoted results currently comprise the transition marker chain only:

• transition_1..3/tag_detections.bag:
  • detection-only fiducial exports generated by run_transition_marker_pipeline.sh, which rebuilds a nav-camera ROS bag from nav_cam_timestamps.csv plus img/*.png, then runs the maintainers’ csv2bag.py and a thin compatibility wrapper around export_tag_data.py.
  • export_tag_data.py detects ArUco tags on undistorted nav-camera images and estimates poses per tag with cv.aruco.estimatePoseSingleMarkers(..., zeroDistCoeffs); it is not a board-level solvePnP export path.
  • The script writes /marker_detections only when a frame has at least one known-size tag pose, so these bags are not one-message-per-nav-frame products: within each bag’s own time span they omit 317 / 532 / 580 raw nav-camera frames on transition_1 / 2 / 3.
  • Across the full nav-camera frame counts of 4348 / 4525 / 3468 on transition_1 / 2 / 3, the bags carry 748 / 795 / 1132 /marker_detections messages, so the detection stream is the per-run count of marker-based camera poses available through the transition field.
  • They are the public detection stream the download itself does not ship, and they are the entry point for marker-based transition-ground-truth work.
• transition_1..3/tag_calibration.mat:
  • per-run tag-field calibration generated from tag_detections.bag by generate_tag_calibration_public.m, which calls the maintainers’ tag-calibration functions without the plotting shell in calibrate_tags_from_bag.m.
  • the calibration method (generate_tag_calibration.m) is graph pose-averaging, not bundle adjustment: per-frame pairwise inter-tag transforms are accumulated, 1σ-outlier-rejected, and reduced to a per-pair geometric-median translation and mean quaternion; every tag is then placed by shortest-path chaining over the undirected detection graph anchored at main_tag_id = 102. It carries no covariance and treats all tags uniformly (no edge-marker weighting). The shipped code uses a single shortest path (num_transform_paths = 1), where the paper §3.2.6 prose describes multiple randomized paths averaged by geometric median.
  • The maintainers describe a dedicated calibration recording for one static transition marker field; the promoted files are not that single dedicated-sequence artifact, but alternate per-run estimates of the same static field reconstructed from each transition flight’s own detections.
  • They are still the absolute marker-field maps that turn detections into positions in a tag-world frame.
  • All three promoted files use main_tag_id = 102, the 0.5 m tag on board 8, and save sparse (102,107) tag_calibration_trans / tag_calibration_pose cell arrays populated only along the main_tag_id row.
  • Because the three files reconstruct the same physical field from independent flights, their estimates disagree at the noise floor of that reconstruction, not because the rig moved.
  • Reconstructing each board’s local reference tag (gen_tag_board_calib local main, tag ids 2 / 17 / 32 / 47 / 62 / 77 / 88 / 99) in the shared main_tag_id = 102 frame and comparing across the three maps gives board-to-board pose disagreements of median 5.2 cm / 3.1° and up to 35.8 cm / 7.4° (worst on boards 6 and 7); the full-field per-tag spread is median 5.8 cm / 2.6°, p90 17.5 cm / 5.9°.
  • This is estimate quality, not a changed setup: the mocap tag_board_8 rigid body shows the physical board fixed across transition_1/2/3 to 0.6 mm / 0.04° (Motion Capture).
  • Treat the three tag_calibration.mat files as interchangeable few-centimetre estimates of one static field, not as three physical layouts and not as a millimetre-accurate map.
• transition_1..3/tag_trajectory.mat:
  • per-run marker trajectory generated from tag_detections.bag plus tag_calibration.mat by generate_tag_trajectory_public.m, which calls the maintainers’ tags_to_trajectory path.
  • This is the per-detection-message camera trajectory through the transition marker field and the load-bearing marker-based pose lane for transition-ground-truth work.
  • cam_tag_traj.position is the camera position in the tag-world frame, and cam_tag_traj.orientation is stored as quaternion [q_w, q_x, q_y, q_z] because the maintainer Quaternion.double writes [s vx vy vz].
  • Its timestamps match tag_detections.bag exactly.
  • The maintainer trajectory path explicitly skips tag_id == 0, so tag-0 detections (125 / 195 / 166 messages on transition_1 / 2 / 3) never contribute to the saved trajectory or calibration map.

The maintainers’ continuous transition ground truth is assembled by aligning the outdoor GNSS+magnetometer trajectory to the fiducial-marker trajectory (the indoor mocap and the marker-based pose already share the mocap frame, since the main marker board is a tracked mocap object). Because accurate RTK becomes sparse toward the entrance, GNSS data from multiple building-entry approaches feed the alignment, and the final outdoor-to-marker registration is a least-squares solution to Wahba’s problem (paper §5.4). Sensor time alignment upstream of it is GNSS-to-GNSS by velocity cross-correlation and magnetometer-to-GNSS by horizontal-projection yaw-rate (§5.3).

The maintainer-script tooling also contains a public-data path for alternative stitched transition outputs:

• estimate_public_pximu_mv.m reconstructs the IMU-to-mocap extrinsic that data_stitching.m consumes but the published YAMLs do not ship.
• run_transition_stitching_public.sh stages matlab_sensor_data.mat, sensor_calibration.m, settings.yaml, tag_calibration.mat, tag_trajectory.mat, and outdoor_ground_truth_data.mat into the hard-coded /tmp paths expected by the maintainers’ stitcher, then runs data_stitching.m.
• This path can generate a new transition_gt.mat and a new time_info_aligned.yaml, and it can also re-derive alternative transition_gt_in_gps.csv and transition_gt_in_moap.csv files from public data.
• The two transition GT CSVs already ship in each transition run’s ground_truth/ directory.
• The stitcher also declares a transition_gt_in_tag.csv filename but does not write such a file, and no shipped transition ground_truth/ directory contains one.
• Those stitched outputs are not promoted into the results yet because the alignment-window and cut-time inputs are run-chosen values, not fixed dataset constants.

Regenerating the Marker Chain

The transition marker chain regenerates from the public nav-camera PNGs:

1. rebuild a nav-camera ROS bag from nav_cam_timestamps.csv + img/*.png
2. run the maintainers’ csv2bag.py
3. then their export_tag_data.py (ArUco detection on undistorted nav images, main_tag_id = 102) to write tag_detections.bag
4. and the maintainers’ tag-calibration and tags_to_trajectory paths to write tag_calibration.mat and tag_trajectory.mat

The promoted products persist among the retained run artifacts of the maintainer-script regeneration.

The alternative full-transition stitching path (data_stitching.m) needs run-chosen alignment-window and cut times and is not promoted.