Linux 20.04 LTS support in future L4T

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi,

Are there any plans to support Linux 20.04 LTS in the following L4T releases?

Thanks

2 Likes
2

Hi roey.bh,

That’s under planning, but no clear schedule yet, the 1st SW release for Xavier NX will still be Ubuntu 18.04.

3

Would be very interested in this to get ROS Noetic working on the Xavier NX. Is there a clearer schedule now?

1 Like
4

Joining the question as well, as ROS Noetic only supports Ubuntu 20.04

5

I would really appreciate that, especially for running Python3 in ROS noetic. Also a newer Kernel would good to make use of modern hardware…

6

Hello, have anyone try Ubuntu 20.04 with ROS noetic on jetson xavier NX successfully?

7

I built ROS Foxy from source for 18.04 in this Dockerfile - https://github.com/dusty-nv/jetson-containers/blob/master/Dockerfile.ros.foxy

I will try the Dockerfile for ROS Noetic next. The one for ROS Foxy worked by just following the ROS build instructions.

1 Like
8

Here is a Dockerfile for building ROS Noetic from source for 18.04 on JetPack 4.4: jetson-containers/Dockerfile.ros.noetic at master · dusty-nv/jetson-containers · GitHub

See the readme from GitHub - dusty-nv/jetson-containers: Machine Learning Containers for NVIDIA Jetson and JetPack-L4T for instructions on building the containers.

9

Hi @dusty_nv!

I’m in the process of moving one of my ROS2 projects to Xavier and thought that you could perhaps give me some advice.

It is a pretty simple project at the moment, basically just teleoperation over WebRTC with a 5G router. I want bi-directional high-res video and audio between the connecting browsers and the robot so I need the nvmpi codecs for FFmpeg to work in the container where I will be running the ROS2 nodes.

I was previously running the code on a raspberry pi 4 in a container based on the arm64v8/ros:galactic image from the official registry.

My current best guess is that I will need to use the nvcr.io/nvidia/l4t-base:r32.5.0 base image and build foxy(/galactic) from source and follow the instructions in GitHub - jocover/jetson-ffmpeg: ffmpeg support on jetson nano for the codecs to work in my ros-nodes on the Xavier? Is this correct, or can I still use arm64v8/ros:galactic somehow?

Also, the ROS2 related dependencies are limited enough that I should be able to manage building everything I need from source initially. As the complexity of the project grows (driving assistance systems, mapping etc) this is really going to become an issue though. I’m considering back-porting the project to the 18.04 based dashing release of ROS2 if a Linux 20.04 based image with support for hardware-accelerated encoding is too far off into the future. Can you give any ballpark indication of the timeline for this or is it still an unknown?

I understand from the other thread about this that updating to Linux kernel 5.x is tricky, so I don’t want to push here… just trying to make the best decision for my project :)

10

Hi @samuel15, you can use one of my pre-built Foxy/Galactic container images on DockerHub:

# https://github.com/dusty-nv/jetson-containers#pre-built-container-images
dustynv/ros:foxy-ros-base-l4t-r32.5.0
dustynv/ros:foxy-ros-base-l4t-r32.4.4
dustynv/ros:galactic-ros-base-l4t-r32.5.0
dustynv/ros:galactic-ros-base-l4t-r32.4.4

These built Foxy/Galactic from source against l4t-base container.

I’m not familiar with using the accelerated ffmpeg, although I believe that JetPack-L4T does now include hw-accelerated ffmpeg (although that appears to be for decode-only currently)

The way I handle video streaming is to use the video_output node from my ros_deep_learning package, which internally uses GStreamer and can output RTP stream that is encoded using Jetson hw codecs.

11

Hi,

Thank you for your quick response and for making those container images available!

Also for the suggestion about the streaming solution in the ros_deep_learning package. Do you know of a way to integrate that with WebRTC?

I’m pretty tied in with using FFmpeg-based encoding in my current software stack for WebRTC. I actually already got hardware-accelerated encoding for FFmpeg mostly working yesterday in a container based on dustynv/ros:galactic-ros-base-l4t-r32.5.0 (after quite a bit of detective work and a pretty complicated Dockerfile…) There is currently a pretty large delay in the output so I think I need to configure the encoder to not buffer frames or use some low latency mode. It’s also possible this is a dead end as jetson-ffmpeg seems pretty experimental…

It a pretty big deal for me that rosdep doesn’t work for foxy/galactic in the 18.04 based l4t image though (and can’t really work properly in principle?) I only had the ros2_control stack and a custom motor driver as ROS2 dependencies in the project and their dependencies were already really hard to manage without rosdep.

I ended up giving up on building everything for l4t and decided to split up the project in two separate containers. One for the node that needed hardware acceleration based on dustynv/ros:galactic-ros-base-l4t-r32.5.0 and another container based on arm64v8/ros:galactic for everything else.

I’m not really a big fan of this solution and so I’m still thinking that reverting the project to dashing could be a good idea. Having 2 separate docker images (pretty complicated ones at that with experimental dependences, lots of stuff built from source and dubious patching steps like for ffmpeg etc) seems bad from a maintainability perspective. This is especially important for me since the robot will be deployed at a customer and downtime while I try to rebuild broken Dockerfiles won’t be appreciated.

12

OK, you may want to stick with FFMPEG then since you already have it integrated. You can search for “GStreamer WebRTC” for the webrtcbin element in GStreamer, however it seems to require some additional configuration from the client side.

I haven’t used Dashing, but Eloquent is based on 18.04 so it has the pre-built packages available so you don’t need to build everything from source. I have Dockerfiles/containers for Eloquent that are simpler than the Foxy/Galactic ones are.

13

Ok, thanks!

I’m kind of getting the impression here that 20.4 for L4T is likely to be several years away. Is that accurate?

14

Hi @samuel15, see this thread for timeline for the Ubuntu 20.04 upgrade for Xavier devices:

https://forums.developer.nvidia.com/t/jetson-software-roadmap-for-2h-2021-and-2022/177723

JetPack 5.0 will be the next major release, and will include an upgrade to LTS Kernel 5.10 and Ubuntu 20.04. Other noteworthy changes include support for UEFI (replacing CBoot), support for OP-TEE (replacing Trusty as the trusted execution environment), and an upgraded compute stack including CUDA 11. The Developer Preview of JetPack 5.0 is planned for Q1-2022 and the production release is planned for 2H-2022.

15

Ah, I see!

I can probably get by with my multi-container solution until Q1-2022 in that case and put everything in the same container after that. Thanks for the info.