We are testing a very large quadcopter (>400kg take-off weight), and we are trying to implement altitude hold. This will obviously require some careful tuning, but before we got to the tuning stage, we found some strange behaviour in the altitude setpoint which I will describe after a quick bit of setup info.
Cubepilot orange, lightware LW20/C pointing down (fixed to the vehicles vertical axis), Copter v4.2.3.
Lidar is being used as primary altitude reference in EK3 due to indoor testing (limited GNSS accuracy), and a very poor barometer performance (flight controller is right below the airflow of rotors that are >2m diameter, and close to a significant heat source - these might be the root causes of the inaccuracy or maybe it’s something else…). The logs will show the barometric altitude is useless to us - we are only changing altitude by about 4 or 5 metres at most due to the indoor limitations.
So the issue: when switching to altitude hold mode with our thrust stick in the deadzone (which is +/-15%), the altitude setpoint does not remain constant. This means the vehicle doesn’t even want to sit at the fixed altitude. I’ll note again that we haven’t really started tuning the alt hold params so it doesn’t even track the moving setpoint, but we’d like to understand why the setpoint is not constant in the first place.
This is the setpoint vs measured altitude - see the setpoint is varying
I’m currently having trouble attaching the .bin log file for investigation, I’ll keep trying the the replies. Any insight at all will be appreciated greatly. Thanks!
A few observations:
Update to latest Stable.
Vibration levels are too high. X particularly.
Tuning is terrible. The ATC_ANG for Pitch and Roll look way too low. Rarely if ever will they be <default.
It appears to be overweight underpowered. MOT_THST_THST at 0.6 and CTUN>THo inline with that.
You don’t have battery logging.
The notch filters are not configured properly. Well the fixed one might be but hard to say.
Yes most of these are known issues - we are in development process. Thanks for the insight though - we will spend extra time looking at the P gains and notch filtering soon. It’s flying fine for what we need currently and we have lots of insight for things to improve in v2
No battery logging as we are not using batteries
Thrust to weight is known issue as this is v1, not optimised but plans to improve significantly in V2
Vibration issue to be solved in V2 - not causing obvious control issues due to frequency of vibe being much higher than any of the vehicle dynamics, but obviously not desirable for mechanical stress and noisy data
Would any of these issues cause alt hold setpoint to be non constant ?
Flying such an expensive vehicle without battery monitoring (preventing proper PID scaling) is risky.
The same for the notch filter. Both changes are easy to do and are important for flight security.
We don’t have battery monitoring because it is not battery electric. We are monitoring power levels externally as part of the extended DAQ systems and combining this data with the flight logs.
Current theory based on the altitude information on this ardupilot info page is that the lidar is essentially the driving force here. When measured Lidar alt changes, the FCC assumes terrain is approaching the vehicle and so tries to increase the setpoint to maintain altitude above terrain.
We’re looking into improving the accuracy of the barometer - it seems some of the drift is due to bad temperature compensation. The relatively constant slope indicates it’s not due to airflow or flight conditions, more likely due to something such as steadily changing temps. Will also try to have a RTK base station outside but within LOS of the mobile antenna to see if this gives any improvement on GNSS accuracy.
Will also do a separate test and disable rangefinder for EK3 height but continue using it as primary altitude source to see if this essentially disables the ‘terrain follow’ aspect of the altitude holding.
We had some improved results eventually. By disabling surface tracking (SURFTRAK_MODE = 0) it seems to have allowed the setpoint to remain constant. I guess this is because we are now using the LIDAR for altitude reference but telling the FCC to not attempt to maintain altitude above the surface, which means the setpoint doesn’t change when the altitude measured by the LIDAR changes.
We still get fairly severe rise and fall immediately after entering althold, and this means the consistency is quite difficult. Looks to me like some sort of time constant so will investigate the filtering parameters related to althold and surface tracking etc.
