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)
- 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.