also, if you haven’t seen it, its worth reading this page:
http://ardupilot.org/plane/docs/common-transmitter-tuning.html
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
- AHRS_EKF_TYPE=3
2 Likes
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
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:
https://github.com/tridge/ardupilot/commit/de3f5f88d7e8f26591b1406c6818f1ee675b8830
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!
no problem. Binary is here:
http://uav.tridgell.net/tmp/plane-tailsitter-leonard-fmuv4.px4
if you can also send a log of your first flight I can take a look and offer some suggestions
Cheers, Tridge
I should also mention one other potential issue with Leonards patch. Imagine you are pitched over 40 degrees and it is trying to right itself. It will add a lot of throttle to do that. If it manages to right itself then all is good. If it doesn’t then it is going to start flying forward pretty fast!
Test in a largish area 
With a 2:1 power-to-weight ratio, that is definitely the case! Luckily we have a 400m x 300m field behind our office that we use for flight testing, so space shouldn’t be a problem. I left my GCS computer at work, so the log file will have to wait until I get back to the office. Do you want the tlog or the dataflash log?
dataflash log please
@tridge I flashed your pr-tailsitter-compensation branch on the Stryker, but it’s raining here now…
EKF3 log is here (similar loss of pitch control): https://drive.google.com/open?id=0Bw3digSMQXDuRmtob3NycmRlU1k
PTCH2SRV_P is for fixed wing flight. Q_A_RAT_PIT_P is for hovering. We use two separate controllers for the two flight modes, with separate gain settings.
you could push MIXING_GAIN up to 1 if you wanted to try that too. I wouldn’t go above 1.