I did some test flights with 4.1 beta3 and noticed that the altitude performance in Auto mode is much worse compared to 4.0.7. I send the same mission to a similar quad with the same rangefinder (TeraRanger Evo 60m) with 4.0.7 where I can’t see any issues.
Is it necessary to adjust the altitude controller values in 4.1?
Txs for the report. I’ve added it to the 4.1 issues list (see “surface tracking poor stability”) so it won’t be forgotten. There have been changes in the position controller but we’re not expecting that any re-tuning should be required. Of course your test indicates we’re wrong but let’s see. Txs again.
I think I have the same observation with 4.1.0-beta3 and a TFmini Lidar.
First I thought it is a bad Lidar reading when flying over the not solid surface of the cornfield.
As far as I can remember it was fine with 4.1.0-beta1 (cornfield was not so high as now with beta3
@RainFly I had never success with Benewake lidar sensors for missions over cornfields. If the plants are small the performance is acceptable, but as soon as they grow the lidar sensor signal becomes very unreliable. Maybe your problem is not firmware related, its probably more due to the sensor type.
Txs for the report. There weren’t any changes that I know of in this area of the code between -beta1 and -beta3 so I suspect it is an environmental issue (e.g. taller corn). Surface tracking has always been a bit rough when flying over crops or trees when using lidar because the altitude changes so much.
In any case, if you’d like me to look into this further could you perhaps provide an onboard log? I can’t promise 4.1 will work better than 4.0 but at least it shouldn’t be any worse.
I did today another test flight. I replaced the TeraRanger Evo 60m with a Lightware LW20 to make sure that the issue is not rangefinder related. The behavior is the same. Unfortunately it’s pretty bad I hope the performance can be improved for the stable release. For me it’s not usable for safe flight at the moment.
I also checked if the dolphin fly occurs in Loiter. It does not, it’s smooth as always.
Does the new s-curve navigation also affect the altitude controller?
Have a look at the video from the flight this afternoon:
And finally I have another strange behavior. My copter suddenly pitch back during take off and landing in Loiter. I have installed a proximity sensor. This sensor sees obstacles where I can’t see anything Never took a note during 4.0.7…
The video looks similar to what I see with my copter. Also the airflield looks quite similar to mine
The frequency looks identical. But I have lower amplitude of the oszillation. But I fly also lower, only 3m relative above ground.
It can be, that my statement in a previous post was wrong.
I’m not sure any more, if 4.1.0-beta1 was OK.
Too many toys with new AP-version to remember - copter, rover, boat, plane
Maybe a side effect from switching from EKF2 to EKF3?
OK, thanks for the video. This is very clearly caused by a change to the filtering we do on the rangefinder between 4.0 and 4.1. I think we will restore the original filter value but also make it configurable using a new RNGFND_FILT parameter (see PR here)
This will likely be included in -beta5 in a couple of weeks but if you would like to test before then I’ve created a developer build here for CUAVv5Nano. This is almost exactly the same as -beta4 but with this new parameter added and the default filtering restored. If you’re OK to test this I’d love to hear if it resolves the problem or not.
Thanks very much for testing this. From a look at the log it seems like various values were tested but the autopilot wasn’t rebooted between changes. Sorry, I clearly should have explained that a reboot is required between changes. Once this is released the parameter descriptions will say it is a “RebootRequired” parameter.
I suspect though that maybe the real issue is this innocuous looking change that I did at the request of Lightware to increase the timeout for the Lightware lw20 I2C which is the lidar you’re using (I think).
ERR: TERRAIN-2 means that it is missing terrain data. This error message seems to be appearing every time the vehicle enters Auto mode so I’ll have a look into this as well. The lidar seems OK and we don’t see the vehicle executing a terrain failsafe… anyway, i’ll look into it and add it to the “to be investigated list”
@rmackay9 I did another 10 flights with different settings. I was able to reduce the dolphin behavior. It seems that a value of 5 works the best for my quad. The overall altitude control is not that bad. Unfortunately the motors pulses more and getting hotter than normal.
Compared to 4.0.7 it’s still worse, so I think we have to put another effort in this topic.
OK, thanks for testing and it makes sense that increasing the filter improves things.
I suspect the additional roughness (vs 4.0) is coming from the changes to the altitude controller done as part of the SCurves project. So I’ll have a talk with @Leonardthall about this. Below is a graph of the desired climb rate in Auto (1st half) and Loiter (2nd half).
This adds some logging so it would be good to turn off your FFT batch logging.
It would be great if you could do an auto flight with:
PSC_TC_Z 0.25 and 0.5
The logs will be quiet large so it is a good idea to do a short mission that would recreate the problem and not spend too much time flying around after.
We are experiencing a similar problem with our drone dolphing. We do not see a parameter PSC_TC_Z in ArduCopter 4.3.0. Additionally I would like to know what the paramater do, where to access it and how it fits in with the greater control logic. The same goes for RNGFND_FILT. We can can change this one, but I am not aware of any explanation to its function and how it ties in with the control loops?
I hope the performance can be improved for the stable release. For me it’s not usable for safe flight at the moment.
Never took a note during 4.0.7…
