PX4Flow sensor not working - "Bad OptFlow Health"

Andrew_D · December 23, 2020, 5:03am

It appears that this was a common problem in the past. I have read all the threads I could find related to this issue but I found no solution. If anyone could post a link to a solution I’d be eternally grateful. I spent many days trying to make my PX4Flow sensor work but with no luck.

I have Pixhawk Mini FC with AC 3.6.11 firmware (I’ll update to newer version but only if absolutely necessary) and the PX4Flow v1.3 sensor with built-in sonar range finder. I’d like to be able to use the built-in range finder but this is not a must. If need be I’ll use a lidar.
At this stage I am focused on the flow sensor.

I loaded the recommended px4flow-klt-06Dec2014.px4 firmware into the PX4Flow. The sensor connects to an I2C splitter board (with 4-wires) which connects to GPS&I2C port in the FC. It is not connected to the sonar, though there are 2 extra 6-pin receptacles on the Flow sensor board. I assume the rangefinder shares connection with the flow sensor.

After powering up from a battery I get “Bad OptFlow Health” message.
Opt_m_x, opt_m_y, and opt_qua stay at 0.

I eventually soldered +5V and common ground to the I2C splitter from an UBEC, as it was suggested by several people. This made no difference, same error message.

However, when I power the flow sensor from USB port and then boot up the FC, the opt_m_x, opt_m_y, and opt_qua show some values but these values do not change when I move the drone (I think they should). Obviously I cannot use USB port when flying.

I have FLOW_ENABLE = 1
and changed AHRS_EKF_TYPE = 3 as some people suggested, but EKF 2 did not work either.

My board orientation is AHRS_ORIENTATION = 17 (+45 deg yaw, +90 deg roll) while the flow sensor is at default orientation and set to: FLOW_ORIENT_YAW = 0

I don’t quite understand the below parameters but I think they are correct:
FLOW_ADDR = 0 (tried from 0 to 7)
RNGFND_PIN = -1 (tried all of them with no luck and went back to -1)

I’ll be happy to provide more information if anyone has questions.
Really appreciate your help.

amilcarlucas · December 23, 2020, 5:47pm

There is a bug in 3.6.11 please update ASAP to at least 3.6.12

Andrew_D · December 23, 2020, 6:39pm

Thank you! Saves me running around in circles.
This is going to be a huge pain however. I had 3.6.11 modified for my needs by a professional programmer. That was supposed to be a stable version.
Now I will have to go through this same with a new version and then retest on small drones before loading it to my large drone. 3 months at least…
In this case I’ll jump right into 4.0.5 as it supports a lot of new hardware and is listed as stable version. My concerns is - how stable, and bug free is 4.0.5? Would anyone recommend it?

amilcarlucas · December 23, 2020, 10:27pm

3.6.11 was a very stable version, the twelveth iteration of 3.6, with multiple betas. Until the bug got discovered it was as stable as it can be.
Bottom line there is no bug free software, and there are no guarantees. Besides that 4.0.6-rc1 got released today.

That professional programmer should be able to rebase his changes on top of 3.6.12 and recompile in at most 10 minutes. If he can not do it, send it to me I`ll do it.

Andrew_D · December 23, 2020, 10:37pm

Thank you, I’ll take a rain check!
That programmer is a friend of mine. I know he had a big problem compiling some versions. He may be using a compiler that’s not suitable for this.

So which version do you recommend: 4.0.5 or 4.0.6? Which one is safer? I’d hate to crash my prototype. Takes half a year to build one.

amilcarlucas · December 24, 2020, 12:01pm

4.0.6 is still a release candidate. So 4.0.5 is more tested. But 4.0.6 fixes some issues with 4.0.6.
The best way is to look at the release notes and decide which one is better for your specific use case.

Andrew_D · December 25, 2020, 6:32am

Thank you for the link to the release notes.
It appears the latest I can use is 4.0.3 anyway.
I have Windows7 on all my computers because of an expensive software that will not run on W10 (unless I pay $5k/year/copy for maintenance and upgrades).

Any version of Arducopter above 4.0.3 would not connect to MP via USB cable.
With the 4.0.3 loaded, Pixhawk shows as STMMicroelectronics virtual com port and is recognized by my MP.
With versions 4.0.4 and higher, it shows as Pixhawk1, no driver. All my searches have not found any driver for this device for W7.
I also tried to update MP to the newest version (hoping this would solve the problem) but I get a message: Update Failed File downloaded does not match hash:ar/files.html
So unless someone knows of a solution, I’m stuck with v4.0.3
I can connect to my FC with 4.0.4 and 4.0.5 only via telemetry, but not via USB.

There is another, larger issue: it appears that the problem has not been fully fixed for the PX4Flow sensor.
I tried 4.0.3, 4.0.4, and 4.0.5 and in all of these:
opt_m_x, opt_m_y, and opt_qua all stay at 0 when powered from a battery.
There is also a message: Bad OptFlow Health
If connected via USB cable they show values that change if drone moves (opt_qua stays constant = 255).
After battery is connected and USB disconnected, all those parameters freeze and will not change.

I believe that some people successfully use the PX4Flow sensor. I wonder what they did to make it work. Could this be somehow related to the FC I’m using (Pixhawk Mini)?

amilcarlucas · December 25, 2020, 10:20am

Do not update MP. Just download the latest version manually instead of doing the in-app update.

Andrew_D · December 26, 2020, 5:29am

Thanks, will do. Will uninstall the current one and load the latest. Appreciate you’re taking time to read my posts on Christmas! You are truly my Santa Clause!

I’m tinkering with the 4.0.x versions. It’s a shame that this issue has not been fixed. The only way to make the PX4Flow work is to power it first thru PX4Flow’s USB port, and then connect the battery and disconnect the USB.
Right now I’m thinking of the easiest way to make it work with some added hardware. An extra UBEC and a manual 3-way switch…
Or pretty ask my friend, the programmer, to change the boot-up sequence. All the posts since 2016 say that PX4Flow needs to be powered before powering the FC.

amilcarlucas · December 26, 2020, 10:01am

There is the BRD_BOOT_DELAY parameter that delays the boot of the arducopter FW. That parameter will do the trick no need for a second ESC or to change the software.
And please stop wasting time testing multiple 4.0.x versions, just use the latest one.
If you really, really want to experiment around, just experiment with 4.0.5 and 4.0.6-rc1. Do yourself and us a favor and ignore all others.

Andrew_D · December 27, 2020, 4:18am

BRD_BOOT_DELAY = 2000 works. I tested only 2000, but lower values may work too.
Nice and clean solution. This should go to PX4Flow setup description.

It also works without additional power to I2C splitter from UBEC, suggested as necessary in multiple threads.

After confirming by more testing I’ll edit my initial entry and will post it as a solution for those who search the same issue.
Thanks a million Amilcar!

Andrew_D · February 3, 2021, 5:09am

Thanks for your help. I have converted everything to 4.0.5. After changing the BRD_BOOT_DELAY my flow sensor is working nicely. But now I have a new problem: the 4.0.5 resets one parameter inside my LIDAR to its default value.

The AC 4.0.5 resets the “Lost Signal Confirm Time” inside my SF11c rangefinder to its default value of 0.05 (connected to Pixhawk via I2C bus). The manufacturer requested me to reset this parameter to 3.0 to eliminate large spikes in the height readings. Unfortunately the 4.0.5 resets it back to 0.05

The AC 3.6.11 does NOT reset this or any other parameter inside the SF11c rangefinder.
Do you know if there is a parameter in the AC 4.0.5 that I should change to fix this problem?

Cheers

amilcarlucas · February 3, 2021, 8:43am

You can take a look at the SF11 device driver to see if that value (0.05) is present in that code. If it is not, then it is not a device driver issue

Andrew_D · February 3, 2021, 7:48pm

Thank you. If it helps, below is a preliminary explanation that I just received from Lightware:

“I have confirmed with our software engineer that the lost signal timeout is being reset when connected to the I2C bus, they are resetting this value to 0.05s, the result of which is that when the lost signal timer has internally finished, it reports a lost signal, which in the case of the SF11 could be reported as 150/130.
From these few tests it is pointing to an Ardupilot issue, that the lost signal timer is too short.”

I must add, that it does not happen in 3.6.11

This doesn’t tell me much, but I hope it will point you in the right direction. At Lightware I am working on this with Mohit Morar, whom I’m sure you must know.

amilcarlucas · February 3, 2021, 8:03pm

Is this a serial, or and i2c?

or

You can also compare 4.0 branch with 3.6 branch:

github.com

ArduPilot/ardupilot/blob/Copter-4.0/libraries/AP_RangeFinder/AP_RangeFinder_LightWareI2C.cpp

/*
   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */
#include "AP_RangeFinder_LightWareI2C.h"
#include <AP_HAL/AP_HAL.h>
#include <AP_HAL/utility/sparse-endian.h>

extern const AP_HAL::HAL& hal;

This file has been truncated. show original

and

github.com

ArduPilot/ardupilot/blob/Copter-3.6/libraries/AP_RangeFinder/AP_RangeFinder_LightWareI2C.cpp

/*
   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */
#include "AP_RangeFinder_LightWareI2C.h"

#include <utility>

#include <AP_HAL/AP_HAL.h>
#include <AP_HAL/utility/sparse-endian.h>

This file has been truncated. show original

Because it should be a single file you should be able to find it

Andrew_D · February 3, 2021, 10:49pm

I can connect my SF11c through I2C only.

The cpp files you attached above do not tell me much. Should I do anything with them?
What do you mean by “compare 4.0 branch with 3.6 branch”?

amilcarlucas · February 4, 2021, 2:59am

If you compare the last two files I sent you, you will see the exact changes in the lightware i2c device driver between ArduCopter 3.6.12 and 4.0.6

Either your software engineer or Mohit Morar should be able to fix it then.

Andrew_D · February 4, 2021, 3:33am

Thank you Amilcar. I take it then that this is Lightware problem. I’ll pass it to Mohit.

ton999 · February 4, 2021, 1:48pm

Hello @amilcarlucas,
Please help me, I also have similar problem with PX4Flow sensor using Windows10. First problem is Windows10 can not run the PX4Flow sensor correctly even though I have installed the driver according to the documentation. I the device manager of Windows10 the PX4Flow shows error sign (as if it does not have correct driver). As a result Mission Planner does not recognize this sensor (Can not enable the parameter). But the sensors seems working ok as the Leds light (On) as if it is working. So I suspect this is because of the current driver is Not compatible with Windows10. I have followed the link to the Windows driver according to documentation. Please advise me how to solve this problem…
Thank you.
Tony

Andrew_D · February 5, 2021, 4:16am

Hi Tony,
I’m sure Amilcar will be able to help you. But before you talk to him I would advise you to load Arducopter 4.0 or higher to your flight controller. That version has a parameter: BRD_BOOT_DELAY which you should set to 2.0 through Mission Planner.
This parameter makes PX4Flow boot before the flight controller boots up. Otherwise PX4Flow will not work even if the lights in the flow sensor are on. I don’t think this has anything to do with Windows 10 but I am not an expert so I can be wrong. Either way - the PX4Flow must boot up before the FC boots up and this is possible in AC 4.0.x
BRD_BOOT_DELAY = 2.0