MAVROS + ROS 2 in Docker w/ Navigator

Blue Robotics Software ArduSub
1

I have created a Docker image with MAVROS installed, and I am currently attempting to run this image on the BlueROV2 Heavy’s Raspberry Pi 4 (8GB RAM). The Raspberry Pi is running Raspberry Pi OS Lite (Bullseye) with BlueOS 1.1.0-beta.26.

I am having some issues establishing a connection between MAVROS and ArduSub. Specifically, when launching MAVROS within the container, MAVROS indicates successful connections with the specified devices/endpoints; however, I do not receive any information on the MAVROS side. To confirm this, I echo the /mavros/state topic, and have received the following result:

header:
  stamp:
    sec: 1691709106
    nanosec: 196121083
  frame_id: ''
connected: false
armed: false
guided: false
manual_input: false
mode: ''
system_status: 0
---

I have tried a number of MAVROS configurations without any success (receiving MAVLink message) including:

  • fcu_url: "udp://@localhost:5760 | gcs_url: "udp://@localhost:14550"
  • fcu_url: "udp://@localhost:14550 | gcs_url: "udp://@localhost:14550"
  • fcu_url: "udp://@0.0.0.0:14550 | gcs_url: "udp://@localhost:14550"
  • fcu_url: "tcp://localhost | gcs_url: "udp://@localhost:14550"
  • fcu_url: "udp://@localhost:14550"

The configuration that I have been able to use successfully in the past for simulation purposes is

fcu_url: "tcp://localhost | gcs_url: "udp://@localhost:14550"

I am running the container with host networking privileges, but have also tried setting the relevant devices and ports.

I was wondering if there are any folks that have been able to get this working in the past, or if there may be some configurations that I may have set incorrectly? I have also attached some of the relevant configuration files and logs.

EDIT: I forgot to mention, that I also attempted to create a new endpoint within BlueOS to connect MAVROS to; however, that attempt was unsuccessful.

mavros.log (11.2 KB)
mavros_config.txt (455 Bytes)

Cheers,
Evan

2

Hi Evan,

Can you share your docker container for me to test locally ?
If possible, please share it on github for me to compile and checkout, I may help you to create an example for a BlueOS ROS extension.

1 Like
3

Hi @evan-palmer ,

Have you set up a a new mavlink endpoint for it? I’d create a new one to 127.0.0.1, on a new port, and try to connect to it udp://@localhost:[your new port]

4

Can you share your docker container for me to test locally ?
If possible, please share it on github for me to compile and checkout, I may help you to create an example for a BlueOS ROS extension.

Sure thing! Here is the link to the Dockerfile that I am currently testing. The stage that I am building up to is the robot stage, the build context is the root project directory (angler), which you can see in the devcontainer configuration. Though if you would prefer to just pull the image, I have made the arm64 builds available on the GitHub registry here. The version to pull if you choose that route is the rolling image. I can follow up with the docker-compose script that I am using to start everything once I get to my lab and have access to the BlueROV. With regards to the BlueOS extension, that sounds great! Ironically, I have an issue open here for it’s sibling project, though it would be nice to decouple the MAVROS dependency into it’s own extension.

EDIT: Here is the compose script that I am currently testing with docker-compose.txt (373 Bytes)

5

Have you set up a a new mavlink endpoint for it? I’d create a new one to 127.0.0.1, on a new port, and try to connect to it udp://@localhost:[your new port]

Thank you for the response! I did try that, yes. I initially configured it according to the provided pymavlink example, but changed the configuration to use localhost as I am not using the topside computer to run my interfaces. I tested out a TCP client and UDP clients at the following addresses, respectively:

  • udp://@localhost:14770
  • tcp://localhost:14770

For the sake of exhaustion, I made sure to test out server endpoints as well. Something that I would like to note, however, is that in the case of the UDP endpoints, MAVROS is able to establish a connection, but in the case of the TCP endpoints, MAVROS fails to establish a connection at all with a connection refused error. I am fairly convinced that there is a networking configuration error that I have made on my end that is preventing MAVROS from connecting to the mavlink router, though I am not sure what that could be at this point :slightly_smiling_face:

6

I have done some additional testing with pymavlink, and was able to establish a connection to ArduSub from both a topside computer using the ArduSub example script and in the container using my custom endpoint udp://@0.0.0.0:14755 which indicates that there is likely an issue with my MAVROS configuration.

7

After some more debugging, I was able to get a solution together. As expected per my last post, the issue was the MAVROS configuration. I am not fully convinced that the GCS connection string is correct, though I will find out as soon as I try to override the RC inputs :smiley: I have included the relevant MAVROS configurations below for any folks that stumble across this post in the future. @patrickelectric I would be happy to collaborate on a MAVROS extension in the future as well if you think that would be a useful contribution.

Relevant, working MAVROS configurations

mavros_node:
  ros__parameters:
    fcu_url: "udp://:14755@0.0.0.0:14755"
    gcs_url: "udp://@192.168.2.1:14550"
1 Like
8

Have you noticed any significant lag between BlueOS and MAVROS? When we were experimenting with it a couple of months ago, there was almost a one second delay between when MAVROS issued a command and BlueOS receiving it and acting on it.

9

The response times that I have observed have varied according to the command that I am sending. For example, if I send a service request, the response time is a bit longer, though nothing extraordinary (one second would be a reasonable estimate, but I haven’t measured). This is consistent with what I see in simulation as well, albeit the responses are a little faster due to the increased compute power. However, if I send PWM commands to a thruster (or thrusters) using the RC override interface, the response is quite fast. I have been able to do control using MPC and ISMC with the setup used.

EDIT: Something else that I forgot to mention is that how the messages are sent plays a role. When issuing commands via a node, the response times, even for services, are typically pretty quick. If the CPU usage starts to get too high (85%+), I’ve seen the response times increase a bit though. When issuing commands via the ros2cli, commands take a bit longer to be constructed and delivered (which is expected).

10

Very interesting. We may have to rerun our experiment then.

Just FYI, the link you posted earlier to your GitHub and Docker container no longer seems to work. Would you happen to have another link that’s available?

11

Ah, yes. I made that project private again while I get things into an MVP state. I will edit this post to include the project when I make it public. Though most of the BlueROV-specific work that I have been discussing can be seen here (still in a pre-released state). The thing missing from the linked repo at the moment is the Docker image built for arm64, but the Dockerfiles are mostly the same

12

Ah gotcha. I’ve pointed one of my undergraduate senior design groups at your project to see if we can deploy it on one of our vehicles. They want to implement basic waypoint and velocity control and eventually a path planner for navigation and obstacle avoidance. Your work so far seems to be an excellent starting point for them - we are really excited to dig into it and appreciate everything we’ve seen so far!

Would you be willing to collaborate on this effort? I seems like you have invaluable experience with ROS and getting it work on the BlueROV. Together, I think some major features could be implemented!

1 Like
13

I’d be happy to collaborate! Please feel free to send me a message, and we can continue the conversation offline.

1 Like