I’m relatively new to ROS2 and have been coming up to speed on learning NITROS. I’ve been able to
get GitHub - NVIDIA-ISAAC-ROS/isaac_ros_image_pipeline: Hardware-accelerated ROS2 packages for camera image processing. running with a Realsense D435i camera on my Orin dev kit. I’ve also been able to get GitHub - NVIDIA-ISAAC-ROS/isaac_ros_image_segmentation: Hardware-accelerated, deep learned semantic image segmentation running using that same Realsense camera. I’ve got a few questions as a result of getting through those efforts that I’m hoping people here can answer:
-
How customizable are GEMS? If an end-user wanted to craft their own unique hardware acceleration operation,
is there any documentation available that describes how to write custom GEMS or is GEM development solely being done by NVIDIA? -
On a related note, I see yaml files for utilizing ‘gxf’ extensions. I’m thinking that ‘gxf’ is the same thing as ‘GEM’. Is this the case? If not, is there any documentation on these ‘gxf’ extensions and how they are used?
-
The Isaac NITROS animated graphic here (GitHub - NVIDIA-ISAAC-ROS/isaac_ros_nitros: NVIDIA Isaac Transport for ROS package for hardware-acceleration friendly movement of messages) shows “tickets” (handles?) being passed from one node to the next, with the data presumably staying on the GPU without having to be serialized / deserialized by ROS2. I know that ROS2 “type adaptation” is going on to transform ROS2 messages to NITROS messages (e.g. sensor_msgs::msg::Image → nvidia::isaac_ros::nitros:NitroImage). How are these “tickets” being passed from one NITROS node to the next? This question really relates to understanding whether GEMs are customizable by an end-user, and to what extent one needs to understand the underlying
NITROS implementation. -
I understand that operating inside the same process provides zero-copy capabilities with NITROS. I assume this means that if I have two NITROS nodes operating in different processes, data that gets passed between them will suffer a serialize/deserialize penalty as things go from NITROS → ROS2 → NITROS in the transfer. Is this correct?
-
If you are dealing with custom ROS2 messages that are not listed in the “NITROS Data Types” listed here (GitHub - NVIDIA-ISAAC-ROS/isaac_ros_nitros: NVIDIA Isaac Transport for ROS package for hardware-acceleration friendly movement of messages), I assume that you will not be able to take advantage of the hardware acceleration & zero-copy NITROS provides. Is this correct?
Thanks.