I’m new to this forum so let me quickly introduce myself. I’m Bas Goossen, i’ve a grade in embedded system engineering and a technology entheusiast. In my daily life i run a company in communications software for hospitals, gp’s and the paramedical sector. I’m located in the Netherlands.
The last 3 years i took up on the RC hobby again, mainly with fpv racequads using betaflight as the controlsoftware. Since in doing this i realized i enjoyed long range flying very much so i decided to build a long range wing. After some research i was very exited about ArduPilot so decided to go for ArduPilot (ArduPlane) as the control software.
I’ve been experimenting a bit with different set-up’s but i keep running into some problems. Mainly it seems the gyro and accelerometer readings from my FC are unstable. And ArduPlane is reacting to this. To show the problem a bit better i’ve created a small video that shows what happends. Meanwhilst i’ve resolved the problem with the magnetometers (by re-flashing the board). The stuttering / jittering motion remains.
I’ve got 2 of those Wing FC-10 boards and they both behave the same. Is this just a bad batch of boards or is somthing wrong in my configuration / filtering / gyro / acc settings? I’m used to having a lot of settings with regards to Gyro and ACC filtering, but i can’t find any on Mission Planner with regards to this. I’ve flashed the latest stable ArduPlane for the Lightning F35 board, that is compatible with this “clone”.
Of course all help is welcome. If i can provide other info that helps the case, please let me know. I’m new to ArduPlane so probably i’ve got a lot to learn ;-).
You need to upload a .bin flight log from the flight controller so we can see what is happening inside the unit to answer your questions adequately.
Initial look would indicate electrical interference is getting into the servo leads.
What Tx signals are close?
If you plug a servo into the same output and move it around does the interference change?
Or change the right to left and vice versa does the interference stay in the left or move to the right?
Are you in manual mode or stabilise?
I would guess its just trying to stabilize itself as the horizon is moving a lot. Your also getting AHRS errors that you should fix before flying. Because is going slow (0m/s) the air speed scaling means it moves the servos allot, once it has some speed this will reduce.
When stationary the GPS position jumping about in all directions because of the EKF sensor fusion this can cause the roll and pitch estimates to be jumpy. As soon as you move at any speed the relative error is much less and it all smooths out.
Thanks for the replies! Both very helpfull. The jittering does not occur when in manual mode, it does not seem to be electrical interference. Also when throttling up in manual mode it is not jittering at all.
How can i create a .bin file? since there is no CF or Datalog chip on the board for as far as i am aware of.
I’m indeed constantly getting Bad AHRS, i think (definitly do no know for sure, since i don’t accactly know what it means) this is also because the horizon is “jumping” a lot. When trying to arm i get a “DCM roll/pitch inconsistent by **deg” where ** varies a lot in value between 20 and 50.
The video was recorded when the wing was in FBWA mode.
imho your horizon movements look like a marginal or sub-par gps sat fix, like @iampete suggested. while your taranis’ telemetry screen shows 9 sats, which is just a high enough sat count, there might still be a insufficient hdop. free sky view including a sufficiently low elevation angle (no tall buildings around) highly facilitates getting a good fix.
on a sidenote, this board has an onboard mag pretty close to the high power components, which renders it pretty much unuseable due to magnetic interference. it might be a good idea to use an external mag instead, in case you do want to use one that is: https://ardupilot.org/plane/docs/common-furiousfpv-f35.html#notes
your board uses onboard flash memory for logging by default instead of an SD card, with the obvious file size limitations. you might want to set LOG_DISARMED = 1 to retrieve a log of what‘s going on prior to arming. you can then download the flash log via mission planner and post it here.
The jittering also occurs when having 15+ sattelite fix, so that does not seem to be the issue. Also i’m using an external compass (wich is mounted on the wing) (Beitian BN-880).
I’ve configured logging to log everything, enabled block logging (since it is indeed dataflash), and armed the plane (i’ve solved AHRS and misalignment issues by installing a new gps/compass and recalibrating everything). After having the plane armed for a while and disarming there still are no logs to download according to mission planner.
I’m used to the rock-solid horizon in betaflight which tracks the quad (in the case of Betaflight) real-time with a super responsive feeling and is always spot on (only using acc and gyro). How come the horizon is bouncing so much (and sometimes far from level while the plane sits level on a table). This could be the board of course (my betaflight builds use Holybro Kakute F4 and F7 boards, which i consider of better quality than the Wing FC-10 DOF) or the gyro chip. But i’ve seen people who use the board with great success in their ArduPilot builds. I also have a Matek F-765 Wing lying around (intended for another build) which i can test out, but i wanted to have this one working first as a testbed.
ok, thanks to your report i’ve rechecked the board’s hwdef for logging defines and realized we’ve actually not set onboard flash logging defaults yet! i’ll try and get that in asap.
re BF vs. ardupilot horizon stability: of course it’s hard to definitely rule out a hardware issue without any IMU data, but imho it’s the least likely issue if your board basically works without errors reported.
as stated above, the way ardupilot’s ekf fuses additional sensors like mag and gps is somewhat different from basic gyr / acc stabilisation.
maybe you want to post a file with your current parameter settings.
Thanks again vierfuffzig, glad to see this topic has at least lead to something ;-).
I did swap boards this morning (i have another Wing-FC 10) and this one had the same problem. I than swapped to the Matek F765-Wing and it’s rock solid and stable… So either both boards (Wing FC) are bad, or there is something wrong in the default configuration or firmware for the board.
For now i’ll stick to the matek. And probably buy a F405-Wing for this one than as the F765-Wing is a bit overkill for a plane with only 2 servo’s.
These were my params at the time of the movie, after that i did a new ACC calibration and compass calibration, which solved some of the AHRS and alignment issues. But the shaky horizon remained. ardupilot params 14-08-2020 (AR Wing).parm (20.1 KB)
i have to stand corrected: there just is no flash on the 10DOFWing-FC. most likely that’s why we didn’t enable it in the first place
secondly i fired up my board which had been collecting dust in the drawer for quite a while and i have to say i’m seeing the exact same horizon movements you did see, with just acc and gyr running. i do see eventual “initializing ardupilot” messages when trying to do acc cal, so something is not working to expectations here, while it does run perfectly well on plane3.9. so this isn’t a hardware issue, but some firmware issue. if you care you might want to check https://firmware.ardupilot.org/Plane/stable-3.9.10/F35Lightning/ just for reference.
i’ll do a bisect search to find out what broke board support along the way. thanks for pointing to this issue!
on a sidenote, can’t do anything wrong with moving to a matek wing type board. i’m using these pretty exclusively too.
Hi Vierfuffzig,
Thanks for pointing this out, i’m glad i’ll still be able to use the boards for some DIY projects i’ve got lying around (working on a KFm tailsitter). But yeah i’ve got a lot more trust in the Matek boards for long range flying.
Thanks all for the help, i’m glad it did point out an issue in the end and am very happy to see that there is a good community around ArduPilot which i’m happily joining.
Yesterday i did the maiden of the wing with the Matek board, and tested out some of the basic flight modes of Ardupilot (LOS for now). I must say i’m stoked, it’s rock solid even before tuning and trimming (in the stabilized modes FBWA, ACRO, Loiter) so that’s a 10 score for ArduPilot there.
P.S. i quickly flashed iNav (last version) back on the Wing-FC and also here the horizon is shaky, is there any code sharing? If so than that might be a place to look for the problem.
i just cross checked with AP 3.9 and on a rough test had the impression this did not show any irregularities. will do further tests as soon as time permits.
@basgoossen so the fix has been merged into current master (thanks @tridge ) and we‘re trying to pinpoint the root cause.
meanwhile you can either load current master or set INS_FAST_SAMPLE = 0 on any previous release type firmware to have your board run fine as expected.
Hi Vierfuffzig,
I’ve tested with the parameter you mentioned “INS_FAST_SAMPLE = 0” and this indeed solves the issue! the horizon is now as solid as with the Matek board and comparable to Betaflight, (with exeption of the refreshrate in MissionPlanner, but that has to do with MissionPlanner i assume).
One thing i learned tuning quads @32Khz (which i assume you are aware of) is that whenever you enable high speed mode on the most common gyro chips they disable their internal low pass filter. On some chips this lead to problems as wel in BetaFlight. And even though i always had very good flight performance using 32Khz they eventually even removed 32Khz sampling all together. Since: (qoute) “it caused too many issues with too many users and did not really improve flight performance” according to the Betaflight crew. Since then they did change a lot of filtering and with the RPM filters in place the quad flies better anyways than with older firmware that still included the 32Khz.
So it could simply be the fact that the gyro chip is kinda sloppy in 32Khz and the applied filter is not up to the task to straighten it all out again. (can’t tell for sure though since filter tuning in ardupilot seems to be a bit hidden from the public ;-), wheres in BetaFlight it is part of the base set-up).
@basgoossen thanks, great info there! i‘m a fixed-wing guy pretty exclusively and honestly don‘t have too much of a concept regarding imu filtering and high-rate applications. however, i do think the actual issue we‘re dealing with rather is a low-level one, that‘s at least what the FIFO corruptions (temp resets) suggest. hope we‘ll get more insight soon!
