Supported Sensors

PolySync Core Driver for OSCC

core-oscc-interface
V2.4.0
CAN
460

Supported hardware versions

Open Source Car Control (OSCC) is an assemblage of software and hardware designs that enable computer control of modern cars in order to facilitate the development of autonomous vehicle technology. It is a modular and stable way of using software to interface with a vehicle’s communications network and control systems.

Hardware requirements

  • A 2014 or later Kia Soul
  • An ECU with a USB-CAN adapter (or native CAN interface)
  • An ECU with PolySync Core installed
  • Check out the Wiki

Required Pre-configurations

  • SocketCAN interface configured

Configuring the ECU

  • Plug the CAN adapter into the ECU
  • Determine which interface the adapter is associated with (ie can0)

Adding the sensor to the SDF

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

The ‘Node Interface’ name is core-oscc-interface.

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 driver is properly configured.

Setup checklist

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

  • The OSCC kit is installed and powered on
  • The SocketCAN interface is configured (default uses channel 0 for can0)

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 OSCC bus over the CAN interface using the OSCC API.

  1. Power the sensor and ECU on
  2. Optionally follow the setup checklist
  3. Start your runtime
  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 node’s 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
-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 <N> Yes SDF node configuration key for the node [required]
-o No Reserved
-r No Reserved
-d No Enable additional debugging output
-t No Perform a validation test on the VectorNav VN-300 interface
-p No Use provided logfile in Record and Replay operations instead of the default
-O No Check the node SDF configuration for required updates and exit option (returns exit status zero if no change required)
-U No Update the node SDF configuration and exit
-u No Allow updates to the SDF configuration during the normal runtime if needed (does not exit)
-w No Disable the hardware interface(s), allowing the node to run without hardware connected

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 Core nodes that subscribe to the sensor’s output message types.

Input / output message types

Message API Docs Notes
Publishes oscc_brake_report_msg OSCC C Data Model Publishing is enabled by default
Publishes oscc_steering_report_msg OSCC C Data Model Publishing is enabled by default
Publishes oscc_throttle_report_msg OSCC C Data Model Publishing is enabled by default
Publishes oscc_fault_report_msg OSCC C Data Model Publishing is enabled by default
Publishes oscc_obd_can_frame_msg OSCC C Data Model Publishing is enabled by default
Subscribes to oscc_enable_disable_msg OSCC C Data Model Subscribing is enabled by default
Subscribes to oscc_brake_command_msg OSCC C Data Model Subscribing is enabled by default
Subscribes to oscc_steering_command_msg OSCC C Data Model Subscribing is enabled by default
Subscribes to oscc_throttle_command_msg OSCC C Data Model Subscribing is enabled by default

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

You can find all sensor descriptor values in this article.

Resources