Dual-motor tailsitters

Hm, I was thinking the same thing except with Qstabilize, I like to have more control over the thrust. I’m just trying to think of the best place for the tether. The simplest placement I can surmise would be between the motors attached at the middle top with a crane or something holding it. What do you think?

Thank you for your input Mark, it is much appreciated.

Agreed, qstabilize would be better if you have sufficient skill in throttle management, and you can clearly see the rate of climb. But I’ve had a crash in qstabilize where I let the descent rate get too high and couldn’t recover in time. The risk of that can be reduced by increasing SPIN_MIN to keep the thrust from getting too low.
With my models, I attach the tether to the nose and suspend the model from the shop rafters for initial tuning. Thought I posted a youtube video of that, but can’t find it now. If I’m really paranoid about testing qhover this way, I attach a second tether to the tail to prevent a runaway climb.

1 Like

That will be quite a machine! Got any pictures?
Note that none of us have experience with tailsitters of that size, and this would be the first ICE tailsitter with ArduPilot that I am aware of.
If you have funding to pay for consulting then I’d suggest Leonard Hall or Paul Riseborough. I can give contact details if needed.
Otherwise here is what I suggest:

  • build a good RF9 model. The model will almost certainly not allow for getting a good tune with your real vehicle, but it will likely get you in the ballpark and should allow you to find any major issues with this scale of vehicle. Concentrate on the mass distribution in the model and the motor response curves and timings
  • ensure you have a really good isolation system, and test it with a tethered test stand, ensuring the EKF stays completely happy with motors running
  • build a really good hanging tether for testing. Constrain it to one axis at a time initially. Have a single simple motor kill switch on RC transmitter and make sure that tether can handle large forces
  • take it slowly and carefully, documenting your experiments as you go. Expect it to take dozens (possibly hundreds) of short flights in the tether to get a good tune.
  • do not try a fwd transition until the QSTABILIZE flight is really solid, including rapid non-oscillating recovery from large disturbances

and most importantly, feed us with lots of videos :slight_smile: Maybe start your own blog post with updates after each test?
Cheers, Tridge

3 Likes

I started always with test in a Rigg to optimize parameters without risk.

So the idea with a crane is good.

3 Likes

Hi Mark,

I’ll definitely tamper with SPIN_MIN at some point, good you pointed that out to me.
A tether at the top and bottom seems like a really safe avenue, think I’ll start with that after simulations.

Have a good one,
Shef

Tridge, thanks for your response, I know all developers are busy people.

I don’t have any pictures, nothing is built yet (except for a really ugly bent up plank that I’ve been using to learn ardupilot).

I may take up Mr. Hall and Riseborough’s help at some point, I would like their contact information if you would.

I’m not familiar with any flight simulation software, would RF9 be able to estimate rotation rates based on the size of the elevons? Or perhaps it doesn’t allow that kind of customization. Very good tutorial you made here btw: https://ardupilot.org/dev/docs/sitl-with-realflight.html

I will indeed focus on minimizing vibrations with isolation mechanisms.

Good advice on the tether, I have a switch that disarms the craft, that will always kill the motors no?

I will share what I can.

I have a thing about fwd transitions and FBWA, I don’t trust these modes mainly because I don’t have yaw stabilization (everytime I switch to FBWA my plank yaws out of control, I won’t be using fins so I need yaw stabilization). I’m actually able to fly the plank at high aoa’s in Qstabilize (imitating fwd flight) by increasing the Q_angle_max parameter. There’s significant oscillation at around 90 deg though, I need to try at 80 and see what happens. It’s also difficult to turn unless I ease up on the angle to around 70 deg. It’s to be expected, but I kind of want to be able to have it as my back up mode if Qacro doesn’t work.

Tridge, really important question for you- when in Qstabilize does the angle calculating algorithm use the GPS at all to help correct its orientation (or estimate its attitude)? I am aware that it does use an airspeed sensor to scale gains as discussed here https://ardupilot.org/plane/docs/qacro-mode.html

I think QACRO provides rate based yaw stabilization, so I think I’ll mess around with that mode and see what happens. Why doesn’t FBWA support differential thrust yaw stabilization anyways?

Any insight would be much appreciated, thanks

Shef

Lorbass my good friend,

That is one nice test rigg you got, I was thinking of a tether at the top and bottom (nose and tail) of mine, but perhaps if I find that method unsatisfactory, I may choose to make something similar to what you have here. Very cool.

Shef

The wing is fixed with a universal joint at the CG.

A universal joint, I think I heard about such a thing somewhere -I need to study up on it. Thanks for the info!

Hello Mark!

Two things to report, one is that no magnetometer is needed to fly in Qstabilize or Qacro (only hovered breifly in Qacro), I’ve flown in both with all compasses disabled and although there’s definitely some drift, it’s very manageable. You would of course need a magnetometer for any of the autoflight modes.

Secondly, I think you mentioned somewhere that you were going to check if FBWA supported differential thrust yaw stabilization. Correct me if I’m wrong perhaps someone else has told me that. But it does actually, it just needs to be enabled with the following paramteres:

KFF-RDDRMIX : 0 WAS .2
YAW2SRV-SLIP : 0 WAS 0
YAW2SRV-DAMP : 0.08 WAS 0 (.08 is suggested but it may need to be higher or lower)
RUDD-DT-GAIN : 100 WAS 10

Anyways, have a good one Mark!

Thanks Shef. Which frame_class are you using with those parameters for differential thrust yaw stabilization?

Never mind, I finally found the code path which does FW yaw stabilization.

Hey Mark,

I’m just using the standard 10-tailsitter frame class.

“I finally found the code path which does FW yaw stabilization”
nice.

Another question for you dude, does Qacro naturally try to soft-level a dual motor tailsitter in any way? Because when I fly in Qacro and I bring the nose down to simulate forward flight it’ll actually slowly come back up requiring me to bring it down again.

And when it experiences significant wind, sometimes it’ll get rolled to where it’s flying upside down but it won’t try to bring itself back rightside up and rather just lock itself in that upsidedown position until i command it to roll back rightside up.

And lastly, sometimes when it gets hit hard by wind it’ll forget about the old orientation it had and instead try to keep its new orientation in Qstabilize and sometimes like I just mentioned in Qacro. I read somewhere that this is supposed to happen when the autopilot has judged that it can’t maintain the orientation it had and instead just focuses on keeping a new, closer orientation. Is this true?

Thank you,
Shef

One question about Quadplane windvaning implementation:

How does the TS defend itself against the wind?

  • Positioning the marginal edge in the direction of the wind and correcting with differential thrust or
  • Standing with the wings facing the wind and correcting with both motors

There is a demo:

Its not in master yet tho.

ok understood
yes I know it is not implemented yet but it was just curiosity.

it would be wonderful to see one Aruplane TS defend itself against the wind.

Covid restrictions are delaying flight tests, last week I was able to fly again. Take off correctly, the transitions were more than acceptable for the first flight. :grinning: :grinning:

Just one problem. in QHOVER mode if I move short pitch movements TS recovers the verticality when I center the stick but if I keep pitch for several seconds then it is NOT placed nose up; it stays horizontal and moving forward until switch to QSTABILICE and then if it turned nose up.

I think the cause could be the CG in the vertical axis (nose up), I cannot move the battery to the bottom of the fuselage and therefore the solution would be to imagine increasing Q_TRIM_PITCH.

Or increase Q_A_RAT_PIT_FF.

I broke one propeller absurdly in the land and the second test will be delayed but I would like to have it ready for when I receive the propellers.

Can you think of any other reason why it doesn’t regain vertical when centering the pitch stick in QHOVER mode?

Did you observed elevons deflection ? From what you describe we can suppose elevons where almost fully deflected at 40° lean angle in order to balance the wing and they did not have enough authority to get the nose up. Switching to q_stabilize allow to increase airflow on control surface. If you look at PIQ_P_I you will probably see that I term saturate to Imax. You can try to increase Imax. But what we want to fly safely a tailsitter is a minimal elevon deflection whatever the attitude. To move the CG backward will give a better balance in hover and then will probably lower elevon defection to regain authority. If possible, increase Q_a_rat_pit_p and Q_a_rat_p_ff will help too.

Sorry, it is always better to attach the. bin and video.

36" > I start pitch up on QHOVER mode
40" > I center the stick pitch
43" > I change to QSTABILICE mode when I see that it does not recover the vertical

Maiden flight video

Maiden flight log

Before the flightI I had increased both parameters:
Q_A RAT_PIT_FF = 0.4
Q_A RAT_PIT_IMAX = 0.55

The authority error to verticalize when centering the stick pitch I think it must be more correct centering of the CG.

Thanks for the video, I like it so much. But no log.

Sorry, I was wrong. it’s ready