Unfortunately, I couldn’t find any definite information about the model’s center of gravity right off the bat. But if Sam also has the model, he can certainly say more about it.
Hi @Bastian
Thanks for the log. It looks like the pitch axis is unstable i.e. control loop gain too high. So this isn’t related to the lack of airspeed sensor. My CG is on the moulded marks on the wing.
The overall gain is made up of the parameters AND the mechanical ratio between servos and control surface. So if your control arms are using holes that give a higher ratio that could cause this oscillation. Please check what holes you are using - my parameters are good for the linkage on the second-outer hole hole on the elevator arm, and third-outer hole on the servo arm.
Me too!
I have, but only versus airspeed i.e. in 1-D.
Since you have such a nice model setup, I wonder if you could do an experiment for me?
There are some potential benefits to using the z acceleration rather than the inverse cosine of the bank angle in that equation. If the turns aren’t perfectly coordinated, z acceleration will be a better way to estimate lift coefficient.
Could you see if the curve fit gives a cleaner result if you use n^2 in place of 1/(Bankangle^2/2-1)^2, where n^2 is the load factor IMU.AccZ/g? So the overall formula would be
fitresult(Airspeed, n) = -Airspeed*((CD0*Airspeed^2)/K + (B*K*n^2)/(Airspeed^2))
IMU.AccZ will probably need some filtering, I’d recommend starting with a low-pass filter time constant of 0.1s.
Hello Sam, today I have been flying again, with very similar results, that is, I am still just as bad.
I have checked what you say about the servo arm and Pits drive, and it is correct.
I have analyzed many things about the Ardupilot commands, and a couple of parameters that were not in other versions, and that are related to the control of Pits, call my attention, they are these:
TECS_PTCH_FF_K, 0
TECS_PTCH_FF_V0.12
Specifically TECS_PTCH_FF_K we set it to 0, and by default for gliders it is advisable to set -0.04.
This TECS_PTCH_FF_V0, is the target speed, and 12 seems to be a good value for glide speed.
It may be happening, that in your case, that you mount real ARSPD, this has no effect, but in my case it can be fatal, carrying TECS_PTCH_FF_K = 0, instead of -0.04.
Ardupilot says the following:
TECS_PTCH_FF_K: This parameter can be used in conjunction with TECS_PTCH_FF_V0 to provide an anticipated gain between required airspeed and pitch attitude. This is best used with TECS_SPDWEIGHT set to 2.0. As noted above, this is appropriate for gliders, and setting TECS_PTCH_FF_K can improve responsiveness to changes in speed demand.
Note
The units of this parameter are pitch radians per meter per second between the current demanded airspeed and TECS_PTCH_FF_V0. Appropriate values are negative (incline down with increasing speed demand). Sensitive initial values are -0.04 for gliders and -0.08 for trailed airframes.
I still think that in this version, the TECS_SYNAIRSPEED function is not implemented correctly, to be used with Soaring, and that simply in the FBWB and CRUISE flight modes, there is no speed information, if not an ARSPD is mounted real.
Hi @Bastian
OK thanks for confirming. I’ve have had another look at your log and I recommend raising ARSPD_FBW_MIN from 7 m/s to 10 m/s. 7 m/s is too low for this aircraft and you may be stalling it.
If it is still oscillating at this higher speed I recommend reducing PTCH_RATE_P and PTCH_RATE_FF parameters to half of their current value and following the autotune procedure.
Remember that an airspeed sensor is a requirement for soaring to work well and without it you are in experimental territory.
Sam
Hi Sam,
I will try it and let you know.
Today I flew ~103 minutes in closed cloud cover and virtually non-existent thermals with ~26% remaining capacity in the battery. Since I set the vspeed to 0.2 m/s, it even tries and mostly manages to center very weak thermals.
Log:https://1drv.ms/u/s!Aii1zfYqI1Zijdg_Xu4GvPEd9stEbQ?e=oRls04
I think I have found a relatively good way to determine the soaring performance related parameters SOAR_POLAR_K, SOAR_POLAR_CD0 and SOAR_POLAR_B for my Lentus using Matlab’s Curve Fitting Toolbox.
The question is whether it would work well for other aircrafts.
If anyone here is interested, I could try to estimate the soar polar parameters. I would just need a log file (.bin format) of a flight in calm air (without thermals) where the aircraft was flown at different speeds and bank angles. With or without airspeed sensor. Even SIM logs should be possible.
So the basic idea is that the result of Sam’s equation for the nettorate should always be 0 when gliding in still air, or in other words, the calculated nettorate is equal to the actual sink rate.
In this case, all variables (airspeed, bank angle and sink rate) of the equation are known. And we can try to find the best fitting values for the coefficients K, CD0 and B.
Basically, it is gliding for a few minutes in still air (without any thermic) at e.g.:
10m/s at 0°, 30°, 45°
15m/s at 0°, 30°, 45°
20m/s at 0°, 30°, 45°
The more, the more different and the finer the resolution of the data, the better the curve fit will be.
I will filter the data, for example, when the motor is running, when the aircraft is climbing or when the speed/banking angle is changing rapidly.
To get useful data, the aircraft should be well tuned to keep the airspeed and bank angles.
If anyone is interested, just let me know.
@Samuel_Tabor, may I send you the Matlab file and you might have a look if it is useful?
Sounds great! You can even fly with vspeed = 0.0m/s, which means thermal as long as altitude can be maintained. Good for weak conditions.
Very nice process - a step up from the 1D curve fit in the spreadsheet linked on the wiki. I’ll see if I can get a trial of the toolbox.
Here is the result of the fit with z acceleration instead of bank angle:
gof indicates the quality of the curve fit, and the values are pretty much the same as for the bank angle.
Both nettorate calculations compared with each other:
Substracted both nettorate results:
I will create a OneDrive folder with all the relevant files today and send the link to you via PM.
If needed, I can also lend you my Matlab license:
Hi Sam, I want to share with everyone that I have ridden my ASW 28, a Matek Analog Pitot, and that today I have flown wonderfully with Soaring.
It is clear to me that it is absolutely necessary, to mount an ARSPD, for Soaring to work.
I suppose that today’s flight can be improved a lot, but from the outset I can firmly affirm that Soaring WORKS, and that it does it very very well.
My flight area is quite poor in Termicas, due to its proximity to the sea, but even so, Soaring is able to detect the slightest descent and take advantage of it.
Basically I have your same parameters, adapted to my FC, an Omnibus F4 pro, and I have only taken as a reference some Sonic parameter, which seemed more accurate than yours, sorry for the livertad in this regard.
Thank you for everything, and my congratulations to you and the entire group, for the great work that is being done.
I am enclosing my flight records.
https://1drv.ms/u/s!ApA-NQi5IsByh27jthB_TMNs-dYF?e=baX5iW
Interesting that it gives a similar result. I suspect that in future with more dynamics flight, e.g. with speed to fly enabled, the formulation in terms of load factor might be preferable. Thanks for looking at that!
Hi Jose,
I’m glad it’s working for you now. An airspeed sensor will probably always give a performance advantage and in my opinion it is worth the small cost. We’ve updated the wiki to make the recommendation a bit clearer. However with time we can no doubt improve operation without an airspeed sensor to some extent.
Sam
Hi Sam, I have loaded version 4.1 Beta, and I have entered the same parameters of my .param, from the last successful flight.
I want to ask, if I should change any parameters, or do I continue with the same ones from the Dev version.
Thank you.
Hi Jose,
Same parameters should work fine.
For anyone using the Matek F405-Wing, soaring had to be temporarily disabled in new firmware builds to save flash space. This affects “latest” builds from the last week and 4.1beta1.
Since then flash space has been saved in other ways and soaring will be re-enabled soon.
So if you have a F405-Wing and want to update, you will need to hold off for a few days for “latest” builds, or for 4.1beta2 (probably won’t be long).
Hello again Sam, after reading what you put in the previous post, I think I may have problems with the Beta version.
My FC is an Omnibus F4 Pro, after all it is an F4 with a STM32 micro, just like the one that equips the Matek F405 Wing.
Therefore, if you do not tell me something that I do not know, if I load the Beta version, I cannot have Soarin.
You tell me what I can do.
Thanks.
Hi Jose,
You’re fine on Omnibus F4 Pro, the list of enabled features can be different even if the CPU is the same.
Sam
Hello sonicdahousecat, can you tell me which version of Ardupilot you are using on your flights.
I have many doubts about the PID configuration parameters, because I see that your configuration is very different from Samuel’s, which is the same as me.
Thanks.
Hi Jose, I did the first flights with Sam’s glide-polar-learn branch, but I was struggling with a DShot problem, so I tried Master.