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:
Power copter from flight battery
Connect MP via 3DR radio
Set FLOW_ENABLE to 1
Reboot Pixhawk (using reboot button from Misson Planner CTRL+F menu)
Check opt_m_x and opt_m_y are showing non-zero values.
Reboot pixhwawk again (using reboot button from MP)
Check FLOW_ENABLE = 1 and opt_m_x and opt_m_y are still showing non-zero values.
The problem:
Disconnect flight battery for 10s
Connect flight battery
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
EDIT:
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.
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.)
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…
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.
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!
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.
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.
