Supported Sensors

MobilEye 560

mobileye-560
V2.0.0-b.1
CAN
170

Supported hardware versions

The driver interface receives data from the MobilEye 560 over the CAN bus.

Manufacturer MobilEye
Model Number 560

Sensor background and requirements

The Mobileye 5-Series uses a single-camera based safety solution for collision prevention and mitigation. A smart camera, mounted on the interior side of the windshield, utilizes Mobileye’s pedestrian, vehicle, lane and traffic sign detection technologies to measure the distance to pedestrians, bicyclists, vehicles and lane markings, providing the driver with timely and often life-saving alerts.

Sensor Notes

  • The sensor must be mounted and calibrated before it’s connected to PolySync Core
  • PolySync Core requires access to the EyeCAN CAN bus, the brown and purple wires which are the respective CAN high and CAN low signals
  • The CAN bus contains object, lane model, object, and event information
    • Image data is not provided by the sensor

Hardware requirements

  • 12V power supply
  • 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
  • ECU with PolySync Core installed
  • CAN interface on the ECU, compatible with linuxcan or socketcan hardware drivers
  • For setup and calibration
    • OEM or reseller startup guide
    • Windows 7, 8, or 10 laptop
    • MobilEye Setup Wizard software (Windows only)
    • MobilEye EyeCAN Unit with USB cable and 6-pin female connector

Configuring the sensor

Install and calibrate the sensor per the OEM requirements.

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 mobileye-560.

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

Validating the sensor is properly configured

If you’re approaching a new PolySync Core 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, and the blue light on the sensor is lit
  • The CAN bus is terminated with a 120 Ohm resistor
  • The PolySync Core driver is able to parse the sensor identifier
  • Able to sniff the CAN bus and see valid CAN frames

Starting the PolySync Core 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 one of 4 message types: ps_lane_model_msg, ps_objects_message, ps_traffic_sign_msg, or ps_event_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 MobilEye 560 interface
-h No Show the help message
-i <pal.so> 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 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 Core 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 Core 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

Input Message Type Input Message Note
Native CAN message stored as ps_can_data_msg Default baud rate: 500K
OBD data - indirect Assumes device has its native OBD connection supplied outside of PolySync
Output Message Type API Docs Output Message Note
ps_lane_model_msg Sensor Data Model Device provides only a single lane model, this is stored in the stream buffer (additional_lanes) element zero
ps_objects_msg Sensor Data Model Device detected objects
ps_traffic_sign_msg Sensor Data Model Device detected traffic signs
ps_event_msg Core Data Model Device events

Events

The ps_event_msg is published to the bus when the following situations are detected by the sensor.

Event ID Event Description Implemented Active When Notes
500 Right lane crossing - lane detection algorithm detects a lane switch yes per extLog spec AWS display message
501 Left lane crossing - lane detection algorithm detects a lane switch yes per extLog spec AWS display message
502 Right lane departure warning yes per extLog spec AWS display message
503 Left lane departure warning yes per extLog spec AWS display message
510 Forward collision warning on vehicle yes per extLog spec AWS display message
511 Forward collision warning on pedestrian yes per extLog spec AWS display message
515 Pedestrian in danger zone warning yes per extLog spec AWS display message
520 CIPV headway warning - CIPV headway time provided in seconds yes per extLog spec AWS display message

Lane model message fields

The ps_lane_model_msg message. Contains a buffer of ps_lane_model data. Arbitration key member(s): header.src_guid

Data Type Name Description
ps_msg_header header PolySync message header.
ps_sensor_descriptor sensor_descriptor Sensor descriptor.
sequence< ps_lane_model > lanes Lane models.

Traffic sign message fields

The ps_traffic_sign_msg message. Contains a buffer of ps_traffic_sign data. Arbitration key member(s): header.src_guid

Data Type Name Description
ps_msg_header header PolySync message header.
ps_sensor_descriptor sensor_descriptor Sensor descriptor.
sequence< ps_traffic_sign > signs Traffic signs.

Objects message fields

The ps_objects_mgs message. Contains a buffer of ps_object data. Arbitration key member(s): header.src_guid

Data Type Name Description
ps_msg_header header PolySync message header.
ps_sensor_descriptor sensor_descriptor Sensor descriptor.
sequence< ps_object > objects Objects.

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

You can find all sensor descriptor values in this article.