[Bug] urorb: vehicle command refusing to in a flight mode switch

[NXPLoic]

Describe the bug

When sending a vehicle_command with MAV_CMD_DO_SET_MODE (command ID 176) from a ROS 2 node, PX4 acknowledges the command as ACCEPTED, but the flight mode does not change. The navigation state remains unchanged (Navstate = 15).

To Reproduce

Create and publish a vehicle_command message with:

command = 176 (MAV_CMD_DO_SET_MODE)
param1 = 1.0 (base mode)
param2 = 262144.0 (custom mode)
target_system = 24
target_component = 1
source_system = 24
source_component = 191
from_external = false

Observe PX4 console output and vehicle status.

Expected behavior

PX4 should switch to the requested flight mode after acknowledging the command.
Or deny the command with a reason.

Sending other commands (e.g., VEHICLE_CMD_NAV_PRECLAND / command ID 23) works as expected and changes mode.

Tried:
Different target_system, source_system, and component IDs
Changing from_external flag

Screenshot / Media

Console log:
[INFO] [1764765859.886371898] [rc_commander]: Mode change requested: 16
[DEBUG] [1764765860.213064037] [rc_commander]: Vehicle Status: Navstate=15; Time in state=1764765667.312 sec
[DEBUG] [1764765860.474694807] [rc_commander]: VehicleCommand: ts=1764765860474687, command=176, param1=1.000, param2=262144.000, param3=0.000, target_system=24, target_component=1, source_system=24, source_component=191, from_external=false
[INFO] [1764765860.475026322] [rc_commander]: Mode change requested: 2
[DEBUG] [1764765860.488467163] [rc_commander]: COMMAND_ACK: ts=1764765860480765, cmd=176 (MAV_CMD_DO_SET_MODE), result=0 (ACCEPTED), result_param1=0, target_sys=24, target_comp=191
[DEBUG] [1764765860.488678923] [rc_commander]: Vehicle Status: Navstate=15; Time in state=1764765667.587 sec

Flight Log

No response

Software Version

PX4 version 1.15+ dev
ROS2 Jazzy
Cyclone DDS (Communication

Flight controller

Holybro Pixhawk 6X-RT

Vehicle type

Multicopter

How are the different components wired up (including port information)

FMU_V6XRT
NAVQplus
Connected via Ethernet

Additional context

No response

[NXPLoic]

@dk7xe

[NXPLoic]

additional screenshot of the console output:

CMD 23 is Precland CMD 176 is DO_SET_MODE

Any Idea why PX4 Acknowledges the command but does not execute it?

[beniaminopozzan]

He @NXPLoic , do you have a PX4 log file to share?

[NXPLoic]

@beniaminopozzan
https://logs.px4.io/plot_app?log=868bff7a-9118-43e6-8596-af85eb4728f6

I uploaded a file.

This snippet should also show the problem:
Top graph: is the Channel 10 that I was switching
Second graph: Vehicle Command message that was sending a Navstate switch request
Third graph: Vehicle Command Ack that the message was recieved
Fourth graph: Vehicle Status wich stays the same.

[hamishwillee]

If it is not a bug in the ACK code, it might ack and then immediately failsafe. Can precland be tested in SITL in current master? (i.e. is this testable in SITL)? If so, what's an easy setup? note, I'd be testing via MAVLink.

Note, I touched this stuff last in #24704

[NXPLoic]

I found the issue, was of course an error building the topic VehicleCommand.
I set it to a non functional command and the Commander ignored it.
Thank you for #24707 thats exactly the issue.

@julianoes @hamishwillee

@julianoes Actually this does work. I was confused. I can set modes quite happy. It will return accepted for modes you might not expect, but I'm pretty sure that's because the base modes are valid.

what would a safer ACK be? If the command is not explicitly found it should reply with something like this:

VEHICLE_CMD_RESULT_FAILED = 4			# Command executed, but failed |
uint8 result_param1 = cmd_unkown_error				# Also used as progress[%], it can be set with the reason why the command was denied, or the progress percentage when result is MAV_RESULT_IN_PROGRESS
int32 result_param2	= cmd_that_failed					# Additional parameter of the result, example: which parameter of MAV_CMD_NAV_WAYPOINT caused it to be denied.

Whats your opinion here. not really needed?