Hi, I have a suggestion for a new parameter that I think would be nice to have. I own a Bix3 with airspeed sensor.
I’m tuning TECS at the moment which is working out well. Only I find it somewhat strange to have to find out a vertical speed figure that my aircraft can achieve towards the end of the flight. If I do this correctly, it means my aircraft doesn’t climb at its max capacity at the beginning of the flight. On the other hand when I add weight or drag it doesn’t make that vertical speed any more. So it isn’t very flexible and efficient in my opinion. And it could be simpler.
I would like to see that the aircraft climbs with throttle_max (say 75%, or even 100%) and keep the airspeed at the airspd_trim figure by using pitch. The vertical speed that comes out is a variable and will be the result of all the factors I mentioned before. This goes for descent as well. Use Throttle MIN and keep the airspeed constant by pitch. The vertical speed is a variable.
I could ofcourse try to achieve this by setting TECS_SPDWEIGHT to 2.0 (I think, haven’t tried it yet) however when flying level I don’t want the pitch to control the airspeed because I don’t want the large altitude deviations that come with it.
So my suggestion: the current speedweight parameter split in 2 speedweight parameters: One for climb/decent and the other for level flight. In my case I would set the climb/descent speedweight to 2.0 and the level flight speedweight to 0,5 or so.
I agree that much more work needs to be done with the speedweight function. Every since it was introduced I have never been able to get a setting that I liked on some aircraft. Some fly ok with default but some never fly well. For those aircraft I usually set it to a small number. This is the only area that I am not happy with. Everything else flies amazingly well.
Did some more testing today. Using speedweight 1.0 the aircraft descents about 10 meters when it turns to a heading on which it experiences a sudden tail wind (we had about 10 knots wind). It tries to correct the temporary loss in airspeed due inertia (the aircraft needs to increase groundspeed all of a sudden) by a gentle dive. I don’t want that so I set speedweight to 0.5. It now only varies by a few meters, which is good.
I then wanted to see how it performed in a large commanded climb. I already knew I wanted a higher speedweight so I set it to 1.5. The vertical speed I requested was intentionally too high (8 m/s) because I want the aircraft to climb using max throttle and to keep the target airspeed using pitch. This worked perfect, it achieved a vertical speed of only 3,5 m/s but the airspeed was kept within 2 m/s of target airspeed.
So this is why I would like the firmware to be able to distinquish between flying level (using pitch for altitude keeping, using the motor for speed keeping) and climbing / descending (exactly the opposite: using pitch for airspeed and using the motor for climbing / descending)
Advantages:
More efficient altitude keeping, climb and descent performance
Safer, less chance of a stall when too steep a climb is requested. Also less chance of aircraft flying a lot lower than allowed when flying level.
Easier tuning, no need to find good target vertical speeds for each different flying weight.
It could be done as suggested before, having two different speedweight parameters: one for flying level and one for a commanded altitude change. Is there any chance for something like this being looked at? Or should I post this on a different forum? (DIYdrones, GitHub?)
One more speedweight / stall protection related suggestion:
No matter what speedweight value you have (I like a high figure but might use a low one sometimes), when airspeed falls below FBWA_MIN speedweight becomes temporarily 2.0, to decrease pitch until airspeed is FBWA_MIN again.
You might not want this in landing to prevent a dive into the ground, but certainly in climb. If the engine stops working it automatically behaves as a glider, giving the user a chance to land it manually, instead of stalling.