Rover 4.6.3: MAV_CMD_DO_REPOSITION returns MAV_RESULT_DENIED

ArduRover Rover 4.6
1

We have been using a surface vehicle, commanded via LTE and a script that takes the incoming messages from the server and creates the necessary mavlink commands to the autopilot.
We have successfully been using it at lower altitude lakes and on sea level. But this weekend we are trying the vehicles on alpine lakes (over 1200m altitude) and the Reposition command is being “DENIED”…
Everything worked great last weekend on lower level lakes and now suddenly not… We have plenty of satellites and EKF is working fine. We found a workaround by using “set_target_location” and that works!

Here is a AI generated summary that includes everythiing… Has anyone else experienced a “DENIED” reposition command?

ArduPilot version: Rover 4.6.3 (3fc7011a)
Board: Pixhawk6C
Frame: Boat (FRAME_CLASS=2)
Autopilot config: ARMING_CHECK=0, GUID_OPTIONS=0, FENCE_ENABLE=0

Summary:
MAV_CMD_DO_REPOSITION, issued from a Lua script via gcs:run_command_int(), consistently returns MAV_RESULT_DENIED (2) — every attempt, across multiple sessions — despite the vehicle being armed, already in Guided mode, and the target coordinates being verified correct.

Reproduction:

  1. Vehicle armed, switched to Guided mode via a prior MAV_CMD_DO_SET_MODE call (succeeds)
  2. Script calls:

lua

gcs:run_command_int(MAV_CMD_DO_REPOSITION, {
  frame = MAV_FRAME_GLOBAL_RELATIVE_ALT,
  p1 = <valid positive speed, e.g. 1.5>,
  p4 = NaN(),
  x = <target lat, int32 *1e7>,
  y = <target lon, int32 *1e7>,
  z = NaN()
})
  1. Return value is consistently 2 (MAV_RESULT_DENIED)
  2. Confirmed via logging: arming:is_armed() returns true at the moment of the call; mode is confirmed Guided (15) well before the call (>1 second prior); target coordinates verified correct by cross-referencing against actual vehicle position

What we ruled out before concluding this was a command-handler-level rejection:

  • GPS quality, EKF innovation gates (tested with both default and significantly loosened EK3_GPS_CHECK/EK3_*_I_GATE values — no change)
  • EKF height source (baro vs GPS — no change)
  • EKF core configuration (single vs dual IMU core — no change)
  • Compass/yaw accuracy (confirmed correct independently)
  • Barometer ground-pressure calibration (confirmed correct for elevation)
  • Command frame/altitude mismatch in our own script (found and fixed a real bug here — relative-alt frame declared while sending absolute altitude — but fixing it did not resolve the DENIED result)

Workaround found:
Replacing the gcs:run_command_int(MAV_CMD_DO_REPOSITION, ...) call with the direct scripting bindings:

lua

vehicle:set_target_location(loc)
vehicle:set_desired_speed(speed)

resolves the issue completely — the vehicle navigates to the target correctly and reliably. This suggests the rejection originates specifically in the MAVLink command-handler layer (GCS_MAVLINK’s processing of COMMAND_INT for this command), not in the underlying Guided-mode navigation logic itself, since the latter works fine when invoked directly.

Open question:
We observed this behavior at two different high-altitude alpine locations (~1550–1800m elevation) after the same vehicles/scripts had worked reliably at lower-elevation lakes (~400–550m) with no configuration or code changes in between. We were not able to identify a confirmed mechanism connecting altitude/location to the DENIED result — GPS signal quality by conventional metrics (satellite count, HDOP) appeared normal throughout — but the correlation was consistent and reproducible across two independent hardware/firmware-script combinations. Flagging this in case it’s a known or reproducible pattern, or in case the command-handler check in question happens to be sensitive to something location-dependent that isn’t obvious from the outside.

Happy to provide dataflash logs from the failing and working sessions if useful.

2

If you can send a dataflash log and example MAV_CMD_DO_REPOSITION message (that give s a MAV_RESULT_DENIED result) I can take a look.

3

Thank you. Here are two logs

4

Just for additional information: we do have a 250ms time period from the moment that GUIDED has been set and we then send the DoReposition command. I would think that is appropriate? or is that too short?

5

I’ve had a closer look at the Rover source code.

I was able to replicate your issue. However, by setting the z (altitude) to 0, the command was accepted:

gcs:run_command_int(MAV_CMD_DO_REPOSITION, {
  frame = MAV_FRAME_GLOBAL_RELATIVE_ALT,
  p1 = <valid positive speed, e.g. 1.5>,
  p4 = NaN(),
  x = <target lat, int32 *1e7>,
  y = <target lon, int32 *1e7>,
  z = 0
})

Can you check if that works for you?

6

Thanks for the suggestion — z=0 changed the result from MAV_RESULT_DENIED (2) to MAV_RESULT_FAILED (4), consistently, across three separate attempts (attached log). The vehicle still doesn’t navigate to the target in any of them — distance stays flat rather than closing. This is on the bench, not in water, so I can’t yet rule out that being a factor, but wanted to share this result in case it’s useful on its own.

7

Try setting the p1 to -1 (default speed)

8

Stephen, long story short. It worked.
While we were fixing the altitude problem, we simultaneously also changed P1…
creating a new problem… Altitude calculation was the original problem… Fixed it , but at the same time intriduced a new error. my bad..

Thank you for your help… will do some more testing.

Best regards, chris