Hello everyone!!
I am really glad some of the community members have been using the ROS2 extension ^-^
Based on some of the questions I’ve been getting, I added some extra feature to the extension
MAVROS: Includes a launch file to communicate with the flight controller (vehicle)
Foxglove : Web-based RViz for visualizing ROS2 data
mavros_control: Includes a python script to control the vehicle using GPS-based waypoints (BlueBoat) and RC-control (BlueROV2) via mavros
The extension also mounts the following folder on the computer running BlueOS to the home directory folder in the extension’s Docker container, which can be used to store files that need to persist across reboots, such as a ROS2 workspace with custom code:
Hi! I have been using your original blueos-ros2 extension that launches MAVROS through Docker. I am having issues with sending RC commands. I can ARM/DISARM the vehicle through MAVROS, and can echo the MAVROS topics. However, I can’t seem to get the /mavros/rc/OverrideRCIn topic to do anything.
This is based on a MAVLink UDP Client endpoint I made on Port 14770 (through the blueos webpage) to another Pi which I am intending on using as the control station computer.
I have read that I may need to change the sys id on QGC to 1? Is there anything else I need to consider? Should I also include a gcs_url in my launch command?
Thank you! I have enjoyed working with your extension so far.
Yup, you need to change the sys id to 1. But also the fcu url is different on BlueOS, the extension launches mavros with the correct fcu_url, you shouldn’t have to change it
As I try and clone your repository using your commands provided online, I get an error when trying the fetch the mavros_control submodule path. Following it through GitHub too I find that it is not accessible. I am not sure if the issue is on my end?
Hi! @Bibxi123
It works with any 64bit version of BlueOS. Mainly because ROS2 does not natively support 32bit systems. I recommend starting with BlueOS 1.4.2.
Also, keep your eyes peeled for v0.0.3 of the plugin, it will include sonar and camera packages ^-^
I am back looking at sending RC commands through ROS2. I am simply publishing commands like this through the terminal (inside the blueos-ros2 Docker extension):
I have noticed that whenever I set the PWM of a channel between 1100 to 1800 using this command, it automatically sets the PWM to be 1800. I was wondering if anyone has had this issue?
@clyde The new version of the extension uses sysid 255 which is the same id used by QGC and Cockpit. If either of those applications are running alongside mavros, they will override the messages.
You can either change the mavros config to use sysid 1 to resolve the issue or close the ground control applications to avoid interference
I am also currently trying to mount volumes to the docker container using the blueos-ros2 image but am having issues with this. Is there a specific path inside the container that I should mount to so that I can avoid mount issues?
One more question… when I run ros2 launch mavros apm.launch inside the Docker container, the Mavros script runs however I end up getting timeout errors indicating a failed connection to the BlueROV2. It is a Timeout error indicating retrying connection for 5 seconds. Any idea why this might be happening?
First off, thanks to everyone for the hard work on this. It has made my work significantly easier.
That being said, I just wanted to echo that I am in a similar situation.
I was able to reproduce all the steps described in this forum post and other related ones to get command line commands working for arming, disarming, mode switching, and manual rc overrides, all verified via return messages, vehicle state, etc.
However, when I run:
ros2 launch mavros apm.launch
or
ros2 launch mavros_control demo.launch.py
I get a host of timeout errors, among other things. Happy to paste logs as needed here but was curious if these are known issues or if there is additional configuration that is needed to launch some of the examples such as the demo. I have some thoughts as to what might be needed to get the demo to work, but I figured I’d check here before continuing to alter system level parameters.
@blutonomy@j_vivum It’s a common issue with ardurover used on the BlueBoat. The feature syncs the clock between the raspberry pi and the filght controller. You can relax the sync rate with the “timesync_rate“ ros parm available in the mavros package, need to be run everytime use launch mavros:
ros2 param set /mavros timesync_rate <desired_rate_value>
or add set it from the apm_config.yaml file.
Set the value to 0 to disable the feature or decrease the update rate, e.g., 1.
I haven’t had any issues with disabling the feature, but BlueRobotics might know better
