I am getting very close to getting ROS2 docker going on a Rosbot2 upgraded with an Odroid C4 (since Rpi 4B’s are unobtainable). I’ve successfully flashed the core2 board,
and can get the lidar spinning with hetzerrr’s very helpful quick start yaml file. However, I do get an error when that quick start file tries to bring up the microros container. The message is:
odroid@odroid:~/Downloads$ sudo docker compose -f compose.rosbot.hardware.yaml up
[+] Running 2/0
⠿ Container downloads-rosbot-1 Running 0.0s
⠿ Container downloads-rplidar-1 Running 0.0s
Attaching to downloads-microros-1, downloads-rosbot-1, downloads-rplidar-1
downloads-rosbot-1 | [ros2_control_node-2] [WARN] [1671834521.550040761] [RosbotImuSensor]: Feedback message from imu wasn't received yet
downloads-rosbot-1 | [spawner-4] [INFO] [1671834521.835404214] [spawner_joint_state_broadcaster]: Waiting for '/controller_manager' services to be available
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/home/odroid/Downloads/micro-ros_entrypoint.sh" to rootfs at "/micro-ros_entrypoint.sh": mount /home/odroid/Downloads/micro-ros_entrypoint.sh:/micro-ros_entrypoint.sh (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
odroid@odroid:~/Downloads$
The complete yaml file again is:
# Quick Start
# $ docker compose -f compose.rosbot.hardware.yaml up
services:
rplidar:
image: husarion/rplidar:humble
restart: unless-stopped
devices:
- /dev/ttyUSB0
command: >
ros2 launch sllidar_ros2 sllidar_launch.py
serial_baudrate:=${RPLIDAR_BAUDRATE:-115200}
microros:
image: microros/micro-ros-agent:humble
restart: unless-stopped
command: serial -D ${SERIAL_PORT:-/dev/ttyS1} serial -b 576000 # -v6
volumes:
- ./micro-ros_entrypoint.sh:/micro-ros_entrypoint.sh
devices:
- ${SERIAL_PORT:-/dev/ttyS1}
rosbot:
image: husarion/rosbot:humble
restart: unless-stopped
command: >
ros2 launch rosbot_bringup rosbot_bringup.launch.py
There seems to be some problem with the volumes section and micro-ros_entrypoint.sh. I have only a very shallow grasp of docker, so am not sure what the fundamental problem is.
Thanks,
– Ralph
Hello @ralphstirling
Try launching two repositories (mapping and navigation) listed below. They are fully tested and work with the ROSbot 2R.
Let me know about your results.
Best regards
Jan Brzyk
After a few necessary customizations to the sync_with_rosbot.sh script, and a manual ssh to get the key appended to the key file, I got the pc end running.
I had trouble with the rosbot end, because the syntax for specifying the serial port in the microros section of the compose.rosbot.yaml file does not seem to be correct. I just deleted the devices parameter and hardwired /dev/ttyS1 in the ros2 command line. However, I am getting “serial port not found” messages when running, even though I earlier successfully flashed firmware on the core2 board using /dev/ttyS1. The sllidar connection to /dev/ttyUSB0 also timed out, so I’m wondering if there is some kind of permission problem with the serial ports and docker.
– Ralph
Here is the first snippet of the stdout from running docker compose on the rosbot:
odroid@odroid:~/rosbot-mapping$ docker compose -f compose.rosbot.yaml up
[+] Running 4/0
⠿ Container rosbot-mapping-rosbot-1 Created 0.0s
⠿ Container rosbot-mapping-rplidar-1 Created 0.0s
⠿ Container rosbot-mapping-mapping-1 Created 0.0s
⠿ Container rosbot-mapping-microros-1 Created 0.0s
Attaching to rosbot-mapping-mapping-1, rosbot-mapping-microros-1, rosbot-mapping-rosbot-1, rosbot-mapping-rplidar-1
rosbot-mapping-mapping-1 | [INFO] [launch]: All log files can be found below /root/.ros/log/2022-12-30-22-25-52-454915-odroid-1
rosbot-mapping-mapping-1 | [INFO] [launch]: Default logging verbosity is set to INFO
rosbot-mapping-microros-1 | [1672439152.762930] info | TermiosAgentLinux.cpp | init | Serial port not found. | device: /dev/ttyS1, error 2, waiting for connection ...
– Ralph
The way of setting the SERIAL_PORT variable in microros service of compose.rosbot.yaml file is correct.
Since you are upgrading from ROSbot 2 to ROSbot 2R, you need to take into account the change of this SERIAL_PORT environment variable. By default, in sent ROSbots 2R its value is /dev/ttyAMA0.
Try to set it up as below.
$ export SERIAL_PORT=/dev/ttyAMA0
Best regards
Jan Brzyk
OK, setting the SERIAL_PORT environment variable stopped the error messages about “serial port not found”, but I am still getting a variety of messages about feedback from motors or imu not received. Is there any debug mode which will display or log communication between the processor and the core2 board? Is the serial command/response protocol documented anywhere so I can do some testing directly to the core2 board?
Thanks again.
– Ralph
Here you can find manual of the Core2:
Can you specify these messages about feedback from motors or imu not received?
Best regards
Jan Brzyk
I have successfully flashed the firmware on the core2 board now, although the instructions said to use firmware_diff.bin and only firmware.bin existed in the docker image. The IMU and motor comm failures continue. The IMU failures are reported first, with the motor failures later.
odroid@odroid:~/rosbot-mapping$ docker compose -f compose.rosbot.yaml up
[+] Running 4/0
⠿ Container rosbot-mapping-mapping-1 Running 0.0s
⠿ Container rosbot-mapping-microros-1 Running 0.0s
⠿ Container rosbot-mapping-rosbot-1 Running 0.0s
⠿ Container rosbot-mapping-rplidar-1 Created 0.0s
Attaching to rosbot-mapping-mapping-1, rosbot-mapping-microros-1, rosbot-mapping-rosbot-1, rosbot-mapping-rplidar-1
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672947972.125878307] [RosbotImuSensor]: Feedback message from imu wasn't received yet
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672947972.626121411] [RosbotImuSensor]: Feedback message from imu wasn't received yet
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672947973.126363720] [RosbotImuSensor]: Feedback message from imu wasn't received yet
rosbot-mapping-rosbot-1 | [spawner-4] [INFO] [1672947973.387648215] [spawner_joint_state_broadcaster]: Waiting for '/controller_manager' services to be available
.
.
.
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672948180.777989155] [RosbotSystem]: Feedback message from motors wasn't received yet
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672948181.278472062] [RosbotSystem]: Feedback message from motors wasn't received yet
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672948181.778967259] [RosbotSystem]: Feedback message from motors wasn't received yet
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672948182.279452617] [RosbotSystem]: Feedback message from motors wasn't received yet
rosbot-mapping-rosbot-1 | [spawner-5] [INFO] [1672948182.330433738] [spawner_rosbot_base_controller]: Waiting for '/controller_manager' services to be available
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672948182.779938057] [RosbotSystem]: Feedback message from motors wasn't received yet
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [WARN] [1672948183.280428701] [RosbotSystem]: Feedback message from motors wasn't received yet
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [FATAL] [1672948183.780624125] [rosbot_system_node]: Activation failed, timeout reached while waiting for feedback from motors
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [INFO] [1672948183.780825381] [RosbotSystem]: Handling error
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [INFO] [1672948183.782115001] [resource_manager]: Failed to 'activate' hardware 'wheels'
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [INFO] [1672948183.821306618] [controller_manager]: update rate is 20 Hz
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [INFO] [1672948183.821957720] [controller_manager]: RT kernel is recommended for better performance
rosbot-mapping-rosbot-1 | [ros2_control_node-2] [INFO] [1672948184.002521117] [controller_manager]: Loading controller 'rosbot_base_controller'
rosbot-mapping-rosbot-1 | [spawner-5] [INFO] [1672948184.126406396] [spawner_rosbot_base_controller]: Loaded rosbot_base_controller
The interesting thing is that I see serial packets appearing on pin 10 whether I am running the docker container or not, and I see no serial data on pin 8 in any case (but did during firmware flashing). It is puzzling to me that the Core2 board would be sending data unsolicited, and that the processor does not seem to be sending any data to the core2.
The packets I see on pin 10 are 56kbaud, and appear at somewhat irregular intervals of 20-60ms.
Just as a reminder, I am using an Odroid C4 cpu, which uses /dev/ttyS1 for pin 11 TXD and pin 12 RXD, and gpio 479 for pin 11 BOOT0 and gpio 492 for pin 12 RESET. I would have loved to use an actual RPi 4B, but those are unobtainable now, as I need eight for our eight Rosbot’s.
Thanks again.
– Ralph
Before we try to solve the above problems together, I need to make sure that you have uploaded the latest OS image (Humble, Noetic or minimal). You can find them and full OS reinstallation here. Of course, chose ROSbot 2R tab. Then, make sure to flash the newest firmware. Full guide after OS reinstallation you can find here.
Let me know.
Best regards
Jan Brzyk
I cannot use the rosbot2r image directly, since I am using an Odroid C4 processor rather than the Raspberry Pi 4B. My approach has been to install the official Odroid Ubuntu 22.04 image, then docker, then pull the Husarion rosbot and microros packages. I then flashed the core2 firmware (after setting up the correct serial port, reset and boot0 pins). Flashing was successful, based on the output from flash-firmware.py. The /root/firmware.bin file is dated 2022-12-10, and has an md5sum of b3e315c22783ec5035613f2d9339fc60. I could observe serial data going both directions on my oscilloscope during flashing.
Once flashing is done, I see the repeated transmission of 0072F4 packets from the core2. I set the SERIAL_PORT environment variable, and run the rosbot-mapping docker. No data is transmitted over the serial to the core2, and the log has repeating warnings about feedback messages not received.
– Ralph
@ralphstirling, unfortunately, I must say that the hardware you are using for changes is not supported by us and I will not be able to help you at this stage. As Odroid C4 is based on arm64 architecture, everything should work based on our docker images.
However, we offer full support when using the Raspberry Pi 4 SBC.
Maybe these links will prove useful in your case:
Best regards
Jan Brzyk
Is the “low-level firmware repository” suitable for Humble? It only mentions Melodic, and I see nothing about micro-ros. I’ve been searching in vain for documentation or source code on the communication link between the Core2 board and the SBC.
– Ralph
OK, so I found the husarion/rosbot_ros2_firmware repository on github, which appears to be the microros version for ros2. Compiling that makes a firmware.bin file that is a little larger than the firmware.bin in the husarion/rosbot:humble docker image, but whatever. It behaves the same way.
Now, I just observed another issue: the Core2 board in my Rosbot2 is a V1.1 board, and all the documentation is for a V1.0 board (no IMU). Any chance of an updated manual for the Core2 V1.1 board being available? A schematic even?
Thanks.
– Ralph
Hi ralphstirling,
CORE2 v1.1 was made only as an internal part of ROSbot, so it has never been in sales. That is why we can’t share schematic with you. Changes between version 1.0 and 1.1 are strict to make ROSbot production process simpler. For example:
- Removing CAN connector, and USB A
- Additional MPU/BNO connector, and servo connector
- Additional power supply connector
And few others small changes. None of them effect on working of ROSbot firmware because we made new board version with full backward compatibility.
May I ask you what you want to use from CORE2 board which isn’t on ROSbot rear panel?
Best regards,
Hubert
We bought eight Rosbot2’s in 2021 for an undergraduate engineering robotics class, which is offered alternate years. So for this year we wanted to upgrade to ROS2 since ROS1 is EOL. We were informed by Husarion that the Asus Tinkerboard in the Rosbot2 won’t support ROS2, since a 64bit processor is required. The Raspberry Pi 4B used in the Rosbot2R is unavailable, so we went looking for alternative SBC’s that were compatible. After a failed attempt to use Asus Tinkerboard 2’s (no current operating system support), we settled on the Odroid C4. The formfactor and specs match or exceed the RPi 4B, and it is well supported with Ubuntu 22.04. We have Ubuntu 22.04 and ROS2 running fine on the Odroid C4 inside a Rosbot2. The only remaining challenge is getting the low-level Rosbot software going. We have not been able to establish communication between the CORE2 board and the Rosbot ROS2 functions. I have been able to flash the CORE2, and watch the serial data going both ways during flashing, but running Rosbot demos just leads to imu or wheel not responding messages, and no serial transmission to the CORE2 board as observed on a scope. Hence my interest in the details of the CORE2 v1.1 to help troubleshoot our problem. I have the platform io toolchain set up and ready to do some debugging, but then realized the manual did not match the physical board in the Rosbot2.
– Ralph
Hi Ralph,
I understand your case, but unfortunately we don’t have the integration of Odroid C4 with ROSbots in our plans.
About ROS - as far as I know EOL of ROS Noetic is planned for May 2025, so this distro is not even in half of it lifecycle, but it will be difficult to create image based on Ubuntu 22 for Asus TinkerBoard.
However, I have a proposal for you for how to solve all of your issues. I am sending it to you in a private message right away.
Best regards,
Hubert
Some success at last. Once I figured out the necessity of micro-ros-agent, and got that installed and compiled, I have communication with the CORE2. Unfortunately, though, I don’t see all the topics promised in the documentation. The topic list I get is:
/battery
/button/left
/button/right
/cmd_ser
/led/left
/led/right
/parameter_events
/range/left_front
/range/left_rear
/range/right_front
/range/right_rear
/rosout
What is missing is:
/_motors_cmd
/_motors_response
/_imu/data_raw
according to GitHub - husarion/rosbot_ros2_firmware: Micro-ROS powered firmware for STM32F4 microcontroller in ROSbot 2 .
However, the list of topics at the Rosbot2 manual page is even longer, and has some topics named differently than what I see from the actual firmware and agent.
I am using firmware compiled and flashed from GitHub - husarion/rosbot_ros2_firmware: Micro-ROS powered firmware for STM32F4 microcontroller in ROSbot 2. I am using micro_ros_agent/micro_ros_agent, following the Dockerfile from husarion/micro-ros-agent.
I see other repositories, like husarion/rosbot_hardware_interfaces, but it is not at all clear which ones are necessary to achieve the documented behavior.
It is lovely to be able to subscribe to /button/left and see “data: True” show up in ros2 topic echo /button/left, but I’d now like to get on with odometry and motor control.
Thank you.
– Ralph
Got the wheels spinning. I was just ignorant of the “ros2 topic list --include-hidden” flag. Apparently topics starting with ‘_’ are hidden.
So, I have rosbot_ros2_firmware running on the CORE2 successfully and micro-ros-agent running on the Odroid C4 communicating with the CORE2 successfully. Finally.
I will try to put together a comprehensive list of steps needed to get to this point for the benefit of others.
– Ralph
1 Like