Servers by jDrones

Dual-motor tailsitters


(Pavel) #1564

How to achieve such fluent transitions as in this WINGTRA video, or in video from the previous message?


(Mark Whitehorn) #1565

@losawing Here are binaries from the latest version of quad tailsitter code (thanks @iampete) rebased to current master: https://drive.google.com/open?id=1JGRpsKVrc_44TwtxHSFXqf1KZUhg9yoy

For a quad tailsitter in this branch, set Q_FRAME_CLASS to 1 and
Q_TAILSIT_MOTMX to 3 or 15, depending on whether you want wing motors or all motors active in forward flight.
Also set Q_FRAME_TYPE to 0 (quad “+” configuration)

There were some changes to master which affect the spool-up behavior of quadplanes, so beware of behavior changes in when motors spin up. One obvious difference is that the motors won’t spin until you enter a VTOL mode. Be careful if you try this, it has only been tested in SITL. I’ll be trying it on my Dart soon.

The branch this is based on is https://github.com/ArduPilot/ardupilot/pull/10336 and there is some conversation there about how best to implement the PID gain scheduling for quadplanes in general.

Also note that hover thrust learning is not in this branch; it has been submitted as a separate PR: https://github.com/ArduPilot/ardupilot/pull/10323


(Mark Whitehorn) #1566

The tri-motor configuration looks like a good idea. All the benefits of a quad or tilt-vectored config for pitch authority plus the potential for “normal” runway landings. But I think the E-flite Convergence configuration is better except for the extra complexity of the motor tilt mechanisms.


(Mark Whitehorn) #1567

This is a plot of transitions from a log provided by @losawing

The pitch behavior looks pretty smooth to me; the 90 degree discontinuities are just an artifact due to switching reference frames.


(letpi) #1568

I wrote all I know in post 1525.
About your wing maybe a stupid remark but it seems to me that motors are very big for a small wing. I am wondering whether it is the motors that tilt or the wing. :thinking: total weight of motors in the range of 10 % of the wing weight (with battery) is good
Also I understand now that you fly only auto modes and this is not the easiest way to tune the wing. Did you perform autotune fixed wing ? Also I suggest you make a Qautotune, it gave me pretty good results.
A last remark concerning auto mode. I did a mission including takeoff and transition only one time and only recently. I found the forward transition was OK but the back transition was not smooth. Also, the hover in q_loiter mode is much less stable than with q_hover or q_stabilize.
I read that arduplane 3.9.5 improve quadplane auto take off
htthttps://discuss.ardupilot.org/t/plane-3-9-5-release/37264ps://discuss.ardupilot.org/t/plane-3-9-5-release/37264


(Mark Whitehorn) #1569

2 things you can try for SITL:
set INS_GYR_CAL = 1
set ARMING_CHECK = 0

Also make sure EKF_TYPE = 10


(letpi) #1570

Tomorrow I will have a small window to make tests because from Sunday we will have a very windy week, it will be time for windsurfing. I will try to make a video.
I tried to read your discussion with @iampete about gain scaling and that’s not easy to follow. But I have only a remark: do you consider the desired lean angle or the real lean angle ? In other word what happen in case of large pitch error ?


(Mark Whitehorn) #1571

good point; the gains are reduced even if there is a large control error. Perhaps I should change it to use desired attitude instead.

I used to take my windsurf board with me to the flying field :slight_smile:


(letpi) #1572

a boat comparison I have in mind is a proa sail boat. As long as the wind is in the right direction it is stable but if you fail a tack it capsize !!


(letpi) #1573

was it an hover board ?


(Mark Whitehorn) #1574

:slight_smile: that flying field was near a reservoir: https://www.google.com/maps/@39.5320788,-105.0636139,16.21z

So if the wind was blowing hard enough: windsurfing instead of flying models.

The Proa is interesting; very asymmetrical design.


(letpi) #1575

just a short feed back.
I took off with q_hover mode, everything worked as expected except the wing wanted to climb forever even with the throttle stick at his lowest position. Hopefully the forward transition worked and I was able to land as a fixed wing. Before landed I tried several back transition that was smooth but again the wing wanted to climb forever. As I was a little stressed I did not thought about switching to q_stabilize.
Also, once armed and throttle raised in a copter mode if I switch to fbwa or manual mode, motors never stop spinning. It seems to be related to q_m_spin_min parameter.
more report and a log soon. the glue is heating.


(Mark Whitehorn) #1576

Sorry about the problem with q_hover mode. I did some bench testing with my Dart and observed the problem with motors not stopping in FBWA. Qstabilize mode seemed to work properly though, motors spooled up to spin_armed on arming, and responded to throttle as expected. I had spin_arm at 0.1 and spin_min at 0.15.

Since this version is using the copter motor logic, all of the Q_M_SPIN parameters should be in effect. There is also a new param called Q_M_SAFE_DISARM which I haven’t tested yet.

I’ll be generating new binaries soon with a fix for the FBW motor behavior, and I’ll also do some (tethered) qhover testing with the Dart to make sure that’s working properly.


(Mark Whitehorn) #1577

I just updated the binaries at https://drive.google.com/open?id=1JGRpsKVrc_44TwtxHSFXqf1KZUhg9yoy
with the fix for FBW modes.
And I bench tested on my Pixracer/Dart airframe, qhover throttle looks OK with spin_min at 0.15 and spin_arm at 0.1


(letpi) #1578

I forgot to set q_frame_type to 0. I flew with this parameter =1. It explains stability problem I had and a lot more…

I have understood the climbing forever problem. It was due to motor oscillation together with spin_min=0.2. If you look at the first log you will understand. Oscillation were large and limited in their low value by spin_min so average value of oscillations were above hover. We can assume that these oscillations were caused by the wrong frame parameter.

For the second flight I lowered spin_min to 0.1 instead of 0.2 and also lowered q_a_rat_ptch_p and the climb problem was solved. Just to mention, the wing went crazy while flying fbwa (inverted flight and rolls). If you look at the second log you will see there is a large attitude estimation error at 1120s. When the problem occurred the wing was pitching up by lets say +70 to 80° and the log shows attpitch=-60°. I have had to switch to manual to recover.

But of course, as the frame type was wrong also in this flight this is not very useful to spend much time on these log. I have to make again the tests.


(Mark Whitehorn) #1579

I’m glad the qhover problem was easy to fix.
Unfortunately SITL doesn’t validate the EKF, but these changes to the code shouldn’t be affecting it, and I have logs showing it stays locked through spins and snap rolls.
Things should work much better with the “plus” frame type too.


(letpi) #1580

I made a short hover test in my garden this morning with the right frame parameter. Attitude and altitude stability is now very strong, nothing to compare with yesterday. No more oscillations. I am pretty sure it will be also much better as a fixed wing.
Outside the wing blow with gusts up to 50 nds so impossible to test more and also too much for my windsurfing skill…


(Mark Whitehorn) #1581

That’s great to hear. Here’s hoping that transitions work too :slight_smile:
Is there a convenient way to set the pitch trim in FBWA? My Dart wants to pitch down about 15 degrees with the stick centered.


(letpi) #1582

Usually I make level accelerometer calibration at the normal flight attitude, so let’s say with the wing pitching up by around 2°. But I think this is not the problem. Maybe your tx is asking for a negative pitch rate, try to make again radio calibration and check your trim and neutral pwm value. This link gives a better explanation
http://ardupilot.org/plane/docs/starting-up-and-calibrating-arduplane.html


(Mark Whitehorn) #1583

Thanks, just doing the “level horizon” calibration using QGC seems to have fixed it. I had tried changing AHRS_TRIM_Y, but it had no effect.