Filter by Type
Autoliv MMR 77Ghz
Autoliv SRR C6
Continental ARS 308
PolySync Core Driver for OSCC
Dataspeed MKZ DBW
Delphi ESR 2.5
Delphi ESR 9.21.21
Delphi ESR 2.5 Ethernet
Generic Video Device / Webcam
ibeo LUX 4L
ibeo Feature Fusion for LUX
ibeo LUX HD
OxTS RT3000 Series
FLIR / Point Grey GigE
Preco Gen 3
SainSmart 16 Channel Controller
Swift Navigation Piksi Multi
Velodyne VLP-16 (Puck)
Xsens MTi-G-700 Series
Autoliv SRR C6
Supported hardware versions
|Hardware model||SRR C6|
Sensor background and requirements
Autoliv’s RADAR sensors note vital information, such as range, angle and doppler velocity. This information is used to determine the driving situation and warn the driver in potentially dangerous events. If the driver does not take appropriate action in time and a crash is about to happen, advanced RADAR systems can take control of the vehicle to avoid the crash or lessen the accident’s severity. This high level of safety functionality is maintained in bad weather and no light, when driving conditions are at their worst.
- Power and data harness, typically provided by OEM or reseller
- CAN High/Low signals should be wired to DB9 pins 7⁄2 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
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
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.
CAN Channel 0 Hardware Identifier and
CAN Channel 0 Circuit Identifier in the Configurator.
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.
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.
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
- Power the sensor and ECU on
- Optionally follow the setup checklist
- Start the PolySync Core manager
$ sudo service polysync-core-manager start
- 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.
||No||Get the sensor identifier address from the Autoliv SRR C6 interface|
||No||Use provided CAN channel system index instead of what is stored in the SDF|
||No||Export a JSON support string describing the interface, used by the SDF configuration tool|
||No||Show this help message|
||No||Use provided PAL interface file instead of what is stored in the SDF|
||No||SDF node configuration key for the node [required]|
||No||Enable output of log messages to stdout (in addition to syslog)|
||No||Perform a validation test on the Autoliv SRR C6 interface|
||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
||Sensor Data Model||Publishing is enabled by default|
||Core Data Model||Publishing is disabled by default, the message buffer contains the raw data received from the sensor over the CAN bus|
Enable and disable the publishing of specific message types in the Configurator.
RADAR target 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 identifying the publisher||Yes|
||targets||Up to 64 targets populated by the radar||Yes|
|Data type||Name||Description||Message field populated by this sensor|
|ps_identifier||id||The track identifier in the sequence of potential tracks||Yes|
|ps_timestamp||timestamp||UTC timestamp when this target was received by PolySync||Yes|
|DDS_double||position||Position of target. Value PSYNC_POSITION_NOT_AVAILABLE means given axis component not available. [xyz meters]||Yes|
|DDS_double||size||Size of target. Value PSYNC_SIZE_NOT_AVAILABLE means given axis component not available. [xyz meters]||No|
|DDS_double||velocity||Velocity of target. Value PSYNC_VELOCITY_NOT_AVAILABLE means given axis component not available. [xyz meters/second]||No|
|DDS_double||range_rate||Range rate (or sometimes the Doppler velocity) of target. Value PSYNC_VELOCITY_NOT_AVAILABLE means not available. [meters/second]||Yes|
|ps_track_status_kind||track_status||If this target is a track, this provides its status if supported. Value TRACK_STATUS_RAW_TARGET means this is a raw target/measurement and not a track.||Yes|
|ps_range_kind||range_type||Target range type.||Yes|
|ps_zone_kind||zone_type||Target zone type.||Yes|
|DDS_double||amplitude||Target amplitude. Value PSYNC_AMPLITUDE_NOT_AVAILABLE means not available. [decibels]||Yes|
|DDS_double||magnitude||Target magnitude. Value PSYNC_MAGNITUDE_NOT_AVAILABLE means not available. [decibels]||No|
|DDS_double||alias||Target range rate alias (or sometimes the Doppler alias) of target relative to the parent coordinate frame. Value PSYNC_VELOCITY_ALIAS_NOT_AVAILABLE means not available. [meters/second]||No|
|DDS_double||cross_section||Target RADAR cross section. Value PSYNC_RADAR_CROSS_SECTION_NOT_AVAILABLE means not available. [meters^2]||Yes|
|DDS_unsigned_long||scan_index||Target scan index. Value zero means unknown or not available.||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
You can find all sensor descriptor values in this article.