Servers by jDrones

Dual-motor tailsitters

(Mark Whitehorn) #1818

Yes, this is a major disadvantage of a non-vectored dual-motor tailsitter. I had tried to write code to automatically boost the throttles when in this situation, but didn’t have much success (although the PX4 code has a feature to recover using roll/yaw gymnastics, that takes a fair amount of space).

So I agree that a warning should be in the wiki somewhere; would you be willing to suggest some text?

(letpi) #1819

Hello,
I don’t think the Zohd Orbit has been modified to dual motor tailsitter. You have the choice to make it vectored or not. I strongly advise to begin with vectored motors because the zohd has small elevon surface and is not designed to be a tailsitter. Without vectored thrust the pitch axis will be very hard to control. To begin you don’t need specific servo or a complex mechanism, a 20g servo and ±30° will be good enough. Rotation axle should be in front of the CG.
An other possibility is to make a quad motors tailsitter, this is probably the most stable configuration and you avoid the complexity of tilt motors.

(Pilot) #1820

Hi, what a great topic you have here!
Took me a while to read through all posts, and it did provoke some thought process. I’d like to share some ideas and observations.
If main problem of non-vectored tailsitters is different requirement for CG an in forward flight and hover, maybe it’s possible to change location of CG by moving battery inside the plane by means of servo actuated by estimated airspeed. Another option is to move center of pressure by moving tail/canard type surface back and forth (less feasible).
Dozens of tunable parameters are intimidating, and their number is continuing to grow. Maybe some kind of analysis can be done on logs to automatically find better set of parameters, and then load them into aircraft and fly again, then repeat.
Existence of two sets of PID parameters (plane/quad modes) complicate things two. In reality it’s the same aircraft, so only one controller should exist, (obviously dependent on the airspeed).
Also there is no technical reasons (other than operator convinience) to have speed/pitch angle limited in qstabilize mode. Transition can be seamless (in theory).
On note of transition - if you need rapid transition from hover to FF, it can be done via yaw/roll combination (sort of knife edge).
About quad tailsitters without control surfaces - should be possible, do not see why not. But the frame should be aerodynamically stable in forward flight.
Overall, I think we should rethink controller hierarchy. Airframe types have a lot in common (some combination of (potentially vectored) motors, fixed and articulated aerodynamic surfaces). Given the configuration, there should be a way to know what frame can do (max angular acceleration vector, max acceleration (thrust + lift) and how (servo/motor outputs given current state, including airspeed vector)). It can probably lead to unification of plane/quadplane/quad/tailsitter codebases.
Modes, on the other side, should concern only translating user input/waypoints to desired linear and angular acceleration vectors. Maybe it’s how it works now, I just had a brief look at the codebase.
I was thinking, vectored tailsitter with control surfaces can probably move without roll if motor tilt and ailerons with not work together, but against each other, giving zero pitch change (but very slowly, because vectored motors have much greater pitch authority then ailerons).
Overall, I am very excited because I think tailsitters with allow for very efficient flight in terms of range - very high wing loads become possible without concern of takeoff/landing speeds.

(letpi) #1821

congratulation for reading this long long topic. This not easy to answer your long post with so many thought Moving Cg is a good idea, tailsitter concept is interesting because it is open to innovative design like the amazon delivery drone shown recently by @iampete.
You are right, there is two set of PID but the work recently done by @kd0aij and @iampete about qacro and several gain attenuation method allow to fly with only one set. Stabilize mode with limited max angle is very useful because most airframe are not able to recover at high lean angle and low speed, specially is they are not perfectly tuned.
Probably a lot more can be done, I cant say, my skill is more about building and tuning. But lets go.

(letpi) #1822

This is not an exercise I am not familiar with but I can not escape :innocent: So the warning could be:
Ttransition from qacro mode to any qstabilize mode should be avoided as no throttle boost is involved. This is critical when airspeed is needed for attitude control, eg dual motor tailsitter.

(Mark Whitehorn) #1823

Thanks! I started a PR for the wiki here: https://github.com/ArduPilot/ardupilot_wiki/pull/1799

I tried to expand the explanation a little bit; let me know what you think.

(Mark Whitehorn) #1824

Welcome @bojxkimq and thanks for your comments.

As @losawing pointed out, we have made some progress toward using a single attitude controller in all flight regimes of a tailsitter, but there are very few people in the world that would qualify as test pilots :slight_smile:

One thing that has been encouraging is the success which @losawing has shown with the gain scaling option which needs no airspeed sensor. That allows 3D acrobatic flight over a large speed range with a very simple quad tailsitter.

(Pilot) #1825

I think the problem of lack of the test pilots is because setting up ardupilot for tailsitter is very involving (dozens of test flights and half as many crashes). And even after that you will just hope EKF will not freak out or you will not experience instability is some corner of flight envelope.
Regarding EKF, how feasible do you think is to have 6DOF + baro only, but including control outputs (motors + servos) as inputs of EKF for estimation of wind speeds?

(lorbass) #1826

Yes, that makes it interesting and it is a challenge to solve all problems.
The only area where creativity can still be lived compared whith unboxing and play.
There the only challenge is to be able to charge the battery.

I’m not a developer but as I understand it is possible to get a branch and to follow another way in programming. http://ardupilot.org/dev/index.html

(Mark Whitehorn) #1827

The ArduPilot EKF is extremely robust now. I have installed a PixRacer/GPS as a blackbox logger in an RC pattern plane which was then flown by an expert pilot; lots of inverted flight and aerobatics including snap rolls. The EKF attitude estimate has never diverged in these flights, so I think it is quite capable of providing the attitude estimate for a tailsitter: https://drive.google.com/open?id=1rWynvwDezjSUxcP3tYw3upWoesd6r1FR
Not only is it stable, but the accuracy of its results will be better than that using gyro/accel/baro alone.

(Pilot) #1828

I am quite sure it’s very robust for conventional plane dynamics, and with some altitude where GPS has good fix (no multipath, no obstructed satellites).
I understand having GPS is better than not, but it would be nice to be able to do tests indoors, where GPS is not available, and cope with GPS problems if they arise.

(Sam Salway) #1829

Hi all. Long time reader, first time posting. Thanks to everyone who contributes so much time to making tailsitters possible. I’ve learnt a lot from reading this thread.

I’ve managed to modify an FX-61 as a tailsitter. It hovers pretty well after manual tuning (zeigler nichols method as someone above suggested). I’ve just done flight tuning with autotune, it’s flying fine. However, transition back to hover is doing some weird stuff. Desired pitch seems to oscillate, then throttle gets cut. It looks pretty wild in the air, but eventually it hits the throttle again and gets right. Anyone have any suggestions? I’m hoping to get it a bit smoother than this.

Edit: log https://drive.google.com/open?id=1DmQmVAD1B3-l6N2KQPL35EIuo8J-jsUT

(letpi) #1830

Glad to see a new tailsitter user.
Is the log the right one ? I can not find any transition, just auto and FBW.
A photo of your FX61 would be great too.

(Mark Whitehorn) #1831

I’m not sure what’s going on with desired_pitch, but it looks like autotune may have set your pitch gain too high. Did it increase significantly from your manual tuning value?

(Sam Salway) #1832

I just downloaded the log from the link to make sure, yeah it’s the right log. I did an auto mission twice. The mission was vtol takeoff, fly through 5 waypoints, vtol landing. It’s after the last waypoint when it goes to vtol landing when it transitions.

(Sam Salway) #1833

I didn’t do any manual tuning of the forward flight controllers. I initially halved the default values for pitch and roll, then did autotune. The first time I did autotune it dropped RLL2SRV_P down to 0.3 from 0.45, and didn’t change PTCH2SRV_P, it stayed at 0.3. The second time I did autotune it didn’t change anything, they both stayed at 0.3. Makes me wonder, is there a limit on the autotune range preventing it from going below 0.3?

(Sam Salway) #1834

Here’s my baby. I’ve extended the ailerons. I took the wingtips off to bring the centre of pressure forward during hover movements in the pitch axis which helped. I’ve been through a couple of motor/prop combinations and had to modify the motor stands for this one, next time I won’t need the motor mount offset like it is.

(Mark Whitehorn) #1835

I was talking about your copter PID gains, which are Q_A_RAT*
Your pitch gains are
Q_A_RAT_PIT_D 0.004830
Q_A_RAT_PIT_FF 0.200000
Q_A_RAT_PIT_FILT 10.000000
Q_A_RAT_PIT_I 2.000000
Q_A_RAT_PIT_IMAX 0.500000
Q_A_RAT_PIT_P 0.444000

The I gain looks very high; how did you arrive at these values?
I’d try decreasing the I and P gains to see if that improves the back-transition.

(Sam Salway) #1836

I tried to follow the zeigler nichols method. I disabled I and D (Q_A_RAT_*_D to 0 and IMAX to 0), then using manual tune ramp up the P gain until the plane oscillated. Then I use the log file to measure the frequency of the oscillation (Tu) and the gain where the oscillation starts (Ku). That goes in to the zeigler nichols formulas.

This was my results for pitch:
Ku = 0.74
Tu = 87ms (measured 11.5Hz)
Kp = 0.6Ku = 0.444
Ki = 1.2Ku/Tu = 10.2 (limit is 2 so that’s what I used)
Kd = 3KuTu/40 = 0.00483

It did seem odd that I produced an I gain which is 5x the ardupilot max, but I just gave it a shot with 2 and it worked beautifully. I’ll try dropping I gain down to match P and see what that does.

(letpi) #1837

Thanks for the photo and all details,
With a dual motor tailsitter non vectored, there are several important aspects:
1- always keep airflow on control surfaces: increase q_m_spin_min from 0.15 to 0.35 and probably more (be sure your aircraft will not climb forever) and increase q_m_thst_hover from 0.5 to 0.65 (maybe 0.7, check q_tune_throut or servo1/2 output). I can see on your log that the transition happen around -60° as it should be -45° according to q_tailsit_angle. I think this is because your aircraft is not able to reach the desired angle because of low thrust. I have no idea why the desired pitch angle is oscillating ??? that’s strange.
2- get a throttle boost when your aircraft makes uncommended altitude loss in hover: increase as much as possible q_p_accz_p and q_p_velz_p and may be q_p_accz_d, I have 0.5, 8 and 0.01 for these parameters.
3-CG position : you know it already, also take care of the CG position with respect to the thrust line.