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.
I just wanted to share that I have moved all of my ros2 development to docker.
One of my biggest concerns with both ROS and ROS2 is that a system can get very messy if you work on multiple projects on the same machine. It is easy to forget what you have installed for one project.
It is not always clear what gets pulled in when you install something and it is even less clear that everything is uninstall and cleaned up when you uninstall something.
Now I can freely experiment with multiple versions of software without worrying if I have a physical machine partition running the correct OS.
Finally, docker makes it very easy to file reproducible bug reports. Historically it seems that 90% of ROS bugs were closed with “works for me” or “can’t reproduce.” Even when 10’s of people have reported the same issue across multiple software releases.
Long story short… anything you can do to promote the encapsulation of ROS development environments in docker machines is a great step forward.
Interestingly this notion of preconfigured ROS development environments seems to be the entire business model of the construct.
Hi,
I’ve created my first ROS2 Docker image on my host machine following the video (great video again, thanks @JoshNewans). I then ran up my ROS2 robot, but when I run “ros2 topic list” in the host docker ‘container’(have I got the correct terminology?) it can’t see any of the topics created by my robot, it just lists parameter_events and rosout 
I can happily ssh from the host Docker container to the robot - so I know networking is working.
Any ideas?
This is a fresh install of Ubuntu 22.04 on the host machine, with no native ROS2 install.
Regards
Andrew
In your docker run command are you setting your network and ipc as host?
--network=host \
--ipc=host \
These are two security-related parameters that let you set the docker network and interprocess communicates run on the host machine rather than be encapsulated in the container itself.
Personally, I use
docker run -it --user ros --network=host --ipc=host -v /tmp/.X11-unix:/tmp/.X11-unix:rw --env=DISPLAY -v $PWD/config:/my_source ros2-humble-dev-env
Hello @JoshNewans,
I am trying something that should be simple but I am struggling: accessing a USB webcam from a docker container.
Using the dockerfile in your tutorial as starting point (i.e. osrf/ros:humble-desktop-full is the base image) I added a RUN instruction to install cheese, then built the image, then run it with:
$ docker run -it --user ros --network=host --ipc=host -v $PWD/code/:/my_source_code -v /tmp/.X11-unix:/tmp/.X11-unix:rw --env=DISPLAY --device=/dev/video2 --device=/dev/video3 nano_image
(when I plug the camera /dev/video2 and /dev/video3 are the two new devices that appear)
from inside the container cheese app launches fine, but there is no streaming and the device pulldown menu is grayed out. On console I get the following error messages:
(cheese:53): dbind-WARNING **: 19:52:59.649: Couldn't register with accessibility bus: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
MESA: error: Failed to query drm device.
libGL error: glx: failed to create dri3 screen
libGL error: failed to load driver: iris
libGL error: failed to open /dev/dri/card0: No such file or directory
libGL error: failed to load driver: iris
** Message: 19:52:59.899: cheese-application.vala:222: Error during camera setup: No device found
(cheese:53): cheese-CRITICAL **: 19:52:59.903: cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' failed
(cheese:53): GLib-CRITICAL **: 19:52:59.903: g_variant_new_string: assertion 'string != NULL' failed
(cheese:53): GLib-CRITICAL **: 19:52:59.903: g_variant_ref_sink: assertion 'value != NULL' failed
(cheese:53): GLib-GIO-CRITICAL **: 19:52:59.903: g_settings_schema_key_type_check: assertion 'value != NULL' failed
(cheese:53): GLib-CRITICAL **: 19:52:59.903: g_variant_get_type_string: assertion 'value != NULL' failed
(cheese:53): GLib-GIO-CRITICAL **: 19:52:59.903: g_settings_set_value: key 'camera' in 'org.gnome.Cheese' expects type 's', but a GVariant of type '(null)' was given
(cheese:53): GLib-CRITICAL **: 19:52:59.903: g_variant_unref: assertion 'value != NULL' failed
** (cheese:53): CRITICAL **: 19:52:59.903: cheese_preferences_dialog_setup_resolutions_for_device: assertion 'device != NULL' failed
Seems the device is not accessible. sudo cheese fails completely (does not even launch) with:
No protocol specified
** (cheese:145): ERROR **: 19:54:13.667: cheese-application.vala:89: Unable to initialize libcheese-gtk
Trace/breakpoint trap
Note: cheese works just fine in the host
Any idea what I am doing wrong?