15. Frequently Asked Questions (FAQ)

Applies to: Odin1 Companion software: ROS Driver, MindCloud Studio Version: v0.1.0 · 2026.05

Bag recording best practice: before recording a ROS 2 bag, use a QoS override to minimize packet loss. Usage:

ros2 bag record /odin1/cloud_raw /odin1/imu /odin1/image/compressed --qos-profile-overrides-path rosbag2_qos.yaml

Download rosbag2_qos.yaml

1. Hardware and Power

❓ Q1.1 What is the standard adapter spec, and why is using the specified power so strongly required?

Answer:

Recommended: a 12 V / 2 A adapter.
Risk: input voltage above 26 V will directly burn the internal DC chip — even 26.8 V is enough to destroy it.
Recommendation: before powering the device, verify the supply model, output range, and peak voltage with the vendor; never use unofficial power cables. If the cable you receive has any exposed bare wire, wrap the bare sections with insulating tape before use.

❓ Q1.2 The red LED is off / the device will not power on. What should I do?

Answer:

Common causes: reversed polarity on the power lines; bad contact on the aviation plug; intermittent failures after repeated plugging/unplugging.
On-site procedure:
1. Use a multimeter to verify the supply matches DC 12 V / 2 A (within 9–24 V).
2. Disconnect and re-seat the aviation plug, confirm it is locked, and gently rock it left and right while watching for the red LED.
3. Further diagnosis: switch the multimeter to the diode/voltage drop range; connect the black probe to GND and touch the red probe to the SYNC and GPIO pins (see the wiki for pinout). Read the voltage drop:
  - Normal: SYNC ≈ 0.9 V, GPIO ≈ 1.3 V.
  - Faulty: below 0.6 V, or no reading at all, indicates the chip is internally damaged. Please contact after-sales support.

❓ Q1.3 No data after connecting Odin1 to the PC and running the driver

Answer:

Check that the device is powered (the red LED should be solid).
Run lsusb to check enumeration; the Odin USB ID is 2207:0019.
Check whether /etc/udev/rules.d/99-odin1.rules exists; create it if missing, or verify its content if it does.
Reload udev: sudo udevadm control --reload-rules && sudo udevadm trigger.
Inspect the driver logs for any “version too low” message; if present, update the firmware. See Firmware Upgrade.
If the device used to work but now logs start listening usb event, further connection should be handleed by hotplug_callback, a previous driver node is still running in the background. Kill it, replug the USB cable, and restart the driver. Always send SIGINT / SIGTERM (never kill -9) so the driver can release the USB interface — see Q2.7. Otherwise the next start will fail with LIBUSB_ERROR_BUSY.

❓ Q1.4 What cables and aviation connectors are recommended?

Answer:

We provide a native USB 3.0 data cable and a waterproof aviation power cable.
A 90° right-angle aviation plug is not currently offered.
For very compact installations, custom options are available: ① drop the waterproofing and route the power cable straight out through the back panel with sealant; ② custom right-angle/length cables (contact sales).

2. USB and Connection Stability

❓ Q2.1 USB keeps reporting `heartBeat timeout` / `waiting for device connecting`, or requires a power cycle to recover?

Answer: Recommended troubleshooting order:

USB hub load: avoid sharing a single USB 2.0 hub between Odin and several high-bandwidth devices. Give Odin1 its own bus, or power Odin on last during system startup so that the handshake is more stable.
Driver version: upgrade to the latest ROS Driver (v0.10.5 or later).
Relocalization map config: verify the map file path and that the map matches the algorithm version — i.e. captured with the latest driver or processed by the latest MindCloud.
Host CPU: weak edge platforms (such as some compute boxes) running CPU-saturated workloads will drop heartbeat frames. Reserve some CPU headroom.

❓ Q2.2 After a heartbeat timeout, USB drops from 3.2 down to 2.0 / 2.1?

Answer: Typical causes:

Hardware fault on a single LiDAR (swapping cables doesn’t help, but swapping the device does → almost always device hardware fault, return for service).
Host USB controller fallback (some platforms enable USB compatibility mode).

What to do: cross-check on a different host first; if the second host works, it is likely an issue with the dev board you were using.

❓ Q2.3 Firmware upgrade fails with `LIBUSB_ERROR_NO_MEM`, or stalls past 90%?

Answer:

Perform the upgrade on a PC connected directly — do not run it on the robot host.
Avoid other high-bandwidth USB devices on the same host bus during the upgrade; check with lsusb.
Retrying once or twice usually succeeds.

❓ Q2.4 `lsusb` does not show the device, or the red LED is on but nothing enumerates?

Answer: Most cases trace back to power or hardware issues (commonly correlated with unofficial power cables). Follow Q1.2 to diagnose the supply; if local steps cannot recover the device, RMA it.

❓ Q2.5 Driver fails to start when multiple OpenCV / libusb versions are present?

Answer:

Symptom: [host sdk sample-2] process has died [pid 6487, exit code -11 ......]; disabling sendrgb allows it to start.
OpenCV: ROS 1 systems with both 4.2 and 4.5 installed sometimes conflict. Force-install a single version per the README, or isolate via Docker.
libusb: as a workaround, adjust LD_LIBRARY_PATH so the system-compatible version is loaded first.

❓ Q2.6 RTK cannot achieve fix when used together with Odin1?

Answer:

USB 3.0 emits broadband EMI that includes noise near the GNSS L1 band (1575.42 MHz).
Recommendation: downgrade to USB 2.0, or use a better-shielded cable.

❓ Q2.7 Driver fails to start with `failed to claim interface 0: LIBUSB_ERROR_BUSY` / message `further connection should be handled by hotplug_callback`?

Answer: This is caused by a leftover driver node from the previous run still holding the USB interface, typically when the driver is restarted via a script or when the previous process was killed with kill -9.

1. Root cause: you must use `SIGINT`, never `kill -9`

The driver’s main process host_sdk_sample only registers a cleanup handler for SIGINT(2) and SIGTERM(15) (close device, release the libusb interface, DeInit lidar):

// host_sdk_sample.cpp
static void signal_handler(int signum) {
    if (signum == SIGINT || signum == SIGTERM) {
        // Close device  → release USB interface
        // Deinitializing lidar system
    }
}
signal(SIGINT, signal_handler);
signal(SIGTERM, signal_handler);

kill -9 PID (SIGKILL) cannot be caught: the process is force-killed and the USB interface is never released → the next start fails with LIBUSB_ERROR_BUSY.
kill -2 PID (SIGINT) is equivalent to Ctrl+C on the terminal: it runs the cleanup path and releases USB cleanly.
kill -15 PID (SIGTERM) behaves the same way.

2. Manual cleanup commands

# Send SIGINT by process name (recommended — no need to look up PIDs)
pkill -SIGINT -f host_sdk_sample

# Equivalent forms
pkill -2 -f host_sdk_sample
killall -SIGINT host_sdk_sample

-f matches the full command line. host_sdk_sample is the main executable launched by the launch file and the node that actually holds the USB handle.

3. Recommended cleanup snippet for your launch script

Insert this before ros2 launch ...:

#!/bin/bash

# === Gracefully clean up leftover nodes before starting (key: SIGINT first to release USB) ===
cleanup_old() {
    local procs=(
        host_sdk_sample
        pcd2depth_ros2_node
        cloud_reprojection_ros2_node
        image_overlay_node
    )

    # Step 1: send SIGINT (= Ctrl+C) to trigger signal_handler and release USB
    for p in "${procs[@]}"; do
        pkill -SIGINT -f "$p" 2>/dev/null
    done

    # Step 2: wait up to 5 seconds for the processes to exit cleanly
    for i in {1..10}; do
        if ! pgrep -f host_sdk_sample >/dev/null; then
            break
        fi
        sleep 0.5
    done

    # Step 3: fallback — if it still hangs, send SIGTERM, then SIGKILL as a last resort
    if pgrep -f host_sdk_sample >/dev/null; then
        echo "Process did not exit within 5s, sending SIGTERM..."
        for p in "${procs[@]}"; do pkill -SIGTERM -f "$p" 2>/dev/null; done
        sleep 2
    fi
    if pgrep -f host_sdk_sample >/dev/null; then
        echo "Still alive — forcing SIGKILL (USB may remain busy, replug required)"
        for p in "${procs[@]}"; do pkill -SIGKILL -f "$p" 2>/dev/null; done
    fi
}

cleanup_old

# === Then start normally ===
source /opt/ros/humble/setup.bash
source ~/odin_ws/install/setup.bash
ros2 launch odin_ros_driver odin1_ros2.launch.py

Key points:

SIGINT → wait → SIGKILL, in that order — do not skip ahead.
The sleep is required: close device and DeInit are not instantaneous.
host_sdk_sample is the critical one; cleaning up the other launch-mate nodes prevents node-name conflicts.
Do not start with pkill -9 — doing so will inevitably leave you with a LIBUSB_ERROR_BUSY to recover from.

4. Fallback: recovering when the USB is held by a force-killed process

# Option A: reset the USB device directly (no need to unplug)
sudo usbreset 2207:0019
# Or: sudo usbreset /dev/bus/usb/<bus>/<device>

# Option B: physically unplug and replug the Odin1 USB cable

With the script above in place, failed to claim interface 0: LIBUSB_ERROR_BUSY should essentially stop occurring.

3. ROS Driver Errors

❓ Q3.1 The ROS driver fails to obtain calibration parameters

Answer: Symptoms:

calib.yaml is not generated in the config folder.
cloud_slam appears black, and odometry diverges easily.

Resolution: contact MANIFOLD after-sales support and request the parameter re-write tool. If the device worked before, you can reuse the calibration file from the previous driver instance. If you have no copy, contact after-sales support to look up the factory calibration record.

❓ Q3.2 How do I check the current firmware and driver version?

Answer: Run the driver and look at the terminal — both firmware and driver versions are printed at startup.

❓ Q3.3 In relocalization mode the driver reports `file start fail. transfer relocalizaiton map fail. please retry.`, the stream crashes, or the process memory is saturated?

Answer:

Typical symptom: the terminal repeatedly prints file start fail. transfer relocalizaiton map fail. please retry.; retrying does not help and the driver process eventually consumes all available memory.
Root cause: in older drivers, opening the stream in relocalization mode could trigger a deinit. Calling deinit and then opening the stream again is known to leak memory. Two situations trigger deinit:
1. Wrong map file path (most common) — the path does not exist, is not readable, or is not a valid Odin1 map.
2. Map upload fails three consecutive times — usually caused by an unstable USB link or a saturated host CPU.
Fix:
1. Upgrade to the latest ROS Driver (v0.11.0) and firmware 0.12.0.
2. Check the absolute path of the map in the launch parameters and ensure the file is readable and matches the algorithm version.
3. If the upload still fails, follow Q2.1 to diagnose USB hubs / custom cables / host CPU, and ensure no other high-bandwidth device is sharing the bus during the upload.

❓ Q3.4 Does the algorithm have a reset feature, and how do I use it?

Answer: Use a Driver newer than 0.10.0. The recommended combination is Driver 0.10.5 + firmware 0.11.9:

cd $ROS_WORKSPACE/src/odin_ros_driver
./set_param.sh algo_reset 1

Companion features in this version: IMU smoothed publishing (up to 400 Hz), PTP smoothing, dual-image overlay visualization, and a fix for inaccurate reprojection.

❓ Q3.5 The driver reports `the queue is full`?

Answer:

Cause: the SDK’s internal publishing rate is lower than its enqueue rate, causing a backlog overflow. Common when local resources are contended or network bandwidth is insufficient.
Fixes:
1. Give Odin1 a dedicated data link; avoid shared networks.
2. Use ROS_DOMAIN_ID to isolate communication domains and reduce unrelated broadcasts.
3. Make sure publisher and subscriber QoS match (reliable / sensor_data / best_effort mismatches will block).
4. Disable unused topics (e.g. sendrgb: 0, sendcloudrender: 0).
5. Prefer low-bandwidth topics, e.g. /odin1/image/compressed instead of /odin1/image.

4. Time Synchronization and Latency

❓ Q4.1 Is it a bug that the Odin time lags behind the host time?

Answer: Yes, this existed in early versions. It was fixed in the 0.11.0 series with PTP smoothing and a redesign of the driver-side timestamps. Please upgrade to the latest firmware and driver and re-configure.

❓ Q4.2 What are the relative latencies between the IMU, RGB and point-cloud channels?

Answer: The published documentation covers RGB latency and IMU latency. dTOF latency numbers will be added in a later release. For first-hand whitebox data, contact technical support.

❓ Q4.3 There is a 20–30 ms gap between `cloud_raw` and `image` timestamps?

Answer: This was traced to publisher blocking on the IMU callback path and processing blocking in high_odo. The new driver fixes it by splitting these into asynchronous callbacks. Please upgrade.

❓ Q4.4 Large gap between TF and point-cloud timestamps, or TF lags behind in high-speed scenarios?

Answer: Enable the high-frequency TF (HIGHFREQ) publishing mode. We also recommend disabling unused data channels in the config (rather than only disabling publish); this significantly reduces timestamp jitter on odometry_highfreq.

❓ Q4.5 Does the point cloud `header.stamp` represent the start or the end of a frame?

Answer: The dTOF point cloud is exposed in 32 sub-frame groups (similar to a rolling shutter). The first point belongs to the first group, so header.stamp matches the start of the first group’s exposure — i.e. the start of the frame.

❓ Q4.6 How is the point-cloud `offset_time` computed: is `dtof_subframe_odr` a rate or a microsecond interval?

Answer: dtof_subframe_odr (ODR = output data rate) is the per-sub-frame output frequency (rate), not a microsecond interval. The “microsecond interval” wording in the SDK header is incorrect and is being fixed; please follow the sample code (which uses it as a rate).

❓ Q4.7 Is the first point’s `offset_time = 0` the actual sync timestamp, or just unfilled?

Answer: It is the actual timestamp. The first point belongs to the first exposure group, which is aligned with the frame’s header.stamp, so offset_time = 0 represents the true synchronization origin — it is not a placeholder.

❓ Q4.8 Does the image `header.stamp` correspond to the middle or the start of exposure? Is the camera global or rolling shutter?

Answer:

Image timestamp: corresponds to the middle of the exposure.
Shutter type: global shutter.

5. Point Cloud Quality

❓ Q5.1 Point-cloud distortion at close range (within 0.4 m)?

Answer: Within 0.4 m there is noticeable distortion. The recommendation is to use cloud_raw for close-range obstacle avoidance and cloud_slam for mapping/localization. If your robot has near-field obstructions during installation (such as bumpers or impact rings), tilt the sensor slightly forward or move it to avoid reflection interference.

❓ Q5.2 Why does the point cloud look noisy?

Answer: Noise is more likely in the FOV edge regions beyond 110°. Try to keep targets near the center of the FOV when mounting the sensor.

❓ Q5.3 What is the difference between `cloud_raw` and `cloud_slam`? Why does `cloud_raw` look “layered”?

Answer:

cloud_raw: raw point cloud without historical pose correction. Lowest latency. Use for close-range obstacle avoidance and real-time perception.
cloud_slam: point cloud after pose correction. Use for mapping and localization. No layering.
The “layering” is by design — Odin1 does not replay-correct historical points, this is not a bug. Please use the topic that matches your use case.

❓ Q5.4 RGB color is wrong (too dark / purple cast)?

Answer:

Purple cast: abnormal ISP configuration in firmware. Contact after-sales to re-flash the firmware.
Dark in low-light: add ambient lighting; future hardware revisions will improve high-gain performance.

6. Relocalization and Maps

❓ Q6.1 Difficulty relocalizing on Odin1 using a map built with Q9000?

Answer:

Symptom: maps captured by Q9000 are harder for Odin1 to relocalize against than maps built by Odin1 itself.
Things to check:
1. Use the latest MindCloud to process and export the Q9000 map.
2. When scanning with Q9000, keep the front camera angle and height aligned with how Odin1 will actually be mounted.
Recommended approach: use the custom_init_pos feature to provide an initial pose; this significantly improves relocalization efficiency.

❓ Q6.2 Static relocalization fails when the device is not moving?

Answer:

Algorithm: the algorithm needs to accumulate 10 successful relocalization detections before declaring success. In feature-poor scenes, staying still may not provide enough variation.
Recommendation: after power-on, give the device some small motion (walk, turn, or rotate slowly) to trigger detection. For scenarios where the device powers up on uneven terrain and cannot safely rotate in place (e.g. quadruped robots), pair static relocalization with init_pose.

❓ Q6.3 Difficult to relocalize when the LiDAR is mounted vertically?

Answer: Upgrade to the latest firmware and driver.

❓ Q6.4 Map saving sometimes fails / has a high failure rate?

Answer: Known optimizations have already landed in the latest firmware + driver. Please upgrade and retest. If it still fails, please record and share the full saving-phase log.

❓ Q6.5 Map import / export and MindCloud Studio?

Answer:

Importing a relocalization map into MindCloud Studio: supported as of MindCloud 1.0.3.
Exporting an edited map from MindCloud Studio: not yet supported; tracked on the roadmap.
Importing Q9000 data into the cloud platform → exporting an Odin relocalization map: supported.

❓ Q6.6 MindCloud licensing / can confidential maps stay offline?

Answer:

Activation does not require an internet connection; offline activation is supported on isolated networks.
Once licensed, MindCloud can be used fully offline with no internet access.

7. Extreme Localization Scenarios (Aerial / Tunnels / Low Light)

❓ Q7.1 Low light + flight vibration + low-texture (white walls) scenes?

Answer:

Add on-site lighting (white, diffuse light is recommended).
Reduce vibration during installation (use rubber mounts).

❓ Q7.2 Tunnel scenes: odometry mode drifts while hovering, SLAM mode degenerates along the tunnel?

Answer:

Odometry mode: the current odom mode does not output “position change” information, so the flight controller cannot correct drift. Low-texture tunnels degrade easily.
SLAM mode: long, straight, low-feature scenes need enough features to lock pose.

Recommendations:

Optimize the mechanical design so that the wings, fuselage, frame, etc. are not within Odin1’s FOV.
Provide small (5°–10°) roll/pitch perturbations to avoid pure straight-line motion.
If issues persist, reach out to technical support for a bag-level review. Customers should record /odin1/cloud_raw, /odin1/imu and /odin1/image/compressed into a single bag, and provide the relocalization bin map and the calib.yaml file to the FAE.

❓ Q7.3 When should I use algorithm reset (`algo_reset`)?

Answer: Use it after collisions or large pose jumps to manually re-initialize SLAM. Driver 0.10.5+ provides the algo_reset interface and a sample. The customer can call it whenever an abnormal event is detected.

How to call: open another terminal, go to $ros_workspace/src/odin_ros_driver/, and run:

./set_param.sh algo_reset 1

8. Shock Resistance and Operating Temperature

❓ Q8.1 Shock-resistance data

Answer:

Test scenario	Value
Direct hammer strike	≈ 32 G (10× a typical day)
Flail / morning-star swing	Combined angular velocity ≈ 17.49 rad/s (≈ 2.78 rev/s)
Quadruped robot jumping (3rd impact)	≈ 16.8 G

Note: when the gyro range is exceeded, it outputs the saturation value and is briefly disabled. Do not conflate the shock-resistance numbers with extreme vibration scenarios in marketing material.

❓ Q8.2 Operating temperature / storage temperature?

Answer:

Item	Range
Operating temperature	-20 °C ~ 55 °C
Storage temperature	-20 °C ~ 60 °C

Main heat sources: dTOF and SoC.
Influencing factors:
1. Ambient temperature (≤ 50 °C is recommended).
2. dTOF frame rate (10 Hz vs 14.5 Hz; the latter generates more heat).
3. Scene complexity (more features → more SoC compute).

9. Frame-rate Modes and FOV

❓ Q9.1 Poor performance in high-speed scenarios?

Answer: Odin1 has a 14.5 Hz hidden mode; enabling it gives noticeably better results in high-speed scenarios.

❓ Q9.2 Can I change Odin1’s FOV?

Answer: Yes — you can specify the FOV in the driver launch config. It must be paired with parameters in the algorithm dynamic file such as init_pose_search_radius and init_pose_max_rot_deg. Full documentation will ship with the 0.12.0 release.

10. Multi-device Use in the Same Site

Answer:

The Odin1 dTOF uses coding/time-multiplexing schemes, so mutual interference between multiple units in the same site is low. This has been validated in competition scenarios.
The maximum concurrency depends on spatial density and occlusions. Run an on-site trial before mass deployment; for tuning support, contact technical support.

❓ Q10.2 What sets it apart from mechanical LiDAR?

Answer:

Black paint / low-reflectivity targets: mechanical LiDARs (some “mid” series, mechanically rotating lasers) often miss them; Odin (dTOF) still images them correctly.
Compact, no moving parts: better resistance to vibration (see Section 8).

11. System Compatibility

❓ Q11.1 What systems does Odin1 support?

Answer: Odin1 supports x86 and ARM Linux platforms running Ubuntu 20.04 (ROS 1 / ROS 2) or Ubuntu 22.04 (ROS 2).

12. After-Sales Service

❓ Q12.1 RMA policy and turnaround time?

Answer:

RMA policy:
- Damage caused by adapters within spec (see Q1.1): standard RMA process.
- Software / configuration issues: in principle, remote assistance + firmware/driver upgrade resolves these without shipping the unit back.
Turnaround: the standard repair window is 4–5 working days, subject to the after-sales acknowledgement. Complex hardware issues (e.g. USB negotiation downgrade, no lsusb enumeration) require factory-level diagnosis.
Loaner units: loaner devices can be requested for batch projects. Contact sales for the exact policy.

13. Standard Recording Commands

❓ Q13.1 Recording command for Odin1?

Answer:

# ROS 1
rosbag record /odin/image/compressed /odin/imu /odin/cloud_raw /odin/odometry

# ROS 2
ros2 bag record /odin/image/compressed /odin/imu /odin/cloud_raw /odin/odometry

Note 1: also provide the calib.yaml calibration file. For relocalization mode, also include the map file. Note 2: include any additional topics related to the issue you are reporting.

Appendix A: Odin1 Key Version Reference

Component	Version	Key Changes
Firmware 0.11.0	2026-03	Multi-device feature parity, `algo_reset` interface, mask transmission interface
Firmware 0.11.3	2026-04	Fix for the “module reboot required after heartbeat timeout” issue, dynamic initialization, photo dead-zone (mask) configuration
Firmware 0.11.4	2026-04	Occasional `LIBUSB_NO_MEM` during upgrade; retry 1–2 times to resolve
Firmware 0.11.5+	2026-05+	Confidence filtering enabled by default
ROS Driver 0.10.0	2026-04	IMU smoothing at 400 Hz, PTP smoothing, dual-image overlay, `algo_reset` demo
ROS Driver v1.0.0+	2026-04	Multi-Odin1 support, hot-plug fixes, stable relocalization map upload (strongly recommended)

If your question is not covered in this manual, please contact technical support and provide: ① device SN; ② firmware / driver version; ③ full startup log; ④ a reproduction bag (≥ 30 s recommended). We will respond by ticket priority.

← Back to Odin1 (English)

15. Frequently Asked Questions (FAQ)

1. Hardware and Power

❓ Q1.1 What is the standard adapter spec, and why is using the specified power so strongly required?

❓ Q1.2 The red LED is off / the device will not power on. What should I do?

❓ Q1.3 No data after connecting Odin1 to the PC and running the driver

❓ Q1.4 What cables and aviation connectors are recommended?

2. USB and Connection Stability

❓ Q2.1 USB keeps reporting heartBeat timeout / waiting for device connecting, or requires a power cycle to recover?

❓ Q2.2 After a heartbeat timeout, USB drops from 3.2 down to 2.0 / 2.1?

❓ Q2.3 Firmware upgrade fails with LIBUSB_ERROR_NO_MEM, or stalls past 90%?

❓ Q2.4 lsusb does not show the device, or the red LED is on but nothing enumerates?

❓ Q2.5 Driver fails to start when multiple OpenCV / libusb versions are present?

❓ Q2.6 RTK cannot achieve fix when used together with Odin1?

❓ Q2.7 Driver fails to start with failed to claim interface 0: LIBUSB_ERROR_BUSY / message further connection should be handled by hotplug_callback?

1. Root cause: you must use SIGINT, never kill -9

2. Manual cleanup commands

3. Recommended cleanup snippet for your launch script

4. Fallback: recovering when the USB is held by a force-killed process

3. ROS Driver Errors

❓ Q3.1 The ROS driver fails to obtain calibration parameters

❓ Q3.2 How do I check the current firmware and driver version?

❓ Q3.3 In relocalization mode the driver reports file start fail. transfer relocalizaiton map fail. please retry., the stream crashes, or the process memory is saturated?

❓ Q3.4 Does the algorithm have a reset feature, and how do I use it?

❓ Q3.5 The driver reports the queue is full?

4. Time Synchronization and Latency

❓ Q4.1 Is it a bug that the Odin time lags behind the host time?

❓ Q4.2 What are the relative latencies between the IMU, RGB and point-cloud channels?

❓ Q4.3 There is a 20–30 ms gap between cloud_raw and image timestamps?

❓ Q4.4 Large gap between TF and point-cloud timestamps, or TF lags behind in high-speed scenarios?

❓ Q4.5 Does the point cloud header.stamp represent the start or the end of a frame?

❓ Q4.6 How is the point-cloud offset_time computed: is dtof_subframe_odr a rate or a microsecond interval?

❓ Q4.7 Is the first point’s offset_time = 0 the actual sync timestamp, or just unfilled?

❓ Q4.8 Does the image header.stamp correspond to the middle or the start of exposure? Is the camera global or rolling shutter?

5. Point Cloud Quality

❓ Q5.1 Point-cloud distortion at close range (within 0.4 m)?

❓ Q5.2 Why does the point cloud look noisy?

❓ Q5.3 What is the difference between cloud_raw and cloud_slam? Why does cloud_raw look “layered”?

❓ Q5.4 RGB color is wrong (too dark / purple cast)?

6. Relocalization and Maps

❓ Q6.1 Difficulty relocalizing on Odin1 using a map built with Q9000?

❓ Q6.2 Static relocalization fails when the device is not moving?

❓ Q6.3 Difficult to relocalize when the LiDAR is mounted vertically?

❓ Q6.4 Map saving sometimes fails / has a high failure rate?

❓ Q6.5 Map import / export and MindCloud Studio?

❓ Q6.6 MindCloud licensing / can confidential maps stay offline?

7. Extreme Localization Scenarios (Aerial / Tunnels / Low Light)

❓ Q7.1 Low light + flight vibration + low-texture (white walls) scenes?

❓ Q7.2 Tunnel scenes: odometry mode drifts while hovering, SLAM mode degenerates along the tunnel?

❓ Q7.3 When should I use algorithm reset (algo_reset)?

8. Shock Resistance and Operating Temperature

❓ Q8.1 Shock-resistance data

❓ Q8.2 Operating temperature / storage temperature?

9. Frame-rate Modes and FOV

❓ Q9.1 Poor performance in high-speed scenarios?

❓ Q9.2 Can I change Odin1’s FOV?

10. Multi-device Use in the Same Site

❓ Q10.1 How many Odins can share the same site? Will they interfere with each other?

❓ Q10.2 What sets it apart from mechanical LiDAR?

11. System Compatibility

❓ Q11.1 What systems does Odin1 support?

12. After-Sales Service

❓ Q12.1 RMA policy and turnaround time?

13. Standard Recording Commands

❓ Q13.1 Recording command for Odin1?

Appendix A: Odin1 Key Version Reference

❓ Q2.1 USB keeps reporting `heartBeat timeout` / `waiting for device connecting`, or requires a power cycle to recover?

❓ Q2.3 Firmware upgrade fails with `LIBUSB_ERROR_NO_MEM`, or stalls past 90%?

❓ Q2.4 `lsusb` does not show the device, or the red LED is on but nothing enumerates?

❓ Q2.7 Driver fails to start with `failed to claim interface 0: LIBUSB_ERROR_BUSY` / message `further connection should be handled by hotplug_callback`?

1. Root cause: you must use `SIGINT`, never `kill -9`

❓ Q3.3 In relocalization mode the driver reports `file start fail. transfer relocalizaiton map fail. please retry.`, the stream crashes, or the process memory is saturated?

❓ Q3.5 The driver reports `the queue is full`?

❓ Q4.3 There is a 20–30 ms gap between `cloud_raw` and `image` timestamps?

❓ Q4.5 Does the point cloud `header.stamp` represent the start or the end of a frame?

❓ Q4.6 How is the point-cloud `offset_time` computed: is `dtof_subframe_odr` a rate or a microsecond interval?

❓ Q4.7 Is the first point’s `offset_time = 0` the actual sync timestamp, or just unfilled?

❓ Q4.8 Does the image `header.stamp` correspond to the middle or the start of exposure? Is the camera global or rolling shutter?

❓ Q5.3 What is the difference between `cloud_raw` and `cloud_slam`? Why does `cloud_raw` look “layered”?

❓ Q7.3 When should I use algorithm reset (`algo_reset`)?