- Host Configuration
- Runtime Node Configuration
- SDF Configuration
- Ecosystem Tools
- Application Development
- Dynamic Driver Development
Overview of Core
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):
|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:
|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.
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.
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.
|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.
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:
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:
|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:
|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.
|API Docs||N/A||Set of APIs to enable the development of Level 4⁄5 autonomous vehicle applications|
||Communicates with the sensor and is responsible for processing the raw sensor data and abstracting it from the perception and actuation hardware|
||Manages the runtime by starting and stopping nodes based on command messages received over the bus|
||A utility program that defines the runtime system by defining hosts, nodes, and node parameters|
||Plugin based visualization node that offers real-time access to data on the PolySync Core bus|
|Data model generator||
||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.