Dual-motor tailsitters

this is a log done with flight test hybrid rebased

There are plenty of transitions between q_hover or q_acro and fbwa. Original forward transition is restored. I hope the investigation was not too painful :face_with_monocle:

1 Like

@losawing Thanks, the forward transitions look good to me too. That bug crept in with the gain scaling changes, and I just found another one that only affected logging in qhover/qstabilize. Iā€™ll update the binaries shortly with permanent fixes for both.

Finding that bug was easy once I started comparing to the known-good binaries you indicated. Thanks for that! Implementing the body-frame roll feature was much more difficult.

It looks like the attitude/throttle based gain scaling was working pretty well too. Do you think it may be good enough to eliminate the need for a pitot tube?

I have seen desired pitch was not logged but I coulā€™d imagine it was a bug.

All of these features are very new and need more tests to get reliable conclusion. At speed > 10m/s attitude scaling is very good for both qacro and qhover modes as airspeed scaling is very good at eliminating oscillations only with qacro (and also need to be improved at very high speed). On the other hand it seems to me the airspeed gain scaling works better at low speed. Maybe attitude scaling tends to overshoot when pitch pumping and with the back transition. This is still not very clear for me. Probably, it will be easier to analyze with the correct logging of desired pitch.

I donā€™t think we can write airspeed scaling off yet, just need to get a feel for the parameters, if there is any oscillation you need to lower the upper scaling speed.

It works well in the simulator and has the quite significant advantage (again in the simulator) of allowing the use of gains direct from Qautotune

@iampete

didnā€™t mean to imply that we should not support airspeed sensors, just that it would be nice if they are not mandatory.
I see the attitude/throttle based gain scaling as potentially enabling high speed operation without an airspeed sensor.
We should probably separate the two methods into different commits to make it easier to work on them independently. And maybe clean up the params as you suggested. Currently, we use THSCMX to choose between the legacy (throttle-based gain boost) and new (attitude/throttle-based gain attenuation) methods. Airspeed based gain interpolation is used instead if SPDMIN != SPDMAX. If we added an enum, the choices might be:

  • legacy (3D planes with Q_ANGLE_MAX relatively small)
  • attitude/throttle based attenuation (agile tailsitters with Q_ANGLE_MAX large)
  • gain interpolation (airspeed sensor required)
  • airspeed based gain attenuation (airspeed sensor required)

The last option would be similar to the second one, scaling the copter outputs instead of running the plane controller.

sorry, I misunderstood.

Might be worth trying the attitude/throttle as a input for the gain interpolation. I.e. interpolate gains on attitude rather than airspeed. I think it might work OK and would be a nice way to
compare the interpolation to scaling.

@losawing New binaries with logging fixed: https://drive.google.com/open?id=1fADp1vpQMB5ccJ3_3uIv2RGJWQ5RfB0x

only tested in SITL

I know you are interested in tri motor configuration. This one seen on RC group would be amazing

Two more flights this evening with the last binaries to compare low speed stability with q_talsit_thscmx=1.1 and 0.2. Test done in q_hover mode with max_angle=8000 asking the wing a maximum pitch rate back and forth. Sometime with the overshoot the leam angle is more than 90Ā° at less than 5m above ground, so this test is very hard but whatever thscmx the wing was able to recover quickly. So for me this is very fine. These last days I have moved the CG backward and changed some parameters as it was important not to hit airframe limitation.
Transition are OK but the second log contains errors (first one is OK !!)
Yesterday I tried an inverted loop with qaco mode and gain attenuation based on lean angle and I had a weird behaviour, do you ever tried with RF8 ?

I have noticed ā€œglitchesā€ in attitude control in RF8 when doing outside loops. It seems as though the attitude error gets too large, and perhaps something resets internally. It seems that lowering the value of ACRO_PITCH_RATE avoids the problem in RF8. Did you forget a link to the logs?

I am thinking about making my next build a trimotor configuration based on the Simitar design. Found a source for plans and wing cores here: http://www.eurekaaircraft.com/simitar/simitar_stuff.htm
Thereā€™s even a twin-engine example, and the fin provides an obvious location for a third motorā€¦

I just updated the flight-test-hybrid-rebased binaries to fix a small error in tailsitter.input_type=3
There should be no coupling between earth-frame yaw and body-frame roll now.

this is a log with an aborted outside loop.


outside loop begin around line 570000. Maybe you will be able to see if there is a glitch, it seems to me there is a sudden rate change but it can be also an airframe limitation. Acro pitch rate was 180.

When I open a log I always get the warning

And can only read the log with apm planner if I do not use time on x axis.

I went to Eureka aircraft web site and this is a great source for foam wing core. There is a large choice at fair prices. I hope to see a video of your simitar soon.

There was a bug in my CTHP log record, didnā€™t notice because MAVexplorer doesnā€™t complain; just updated the binaries with a fix for APMplanner2.

I think the pitch rate demand was more than the airframe could achieve for that outside loop (maybe airspeed got too low):

but I should be able to modify the code to reduce the demanded rate when the attitude error becomes too large. Thereā€™s also the possibility of increasing the gains if attitude error is growing, but that could be unstable.

It looks like the gain scaling could use some improvement too, this shows that the gain needs to be attenuated more rapidly as the tilt angle increases. Maybe a form of exponential with an adjustable parameter? (the black MSQy plot shows oscillation in bodyframe roll prior to the start of the loop)

@losawing I forgot to mention you can try ACRO_LOCKING = 0
That specifies rate-only control so you may notice some pitch trim issues (could be major if CG is off). I donā€™t see those attitude control glitches in the simulator using that mode. In the simulator, with ACRO_LOCKING = 0 and ACRO_PITCH_RATE = 360, a full throttle outside loop takes 4 seconds, and there is no loss of pitch control.

I found acro_locking=0 is much better The flight attitude is more natural and the stability at high and low alpha is still very strong, this is really a great fun. I succeed to make an outside loop, not the most beautiful but did not get any glitch.

Hi Guys
I just built Quad Tailsitter without control surfaces for testing
to control horizontal fly with differential thrust(pitch and roll) (add. photo)
Are there firmware that does that, or what I must do in Plane 3.9.7 parameters
that Quad Tailsitter is possible to fly.QuadTailsitter2

You will have to use one of @kd0aij 's firmware, Plane doesnā€™t do pitch control using differential thrust so you will have to fly in Qasssit the whole time.

What flight controller are you using?

I would definitely recommend you have at least a elevator control surface.

Hi
For this QuadTailsitter I have Radiolink MiniPix (only 6 outputs)
May I install this firmware, and how?

I canā€™t find the Param TAILSIT_RLL_MX in the Version 1.3.64 stable.
Not already realized?

By the way: Again thanks for the possibility to increase the ANGLE_MAX.

looks like its not made it to stable yet