Hard roll and crash when enabling position control

🧪 Flight Testing & Log Analysis
1

Hardware:
Pixracer running 1.8.0 with PX4Flow and TFMini Lidar on a custom quadrotor body.

Issue:
Experiencing an uncommanded roll to the right which causes a crash under certain conditions.
Initially this would happen in manual flight - we did turn off most lpe_fusion masks and issue went away.

However, after further troubleshooting to get LPE to initialise with both px4flow and distance sensor data, the issue went away under manual flight. As such, we then tested with a switch to position control flight mode. This then induced the same unexpected behaviour where the device veered to the right at high speeds.

It should also be noted that we recently upgraded from a Pixfalcon flight controller to Pixracer (v2 to v4), and 1.7.4 to 1.8.0 which was the point at which this issue began.

Additionally we have tried several rounds of sensor calibration. A second quadrotor body and second Pixracer is being put together which hopefully would rule out any issues with faulty sensors.

Flight Log:

Video of flight:

Parameters:
Estimator: LPE (due to several issues with EKF2 and not using a GPS module)

Modifications to 1.8.0 firmware:

Any ideas on what could resolve this, or what next steps would need be to help troubleshoot this issue?

2

PX4Flow over the wood is working well but not on these monochromatic cushions. Can you check the local pose manually before flying?

Also we are using the EKF2 with success.

3

Few notes,

  • You are using 1.8.0 dev not 1.8.0?

  • Also you should use EKF with 1.8.0 not LPE, not supported anymore.

  • Multiple calibration doesn’t help, you IMU raw values are ok.

  • It seems that you use barometer which should not be used at indoors.

  • Check your fusion mask, disable baro from there

4

We are using 1.8.0 release (96443b3), not dev - just didn’t change the version string.

LPE was required in 1.7.3 by our vision guidance stack to mitigate some other issues that cropped up due to not having a GPS onboard. I will take a look into this new version and see if EKF2 is now viable for us.

The reason we have barometer enabled is to try and give the quadcopter some height values for its first 6" off the ground before the lidar sensor can get a reading. If this is worked around in software or is not an issue otherwise, we can disable it and try - however this was a concern for us and something we hadn’t tested or played around with yet.

We have the px4flow sensor installed according to the PX4 wiki page, so with the arrows in correspondence with the flight controller and SENS_FLOW_ROT = 6. However the behaviour in flight suggests that it might be inverted 180 degrees in the readings it is sending out.

In addition to this, our use of the PX4flow without the sonar, but with an external lidar sensor seems like a use case that is uncommon and specifically locked out in the PX4 code - see our modifications diff to the firmware. Is there any explanation for why this is the case and why the px4flow driver / service needs to be the primary range device? When it is the primary range device however, the tfmini driver / service fails to start as CDev will not return an ok status registering the device. The modifications we have made get both running, but there may be further unforeseen ramifications.