Hi, new guy here. Short question, has anybody gotten the Mamba F405 mk2 to work properly ? They seem to suffer massive gyro/accel drift, at startup the ground speed keeps increasing and the horizon keeps tilting until it’s upside down. 2x boards, same issue, both ok in Betaflight. Am I missing something ? (Boards are usb connected on my desk, not in drone yet). I have tried with the beta and latest versions of the firmware but have the same result every time.
Same Problem with Mk3.5 Mini
Same problem here. Any ideea to fix this. I use Mambasys F405 MK2 and this board is working ok with iNav and Betaflight. Help! 
Did you give V4.2.0-beta3 a try?
i did not. i will give a try today with big hopes. I have read someting about beta on another post. Thank uou for your answer!
Do you know if on this board MAMBASYS F405 MK2 Betaflight Flight Controller F40 40A 3-6S DSHOT600 FPV Racing Brushless ESC 30.5x30.5mm Sale - Banggood USA is working this firmware MambaF405v2
Yes, this is the correct firmware for that board. I have tested few firmwares version including the one you sugested. The problem is still there On some firmware the drifting is not so fast but still there. The ground speed is increesing on any firmware faster or slower speed. Any ideea?
It would seem to be the correct firmware but as with other boards there can be different versions released that are not documented. Boards from iFlight and Airbot (or clones of) come to mind.
hmmm i think i found the reason for drifting. In specs, this board has MPU6000 GYRO on it. In reality is MPU6500. With iNAV is working perfect as MPU6500. It is posible to change this from configuration in Ardupilot?
1 Like
I’ve been having this problem too, with the DJI variant (MambaF405US-I2C).
fwiw I tried changing the hwdef to MPU6500 which resulted in the drift slowing down a lot, but it’s still there. After a few minutes the groundspeed is showing over 100m/s even with good GPS fix of 12 sats and not moving at all. Makes absolutely no sense.
I was testing with latest github source (named 4.3.0-dev as of now) but the same issue occurs with 4.2.0 and 4.2.1 official.
(edit) As others mentioned this FC flies great with Betaflight.
I have tested the MK4 2022 and get no discernible drift on the bare board. There are some temp related accel offsets, but these are common for the MPU6000 and the EKF should learn appropriate biases given sufficient input from other sensors.
One thing that is worth checking is the UART that the GPS is connected to. On F4’s you really need a DMA-enable UART and on that board only UARTs 2,3 & 6 are fully DMA enabled
@andyp1per Sorry for the delay, I was enjoying this build with Betaflight for a while.
I’ve uploaded a dataflash log here:
http://www.iforce2d.net/tmp/attDriftLog-MambaF405US-I2C-stable-4.2.1.zip
The copter was motionless the entire time. Here are the steps I took to set this up:
- Flash with this hex: https://firmware.ardupilot.org/Copter/stable-4.2.1/MambaF405US-I2C/arducopter_with_bl.hex
- Connect to Mission Planner. Message “PreArm: EKF attitude is bad” shows immediately and repetitively thereafter.
- Calibrate accelerometer axes, calibrate level.
- Set LOG_DISARM=1, uncheck all compass checkboxes, reboot.
- Sit the copter level and reconnect Mission Planner.
- Wait.
In all cases I’ve seen after about ten minutes the pitch and roll have drifted somewhere between 8 and 30 degrees away from level. The direction and magnitude of drift seem to be random from one run to the next, but remain constant within each run.
Ground speed climbs very high (seems to be limited at 707m/s) even if a GPS is connected with good fix. Often the ground speed will flicker to zero, the frequency of this flickering also differs from one run to the next but remains constant within a run. On some runs it will be flickering to zero the whole time, on other runs it will only flicker to zero a few times every 30 seconds or so.
I tried disabling all UART inputs from 2-6 (SERIALn_PROTOCOL = -1), this had no effect.
In my upload I included the telemetry log because I noticed the groundspeed values were not included in the binlog, I guess because there was no GPS. So only the tlog will show the groundspeed behavior. When replaying the tlog I noticed some messages like “PreArm: DCM Roll/Pitch inconsistent by 10 deg” which start to show up when the pitch/roll reaches 10 degrees or more.
The IMU looks absolutely fine in this log. I think the issue is that the copter is motionless and you have no other source of attitude information (neither GPS nor compass) so over the time the EKF goes wonky.
You mean in the absence of actual sensor data the EKF plugs in some placeholder values and hopes for the best? Seems unlikely 
I would think it’s smart enough to completely exclude sensors that don’t exist, especially when they have been explicitly marked as not to be used. iirc one of the main features of KF is that it can demote bad data sources even when they are present but not consistent with others. Also, the message about “EKF attitude is bad” shows up immediately, not over time.
I have another copter here (omnibusf4pro, copter4.1) that when deprived of compass and GPS information the pitch/roll remain within 1 degree of zero for over an hour when motionless.
As I mentioned earlier the same result happens with a solid GPS fix of 12 sats. I’ll make a binlog of that situation tomorrow.
EKF doesn’t like sensory deprivation. That’s why you often see reset messages when a copter is on the ground.
Seeing reset messages on the ground is one thing, but we’re talking about pitch/roll values getting way out of wack - is that something often seen? As mentioned above my other quad doesn’t have any pitch/roll problems without a compass or GPS, even when it’s expecting to use them. I tried two other boards (omnibusf4 nano and pixhawk1) which were also able to sit for an hour without the pitch/roll deviating by more than a degree, with no other supporting sensors.
Speaking of hours, I spent some twiddling around with the source code and various params and learned a little more.
- The IMU is a MPU6000, at least according to the whoami.
- No drift problems occur when EK3_ENABLE=0 (although then we get “EK3 not started”)
- The “EKF attitude is bad” message can be traced to the ‘tiltAlignComplete’ member of EKF3 never becoming true.
The test for tiltAlignComplete becoming true is
if ( tiltErrorVariance < sq(radians(5.0)) )
sq(radians(5.0)) is 0.007615442
tiltErrorVariance starts at 0.02 and climbs very slowly so the condition is never met.
With the Pixhawk1, tiltErrorVariance starts at around 0.00004 and remains pretty much unchanged.
Relevant functions
NavEKF3_core::calcTiltErrorVariance
NavEKF3_core::checkAttitudeAlignmentStatus
NavEKF3_core::updateFilterStatus
It seems like some bad values get into the EKF at startup and can’t work their way out as they’re supposed to.
Not sure if any of this is helpful or if this is the right place to discuss it.
You are into @Paul_Riseborough territory. But I think this pretty much confirms it is EKF rather than IMU related. That said it would be worth you trying Properly reset MPU6000 signal path at startup by andyp1per · Pull Request #20924 · ArduPilot/ardupilot · GitHub just to see if it makes any difference.
Here’s a log from the 2022 version of that board:
No drift. The hwdef is pretty much the same - so maybe there is some hardware issue with the board you have.
I discovered the custom build generation server today…
A build with only EKF2 made no difference, then I tried excluding EKF2 as well, so DCM only.
That result in no drift whatsoever, and I was able to fly it in stabilized mode after disabling arming checks.
Unfortunately it still complains about “need alt estimate” so no autonomous modes can be used. The altitude is from GPS only and shows as the MSL value instead of starting at zero. Looking into the source code again, it seems that EKF altitude is used for arming checks even when EKF doesn’t exist, so that check will never pass.
Anyway, I’m about ready to give up and declare this FC to be dedicated to Betaflight only. At least I had a smile on my face at the end of the days I used it with Betaflight.
I was intending to fly this around the farm in 99% acro mode anyway, but was hoping to get a rudimentary RTL that might prevent a crash when I inadvertently went behind a hill and lost signal. The pages below gave me hope that it might be doable with no baro or compass (I followed the steps outlined) but I guess it aint gonna happen without some kind of EKF.
https://ardupilot.org/copter/docs/common-gps-for-alt.html
https://ardupilot.org/copter/docs/common-compassless.html
I would have just tried Betaflight’s ‘rescue mode’ a week ago, but could never get the GPS to even be detected at all, and I’ve heard the result can actually be worse than just crashing outright
Yeah, you don’t want rescue mode …
I asked Diatone - the only difference between the version you have and 2022 is MPU6500 vs MPU6000.