This is the discussion topic for the video and/or blog post linked above. Please keep all replies relevant to the content, otherwise create a new topic.
3 Likes
Very interesting content 
I have tried to control my ROS2 robot (rpi4 powered) from a docker container (in my Windows 10 machine), but I am unable to ping my container (and thus to get the topics) from the robot. The other way it works without any issue.
I have tried with --network=host and disabling the firewall but I am not able to see the host computer from the rpi.
Any thoughts?
Ok Im still working on it, but right now it seems to be related to WSL network management instead of docker network management (my first thought). A Microsoft article explaining the issue with portproxy:
I dont know if it will be enough to redirect some ports to my docker container because of the autodiscovery.
Anybody has worked with those issues?
1 Like
As a Docker enthusiast I was excited to make use of it once more for using ROS Humble on the Jetson Nano and got myself one.
Unfortunately, I it seems the Jetson devices seem to be an exception to the “use any system you want with any software you want” Docker concept. The issue seems to be, that Jetson use Linux4Tegra (L4T) Linux distributions. So while running a Ubuntu 22.04 container on Ubuntu 18.04 isn’t a problem, as the kernel is fully backwards and forwards compatible, doing the same on a Jetson specific L4T host seems to make problems. Mainly with using the host system’s hardware.
Googling regarding Humble on the Jetson Nano specifically comes up with either “it’s impossible” or “Gotta build a custom Image with Yocto”, confirming to me it’s not as simple as running a Docker container with whatever you want on it.
Whilst still unaware of this I went ahead and ran my 22.04 Ubuntu image compiled for arm64 and Humble does run fine on its own in there, but when I wanted to talk to my dev PC the beast reared its ugly head: The two ROS instances can’t see each other. I went on to rule out all the issues related to networking in general and related to docker. The only variable left is the Jetson-specific L4T host system, which makes sense now after reading what I wrote about above.
Do you know something I don’t, @JoshNewans or were you just thinking “I don’t see a reason it wouldn’t work” like me, when you said “any JetPack you want with any software you want” in the video? Could make my life a lot easier if you do
I guess the reasonable thing to do is to just use the foxy Docker image Nvidia provides, but man I’m really invested in the idea of getting Humble to work in this thing now haha
EDIT:
Ok now I’m running the nvidia ros2 foxy docker image ( nvidiajetson/l4t-ros2-foxy-pytorch:r32.5) on the jetson and foxy on my linux PC as well and they still won’t talk. I officially don’t know what the hell is going on anymore 
I spent way too much time trying to get it to work through WSL2 as well. Until they come out with the mirrored network mode, which removes the isolation of the WSL network, it seems nigh impossible to make work, and I’ve now swallowed the sunk cost and installed a Linux dual boot.
UPDATE:
Josh was right (of course)! It is possible to get the jetson nano to talk with other containerized ROS2 participants on newer versions like Humble. In fact, my problem wasn’t with the jetson at all, like I claimed. I switched over to a raspberry pi, and the exact same issue presented itself. This issue lies with the interaction of docker and the DDS. Specifically with the multicasting discovery method it uses by default.
I switched over to cycloneDDS and configured it to use unicast only and explicitly listed the other machine’s ip to make itself known to when starting a node. Now finally, after an epic journey through middle-ware purgatory with detours to exotic docker networking modes, my two ROS containers talk to each other!
To make use of the CUDA cores I’ll probably stick with foxy anyways but getting to use the nvidia container for that is huge as well!
Nice job! Yeah the world of middlewares and multicast is dark and murky. I plan to do a video on it some day…
It’s great that they are coming up with a new RMW that will hopefully resolve some of these issues that can be really opaque to troubleshoot!
Yeah, unfortunately it seems like network=host only works on linux hosts: “The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.”. See: Host network driver | Docker Docs. Turned to a VM again when working with real robots because I could not get the connection working either.
I am developing on a MacBook Air with M1 chip.
If someone got this working with Docker I would love to hear the solution.