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.
Hi. I had the same problem on takeoff with my 3 inch drone. I later discovered it was caused by an opening on the side of my frame near the propellers which caused low pressure inside the frame on takeoff and the FC interpreted this as a jump in altitude. Maybe it can be your problem too
Good idea but I don’t think that this is the case for me. I think if it was the case, then BAlt would also follow the wrong (too high) altitude measurement, which in my case it doesn’t. As far as I can tell, the measured and logged barometric altitude matches the observed altitude during the flights.
Sure. If the altitude measurement of the baro corresponds to what you observe it must be another reason.
I also struggle with my drones altitude behaviour. Ones work better than others but all lose altitude after stopping from horizontal movement. The baro is well shielded in every drone so the solution to this problem should be messing with some of those EK3_ parameters you mentioned.
As you discovered in my question to @amilcarlucas in the configurator topic, I experienced similar behavior during takeoff in alt hold, and setting PILOT_TKOFF_ALT to a non-zero value seems to have entirely solved it (300cm, in my case).
I’m not going to point to that as the proper fix, but it’s worth a try as another data point.
I’m using a downward facing rangefinder, but the problem was present both before and after enabling it, so I don’t think rangefinder data has enough impact on the altitude solution to matter for this particular case.
My Copter is otherwise reasonably well tuned with low vibrations. I have quite a few flights on it, though I recently redid all the tuning from scratch, since the new configurator GUI was introduced.
hi, may I ask if the downward rangefinder will affect the EKF height, because there is a laser rangefinder above my optical flow, when I turn off the surface to follow, I use the remote control to control the left and right, it seems that the rangefinder does not have tilt compensation, which will cause the ekf height value to drop rapidly
