micro-ros / docker

Docker-related material to setup, configure and develop with micro-ROS hardware.

micro-ROS Dockers

This repository contains Docker-related material aimed at setting up, configuring and developing a micro-ROS-based application.

This set of Dockerfiles provides ready-to-use environments to easily execute micro-ROS examples in your host machine, as well as to use the standalone micro-ROS build system. In addition, two images are provided that allow using micro-ROS as an external library, both in ESP-IDF.

The Docker images can be found at dockerhub.

The available images are listed below:

Image	Description	Status
base	Base image with a ROS 2 Iron installation + micro-ROS specific build system tools. Used as base of any other micro-ROS image
micro-ros-agent	Image containing a pre-compiled micro-ROS-Agent, ready to use as a standalone application
micro-ros-demos	Contains pre-compiled micro-ROS demo applications, ready to use to get a taste of micro-ROS capabilities
micro_ros_static_library_builder	Allows to use a pre-compiled micro-ROS library to develop applications in external environments
esp-idf-microros	Allows to use micro-ROS as a component of the ESP-IDF build system

Pre-requisites

You need to have Docker in your system. For installing Docker, refer to the official documentation at https://www.docker.com/.

Usage

To get an image, use the docker pull command:

• e.g. docker pull microros/base

You can select the preferred tag by appending :tag to the image name

• e.g. docker pull microros/base:iron

Once you have the image locally, type docker run to start it. It is not mandatory, although usually useful, to launch your containers using the --rm and --net=host flags:

• e.g. docker run -it --rm --net=host microros/micro-ros-agent:iron

--rm makes sure that the docker image will be removed after exiting. --net=host provides the container with the same network access as the host. -it allocates a pseudo-TTY for you and keeps stdin listening. Another used command is -v to map local files with docker container ones. -v is useful in case you may want to flash boards from within a Docker container.

base image

It is the base for the rest of the containers. It contains the necessary micro-ROS setup tools and dependencies. From this image, you can start any development targeting micro-ROS.

micro-ros-agent

This image is meant to be used as a stand-alone application. It includes the installation of the ROS 2 version selected by the tag selected, together with a micro-ROS Agent. The entry point of this image is directly the micro-ROS Agent, so upon execution of docker run you will be facing the micro-ROS Agent command line input. Running:

• e.g. docker run -it --net=host microros/micro-ros-agent:iron udp4 -p 9999

will start a micro-ROS Agent listening to UDP messages on port 9999.

micro-ros-demos

micro-ros-demos is one of the example images. With this image, you can launch example applications using micro-ROS (compiled for Linux machines). This image entry point has a ROS 2 environment set up with micro-ROS examples. You can run regular ROS 2 tools to launch the examples.

• eg: docker run -it --net=host microros/micro-ros-demos bash

The currently available examples are listed here.

micro_ros_static_library_builder

The micro_ros_static_library_builder docker image provides you with a set of include files and pre-compiled micro-ROS libraries to develop your micro-ROS application within the Arduino IDE environment. To be able to use it, use the following command to instantiate a container of this image:

• e.g. docker run -it -v $(pwd):/arduino_project --net=host microros/micro_ros_static_library_builder:iron.

Note that folders added to extras/library_generation/extra_packages and entries added to extras/library_generation/extra_packages/extra_packages.repos will be taken into account by this build system.

esp-idf-microros

This Docker image allows you to use micro-ROS as a component of the ESP-IDF build system.

To use it:

• e.g. docker run -it --user espidf --volume="/etc/timezone:/etc/timezone:ro" -v $(pwd):/micro_ros_espidf_component -v /dev:/dev --privileged --workdir /micro_ros_espidf_component microros/esp-idf-microros:latest /bin/bash"

Then, you can navigate to your example aplications and build it using the ESP IDF buildtool system script, idf.py menuconfig/build/flash/monitor.

Automated builds

These Dockerfiles are used for automatically creating images on Docker Hub. These builds are tagged with the ROS 2 version they will be compatible with: e.g. humble, iron, rolling... The latest tag will always correspond to the latest release of ROS 2.

These automatic builds have a direct relationship with the content of the micro-ROS repositories:

Image	Triggers
base	https://github.com/micro-ROS/micro-ROS-build
micro-ros-agent	https://github.com/micro-ROS/micro-ROS-Agent https://github.com/eProsima/Micro-XRCE-DDS-Agent
micro-ros-demos	https://github.com/micro-ROS/micro-ROS-demos
micro_ros_static_library_builder	https://github.com/micro-ROS/micro_ros_arduino
esp-idf-microros	https://github.com/micro-ROS/micro_ros_espidf_component

Apart from GitHub repositories changes, a build can be triggered whenever the base image is updated on Docker Hub. Base images are specified with the FROM: directive in the Dockerfile.

Purpose of the Project

This software is not ready for production use. It has neither been developed nor tested for a specific use case. However, the license conditions of the applicable Open Source licenses allow you to adapt the software to your needs. Before using it in a safety relevant setting, make sure that the software fulfills your requirements and adjust it according to any applicable safety standards, e.g., ISO 26262.

License

This repository is open-sourced under the Apache-2.0 license. See the LICENSE file for details.

For a list of other open-source components included in this repository, see the file 3rd-party-licenses.txt.

Known Issues/Limitations

There are no known limitations.

If you find issues, please report them.

docker's Issues

micro-ros-agent multiarch build

Hello,

I want to run the docker agent on arm devices, docker has an easy way to create multiarch containers, so i was able to cross compile it to arm with the following set of commands.

docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
docker buildx create --name multiarch --driver docker-container --use
docker buildx inspect --bootstrap
docker buildx build --platform linux/amd64,linux/arm64 -t microros/base:foxy base
docker buildx build --platform linux/amd64,linux/arm64 --push -t amfernus/micro-ros-agent:foxy micro-ROS-Agent

can you add it to your CI?

Whats the right config to use for microROS agent and discovery server?

Issue template

• Hardware description: STM32 Nucleo board
• RTOS: Zephyr
• Installation type:
• Version or commit hash: galactic

Steps to reproduce the issue

1. Start microros agent docker agent with fastdds and below config for FASTRTPS_DEFAULT_PROFILES_FILE

<?xml version="1.0" encoding="UTF-8" ?>
<dds>
    <profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
        <transport_descriptors>
            <transport_descriptor>
                <transport_id>CustomUdpTransport</transport_id>
                <type>UDPv4</type>
            </transport_descriptor>
        </transport_descriptors>
        <participant profile_name="super_client_profile" is_default_profile="true">
            <rtps>
                <userTransports>
                    <transport_id>CustomUdpTransport</transport_id>
                </userTransports>

                <useBuiltinTransports>false</useBuiltinTransports>
                <builtin>
                    <discovery_config>
                        <discoveryProtocol>SUPER_CLIENT</discoveryProtocol>
                        <discoveryServersList>
                            <RemoteServer prefix="44.53.00.5f.45.50.52.4f.53.49.4d.41">
                                <metatrafficUnicastLocatorList>
                                    <locator>
                                        <udpv4>
                                            <address>127.0.0.1</address>
                                            <port>11811</port>
                                        </udpv4>
                                    </locator>
                                </metatrafficUnicastLocatorList>
                            </RemoteServer>
                        </discoveryServersList>
                    </discovery_config>
                </builtin>
            </rtps>
        </participant>
    </profiles>
</dds>

2. Enter the docker using docker exec -it <container_id> bash
3. Echo topic list ros2 topic list

Expected behavior

1. Topics from microros on the nucleo are visible

Actual behavior

1. ros2 topic list doesn't show any topics that are being published on the nucleo
2. If discovery server is removed from the XML, then the topics are visible:

<?xml version="1.0" encoding="UTF-8" ?>
<dds>
    <profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
        <transport_descriptors>
            <transport_descriptor>
                <transport_id>CustomUdpTransport</transport_id>
                <type>UDPv4</type>
            </transport_descriptor>
        </transport_descriptors>
        <participant profile_name="super_client_profile" is_default_profile="true">
            <rtps>
                <userTransports>
                    <transport_id>CustomUdpTransport</transport_id>
                </userTransports>

                <useBuiltinTransports>false</useBuiltinTransports>
            </rtps>
        </participant>
    </profiles>
</dds>

Additional information

Errors building docker images.

Hi, I found errors building the docker images:

• bootstrap cannot be found.
  RUN cd tools/kconfig-frontends && ./bootstrap && ./configure && make
• Build hands running the line:
  RUN cd buildroot && /root/script.exp

Those errors are:

• bootstrap is not part of kconfig-frontends anymore since version 4.11.0.1. Nuttx tools updated on commit: Nuttx update
• GCC version changed to 7.3.0 So the expect script hands on trying to match
  9. gcc 7.2.0 (BR2_GCC_VERSION_7_2_0) (NEW)\r

Solution proposed: pull

Questions:

• Shall we agree a Nuttx tools version to go avoiding same errors in the future? I see that we use also use Nuttx buildroot. Shall this be fixed aswell?

ROS_LOCALHOST_ONLY usage

Hello maintainers, thanks for your work. I've seen that ROS_LOCALHOST_ONLY support has been added in https://github.com/micro-ROS/docker/pull/69/files, (which I believe supersedes the approach suggested in micro-ROS/micro-ROS-Agent#49 ), but what I'm observing instead that it's blocking comms. Is any extra config needed?

Context: I have a number of robots each with "desktop nodes" and a teensy connected via microros. The microros agent uses serial comms. I want to use ROS_LOCALHOST_ONLY on the desktop nodes so that the robots don't discover each other. However when I enable it on the desktop nodes, I lose connection to the microros node. (This is not surprising since I lose access to any desktop nodes not using ROS_LOCALHOST_ONLY).

I was hoping that setting ROS_LOCALHOST_ONLY in the docker launch of the micro-ros agent would allow comms again, but no such luck. How can I integrate the microros agent into a ROS graph that's using ROS_LOCALHOST_ONLY?

• Hardware description: teensy, using serial
• Installation type: from docker image
• Version or commit hash: humble

Steps to reproduce the issue

Standard microros agent with ROS_LOCALHOST_ONLY=0...

ronnie@walle:~/vxwave$ ./src/microros_agent_launch.sh 
Teensyduino device found: /dev/ttyACM0
Programming teensy was successful!
+ docker run -it --net=host --device=/dev/ttyACM0 --env ROS_LOCALHOST_ONLY=0 --env RMW_IMPLEMENTATION=rmw_fastrtps_cpp microros/micro-ros-agent:humble serial --dev /dev/ttyACM0
[1709109036.360346] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[1709109036.360494] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4
[1709109037.452976] info     | Root.cpp           | create_client            | create                 | client_key: 0x7E4CAEE3, session_id: 0x81
[1709109037.453044] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x7E4CAEE3, address: 0
[1709109037.460367] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x7E4CAEE3, participant_id: 0x000(1)
[1709109037.460639] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7E4CAEE3, topic_id: 0x000(2), participant_id: 0x000(1)
[1709109037.460812] info     | ProxyClient.cpp    | create_subscriber        | subscriber created     | client_key: 0x7E4CAEE3, subscriber_id: 0x000(4), participant_id: 0x000(1)
[1709109037.461117] info     | ProxyClient.cpp    | create_datareader        | datareader created     | client_key: 0x7E4CAEE3, datareader_id: 0x000(6), subscriber_id: 0x000(4)
[1709109037.461369] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7E4CAEE3, topic_id: 0x001(2), participant_id: 0x000(1)

... connects only to desktop nodes that are also using ROS_LOCALHOST_ONLY=0:

ronnie@walle:~/vxwave$ export ROS_LOCALHOST_ONLY=0
ronnie@walle:~/vxwave$ ros2 topic echo /hardware/motor_current_pos_steps
header:
  stamp:
    sec: 1709109128
    nanosec: 96169930
  frame_id: ''
pose:
  position:
    x: 0.0
    y: 0.0
    z: 0.0
  orientation:
    x: 0.0
    y: 0.0
    z: 0.0
    w: 0.0
---

... and does not connect to, but can still be discovered by, desktop nodes with ROS_LOCALHOST_ONLY=1:

ronnie@walle:~/vxwave$ export ROS_LOCALHOST_ONLY=1
ronnie@walle:~/vxwave$ ros2 topic echo /hardware/motor_current_pos_steps
ronnie@walle:~/vxwave$ ros2 topic list
/hardware/hardware_error_status
/hardware/motor_current_pos_steps
/eef_pose
/parameter_events
/rosout

Microros agent with ROS_LOCALHOST_ONLY=1:

ronnie@walle:~/vxwave$ ./src/microros_agent_launch.sh 
Teensyduino device found: /dev/ttyACM0
error writing to Teensy

Programming teensy failed, trying again...
Programming teensy was successful!
+ docker run -it --net=host --device=/dev/ttyACM0 --env ROS_LOCALHOST_ONLY=1 --env RMW_IMPLEMENTATION=rmw_fastrtps_cpp microros/micro-ros-agent:humble serial --dev /dev/ttyACM0
[1709108701.442692] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[1709108701.442869] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4
[1709108702.568359] info     | Root.cpp           | create_client            | create                 | client_key: 0x7E4CAEE3, session_id: 0x81
[1709108702.568495] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x7E4CAEE3, address: 0
[1709108702.583510] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x7E4CAEE3, participant_id: 0x000(1)
[1709108702.584156] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7E4CAEE3, topic_id: 0x000(2), participant_id: 0x000(1)
[1709108702.584425] info     | ProxyClient.cpp    | create_subscriber        | subscriber created     | client_key: 0x7E4CAEE3, subscriber_id: 0x000(4), participant_id: 0x000(1)
[1709108702.584992] info     | ProxyClient.cpp    | create_datareader        | datareader created     | client_key: 0x7E4CAEE3, datareader_id: 0x000(6), subscriber_id: 0x000(4)
[1709108702.585523] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7E4CAEE3, topic_id: 0x001(2), participant_id: 0x000(1)

can neither talk to or be discovered by desktop nodes with or without ROS_LOCALHOST_ONLY (the nodes discovered are desktop nodes):

ronnie@walle:~/vxwave$ export ROS_LOCALHOST_ONLY=1
ronnie@walle:~/vxwave$ ros2 topic echo /hardware/motor_current_pos_steps
WARNING: topic [/hardware/motor_current_pos_steps] does not appear to be published yet
Could not determine the type for the passed topic
ronnie@walle:~/vxwave$ export ROS_LOCALHOST_ONLY=1
ronnie@walle:~/vxwave$ ros2 topic list
/eef_pose
/parameter_events
/rosout
ronnie@walle:~/vxwave$ export ROS_LOCALHOST_ONLY=0
ronnie@walle:~/vxwave$ ros2 topic echo /hardware/motor_current_pos_steps
WARNING: topic [/hardware/motor_current_pos_steps] does not appear to be published yet
Could not determine the type for the passed topic
ronnie@walle:~/vxwave$ ros2 topic list
/eef_pose
/parameter_events
/rosout

Expected behavior

Setting ROS_LOCALHOST_ONLY=1 env var on docker launch lets the microros agent talk with the rest of the rosgraph using ROS_LOCALHOST_ONLY

Actual behavior

Setting ROS_LOCALHOST_ONLY=1 env var on docker launch prevents both discovery and comms.

Additional information

Highlighting that we are using serial comms to the micro in case it's relevant.

also network info from inside docker run -it --net=host --env RMW_IMPLEMENTATION=rmw_fastrtps_cpp --entrypoint /bin/bash microros/micro-ros-agent:humble docker container:

root@dhood-t14:/uros_ws# ip addr show 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 9c:2d:cd:7b:fd:0d brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:21:9c:2a:d1:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.70/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 3421sec preferred_lft 3421sec
    inet6 2001:818:e24a:3300:d2e7:3b51:1052:e3bb/64 scope global temporary dynamic 
       valid_lft 86401sec preferred_lft 43201sec
    inet6 2001:818:e24a:3300:5b57:74f2:c69:1bb7/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86401sec preferred_lft 43201sec
    inet6 fe80::269b:2407:48a6:db5d/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:dc:63:a5:38 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
...

SHM with microros-agent

Hi,

Both XML files in the entrypoint seem to be disabling SHM, is this actually needed? Shouldn't participants on same machine but in other docker containers still be able to talk to the agent using SHM?

Update dockerfiles

Update docker files using the new hierarchy:

• Simulation
• HIH6130_publisher
• Micro XRCE-DDS

Docker agent command fixs

The title is self explanary. To launch the agent, it would be better to delete it after. Also the different parameters are not working for foxy. I guess a working solution would be:

docker run -it --net=host --rm microros/micro-ros-agent:foxy udp4 --port 9999 # for udp4

docker run -it --net=host --rm microros/micro-ros-agent:foxy udp6 --port 9999 # for udp6

Thank you. Best

It is recommended to change the calling method of the entrance

https://github.com/micro-ROS/docker/blob/iron/micro-ROS-static-library-builder/Dockerfile
In micro-ROS-static-library-builder is ：

ENTRYPOINT ["/entrypoint.sh"]

It should be changed to the following link:
https://github.com/micro-ROS/docker/blob/iron/micro-ROS-Agent/Dockerfile
In micro-ROS-Agent is：
ENTRYPOINT ["/bin/sh", "/micro-ros_entrypoint.sh"]

The above micro-ROS-static-library-builder example will have permission issues, causing it to not work properly when running docker.

flash.sh hangs "after flashing" the board

I am using STM32-E407 development board and trying to flash with the docker image.

Steps I followed:

$ docker pull microros/micro-ros-olimex-nuttx:crystal
$ sudo docker run -it --privileged -v /dev/bus/usb:/dev/bus/usb microros/micro-ros-olimex-nuttx:crystal

Once inside the image:

root@4ac582a9448e:/uros_ws/firmware/NuttX# openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"

I get the output:

Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.316907
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000188 msp: 0x20006f94
auto erase enabled
Info : device id = 0x100f6413
Info : flash size = 1024kbytes
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000046 msp: 0x20006f94
wrote 524288 bytes from file nuttx.bin in 14.520902s (35.260 KiB/s)

It seems that flashing is complete, but openocd command does not end. I see the LED blinking on ST-Link for ever.

How to get Micro ROS Agent docker working in serial mode?

When using the micro-ROS-Agent docker, the serial mode exits early compared to other modes.
udp and psuedo-serial appear to be working, but I have not tested with a client.

Below are the various commands I have tried.

ubu@ubu-VirtualBox:$ sudo docker run -it microros/micro-ros-agent udp 8888
UDP agent initialization... OK
Enter 'q' for exit
q
ubu@ubu-VirtualBox:$ sudo docker run -it microros/micro-ros-agent pseudo-serial
Pseudo-Serial initialization... Device: /dev/pts/1
OK
Enter 'q' for exit
q
ubu@ubu-VirtualBox:$ ls /dev/serial/by-id
usb-FTDI_FT232R_USB_UART_AI02RNQC-if00-port0
ubu@ubu-VirtualBox:$ sudo docker run -it microros/micro-ros-agent serial usb-FTDI_FT232R_USB_UART_AI02RNQC-if00-port0
Serial agent initialization... ubu@ubu-VirtualBox:$
ubu@ubu-VirtualBox:$
ubu@ubu-VirtualBox:$ sudo docker run -it microros/micro-ros-agent serial --dev /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02RNQC-if00-port0
Error: Invalid arguments.
Usage: program
List of commands:
serial <device_name>
pseudo-serial
udp <local_port> [<discovery_port>]
tcp <local_port> [<discovery_port>
ubu@ubu-VirtualBox:$
ubu@ubu-VirtualBox:$ sudo docker run -it microros/micro-ros-agent serial /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02RNQC-if00-port0
Serial agent initialization... ubu@ubu-VirtualBox:$

Docker Image works in a Desktop but not in a RPI

Hello,
I'm trying to face the tutorial from this repository (https://github.com/micro-ROS/micro-ROS-bridge_RPI), i was thinking if i could use some images that are already good to use, i have used the docker-base in my desktop amd64 and works fine, but when i try to compile in RPI

I run the docker image ros-base as a conteiner and the output is:
standard_init_linux.go:211: exec user process caused "exec format error"

What can i do to improve the understanding of my question?
Great work!!

Fix broken docker files.

Fix auto build broken docker files. Dockerfiles are failing caused by ROS2 update.

Some question about micro-ros-agent dockerfiles

Hi, I'm using micros-ros on my custom stm32f722 board connected through USB to a Jetson Nano, with ubuntu 22.04 (custom image for the nano) and ros2 iron.
After an udev rule I can run:
docker run -it --rm --net=host --device=/dev/ttyChori microros/micro-ros-agent:humble serial --dev /dev/ttyChori
and list the topics publish on the host.
The Nano is connected by eth to a router and on the same LAN I have an ubuntu 22.04 with ros iron running on WSL over win11.
I can list all micro-ros topics on wsl too.
So everithing is working ok.
Now I wanted to replicate the same with a f9p GPS using Kumar github ros2 driver.I build my dockerfile using it and I can't list topics on the host computer but I can list them on the WSL OS.
Just to understand why one is working and the other not I made a dockerfile, similar to the ublox gps one, trying to get micro-ros-agent working like the provided image. I can't make it work, I can list topics on the WSL OS but not on the host computer (Jetson Nano)

FROM ros:iron

RUN mkdir -p /home/microros_ws
WORKDIR /home/microros_ws

RUN mkdir src \
    && git -C src clone -b $ROS_DISTRO https://github.com/micro-ROS/micro-ROS-Agent.git \
    && git -C src clone -b $ROS_DISTRO https://github.com/micro-ROS/micro_ros_msgs.git  \
    && . /opt/ros/$ROS_DISTRO/setup.sh \
    &&  apt update \
    &&  apt install -y python3-pip \
    libspdlog-dev \
    libfmt-dev \
    ros-$ROS_DISTRO-rmw-fastrtps-cpp \
    &&  apt autoremove -y \
    &&  sudo rosdep fix-permissions \
    &&  rosdep update \
    &&  rosdep install --from-paths src --ignore-src -y \
    &&  colcon build --cmake-args -DUAGENT_BUILD_EXECUTABLE=OFF -DUAGENT_P2P_PROFILE=OFF -DUAGENT_USE_SYSTEM_LOGGER=ON --no-warn-unused-cli \
    &&  rm -rf log/ build/ src/* \
    &&  rm -rf /var/lib/apt/lists/*

ENV RMW_IMPLEMENTATION=rmw_fastrtps_cpp
# ENV RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

COPY ros_entrypoint.sh /

ENTRYPOINT ["/ros_entrypoint.sh"]
CMD ["bash"]

version: '3.4'
services:
  robot:
    network_mode: "host"
    # privileged: true
    build:
      context: .
      dockerfile: Dockerfile
    devices:
      - /dev/ttyACM0:/dev/ttyACM0
    volumes:
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    command: ros2 run micro_ros_agent micro_ros_agent serial -v --dev /dev/ttyACM0

So I'm wondering which part of your micro-ros agent dockerfile is the one that I'm not taking into account.

I know that it's not a micro-ros related question, but after a week of reading documentation about docker and ros I can't found an answer.

Thank!

More docker build errors

Following https://github.com/microROS/docker/tree/master/stm32-e407:

CC: stm32_bringup.c
stm32_bringup.c: In function 'stm32_bringup':
stm32_bringup.c:147:3: warning: implicit declaration of function 'stm32_pmbuttons' [-Wimplicit-function-declaration]
stm32_pmbuttons();
^
CC: stm32_spi.c
CC: stm32_autoleds.c
CC: stm32_buttons.c
CC: stm32_appinit.c
AR: stm32_boot.o stm32_bringup.o stm32_spi.o stm32_autoleds.o stm32_buttons.o stm32_appinit.o
make[2]: Leaving directory '/root/nuttx/configs/olimex-stm32-e407/src'
LD: nuttx
/root/nuttx/arch/arm/src/board/libboard.a(stm32_bringup.o): In function stm32_bringup': stm32_bringup.c:(.text+0x2): undefined reference to stm32_pmbuttons'
Makefile:203: recipe for target 'nuttx' failed
make[1]: Leaving directory '/root/nuttx/arch/arm/src'
make[1]: *** [nuttx] Error 1
Makefile.unix:416: recipe for target 'pass2' failed
make: *** [pass2] Error 2
The command '/bin/sh -c export PATH="/root/nuttx/buildroot/build_arm_nofpu/staging_dir/bin/":$PATH && cd nuttx && make' returned a non-zero code: 2
dell@dell-Latitude-E5440:~/git/docker/stm32-e407$ sudo docker build -t microros_stm32f4

Docker image age?

This is not really an issue, but Discussions has not been enabled.

Looking at docker/microros/micro-ros-agent/tags, all images, except galactic have seen their last push several months ago. latest and rolling are almost a year old.

We can of course build them locally, but would it be an option to push a recent build to Docker Hub?