Supported Sensors

Leddar-M16

leddar-m16
V2.0.0-b.2
CAN
190

Supported hardware versions

Manufacturer LeddarTech
Hardware model M16

Sensor background and requirements

The Leddar M16 Sensor Module is an advanced solid-state LiDAR solution that combines 16 independent active elements into a single sensor, resulting in rapid, continuous and accurate detection and ranging―including lateral discrimination―in the entire wide beam, without any moving parts.

The versatile Leddar M16 module can be easily integrated to add cost-effective, smart sensing capabilities to almost any application, enabling developers and integrators to make the most of this cutting-edge technology. Various beam options, creating different fields of view ranging from 9 to 95 degrees, are available to provide the best possible match to your requirements.

Hardware requirements

  • Power and data harness, typically provided by OEM or reseller
    • CAN High/Low signals should be wired to DB9 pins 72 respectfully, with a terminating 120 Ohm resistor
  • 12V power supply
  • CAN interface on the ECU, compatible with linuxcan or socketcan hardware drivers
  • ECU with PolySync Core installed

Sensor notes

  • Before it can be connected to Core, several parameters must be set in the device’s firmware using the OEM software Leddar Configuration (Windows only)
    • Set the CAN configuration to use the extended frame format
    • Baud Rate must be set to 500kbps
    • Default Tx ID is 1872
    • Default Rx ID is 1856
  • Currently only support one M16 sensor per CAN bus, due to non-configurable Rx/Tx IDs

Configuring the ECU

The ECUs CAN network needs to be configured to use one of the two compatible CAN interfaces: Kvaser’s linuxcan or socketcan.

Setup the CAN interfaces on the ECU to enable the driver to communicate with the sensor.

Configuring the PolySync driver

Adding the sensor to the SDF

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

The ‘Node Interface’ name is leddar-m16.

CAN Hardware and Circuit Identifiers

Each CAN interface on the ECU has a unique identifier that enables software applications like the PolySync Core driver to identify and connect to the appropriate CAN channel.

Locate the CAN hardware and circuit identifiers based on the CAN drivers installed on your system.

Enter the CAN Channel 0 Hardware Identifier and CAN Channel 0 Circuit Identifier in the Configurator.

CAN channels

Parse the sensor identifier

The driver needs the sensors identifier to validate the hardware device while initializing the connection.

The PolySync Core driver can parse the identifier when started on the command line, after the CAN hardware and circuit identifiers have been entered in the Configurator.

Enter the sensor identifier in the Configurator node entry’s Sensor 0 Identifier parameter field, located at the top of the Sensor Configuration table.

Sensor ID

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 checklist to ensure the sensor is properly configured.

Setup checklist

If the sensor passes these checks then the PolySync dynamic driver will be able to communicate with the sensor.

  • The sensor is powered with 12V
  • The CAN bus is terminated with a 120 Ohm resistor
  • The PolySync Core driver is able to parse the sensor identifier

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 over the CAN interface, requests the data, and waits for confirmation that the sensor configuration is valid.

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

  1. Power the sensor and ECU on
  2. Optionally follow the setup 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 Required Description Arguments
-a No Get the sensor identifier address from the Autoliv SRR C6 interface
-c No Use provided CAN channel system index instead of what is stored in the SDF
-e No Export a JSON support string describing the interface, used by the SDF configuration tool
-h No Show this help message
-i No Use provided PAL interface file instead of what is stored in the SDF
-n No SDF node configuration key for the node [required]
-o No Enable output of log messages to stdout (in addition to syslog)
-t No Perform a validation test on the Autoliv SRR C6 interface
-w No Disable the hardware interface(s), allowing the node to run without hardware connected
DTC codes and common fixes
DTC value DTC name Fault description Notes
304 DTC_NOINTERFACE Interface not available Activated when the sensor is not reachable at the IP address set in the Configurator; activated when the sensor becomes unreachable during runtime

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

Message API Docs Notes
Publishes ps_lidar_points_msg Sensor Data Model Publishing is enabled by default

Enable and disable the publishing of specific message types in the Configurator.

LiDAR points message fields

The ps_lidar_points_msg message.

Data Type Name Description Field populated by driver
ps_msg_header header PolySync message header. Yes
ps_sensor_descriptor sensor_descriptor Sensor descriptor. Yes
ps_timestamp start_timestamp Scan start timestamp. [microseconds] Yes
ps_timestamp end_timestamp Scan end timestamp. [microseconds] Yes
ps_native_timestamp native_start_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 190.

You can find all sensor descriptor values in this article.