Dual-motor tailsitters

most people use google drive similar services

Mark wins first flight for a dual-motor tailsitter!
video soon …

1 Like

Go, Mark!
I hovered mine in hand, and it feels and responds like it should,

note that Mark had MIXING_GAIN=0.5, which is the default. For a tailsitter I think MIXING_GAIN=0.8 or even 1.0 would be a lot better. Be careful though, as it will scale all your gains. So if you’ve already tuned for hover then backoff the gains in proportion to the change in MIXING_GAIN.
I think with 0.5 mixing gain you will be lacking in pitch authority

yes, pitch is slugish but locked in, roll to fast and locked in, yaw little slow and not locked in yet I also think q hover is going to work as well ! GO Tridge!

youtube video of the Stryker’s first flight with ArduPilot: https://youtu.be/3kIKLgSraLI


video or it didn’t happen!
if you’re having trouble uploading DF logs then you can email it to me at andrew@tridgell.net

some other tuning tips for tailsitters. I think a bit of feed-forward on pitch and yaw axis would be worthwhile. For example:
thats just a guess, but should be better than zero.
I also think that setting I equal to P on all 3 axes will help. By default I is a lot smaller than P for yaw, which is right for multicopters but not for tailsitters.


also, if you haven’t seen it, its worth reading this page:
Mark used that for tuning his with some success.

I’ve just pushed an important fix for logging on tailsitters. The logging was in the fixed-wing euler view, so it suffered from gimbal lock. It now rotates the attitude logging when hovering. Makes it much easier to analyse logs.

what GCS software are you using?
Also, you can just grab logs directly off the microSD. Look in the APM/LOGS directory. The bin files are the ones we need.

1 Like

one more tip for tailsitters. I recommend using the new EKF3 instead of the EKF2 state estimator. The reason is that EKF2 only estimates Z accel biases for one axis, and that is the Z axis for fixing wing orientation. For a tailsitter what we primarily need is Z bias estimation for the X axis.
The EKF3 code estimates accel biases for all 3 axes, so it will probably hover better. To enable it change these settings:

  • EK2_ENABLE=0
  • EK3_ENABLE=1

I made all of @tridge’s suggested parameter changes and I had my first successful hover this morning. I’m using earth-frame controls for hover. Here are a couple of things I discovered:

My leaning-forward takeoff position doesn’t work. The thrust of the motors is pivoting the aircraft around the point where that front kickstand is touching the ground, and it doesn’t have enough control authority to stop the rotation before it gets horizontal. After two attempted takeoffs from that position, we propped the aircraft up to near vertical (80 degrees) and had a successful takeoff.

Yaw control is good

Roll control is good

Pitch control is good, up to a point. The aircraft was hovering nicely for about 10 seconds. It was a little blustery, probably more than I should have attempted a first flight in, but I’m impatient. A gust came through and hit the underside of the aircraft, causing it to pitch forward. Despite full pitch-back input from me (and presumably the flight controller) it wasn’t enough to get the nose back to vertical and it started to fly away, eventually pitching down to roughly 30 degrees nose-up (from forward flight attitude). I was in a relatively confined area so I put it in manual and released the controls to kill the motors.

Looking at my logs, it appears that about 25 degrees from vertical is the point where the pitch becomes unrecoverable, but I’m sure airspeed is playing a part. Once some forward airspeed develops, I think aerodynamic stability is going to try to pitch the nose down. Any suggestions on overcoming this? My two ideas are to increase the size of the control surfaces (which seems to be common), or to use a way aft C.G. so the aircraft is aerodynamically unstable in pitch, and rely on the FC to stabilize it in forward flight.

I’ll post a video when I can get around to it; I need to get some actual work done before I can play with this project some more.

1 Like

Video: https://drive.google.com/file/d/0B6c7J-YiLJdsZEEwX3U5RnQxUE0/view?usp=sharing

1 Like

Hi, what I ended up doing is… thrust vectoring,use the thrust to keep attitude were you want

That’s definitely the more effective solution from a controllability standpoint, but I’m trying to avoid the extra weight and complexity of motor pivots. I would really like to minimize the amount of extra stuff required on the airframe to allow for vertical takeoffs and landings, compared to the conventional fixed-wing equivalent. I’m going to keep pursuing an aerodynamic solution, and maybe try some flight testing when it’s not so windy outside!

1 Like

I agree.keep us posted

the only idea I have is to apply Leonard patch to automatically increase throttle as the attitude goes off. That is the theoretically correct fix for this type of aircraft. The main reason it hasn’t been put in master yet is that for the only test aircraft I have (my AddictionX 3D aircraft) it could damage the aircraft. The AddictionX takes off from a horizontal position, and has a big power to weight ratio. When it is taking off in QHOVER with leonards patches it is so aggressive about bringing the aircraft into nose up orientation that it can slap the tail on the runway, potentially breaking it.
That problem doesn’t happen with a real tailsitter like yours.
The patch is here:
If you could try it on your tailsitter that would be great. If it helps then we could enable it with a parameter, and have it on by default.
Also, can you upload a DF log of your flight?
Cheers, Tridge

btw, I can build you a binary for your board with Leonards change if you would like me to (not sure if you are building your own fw or using the prebuilt ones?)

If you can build me a binary with the patch that would be awesome. I’m running using a Pixracer. I’ll send you my email momentarily. Thanks!