Supported Sensors

Delphi ESR 9.21.21


Supported hardware versions

The driver interface communicates with the ESR using the CAN interface. The communication protocol is based on the 2009 model ESR 9.21.21.

Manufacturer Delphi
Hardware model ESR 9.21.21

Sensor background and requirements

Delphi’s multimode ESR combines a wide field of view at mid-range with long-range coverage to provide two measurement modes simultaneously.

While earlier forward looking radar systems used multiple beam radars with mechanical scanning or several fixed, overlapping beams to attain the view required for systems like adaptive cruise control, Delphi’s multimode ESR provides wide coverage at mid range and high-resolution long-range coverage using a single radar.

Wide, mid-range coverage not only allows vehicles cutting in from adjacent lanes to be detected but also identifies vehicles and pedestrians across the width of the equipped vehicle. Long-range coverage provides accurate range and speed data with powerful object discrimination that can identify up to 64 targets in the vehicle’s path.

Sensor notes

  • The driver requires a unique sensor identifier for each ESR sensor, even when there’s only one sensor on the system
  • The RADAR data is provided in radial coordinates in 2D
    • Each RADAR track has a lateral rate provided in polar coordinates, which is the tangential velocity in Cartesian
  • The driver optionally provides Cartesian velocity vector calculations for RADAR tracks
    • It’s strongly recommended to provide platform motion data to the sensor when this feature is enabled

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

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 delphi-esr-9.21.21.

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 ESRs sensor 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

Configuration parameters and calibrating the sensor

The configuration parameters supported by the driver are all optional.

  • If the ESR is mounted upside down, enable parameter 3400 by setting the parameter to 1
  • To disable blockage detection, set parameter 3401 to 1
  • To clear existing any ESR faults, enable parameter 3402 by setting the parameter to 1
    • It’s recommended to disable this parameter after the sensor is in a known good state
  • To enable raw data output, enable parameter 3403 by setting the parameter to 1
  • To enable the ESR to calculate offsets for vehicle movement, enable parameter 3404 by setting the value to 1
    • The driver expects that the ps_platform_motion_msg exists on the PolySync bus
  • To calculate the Cartesian velocity vector for each RADAR target, enable parameter 3405 by setting the value to 1

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

The ESR does not begin writing data to the CAN bus until it receives a command from the driver, so you’re not able to sniff the CAN bus for data. However 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_radar_targets_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
-c <N> No Use the provided CAN channel system index, instead of what is stored in the SDF The system index is the mechanism used by the linuxcan or socketcan drivers to enumerate the drivers to the linux kernel
-e No Export a JSON support string describing the interface, used by the SDF configuration tool
-g No Parse the sensor serial identifier from the Delphi ESR 2.5 interface
-h No Show the help message
-i <> No Use provided PAL interface file instead of what is stored in the SDF Path to the dynamic driver interface PAL shared object library
-n <N> Yes SDF node configuration identifier for the node SDF node ID from the Configurator, [0-65536]
-o No Reserved
-O No Check the node SDF configuration for required updates and exit option, returns exit status zero if no changes are required
-p <file.plog> No Use provided logfile in Record and Replay operations instead of the default File path to a PolySync plog logfile
-s <psync.sdf> No Use provided SDF instead of the default File path to an SDF file
-u No Allow updates to the SDF configuration during the normal runtime if needed (does not exit)
-U No Update the node SDF configuration and exit
-w No Disable the hardware interface(s), allowing the node to run without hardware connected - also known as replay mode
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_radar_targets_msg Sensor Data Model Publishing is enabled by default
Publishes ps_can_frame_msg 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

The ps_radar_targets_msg message.

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
sequence< ps_radar_target > targets Up to 64 targets populated by the ESR Yes

The ps_radar_target structure.

Data type Name Description Message field populated by this sensor
ps_identifier id The track identifier in the sequence of 64 potential tracks reported by the ESR 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
ps_quality_kind quality Target quality. No
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 ps_sensor_kind value 131.

You can find all sensor descriptor values in this article.