RC override not working with SITL ArduSub + Mavros

Hello.

I am trying to use SITL with Mavros to send rc override commands, something really simple. But it is not working. The funny thing is that I am using a program that was working before (in December 2021), so I guess it is probably something related to software versions. Since then, I upgrade my OS packages (ubuntu 20.04) and the ardupilot repo to use the current master version (I also tried with arduSub-stable, and a version from commit 37a1b32).

Basically, I am doing the following things:

  1. Set mode to ‘MANUAL’
  2. Arm motors
  3. Publish override msg into the /mavros/rc/override topic, like channels: [1500, 1500, 1500, 1500, 1700, 1500, 1500, 1500, 1500, 1100, 1500, 0, 0, 0, 0, 0, 0, 0]

The result is that the vehicle is in MANUAL mode, the motors get armed but it does not move.
Am I missing anything? Any specific versions I should use?

This gets printed in the console (not sure if it is relevant)
Got MISSION_ACK: TYPE_RALLY: UNSUPPORTED

Hi @rezenders,

I haven’t used SITL much, and haven’t used mavros at all, so I’ve asked the software team to take a look at this in case they know what’s likely going on :slight_smile:

It would likely be useful if you can specify the ArduSub version you’re simulating, and how you’re running your code.

and rally points are part of missions, so it seems odd to me that they’re apparently being used, especially if you’re trying to manually control the simulated vehicle.

Separately, does it work if you wait for a while? If so you might be facing something similar to this.

ArduSub only accepts RC override messages from the GCS (e.g., mavros).

I have worked around this 2 ways:

  1. comment out this check
  2. run mavros as the GCS

Neither of these methods are ideal. Perhaps others have better solutions.

Thanks,
/Clyde

I’m a bit confused as to the perceived issue here - if mavros is being used to control the vehicle, would it not effectively be the GCS?

True, it works, but it is a bit clunky to use mavros + ROS to do simple things like logging, arming, changing params, etc.

I’m not familiar with the workflow. Changing params is configuration, which I’d generally expect to happen before operation rather than during live control. Assuming you use a more standard GCS application for initialisation and then hand off control to mavros once the vehicle is configured and armed, couldn’t the application continue to receive and log MAVLink messages but allow mavros to take on the role of the GCS?

Thanks for the replies.

  1. run mavros as the GCS

And how can I do that? Setting sytem_id to 255? Something like this?

ros2 param set mavros system_id 255

or for ros1
rosparam set /mavros/target_system_id 255

EDIT:
So, I figure out that I can set the fcu_url as udp://:14551@:14555/?ids=255,240 and then it works. I am not sure why the value 240, I understand that 255 is the GCS sys_id.
I found the answer here

EDIT 2:

At least it worked for ROS1, but it didn’t work for ROS2 using this command to run mavros:
ros2 run mavros mavros_node --ros-args --param fcu_url:=udp://:14551@:14555/?ids=255,240

The vehicle will only accept RC messages from the GCS, you should be able to run both mavros and QGC with the same ID, at least that what I tested a couple of years ago working on the BlueROV2 playground for ROS.
You can check it here: GitHub - patrickelectric/bluerov_ros_playground: Scripts to help BlueRov integration with ROS

I would also recommend to create a .lunch file to organize your startup setup.

1 Like

I like the idea of quickly moving quickly between manual and [external] automated control. So it seems handy to have both mavros and QGC connected if possible.

I just learned that mavros will act as a proxy, with connections to both the FCU and GCS, e.g.:

mavros_node:
  ros__parameters:
    fcu_url: "tcp://localhost"
    gcs_url: "udp://@localhost:14550"

I will try to see if I can get this to work for my use case.

Thanks, @EliotBR

2 Likes