Intermittent failures to switch to Position Control in 1.13.0

After upgrading to 1.13.0, I’m experiencing intermittent failures to switch to Position control mode while the MC is stationary on the ground before lift off. Sometimes, I am able to switch to Position control after waiting some time on the ground. Other times, I start flying in Altitude mode and then can switch to Position mode (which is anyway sometimes hit sometimes miss).

Here is an example of PX4 complaining about valid position estimate (notice 3D DGPS fix with 14 dats in view):

Dmesg log is also not too informative:

NuttShell (NSH) NuttX-10.2.0
nsh> INFO [vehicle_magnetometer] MAG switch from #0#1
WARN [ekf2] 1 - mag sensor ID changed 396825 → 4395785
WARN [ekf2] 0 - mag sensor ID changed 396825 → 4395785
INFO [gps] u-blox firmware version: HPG 1.13
INFO [gps] u-blox protocol version: 27.12
INFO [gps] u-blox module: ZED-F9P
WARN [commander] Switching to Position is currently not available
WARN [commander] Switching to Position is currently not available
nsh>

Hi @j_p ,

A failure to switch into Postion mode is normally a sign that the local position estimate isn’t valid. If you provide a log file, I should be able to tell you why the local position isn’t valid; it’s probably because some metric is at the limit. I don’t think we changed the criteria between 1.12 and 1.13 but understanding why it fails for you should give me a hint.

I have shared the log file directly, and would appreciate any pointers where to look.

@bresch, I am having a similar issue - unable to switch to Position Mode (MC) indoors, using optical flow and range to replace GPS. Earlier this year, I thought I was able to fly in position and hold mode using optical flow. I will send both logs to you privately. I am not sure how to explain the difference in performance.

Both builds:

  • px4flow v1.3.1
  • lidar lite v3
    Both are on and the optical flow quality (~254) is high.

Position mode did not work indoors:

  • EKF2_AID_MASK : 2
  • SENS_EN_PX4FLOW : enabled
  • SENS_EN_LL40LS : I2C
  • EKF2_HGT_MODE : 2

Position mode did work indoors:

  • EKF2_AID_MASK : 7
  • SENS_EN_PX4FLOW : enabled
  • SENS_EN_LL40LS : I2C
  • EKF2_HGT_MODE : 2

In both indoors locations, the drone was able to lock onto 10-15 satellites. It is possible that in the working case, with EKF2_AID_MASK : 7, the drone was using GPS instead of optical flow for state estimation.

More details on the setup:

HW arch: PX4_FMU_V5
HW type: V500
FW version: 1.13.0 0 (17629184)
FW git-branch: stable
OS: NuttX
Build datetime: Aug 13 2022 15:40:51
Build uri: localhost
Build variant: rtps
Toolchain: GNU GCC, 9.3.1 20200408 (release)

The fundamental question, is it possible to fly indoors using optical flow + range sensor alone? Or is the only option for a non-GPS case some sort of external position estimation (vision or motion capture)?

Was the flow sensor reporting data and with a good enough quality metric? A log might be helpful to investigate.

Yes, this mode of operation is supported by EKF2.

Nope, optical flow + range finder is fine.

1 Like

@nsimon I quickly checked the logs you sent to me and you forgot to mention that you were using 2 different software versions, this is the reason why one worked and not the other one. On the log where is doesn’t switch to position mode, it’s because CBRK_VELPOSERR is set and then the checks are not performed at all so they cannot pass.
The optical flow fusion seems to work properly so if you set CBRK_VELPOSERR back to 0 you should be good to go.

1 Like

@bresch Thank you so much for taking a look at this. You are absolutely correct.

Setting CBRK_VELPOSERR = 0 enabled BOTH switching to position and offboard modes indoors, with reference to optical flow for state estimation.

For those curious, here is the associated flight log.