set_mode service always returns true

[tfoote]

I was just debugging a script for controlling a vehicle and was having trouble with sequencing. And I found that the set_mode service always returns true whether or not the state transtion was accepted.

It might fail if the state is invalid but doesn't fail otherwise.

[vooon]

Yes, for some reasons success only show mode parsing status (it may be one from list, or numeric). Unfortunately there are no reliable method to wait AP response. AP may switch to other mode, may switch with some pause, may switch on RC change, so i decided to leave mode change control to user. Example: OFFBOARD may not enable after SET_MODE if there are no setpoint (target), and switch after you stream targets.

So you should implement mode monitoring in your node: a. Subscribe to ~state and check mode, usually it update rate is 1 Hz (HEARTBEAT), possible values:

• one of cmap_mode entries (APM, PX4)
• MODE(0x00) if AP only support base_mode
• CMODE(123) if AP support custom_mode, but mode is unknown

b. Call ~set_mode and wait mode change.

Perhaps i should add note to wiki.

[TSC21]

@tfoote does @vooon solution works for you?

[tfoote]

Well the suggestions are ways you can work around it and use other mechanisms. They're not a solution for the underlying problem.

If the service always returns true. The field should not exist: https://github.com/mavlink/mavros/blob/master/mavros_msgs/srv/SetMode.srv#L22

If I come in an introspect this message (as I did) I expect the service to return true if the SetMode service succeeded, else false. (As the name "success" implies.) There should at least be strong documentation in the srv file to say otherwise if not removing the field.

Or else this callback could actually do the polling to wait for an observed change.

[TSC21]

@vooon do you have time so we look into this closely?

[vooon]

@tfoote @TSC21 well, success may return false, if requested mode unknown or unparsable. Perhaps better to rename that flag to something like parsing_ok.