Supported Sensors

Quanergy M8


Supported hardware versions

The driver interface communicates with the Quanergy M8 through the Quanergy Client Library Version.

Manufacturer Quanergy
Hardware ID M8
Hardware Revision Rev C
Hardware API V5
Quanergy Client Library Version 2.0.12

Sensor background and requirements

The M8 is the first cost-effective long range LiDAR sensor enabling ubiquitous use of smart sensing in dynamic situations— made and tested for 3D mapping, security, harsh industrial environments and the most demanding applications. The M8 sensor’s small design sees by day or night, with no IR signature needed, and works in any weather. Multiple laser beams and Time-of-Flight (TOF) depth perception result in 3D point clouds for spatial sensing. With a 360° field of view, 420,000 points per second, long measurement range, high accuracy, and fine resolution, this sensor is now available at a breakthrough price.

Hardware requirements

  • 24V power supply
  • Gigabit Ethernet connection to an ECU, or network switch
    • It’s strongly recommended to provide a direct connection from the LiDAR to the ECU
  • ECU with PolySync Core installed

Configuring the sensor

  • Quanergy provides a web interface to configure the sensor
  • To configure multiple Quanergy M8 sensors on the same network, they must be assigned unique IP addresses
    • Click the static button and press submit to populate the Network Settings Edit page with values within the network range
    • Change the last octet of the IP address and click submit
    • Disconnect the sensor from power for 2 seconds, then reconnect the power and wait 40 seconds before operating the sensor

Configuring the ECU

Linux network set up

The Ethernet network must be properly configured before PolySync can communicate with the sensor on the target ECU.

It’s highly recommended to use point-to-point Ethernet communication between the sensor and the ECU to lower the latency. You may connect the sensor to a switch but may be prone to high latency.

Setting the ECUs static IP address

Once the LiDAR’s IP address is known, set a static IP address for the ECUs NIC in the same IP subnet range as the LiDAR.

For example if the LiDAR’s IP address is, it’s said to be on the 192.168.1 subnet, and the ECU should be configured with IP address 192.168.1.X.

Configuring the PolySync driver

The default PolySync Configurator configuration has shown to work out of the box on most systems.

Adding the sensor to the SDF

Using the Configurator tool, add a sensor node to the SDF.

The Quanergy M8 ‘Node Interface’ name is quanergy-m8.

Validating the sensor is properly configured

If you’re approaching a new PolySync system or need to validate an existing configuration you can use the following check to ensure the sensor is properly configured.

Set up checklist

If the sensor passes this checklist then the PolySync dynamic driver will likely be able to communicate with the LiDAR sensor.

  1. Ensure you can ping the sensor at the static IP address
    • Get the IP address from the Configurator node entry, static IP address set in the preparing a sensor section
      • $ ping
      • 64 bytes from icmp_seq=1 ttl=64 time=0.030 ms
      • ...
  2. Ensure you can access the Quanergy configuration page (

Starting the PolySync driver

The configuration set in the Configurator is loaded from the SDF when the dynamic driver starts. It connects to the sensor through the serial port, requests the data, and waits for confirmation that the sensor configuration is valid.

When the dynamic driver receives the first packet of data, it begins processing and abstracting the data from the OEM data structure in a high-level hardware agnostic message type. In this case the LiDAR data is placed in a ps_lidar_points_msg.

  1. Power the sensor and ECU on
  2. Optionally follow the set up checklist
  3. Start the PolySync Core manager
    • $ sudo service polysync-core-manager start
  4. Start the dynamic driver process

Starting the node manually on the command line

To start a dynamic driver node on the command line, the node must first be defined in the SDF using the Configurator application.

Each node defined in the Configurator has a unique node ID which points to the nodes configuration. This article explains how to find the node ID.

Command line flags and usage

Once the node ID is known (substitute for X), the dynamic driver node for the supported sensor can be started with the base command:

$ polysync-core-dynamic-driver -n X

Each sensor supports an array of command line arguments. To see a full list of command line arguments, pass the -h help flag:

$ polysync-core-dynamic-driver -n X -h  |  less

There’s a lot of output so we recommend you pipe the output to less, but it’s not required.

Flag Description
-h show this help message [optional]
-o reserved [optional]
-w disable the hardware interface(s), allowing the node to run without hardware connected (also known as replay mode) [optional]
-r SDF runtime configuration key that specifies the domain to operated under, the default domain is used otherwise [optional]
-n SDF node configuration identifier for the node [required]
-i use provided PAL interface file instead of what is stored in the SDF [optional]
-e export a JSON support string describing the interface, used by the SDF configuration tool [optional]
-u allow updates to the SDF configuration during the normal runtime if needed (does not exit) [optional]
-p use provided logfile in Record and Replay operations instead of the default [optional]
-s use provided SDF instead of the default [optional]
-U update the node SDF configuration and exit [optional]
-O check the node SDF configuration for required updates and exit option (returns exit status zero if no change required) [optional]
-d enable additional debugging output [optional]
-t perform a validation test on the interface [optional]

Accessing sensor data

When the dynamic driver node is operating in an OK state then data is being published to the global PolySync bus, and any node can subscribe to the high-level message type(s) output by the dynamic driver node.

There are several tools that PolySync provides to quickly validate that data exists on the bus.

Access sensor data with PolySync nodes that subscribe to the sensor’s output message types.

Input / output message types

The Quanergy M8 dynamic driver node outputs the following message types to the bus.

Message API Docs Notes
Publishes pre-defined ps_lidar_points_msg Sensor Data Model

It takes the following messages as inputs.

Message Notes
ps_byte_array_msg Does not publish to the bus by default

LiDAR points message fields

Data type Name Description Message field populated by this sensor
ps_msg_header header PolySync message header. Yes
ps_sensor_descriptor sensor_descriptor Sensor descriptor. Yes
ps_timestamp timestamp Scan start timestamp. [microseconds] Yes
ps_timestamp timestamp Scan end timestamp. [microseconds] Yes
ps_native_timestamp native_timestamp Native timestamp for the scan start. Provided by some devices. Check ps_native_timestamp.format for meaning. Format value PSYNC_NATIVE_TIMESTAMP_FORMAT_INVALID means not available. Yes
sequence <ps_lidar_point> points LiDAR points. Yes

Filtering incoming data for this sensor

An application that subscribes to a given message type is able to see data from more than one sensor or source.

Applications can filter for specific sensors and data sources in the message callback in C applications, or the messageEvent in C++ applications.

Filter incoming messages for this sensor with ps_sensor_kind value 400.

You can find all sensor descriptor values in this article.

Resources and configuration tools

This section has supporting resources and tools that are referenced throughout the article.

Sensor User Guide

Sensor Setting User Guide

Sensor SDK User Guide for Ubuntu