I am trying to use ArduPilot on a Flywoo GOKU F405 HD 1-2S ELRS AIO V2 flight controller.
I have tested two different flight controllers of the same model, and both show exactly the same behaviour.
Firmware tested
ArduCopter 4.6.3 (official release)
ArduCopter 4.8.0-dev
Board target: FlywooF405HD-AIOv2
Full Chip Erase (Mass Erase) performed before every flash.
Problem
The onboard barometer is never detected.
BARO1_DEVID = 0
BARO1_GND_PRESS = 0
No barometric altitude is available.
Both flight controllers behave exactly the same.
Additional information
I checked the official firmware package (features.txt).
The firmware already includes:
AP_BARO_DPS280_ENABLED
AP_BARO_SPL06_ENABLED
According to Flywoo, this board may be equipped with either a DPS310 or an SPL06 barometer depending on the hardware revision.
Since the same problem occurs on two different boards with both ArduCopter 4.6.3 and 4.8.0-dev, I suspect this may not be a hardware failure.
Could this be related to the board definition (hwdef) for the FlywooF405HD-AIOv2 target, or is there anything else I should check?
I have attached screenshots showing:
BARO1_DEVID = 0
BARO1_GND_PRESS = 0
the enabled barometer drivers from features.txt
Any help or suggestions would be greatly appreciated.
Thank you very much.
Update: Flashed original Betaflight target FLYWOOF405S_AIO. Gyro and accelerometer work normally. Betaflight detects a DPS310 barometer. Under ArduPilot the barometer fails to initialize (Baro: unable to initialise driver, BARO1_DEVID=0). This suggests a board-definition or DPS310 initialization issue rather than faulty hardware.
From a bit of searching and googling, I suspect the issue is that the DSP310 can use I2C address 0x76 or 0x77. AP’s Flywoo hwdef says it should be 0x76 but perhaps the board you’ve got is 0x77. There is apparently a pulldown on the sensor that allows choosing which address is used but no idea of course as to whether that’s exposed on the board (probably not) or whether it’s hard-coded.
If you’re comfortable compiling the code yourself, it would be good to test changing this line to 0x77 and see if that helps.
If that works then the next question will be whether all the Flywoo boards use 0x77 or is it a hardware mistake in the board you have.
If it’s not too much trouble, would it be possible for you to provide a test build with the DPS310 address changed to 0x77? I have never built ArduPilot from source before, so that would help me a lot with this first test.
One additional observation that may be relevant: on both of my boards, the gyro and accelerometer also work correctly in Betaflight, but not in ArduPilot. I forgot to mention that in my previous reply. Perhaps it’s unrelated, but I thought it might be useful information.
I do plan to learn how to build ArduPilot myself in the future, but for now I’d really appreciate a test firmware if that’s feasible.
Thanks! I noticed the file contains an APJ header, although it has a .bin extension. I’m flashing via STM32CubeProgrammer after a mass erase (Mission Planner cannot flash my board directly as described). Could you provide the raw .bin for STM32CubeProgrammer, or confirm the correct flashing procedure?
arducopter.bin (836.6 KB)
Apologies! I changed the extension accidentally when renaming, that’s why that one was a *.bin. This is the corresponding real *.bin file.
(I almost sound like an LLM. I confirm there is a meaty human at work here)
I tested the new .bin with STM32CubeProgrammer. The flashing process completed successfully, but unfortunately the board does not boot afterwards (red LED stays on, no blue LED).
To verify the flashing procedure, I reflashed the original *_with_bl.hex, and the board immediately booted normally again.
For this board I have only been able to flash ArduPilot successfully using the *_with_bl.hex method described in the ArduPilot documentation. Would it be possible to provide the modified firmware as a *_with_bl.hex as well?
It took me some time to learn why my build process does not build with_bl.hex and hex files in general… now done. The forum does not allow to attach this, so get one here please.
I successfully flashed the modified *_with_bl.hex using STM32CubeProgrammer. The flashing completed without errors, the board boots normally, the blue LED is blinking, and Mission Planner connects successfully.
Unfortunately, the results are unchanged:
BARO1_DEVID is still 0 (barometer not detected).
The artificial horizon still does not react when I move the board, so the IMU also appears not to be working.
I have two brand-new Flywoo F405S AIO boards, and both show exactly the same behaviour.
Both the DPS310 barometer and the IMU work correctly in Betaflight on the same hardware.
I have attached screenshots from STM32CubeProgrammer and Mission Planner.
Thank you, and please let me know if there is anything else I can test.
I successfully flashed the modified *_with_bl.hex using STM32CubeProgrammer. The flashing completed without errors, the board boots normally, the blue LED is blinking, and Mission Planner connects successfully.
Unfortunately, the results are unchanged:
BARO1_DEVID is still 0 (barometer not detected).
The artificial horizon still does not react when I move the board, so the IMU also appears not to be working.
I have two brand-new Flywoo F405S AIO boards, and both show exactly the same behaviour.
Both the DPS310 barometer and the IMU work correctly in Betaflight on the same hardware.
I have attached screenshots from STM32CubeProgrammer and Mission Planner.
Thank you, and please let me know if there is anything else I can test.
It might be that Betaflight is lying to us, I don’t know
I am also a user of a similar Flywoo board, and while not exactly brand new, it does fly with Ardupilot. But I had to enable SPL06 for barometers (by the looks of my hwdef changes).
Could you try this binary please? It has few other changes apart from enabling SPL06, but these are strictly about adding features, so it should be working well.
UPD: And my apologies, it’s not the FlywooF405HD-AIOv2 binary, but its predecessor FlywooF405S-AIO. By the looks of it, two relay pins would not work with this, but if the barometer would work with the one above, I will compile the “HD” binary too.
in my hwdef, and I was sure that I made that following some discussions that resulted in some accepted changes, but as I see now these actually did not make it into master. (As you see from the post, SPL06 is indeed a possibility as advertised by Flywoo).
good news: the barometer is now working. BARO1_DEVID is non-zero and pressure data is available.
The IMU also provides live raw gyro data: gx, gy, gz and gyrosq all change when I move the board.
However, roll, pitch, nav_roll, nav_pitch and the artificial horizon remain at 0. The accelerometer calibration starts but fails maybe I wiggled it too much.
So the sensor is being read, but AHRS/EKF does not produce attitude data. Could you please check the IMU type, orientation and SPI configuration in the hwdef?
Thank you again for all your effort. I really appreciate your support and I’m happy to test any further builds if it helps.
Could you please, just in case, set up the frame (FRAME_CLASS = 1 for quad, whereas FRAME_TYPE = 12 should be already set up), then reboot - so that all pending initialisation is completed?
FRAME_CLASS = 1 and FRAME_TYPE = 12 are set correctly. After reboot, Mission Planner reports Frame: QUAD/BF_X.
The behavior is still unchanged.
The barometer is working correctly.
Both the gyro and accelerometer still provide live raw data. gx, gy, gz change when I move the board, and ax, ay, az also change significantly when I rotate it.
However, roll, pitch, nav_roll, nav_pitch, and the artificial horizon all remain at zero. The EKF initializes successfully (EKF3 IMU0 tilt alignment complete), but no attitude is produced.
I am a bit confused with RCOut: Initialising still. Not sure if it is just DShot misconfigured, or a sign of something, perhaps that you are running a slightly different firmware.
As the barometer seems to be resolved, here is the correct firmware hex for the HD board. For the barometer support, I’ve submitted a pull request, maybe @rmackay9 may have a look and merge (Andy approved).
Anyway, for the IMU hwdef part, live raw data tells me that the driver side is working correctly. (I’m not a core dev, this is a common sense conjecture)
After you reflash the firmware (and setting frame class - that’s a different board id, which probably erases parameters), please try again, and if it is still misbehaving, let’s try the following for what it’s worth.
My Flywoo board requires AHRS_ORIENTATION = 6. If I remember correctly, I was actually able to calibrate accels with wrong orientation, then optimistically attempted to lift off with funny results (“funny” to be read “flipped wildly on throttle-up”, which is almost harmless for a 2" quad). I would suggest checking how the raw values behave, choose the correct orientation and trying calibrating accels again.
Here I might be asking too much and it is not necessary, but I was running accel calibration via mavproxy, not any kind of planner. (I was a user of apmplanner2, which started being problematic with calibration commands even when I was able to compile it, and now I’m managing my drones via mavproxy exclusively so far). If you are not afraid of command line, mavproxy can be come a good friend, and I would try it for calibration if everything else fails. (Might be mavlink 1 vs 2 issue, but I am not sure)
Thanks very much for that! I’ve added it to the dev call so it will hopefully be merged in a few hours and then backported to 4.7.1 (it’s already missed the cut-off for 4.7.0 which should be out within a couple of days).
I reflashed the latest HD firmware and repeated the tests.
RCOut now reports DS300:1-4 NeoP:5, and the frame is correctly detected as QUAD/BF_X, so those issues seem to be fixed.
Unfortunately, the artificial horizon still does not move. roll, pitch, nav_roll, and nav_pitch all remain at zero, although the raw gyro and accelerometer values update correctly. I also set AHRS_ORIENTATION = 6 and tried the accelerometer calibration again, but it still failed.
Thanks again for your help. I’m happy to test any further builds or suggestions.
I noticed the file contains an APJ header, although it has a .bin extension. I’m flashing via STM32CubeProgrammer after a mass erase (Mission Planner cannot flash my board directly as described). Could you provide the raw .bin for STM32CubeProgrammer, or confirm the correct flashing procedure?
using STM32CubeProgrammer. The flashing completed without errors, the board boots normally, the blue LED is blinking, and Mission Planner connects successfully.
