Supported Sensors
Generic Video Device / Webcam

video-device | |
V2.0.0-b.2 | |
USB | |
180 |
Supported hardware versions
Hardware ID | Driver supports USB and internal web cams |
Supported hardware | Video4Linux (V4L) compatible USB video devices, tested with the Microsoft LifeCam |
Sensor requirements and background
A webcam is an inexpensive way to visualize your surroundings.
Sensor notes
- The PolySync Core video device interface supports devices that are Video4Linux (V4L) compatible.
Hardware requirements
- ECU with PolySync Core installed
- A USB port on your ECU
Configuring the sensor
When the video device is connected to the Linux machine the Video4Linux (V4L) drivers will enumerate the device name, similar to /dev/video0.
When the device is initialized during the boot process or connected to the host machine you will see it in /var/log/syslog
or you can run dmesg
in a terminal before connecting the device to your host machine.
You can also see all video devices by running the command:
$ ls -l /dev/video*
Configuring the ECU
Refer to the cameras manufacturers documentation to see if it requires any setup. For most V4L compatible video devices no additional setup is required.
Configuring the PolySync driver
The default PolySync Configurator configuration has shown to work out of the box on most systems.
Adding the sensor to the SDF
Using the Configurator tool, add a sensor node to the SDF.
The ‘Node Interface’ name is video-device
.
Configuration parameters
The values in the default configuration has been shown to work for most cameras.
You will need to set the Video Device 0 Name
in the SDF Configurator IO Configuration
section to your video device.
SDF settings
- Node Configuration
- Application settings, such as the file path for the the device driver
- Sensor Configuration
- Physical settings of the device, such as XYZ placement on the vehicle
- Published and logged: Pixel format, image width/height, frames per second
- Optional extended H264 encoder parameters
- IO Configuration
- Video device name
- IO settings for the data, such as video frames per second
- Source: image width/height, frames per second
- Source device configuration parameters
Shared memory configuration
This is an optional step. Shared memory queues provide drastically faster read/write speeds than the global shared PolySync bus that exists on the Ethernet wire.
Shared memory segments exist to allow two or more host-local nodes to access the data. Commonly the data is very large, such as uncompressed image data that would normally saturate a Gigabit Ethernet bus.
- Configure the PolySync driver to use the shared memory queue by providing a unique shared memory queue key
- The driver manages the creation and cleanup of the memory segment
- Configure your custom application to read data by referencing the unique shared memory queue key
- Create the shared memory segment
- Start the PolySync driver and custom application
If the shared memory buffer is not set up when the dynamic driver starts, it will detect this and populate an error in the polysync.log
indicating the appropriate buffer size that needs to be configured.
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.
Set up checklist
If the sensor passes these checks then the PolySync dynamic driver will likely be able to communicate with the sensor.
- Verify your video device is enumerated in /dev/
$ ls -l /dev/video*
- Ensure you can view video with a system application.
- The
Cheese Webcam Booth
application is installed by default on an Ubuntu desktop system.
- The
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 through the serial port, requests the data, and waits for confirmation that the sensor configuration is valid.
When the dynamic driver receives the first packet of data, it begins processing and abstracting the data from the OEM data structure in a high-level hardware agnostic message type. In this case the cameras data is placed in a ps_image_data_msg
.
- Power on the ECU
- Plug the camera into a USB port
- Optionally follow the set up checklist
- Start the PolySync Core manager
$ sudo service polysync-core-manager start
- Start the dynamic driver process
- Use the PolySync Core manager to start all nodes defined in the SDF, or
- Start the node manually on the command line
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 |
---|---|---|---|
-e |
No | Export a JSON support string describing the interface, used by the SDF configuration tool | N/A |
-g |
No | Get all available video devices on the host | N/A |
-h |
No | Show the help message | N/A |
-i <pal.so> |
No | Use provided PAL interface file instead of what is stored in the SDF | Path to the dyanmic 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 | N/A |
-O |
No | Check the node SDF configuration for required updates and exit option (returns exit status zero if no change required) | N/A |
-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 |
-t |
No | Perform a validation test on the Video Device interface | N/A |
-u |
No | Allow updates to the SDF configuration during the normal runtime if needed (does not exit) | N/A |
-U |
No | Update the node SDF configuration and exit | N/A |
-w |
No | Disable the hardware interface(s), allowing the node to run without hardware connected - also known as replay mode | N/A |
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 USB device 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
The Generic Video Device dynamic driver node outputs the following message type to the bus.
Message | API Docs | Notes |
---|---|---|
Publishes pre-defined ‘ps_image_data_msg’ | Sensor Data Model |
By default the ps_image_data_msg
is published to the bus when you create a new Generic Video Device node. You can enable and disable the publishing of specific message types in the Configurator.
Image data message fields
Data type | Name | Description | Message field populated by this sensor |
---|---|---|---|
ps_msg_header | header | PolySync message header. | Yes |
ps_sensor_descriptor | sensor_descriptor | Sensor descriptor. | Yes |
ps_timestamp | timestamp | Image timestamp. | Yes |
ps_native_timestamp | native_timestamp | Native timestamp for the image. Provided by some devices. Check ps_native_timestamp.format for meaning. Format value PSYNC_NATIVE_TIMESTAMP_FORMAT_INVALID means not available. | Yes |
ps_pixel_format_kind | pixel_format | Image data format. | Yes |
ps_identifier | frame_id | Image counter. Value PSYNC_IDENTIFIER_INVALID means not available. | Yes |
DDS_unsigned_short | width | Image width. [pixels] | Yes |
DDS_unsigned_short | height | Image height. [pixels] | Yes |
DDS_sequence_char | data_buffer | Image data buffer. | Yes |
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 180
.
You can find all sensor descriptor values in this article.
Resources and configuration tools
This section has supporting resources and tools that are referenced throughout the article.
Visualize data outside of PolySync Core Studio
- image data viewer example binds the first image data publisher it finds
- Qt Image Viewer example creates a GUI application using Qt to visualize PolySync image data
- Shared Memory Image Data Viewer example demonstrates using the PolySync Shared Memory C++ API