livox-sdk/livox_apollo_driver

1. This repo is a Livox LiDAR adapter for Apollo, located as a self-contained module under apollo/modules/drivers/livox. Its job is to turn Livox raw sensor data into Apollo-standard point cloud messages.

2. The architectural boundary is between the Livox hardware/software stack and Apollo Cyber RT. Livox-specific communication stays inside this module; everything Apollo downstream sees is a standard apollo::drivers::PointCloud published on Apollo channels.

3. Runtime startup is Apollo-native: launch/livox.launch and dag/livox.dag define how the driver component is launched inside Cyber. The README shows it is started with cyber_launch, which means this module runs as part of the Apollo cyber runtime rather than as a standalone daemon.

4. The main control/config layer is conf/livox_conf.pb.txt plus proto/config.proto. That config describes whether the system uses a hub, the per-LiDAR frame_id, hub port, output channel name, fan setting, return mode, and optional broadcast code/SN. This config is what binds physical sensors to logical Apollo topics.

5. The core processing is in driver/driver.cc, driver/hub_driver.cc, and their headers. From the names and README, the driver layer encapsulates Livox SDK interaction and likely hides device-specific details behind a common driver interface.

6. driver/driver_factory.h suggests a factory/abstraction boundary for selecting driver implementations. In practice, the repo’s README says it currently only supports Livox Hub mode, so the hub-oriented driver path is the active architecture.

7. driver/livox_driver_component.cc is the Apollo Cyber component bridge. This is the integration point that connects the Livox driver to Apollo message publishing, so it is the key runtime boundary between sensor I/O and Apollo dataflow.

8. The data path is: Livox LiDAR(s) -> Livox Hub -> Livox SDK/driver -> Apollo point cloud conversion -> per-LiDAR point cloud channel. The output topics are explicitly per sensor, for example /apollo/sensor/livox/front/center/PointCloud2, /apollo/sensor/livox/front/left/PointCloud2, and similar channels for each configured lidar.

9. params/livox_horizon_novatel_extrinsics_front_center.yaml indicates calibration/extrinsic alignment is part of the module’s deployment model. That file is the boundary between raw sensor geometry and Apollo’s vehicle/world coordinate usage.

10. The install path is also part of the architecture: apollo/docker/build/installers/install_livox_sdk.sh installs the Livox SDK into Apollo’s docker environment before building. So the repo depends on Apollo’s dockerized dev environment and an external Livox SDK shared library.

11. driver/driver_test.cc provides a local verification path for the driver logic, while the Bazel BUILD files define how the module is compiled inside Apollo. That means the repo has both a runtime integration path and a lower-level driver test path.

12. In short, the repo is a thin Apollo integration layer around Livox hardware: configuration and calibration feed a hub-based driver, the driver converts Livox data into Apollo point clouds, and the Cyber component publishes those messages onto per-sensor Apollo topics.