Altitude control fails due to SF000b rangefinder malfunction

ArduCopter Copter 3.6
1

Hi there,

I have a quadcopter with Pixracer running ArduCopter 3.6.2.
am using lightware sf000b rangefinder as the downward rangefinder and as the primary height adjustment source connected directly to Pixhawk.
Flying around 3-4m height in indoor environments. During stationary test conditions, I verified that the sensor was reading good values.

But in flight, I experience several crashes where Downward sensor values decreased randomly for a moment irrespective of the actual distance during flight.
Due to these issues, the drone shoots up and crashed onto the roof.
with Logs analysis seems there are 2 different scenarios:

  1. Sensor value freeze for a certain period (around 2~3 seconds)
  2. Sensor value suddenly decreases and the drone shoots up.

FYI: this behavior always occurred around 3min flight time.
here are the logs: Alt_Logs - Google Drive

If possible, could anyone help to find out what goes wrong here?

2

Is it not possible to update for the latest stable release in this FC?

I know that this kind of feature of indoor navigation has massive improvements since this version you are running.

3

I thought so as well,
but I would like to know the root cause first (why this happening) then I will update

@BrunoBagarini do you think sensor temperature or EMI could play a role?
Thank you!

4

I don’t no, I have no experience with this kind of flight profile… but give it a try to a newer version of arducopter, it most probably will help you…

5

@BrunoBagarini, @rickyg32 and @rmackay9
The primary height adjustment source is a lightware SF000b rangefinder, connected via IIC to mRo pixracer but I have seen some weird behavior.

I’m not an expert in log analysis but I would like to get opinions from your experience. Flight log attached here

  1. Why DSAlt get lost or what could cause DSAlt to be lost In-flight?
  2. If DSAlt disappeared In-flight how will the flight controller react to altitude control?

image
image1897Ă—993 114 KB

6

Hi @M.Olivier,

The CTUN.DSAlt value is disappearing when the rangefinder fails. We can see how they happen together by graphing CTUN.DSAlt along with the RFND.Stat1 (status for 1st rangefinder). DAlt disappearing is correct behaviour because the vehicle is switching out of “surface tracking” mode (this is what we call it when a lidar is used to maintain altitude with a rangefinder in manual modes like AltHold, Loiter, etc).

image
image1519Ă—1064 50.3 KB

It looks like the EKF2 has been configured to use the rangefinder for altitude which is generally a bad idea (e.g. EK2_ALT_SOURCE = 1). It may be OK to do this indoors (which is where you’re flying) but if you’re flying the vehicle in manual modes it shouldn’t be necessary.

Copter-3.6 is very old now and I agree with @BrunoBagarini that it would be good to upgrade to 4.3 and use the EKF3. The core dev team doesn’t really have the resources to support software that is this old. Although we don’t have an official policy on the matter, we tend to only provide support for the latest 2 versions (e.g. 4.3, 4.2) although sometimes we make exceptions.

2 Likes
7

@rmackay9 Thank you for the detailed explanation, it helps a lot.
regarding upgrade, I did but have not tested it yet in the same environment.

Actually, I would like to get your expertise on what might cause the rangefinder to fail.
Does rangefinder failure rely (contingent) on compass or I2C interface?

Hardware connection
Hardware connection1178Ă—655 71.7 KB

The above picture is a schematic of how the rangefinder connected to FC.

8

Hi @M.Olivier,

I don’t really have any good ideas about why the rangefinder might fail especially after 3min or so. Maybe the 5V power supply from the autopilot isn’t sufficient… maybe an external BEC should be used. I really don’t know though.

2 Likes