Overview of Core

This article was written for version 2.3.1 of Core. Click here for the most recent version of the help center.

1. The basics

PolySync Core is a platform, or autonomy operating system, consisting of a middleware and set of software API services that are common across autonomous driving applications.

By separating the application layer from the underlying Operating System (OS) and hardware, PolySync Core makes it much more consistent and portable to build autonomous vehicle applications.


The diagram above introduces various applications that can utilize the PolySync Core middleware layer. These applications perform important functions for autonomous driving─like perception and control─with a hardware agnostic approach.

Applications access the hardware and sensor data using PolySync’s software APIs. Applications and logfiles are portable across any PolySync Core ECU─even different architectures─taking advantage of the abstraction provided from the middleware layer.

Let’s take a closer look at the PolySync Core layer to understand what type of functionality it provides.

1.1 A deeper look


As you can see from the above diagram, at the lowest level there are three types of inter-process communications (IPC):

IPC API Description
Publisher/Subscriber A single node can broadcast messages to many listeners simultaneously, and a single node can listen to one or many broadcasters simultaneously
Get/Set Query and change a node parameters at runtime
Shared memory Save bandwidth on the PolySync Core bus by keeping large data─for example uncompressed image data─off the wire using shared memory segments

In addition to IPC, PolySync Core provides a variety of helpful services to access and process the data, including:

API Description
Hardware abstraction Sensors and their recorded logfiles are portable across all supported architectures
Host abstraction Applications written using the APIs are portable across all supported architectures
Time services Unified time-domain across all hosts and nodes
Coordinate frame transformation By default all incoming sensor data is translated to the vehicle centered coordinate frame for easy reference
CAN, Serial, Socket, and Video Device APIs to talk to to connected hardware over the native interface, also used by the PolySync Core dynamic driver to talk to sensors
Messaging Predefined high-level message types that enable hardware agnostic access to sensor data
Record and replay Ability to record raw sensor data, and be able to recreate the environment by replaying PolySync Core logfile sessions
Diagnostics Fully traceable diagnostic trace for each node through the PolySync Core Diagnostic Trouble Codes (DTCs)
Analytics Host and node level analytics, for example messages published per second

Now it’s time to dive into some of the finer details of PolySync Core communication.

2. Bus and runtime communication

The PolySync Core bus and runtime work together to keep your sensors and software talking.

In order to start this process, a PolySync Core runtime has to be established within the boundaries of the System Design File (SDF). This makes for a convenient way to reference the full software and hardware system. The SDF represents the static runtime configuration─defining each host, every node, and all sensors connected to the autonomous vehicle system.

A runtime won’t exist until one or more nodes are executing as valid domain participants, which is done by calling the psync_init function. And all nodes within the runtime communicate on a shared PolySync Core bus.

The PolySync Core bus exists on the Ethernet wire. On a distributed system, all hosts would be connected to the same Gigabit Ethernet switch.

System Architecture

In the diagram, the hardware-dependent nodes─the dynamic driver interfaces─have been logically separated from the pure-software application nodes. All nodes use the PolySync Core C and C++ APIs to access the PolySync Core bus.

Information and sensor data is passed around in pre-defined PolySync Core messages, which are published and subscribed to the bus using the various APIs.

PolySync Generate is used to generate a node to subscribe to the desired message(s). It’s also used to generate dynamic driver interfaces for CAN sensors that have a valid DBC file.

3. Get/set and parameters

All of the provided dynamic driver interfaces ship with a complete parameter set, which includes parameters like mounting position, operating states, and what kinds of filters are active. This provides you with the ability to manipulate features during runtime.

Any node on the PolySync Core bus can utilize the get/set framework to easily implement runtime configurability. This is done on a node-by-node basis through publishing and subscribing to the ps_parameters_msg, as well as maintaining a real-time database of the node’s supported PolySync Core parameters.

PolySync Core also includes some useful tools to help you create, build, debug, and manage runtime parameters.

Application Description
SDF Configurator A utility program that defines the runtime system by defining hosts, nodes, and node parameters
Studio system hierarchy plugin Real-time get/set interface for active runtime nodes
Data model generator A utility to generate custom message types and new parameters that can be used by the publisher/subscriber network

4. Abstracted data model

PolySync’s main form of communication involves using a set of common messages that are broadcast and received to the PolySync Core bus through a publisher/subscriber model. PolySync Core ships with a core data model, as well as other data model modules. This includes typical types of data that are often seen on autonomous vehicles, as well as our own messages, that enable some of the API functionality.

Big Picture

The data model provides an abstraction layer that separates data consumers (application nodes) from data producers (dynamic drivers). The data within each message is in the vehicle-centered reference coordinate frame and is time stamped with UTC time, by default. This makes it easy to swap out hardware and software without breaking the system or the developer’s code.

4.1 Example of sensor abstraction

Architecturally, the dynamic driver for the ibeo LUX looks like this:

Lux Node

The dynamic driver abstracts the “native bus” of the sensor─Ethernet and CAN─into a set of generalized data types (messages) on the PolySync Core bus. Once these messages are published, they are available to any other participant on the bus. They also contain any data generated by other sensors or processes.

For instance, the ps_lidar_points_msg contains the LiDAR points generated by each of the LiDAR sensors on the bus. Each LiDAR point contains generalized data:

Data field Description
Sensor description String name for the source sensor
Native timestamp Some sensors provide their own timestamps
Echo number Used for LiDAR that supports multiple returns (i.e. through transparent objects)
Echo pulse width Duration of energy return
Layer Scanning LiDAR usually returns multiple “layers” of data in horizontal lines
Positions The position of the point, returned in vehicle centered reference frame

There is also a header that contains:

Data field Description
Message type A string name for the sensor
Timestamp Usually a UTC timestamp that comes from GPS
Source GUID A unique identifier for the node, generated by PolySync Core at runtime

5. PolySync Core Components

Listed below are the core tools provided with PolySync Core release packages.

Application Executable name Description
API Docs N/A Set of APIs to enable the development of Level 45 autonomous vehicle applications
Dynamic driver polysync-core-dynamic-driver Communicates with the sensor and is responsible for processing the raw sensor data and abstracting it from the perception and actuation hardware
Manager polysync-core-manager Manages the runtime by starting and stopping nodes based on command messages received over the bus
SDF Configurator polysync-core-sdf-configurator A utility program that defines the runtime system by defining hosts, nodes, and node parameters
Studio polysync-core-studio Plugin based visualization node that offers real-time access to data on the PolySync Core bus
Data model generator pdm-gen A utility to generate custom message types and new parameters that can be used by the publisher/subscriber network


Congratulations! The information you’ve worked your way through has provided you with a background in all of the core concepts and components of the PolySync Core platform.