AC3.5rc8 FLOW_ENABLE resetting to 0

Using AC3.5 RC8, I keep finding FLOW_ENABLE resetting back to zero.

If the PX4FLOW board is already running when the Pixhawk boots up it works fine, however if they are both powered on at the same time, FLOW_ENABLE is reset to 0

I can reproduce this easily:

  1. Power copter from flight battery
  2. Connect MP via 3DR radio
  3. Set FLOW_ENABLE to 1
  4. Reboot Pixhawk (using reboot button from Misson Planner CTRL+F menu)
  5. Check opt_m_x and opt_m_y are showing non-zero values.
  6. Reboot pixhwawk again (using reboot button from MP)
  7. Check FLOW_ENABLE = 1 and opt_m_x and opt_m_y are still showing non-zero values.

The problem:

  1. Disconnect flight battery for 10s
  2. Connect flight battery
  3. See FLOW_ENABLE is now back to 0 in MP.

I have tried this with the PX4FLOW powered from both i2c power, and have just rewired it to get power from the 2nd BEC on the servo rail (measured clean 5v), so this is not a voltage sag issue.

To be sure, I’ve reflashed the correct KLT flow firmware from the link on the Copter docs.

This was working perfectly in AC3.4.6


Seems similar issues have already been reported elsewhere:

Fwiw…I had this problem both when I first installed my Px4Flow and when I upgraded to pH cube. I forgot both times that the pinout is reversed on the px4flow…at least on mine. Meaning the connector pins reverse at the px4flow corresponding to the i2c connection on the fc.
Worth double checking.

@Lance_B thanks for your suggestion. I just tried swapping the i2c pins round but this stops it working altogether, so I’m sure I’ve got it hooked up correctly.

I’ve managed to narrow down the problem further, and this is somehow linked to the RC input.

Test 1:

  1. RC transmitter (Taranis) turned on.
  2. Set FLOW_ENABLE to 1
  3. Disconnected flight battery
  4. Connect flight battery

Result: FLOW_ENABLE has reset to 0

Test 2:

  1. RC transmitter turned off (X8R sends no pulses to SBUS input)
  2. Set FLOW_ENABLE to 1
  3. Disconnected flight battery
  4. Connect flight battery

Result: FLOW_ENABLE is still set to 1 and optical flow is working.

I get the same results every time without fail.

To sumarise:

flow_enable is NEVER reset to zero in the following conditions:

  1. Warm boots of Pixhawk (reboot via Mission Planner reboot button) while PX4FLOW remains powered up.
  2. Cold boots of both Pixhawk and px4flow when the RC transmitter is turned off during bootup.

flow_enable is ALWAYS reset to zero in the following cases:

  1. Cold boots of Pixhawk and px4flow when the RC transmitter is turned ON

Hopefully someone else can reproduce this as it happens like clockwork here!

Just to be sure, this is something you’ve had working?

You’re using a working rangefinder?

You’re lifting the craft after booting and getting the audible tone?

I’ve found the software reboot to be unreliable, personally. I tend to power cycle instead.

Yep - everything was working fine on AC3.4.6, and still works now except for the cases above.

Is it possible this is simply a startup a timing problem, where Arducopter is trying to connect to the PX4FLOW before it’s ready?

The RC transmitter being on / off definitely does make a difference for me (100% reliable when testing on my setup) but maybe this is just introducing a small delay somewhere giving the PX4FLOW just enough time to finish starting up?

If I power the PX4FLOW from a separate supply (only SDA, SCL & GND connected to Pixhawk) so that the PX4FLOW has already booted up when the Pixhawk starts, it works every time without fail (RC transmitter off or on, battery power only, usb power only etc etc.).

I’m no programmer but maybe someone could compile a version of AC3.5 that simply has a Sleep(5000) or equivalent at startup we could prove / reject this theory pretty quickly.

(FYI to double check, last night I downgraded to 3.4.6 without changing any wiring and everything worked perfectly again.)

Good analysis of the problem.

I think we saw a report similar to this earlier in the AC3.5 testing and it was resolved by powering the flow sensor with a BEC.

We’ve changed quite a lot of things between AC3.4.6 and AC3.5 so it’s possible the startup time is different (perhaps less) and that might be exposing the problem. I suppose we could introduce a delay into the optical flow’s startup although it pains me a little every time we try to solve hardware issues with software fixes…

Hi Randy,

In the case where connecting a separate BEC resolved the issue, I’d think this was probably because the new BEC had a faster power on rise time than the BEC powering the Pixhawk, allowing the PX4FLOW to get ahead of the Pixhawk starting up. We’re likely dealing with a few miliseconds difference in startup times to cause success or failure.

I’m probably an edge case or we’d be seeing more reports of the same problem (presuming a decent number of people have actually tested AC3.5 with PX4 flow.) but I’d think a small startup delay for optical flow would be an effective (and hopefully not too troublesome) fix.

1 Like

Sadly I’m still struggling with this (same on Copter 3.5 RC9).

I’m wondering if there is a particular reason why the flow_enable parameter is changed when the optical flow isn’t detected? This doesn’t seem like standard behaviour for external devices - e.g. if copter is booted without GPS or rangefinder, no parameters are changed so when they are re-connected everything works again…

On a separate note, I’ve just been testing AC3.5rc9 using GPS blending, Optical flow and laser rangefinder… the position hold accuracy is seriously impressive now. Really incredible work!


1 Like

@rmackay9 might this have anything to do with it?

It seems to have vanished from the latest AP_OpticalFlow code.

We don’t actually use the px4 driver anymore, we’ve moved it “in tree” (i.e. into ardupilot). The timing of the start-up could definitely have changed and it’s certainly possible that we are attempting to communicate with the flow sensor earlier than before.

I’m not sure if the solution is to add a delay or perhaps to run the detect or init calls a few more times at startup.

I am having the same problem. The FLOW_ENABLE parameter keeps resetting to 0 whenever I powercycle the system.

Running AC 3.5 and Pixhawk 2.
I have an external BEC supplying power to the I2C bus, i.e. to the PX4FLOW.

Could it be, that the risetime /startuptime of my BEC is just to “slow”, since its working for you guys?

Fabian :slight_smile:

Any ideas? Still having the same issue.

It seems like the Pixhawk only checks for an active PX4 Flow sensor on boot. When I disconnect and reconnect the PX4 Flow while the Pixhawk is powered it does not reset the FLOW_ENABLE parameter.

My only solution would be to add a small power switch between power and Pixhawk, so that I can power the Pixhawk after everything else is initialized.

Fabian :slight_smile:

Randy has made a fix that will hopefully resolve this issue.
I’ve not had a chance to test it yet but maybe I will have time on Sunday.

Link in this post: