Four runtime conditions decide whether a ROS 2 depth image moves without a host copy

In ROS 2 Lyrical, a `uint8[]` field comes out of the message generator as `rosidl::Buffer<uint8_t>` ^[3]. The default buffer is CPU-backed and behaves like the `std::vector<uint8_t>` interface existing code already calls, so source compatibility holds ^[4]. The CUDA backend changes what sits behind that interface, implementing the same `rosidl::Buffer<uint8_t>` storage on CUDA Virtual Memory Management ^[5].

The runtime requirements are deployment properties. All four have to hold at the same time ^[18]. In a containerised graph the one to check first is the Linux user: two containers on one Jetson running under different UIDs fail it and take the host copies ^[19]. The node source is identical either way, and the fallback happens without an error ^[7].

Automatic fallback is the right default when a graph mixes CPU and GPU peers ^[7]. It also means the failure mode is a slower graph that still works. The agent skill's last step is verifying that the CUDA transport path is actually enabled, alongside tracing data movement through callbacks and helper libraries and planning an interface-preserving refactor ^[11].

The example shows where the cost sits. The Depth Anything 3 TensorRT node's callback converts the incoming ROS image to an OpenCV view, runs monocular metric-depth inference with TensorRT, converts the resulting `cv::Mat` back to a ROS image, and publishes floating-point depth ^[14]. The algorithm is already GPU-native and the ROS boundary around it is CPU-backed ^[15]. NVIDIA says that boundary is appropriate for a CPU producer or consumer and unnecessary when both sides can handle CUDA memory, and it counts two payload-sized host transfers, a host allocation, and serialization work at the interface ^[15]. The refactor keeps the message type and lets the output `Image.data` field carry storage from another backend ^[16].

The code change is minimal, by NVIDIA's account; picking which boundaries to change is the harder job, and that takes an audit of allocations, serialization, stream ownership, and fallback behavior ^[10].

The post does not publish a before-and-after latency or throughput number for the converted node ^[20]. For a figure from this node to transfer to another graph, the peers would have to be co-located on one device under one Linux user with a supported RMW ^[8], the payload would have to be large enough that two host transfers and a host allocation dominate the callback ^[15], and the downstream consumer would have to accept CUDA memory ^[15]. On Jetson AGX Thor, where the tutorial deploys the result, a perception chain assembled from Isaac ROS 5.0 nodes plausibly meets all three ^[12][9].