# K1 firmware 3.0.2 LiDAR pipeline — redacted static analysis

Date: 2026-07-25
Scope: owner-controlled LixelKity K1 firmware 3.0.2 full archive
Method: offline configuration, ELF symbol and string inspection only
Device writes, firmware upload, runtime process changes and network probes: none

## Evidence boundary

The retained firmware package contains deployable ARM64 binaries, libraries and
configuration files, not the original C++ source tree. Non-stripped symbols,
embedded build paths and protobuf descriptors still provide stronger pipeline
evidence than the external MQTT contract alone. The private firmware archive
and extracted filesystem remain outside Git; this note contains only sanitized
derived facts and content hashes.

## Proven static facts

1. K1 selects `livox_mid360` as its LiDAR driver.
2. The driver configuration exposes separate point and IMU inputs. The K1 LIO
   configuration consumes `/livox/lidar` and `/imu`.
3. The internal converter uses a `PointIRT` representation containing XYZ,
   intensity, per-point timestamp and ring fields. The MID-360 library exposes
   raw packet processing, `PointXyzlt`, `PointFrame` and IMU callbacks.
4. The K1 LIO preprocess contract admits `0.3–200 m`, a `0.1 s` sweep and
   `use_single_pcl: false`.
5. The external MID-360 MQTT point-cloud branch declares
   `mqtt_pcl_samples: 4`; it is deliberately downsampled before transport.
6. The modeling application receives raw `PointCloudMsg`, feeds `SlamCore`,
   and later sends point clouds from `LioResultMsg`. This supports classifying
   external `lio_pcl` as an LIO product rather than the original MID-360 scan.
7. The firmware contains a K1 calibration candidate
   `lidar_imu_trans: [0.01176, -0.01865, 0.075]` with zero initial rotation.
   Static presence does not prove that this exact file was active in the
   recorded session, and it is not the sensor-to-ground installation height.

## Consequences for Mission Core

- Metric range is present in the scanner and internal point path.
- The current MQTT `lio_pcl` evidence is useful for visualization, derived
  ground proposals and detector experiments, but must not be relabeled as raw.
- A future raw-scan gate should capture the existing internal point and IMU
  products through an admitted onboard exporter or recorded bag boundary. It
  does not require replacing the physical scanner.
- The operator-estimated `1.27 m` height belongs only to the handheld recording
  and remains diagnostic until a runtime calibration binds the optical origin,
  axes and installation.
- Patchwork++ comparison must remain diagnostic on MQTT evidence even after
  applying the height estimate.

## Evidence hashes

| Evidence role | SHA-256 |
| --- | --- |
| LiDAR configuration | `cafca05b230dececfde45917f21eaad973491de4cbc2a9668b2fc01a6f79d0b2` |
| K1 LIO configuration | `2b8f06bf95e429862a5559b1aefb39591e5a97cd41dbda89016faf8d05ab7471` |
| K1 calibration configuration | `52db698b80d870b018461501a8582a84dee1aa0f269a9d96cdf96c4169dca95c` |
| MID-360 driver library | `0a9266a337c8112f84728c9c7ae6a4a282e0c92e8ffefc1d43f2d2d54ef55c25` |
| K1 LiDAR adapter library | `e1b8756474098d3a51e08e0690abc5397ea3e7422c16f0ef7f22d81509a96d85` |
| ROS/internal message converter | `225d83fb2468f686a0382324aba595982e34d1dd1e5dc8d0959e1c15d3678c67` |
| Modeling application | `780c9194a749b84b2f8e4c0ea7b297be24f5d8b5946f0315c6c9b74861425ec0` |
