Supported Sensors

Dataspeed MKZ DBW


Supported hardware versions

The driver interface communicates with the Dataspeed DBW system using the CAN interface. The communication protocol is based on the ADAS Kit 20160422 and the following firmware versions.

Manufacturer Dataspeed Inc.
Power Distribution System Firmware 0.1.3
Power Distribution System Controller Firmware 0.1.2
Steering Shifter ECU Firmware 1.0.7
Throttle Brake ECU Firmware 1.1.6

Sensor background and requirements

The Dataspeed ADAS Kit is a complete hardware and software solution that allows seamless control of throttle, brake, steering, and shifting. It also allows you to control the sensors and computers while accessing data on vehicle networks.

Speed up your ADAS development by updating a Lincoln MKZ, Ford Fusion, or Mondeo with the electronics needed for rapid innovation! Dataspeed installs the drive-by-wire hardware, power distribution system, and vehicle network interfaces to get you up and running quickly.

Whether you are working on developing a single sensor, an algorithm or an entire driverless vehicle system, the ADAS Kit saves time.

Sensor notes

  • The Dataspeed driver logs all the CAN data─including received control commands─when you use PolySync to record data from the vehicle
    • Control commands are not re-published to the PolySync bus during replay.

Hardware requirements

  • CAN interface of the Dataspeed DBW system
    • CAN High/Low signals should be wired to DB9 pins 72 respectfully, with a terminating 120Ohm 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 dataspeed-mkz.

CAN Hardware and Circuit Identifiers

Each CAN interface on the ECU has a unique identifier that enables software applications like the PolySync Core dynamic 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

Configuration parameters

The default configuration works well for most testing scenarios. Carefully review the Sensor 1 parameter settings in the Sensor Configuration table before taking the vehicle on public roads. Note that some parameters are read-only.

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 test interface passes

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
-d No Print debug information and raw sensor data to stdout
-e No Export a JSON support string describing the interface, used by the SDF configuration tool
-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 definitions can be found in the C API Control Data Model docs, and the C API Sensor Data Model Docs.

Message Notes
Logs the ‘ps_can_frame_msg’
Publishes the ps_imu_msg Publishing is disabled by default
Publishes the ps_gps_msg Publishing is disabled by default
Subscribes to the ps_platform_brake_command_msg Messages must be received at >=50Hz to be actuated by the DBW module
Publishes the ps_platform_brake_report_msg Describes the vehicles current state
Subscribes to the ps_platform_throttle_command_msg Messages must be received at >=50Hz to be actuated by the DBW module
Publishes the ps_platform_throttle_report_msg Describes the vehicles current state
Subscribes to the ps_platform_steering_command_msg Messages must be received at >=50Hz to be actuated by the DBW module
Publishes the ps_platform_steering_report_msg Describes the vehicles current state
Subscribes to the ps_platform_gear_command_msg
Subscribes to the ps_platform_turn_signal_command_msg
Publishes the ps_platform_gear_report_msg Describes the vehicles current state
Publishes the ps_platform_cabin_report_msg Describes the vehicles current state
Publishes the ps_platform_suspension_report_msg Describes the vehicles current state
Publishes the ps_platform_tire_pressure_report_msg Describes the vehicles current state
Publishes the ps_platform_wheel_speed_report_msg Describes the vehicles current state

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

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 300.

You can find all sensor descriptor values in this article.