My copter is behaving strangely in AltHold Mode, when I try to take off slowly in AltHold, after an initial hop it looses altitude again and sometimes even touches the ground.
I did 3 test flights today and the ‘achieved altitude’ (CTUN.Alt) doesn’t really follow the barometric altitude (CTUN.BAlt) but is closer to the desired altitude (CTUN.DAlt). From what I can tell, the barometric altitude matches what the drone was actually doing during the flights (that includes touching the ground in the third flight). These are the graphs from the 3 test flights I was talking about:
Check EKF height source.
We have same when main vertical pos source was rangefinder.
Also be noted that QGC show not baro alt, but target Alt what is complately stupid.
Yes, the baro is placed on the underside of the FC, between FC and ESC with a bit of open-cell foam covering it. Also the drone has duct-like prop guards so there’s not much prop wash towards the baro anyway.
The EKF’s altitude (shown in CTUN.Alt) is a combination of the IMU’s accelerometer values and the barometer so either ground effects (air pressure disturbances near the ground) or vibration affecting the IMUs can cause problems.
I did another test flight, this time basically outside, the area is open to three sides and has a roof that’s about 6 meters high. Here is the log file.
At around 17:02:50 in the plot, the EKF altitude dropped, causing the drone to shoot up (visible in the baro altitude), which obviously led to me dropping throttle to not hit the roof.
Again the baro altitude matches my observation of the drones altitude during the flight. I don’t think that there is any ground effect going on when flying 3 meters high with a 3" drone.
hello @Janno
from the log what i have observed that your state variances are bit high you need to look into these, it should below 0.5 m/s.
i also recommend you to do barometer calibration and compass calibration.
So I dug some more in the direction you pointed (thank you for that hint), innovations are indeed high.
XKF3[0].IPD gets stuck during flight, do you know what could be the reason for that?
XKF3[1].IPD is fine the whole time and, as seen in your screenshot, IPN and IPE signals are also continuously logged.
XKF3[0/1].IVD/IVE/IVN seem to only be available (or get logged) after ~30 seconds of flight, right when the copter jumps up in the air. Do have an idea what could cause that?
I noticed that XKF3.IVD/IVE/IVN weren’t available at all in the three flights I posted first, which were indoor without gps. Is it possible that there is a connection to EK3_SRC1_VELZ = 3 (GPS)?
I did the MagFit test flight before, but when I uploaded the log in the MagFit webtool it said that compassmot doesn’t yield significantly better results than just compass offsets + iron calibration, so I used the latter. I you want to have a look, here is the MagFit test flight.
With “baro calibration”, do you mean baro compensation or did I miss something? I am planning to do windspeed estimation and baro compensation after I finished Autotune, during which these problems came up.
I usually fly outside with perfect gps signal or in a hangar with decent gps signal (good enough for home to be acquired). I did the first three flights I posted indoor, as they were planned to just be short hovers to check filters. In the future it is planned to use the drone fully indoor with PoZYX beacons.
I’m not sure what you mean with that, I do have XKF3[0] and XKF3[1] messages in the logs.
I don’t think setting EK3_SRC1_POSZ = 3 will help much, the GPS altitude varies even more than the baro altitude. I would attribute the baro fluctuations to flying on a windy day without baro compensation.
I increased EK3_ACC_P_NSE to 0.5 (default 0.35) and descreased EK3_ALT_M_NSE to 1 (default 2).
The real altitude now follows DAlt closer and the XKF3.IPD innovations are much smaller than before, as can be seen in this log. It is still not perfect though.
Also what I noticed is that we tested the drone (all 4 motors at once) on a motor test stand and the data says the drone produces enough thrust to hover at ~40% throttle. However in flight MOT_THST_HOVER is learned to a value that’s even below 20% throttle. Additionally we get an unusually high (for 3" props) MOT_THST_EXPO value of 0.63 from the test stand data. The drone weights 600g so we (should) need ~6N of thrust to hover which would correspont to ~40% throttle.
