GMSL Camera node

[Sharrrrk]

This discussion is about options of adding GMSL camera node to autoware.

Currently there is no camera node included in the autoware project repo.

The following camera node was used in previous autoware:

• spinnaker_camera_nodes
• usb_cam_node
• gmsl_interface

We are using GMSL cameras in our AD vehicle and GMSL camera is also a common choice of many Autoware users, so here I recommed to develop a general GMSL camera node for autoware which support multi cameras and hardware accelerated compression.

Also some sources of GMSL camera driver is available:
https://github.com/Autoware-AI/drivers/tree/master/autoware_driveworks_gmsl_interface
https://gitlab.com/leo-drive/Drivers/sekonix_camera
https://github.com/Adlink-ROS/gmsl_ros2/tree/main

Just wondering any good ideas / requirements for this gmsl camera node? Please feel free to comment. And we would start development afterwards.

[aohsato]

@Sharrrrk Thank you for this topic!

We applied our GMSL camera to our system by developing our own v4l2 device driver and using it with gscam.
(Our device drivers will be released in the future.)

The drivers you shared depend on NVIDIA DRIVE SDK. However, since many cameras are supported, creating a ROS wrapper with the latest SDK and implementing it into autoware may be useful for many users.

@drwnz What do you think about this?

[drwnz]

@Sharrrrk @aohsato
Since each individual GMSL camera will require it's own kernel-level driver (which would be supplied by the vendor), once this is implemented the camera can be accessed over v4l2 like any other camera. Therefore, it is possible to use and v4l2 based camera node in ROS (including GSCam, as mentioned).

However, I think there is benefit in creating a general camera node with a list of supported cameras - this does not have to be limited to GMSL cameras.
The reason for this, is that currently each camera needs careful setting of parameters in launch. For example, with GSCam, the user needs to know exactly which parameters to set for the gscam_config for their particular camera.
If instead, we had a package which had proper configuration for each camera model as well as a wrapper to individual camera features (either over i2cset or v4l2-ctl) then it would make it easier for the autoware user to plug and play a camera.
(@aohsato this could be something like the decoders in Nebula)