Q_TAILSIT_INPUT is ignored In QACRO mode; the roll and yaw sticks always command body-frame roll and yaw rate. There should be no functional changes in QACRO between the branch you have been flying and this new PR.
The new PR is just a subset of the previous branch, including only the new versions of ATT_THR and BOOST gain scaling. Since an older version of those was already in master, this is a smaller change to master than before.
So this PR leaves GAIN_INTERP and Q_ASSIST to be added as the next one or two steps. I’m actually not sure I understand how q_assist works with a tailsitter, since there is not an extra set of motors to “assist”.
frame_class will still be 10 for dual-motor tailsitters, or 1 for a copter tailsitter with non-zero q_tailsit_motmx, as before. And q_tailsit_gscmsk = 1, 2 (and 3) are all supported.
CatTailsitter has moving Props and Motors. I designed the graphic and Tridge finished it.
Bi-WingTailsitter has not, even all correct and build up with the RF8 Model CatTailsitter Link.
I compared the two Models In 3DS and RF8 and can’t find the difference. (except more wings, props ,motors and spinner)
Will try to start with CatTailsitter and transform it step by step into the Bi WingTailsitter to discover the magic about the Props
e.g. Modify one part, export 3DS , import RF8, check Props, delete Model in RF8, Modify another part, exp… may take some time.
congratulations, hover modes are improved once again. I had to wait 17pm that the rain stop and made a flight with my biwing.
gscmsk=2, gscmin=0.2, angle_max=8000, input=2 or 3 , The difference is the handling, the wing fly now exactly like an airplane in hover mode, there is no rates limitation and the handling is totally natural. This is a big improvement, before there were a yaw rate limitation and the handling was not so natural. I did no get oscillations with this gain attenuation and the maximum speed allowed by the 80° lean angle. No difference in the handling with input 2 or 3. I have tested mainly q_hover and shortly q_stabilize. It seems to me q_stabilize is OK too. Also, Q_tailsit_rll_mx works as it should. I have not tested transition or q_acro.
I have tested also input=1 and the difference is enormous: at high lean angle the wing does not turn or does not bank in the same way it was before you add input=2,3.
There is only a very small complain as when hovering vertical the yaw rate is limited by q_yaw_rate_max as it should but caped by something else and the max rate is about 90°/s. Strangely this limitation is disabled in q_loiter. This limitation was already there in previous binaries.
About q_loiter, input = 2 is disabled for this mode, it is always mode 3 (or 1 ?) and q_tailsit_rll_mx is disabled.
many thanks for the rapid response; I really do have to build something so I can help with flight testing, although it’s 0C with a north wind of 20mph here right now.
We have to thank @tridge for pointing out the flaw in my rate-scaling logic. I’m sure fixing that is what improved the handling.
I’ll look into the limitation on yaw rate. It could be due to an internal limitation on yaw error in the control system to avoid instability.
I hadn’t thought about q_loiter… in that case roll and pitch sticks control lateral and forward speed and tailsitter_input type does not apply. I expect there are other parameters for q_loiter which limit the roll and pitch angles.
I misread your comment on q_loiter input_type: and I was wrong about tailsitter_input for q_loiter mode: if it is zero (MC style) roll and pitch sticks are not swapped, otherwise they are.
So, as you reported, q_loiter currently behaves the same for input_type = 1,2,3 (plane mode, and both body-frame roll modes). I’m not sure how to fix it though…
Thanks, but it will be nice (and save documentation) if the discrepancy can be eliminated. I think viewing the input_type as a bitmask might be a simple way to fix it.
The limitation on body-frame roll mode roll rate is in fact due to an internal limitation on the magnitude of yaw error in the body-frame roll mode control loop. It’s not as sophisticated as the one which is used for qloiter mode. I’ll put that on the wish list since it looks relatively easy to improve it.
I fixed the input_type behavior for q_loiter; now you get MC mode controls with input_type=0 and 2, and plane mode controls with input_type=1 and 3.
I was also able to support somewhat faster yaw rates in hover for the body-frame roll modes for qhover and qstabilize, but they still have a limit dependent on yaw control error and should be more stable than q_loiter mode.
The pr-gsc-base binaries have been updated with these changes.
both fixes tested, they work perfect. I set q_yaw_rat_max to 180 and the wing seems to follow that rate.
Transitions are OK, I have been flying q_acro shortly: OK too. For Q_acro test I left cgsmask=2 and gscmin=0.2 and did not get oscillations.
I begun also to tune the q_loiter controller. Stability and braking are good. I will test it more and try an auto flight with take off and landing soon.
I changed to 180°/s around index 856000, it was 120 before.
There is a nice feature in apm planner as we can filter needed data among logs huge line number.
The cursors in APMPlanner2 are nice also.
When the yaw rate demand went back to zero, the vehicle continued to yaw for 0.8 seconds and overshot by about the same amount (98 degrees). Probably some room for improvement there, but do you find the current behavior acceptable?
I did not notice the lag, probably this is something I am used to and I release the stick accordingly. The lag might be also related to airframe inertial moment and servo speed, overall it is very acceptable. I have some experience of flying acro with a normal plane and I can say that when hovering or doing torque roll the lag is much much higher, but of course it is due to airframe limitation.
Thanks for the cursor tip, sometime I need to know average values and I was unable to get them.
Great, I won’t worry about that latency for now.
I also changed the gainscale logging. The scale factor is correlating well to your airspeed in qloiter:
I have rebuilt the Model. Now with moving parts. But the lower mots I had to replace by simple cylinders. Else it would not work. e.g. when I copy one of the top motors, rename and replace it to the lower mot.carrier RF8 crashes as usual wiht “unexpected error”. Absolutly no error handling.
The servo channels have to be modified according the needs of SITL. https://drive.google.com/open?id=1LcL6ecmT6sLR2hnDKXK3gH2mfjNG5pKQ
And below how crazy the Mot.Carrier has to be designed in order to be correct in RF8.
These can not be upright even not when rotating the part-axis.
I tried to use SITLin order to test my “Product”.
But as described in the Dev.Wicki for RF9 it does not work for RF8.
At this place it’s nothing like FlightAxis to select.
*
On RealFlight 9 go to Settings->Physics and enable the FlightAxis option then restart RealFlight.
to SITL and RealFlight 8.
I think I will stay with apm planner.