Dual-motor tailsitters

@kd0aij Hi! Thank you for welcoming me!
I looked at the controller, things are more clear now, thanks!
I took your advice and went up to the field this morning without changing my last tune (not the one in my post above, I did a few iterations in AUTO before you guys replied) in QSTABILIZE mode, and it works! :smiley:
Here are some graphs from that flight!

I see in the log that tracking is not perfect, but it was very acceptable to fly. :smiley:
Current changed settings:

The binary log is here: https://drive.google.com/open?id=17oLH076e0F0H12sN7NXs30-ikscxwQGM
Time interval I’ve plotted: 670-802

@losawing I did adjust the throw to ±45 degrees before I did the flight above, and it is clear that it was def needed! Thanks! (I may have had only ~25 degrees in one direction before…)

@iampete Thanks for clarifying!

A big thanks to all of you! I am so far loving this forum!

A few further questions:

  • The tune above has all rate P settings set to their maximum allowed value (without force writing params). Is that maybe not needed? Or does the non optimal tracking in pitch and yaw rates indicate I need more you think?

  • The end goal is to get this fully AUTO, what are my next steps? I feel that the reason AUTO didn’t work with this tune might be too fast rate demands? Do I need to enable Q_A_RATE_[P,R,Y]_MAX? Whats a good starting value? I tried that on slow, and it crashed pretty quickly.

  • Should I start by trying to transition into flight mode by changing to a stabilized flying mode, or try a transition in AUTO first?* update: I tried flying in QSTABILIZED and switched to FBWA as per the documentation, and the motor power was so reduced the plane essentially fell out of the sky. After repairs I upped the Q_ANGLE_MAX to its max 80 degrees and when flying in QSTABILIZE at 80 degrees it handles acceptably. I tried switching at full power close to 80 degrees, and the thing crashed pretty quickly upon flipping the switch. It looks like roll control is to blame. All ideas on what the problem was are welcome! Here is the log:
    https://drive.google.com/open?id=14K1nYG4D92NqOrLIaTq2jL2dtow4sU8-
    Update It looks like maybe it was my RC inputs that crashed it. I was very slow in releasing the stick upon transition. I did, however, think that FBWA would not allow roll angles to become large enough to risk crashing. Ideas?

  • I do most of my plotting in Matlab, the MODE log has values that seem to correspond to 10-Armed, 11-Disarmed, etc But I haven’t been able to find a full list anywhere. I figured out that 17-QSTABILIZE, but I still have a bunch that I don’t know what they are. Where should I look?
    * Q_ANGLE_MAX I assume can be turned up if I want higher speeds forward in hover mode? Any experiences tuning this? See point above.

* Remember that this is a FlyBoard, there is no way I can fly this manually, I’ve tried and it is just too difficult for me. I have successfully flown a single engined FlyBoard in a custom FBW controller I made, probably very similar to FBWA.
Heres a not too recent photo if it:

3 Likes

Don’t care about maximum values, just hover your wing and increase P gains until oscillations. You will have also to tune D gain. D gain around 0.01 is a good point to start. Higher gain may also produce oscillations but a tailsitter usually does not need high D gain as the wing itself produce a lot of drag that dampen the motion.

To begin, just forgot all q_modes that use GPS, you already have more than one hundred of parameters to play with. First step is to get a very stable hover with q_hover mode and q_angle _max up to 50°. If you are not very familiar with PID tuning, q_autotune is a good option. Second step will be to tune transition parameters and fixed wing parameter. Do not try transition if your wing is not able to recover from angle max around 50°. This is where CG is very very important…
Q_m_thst_hover and q_m_spin_min are critical parameters for transition, remember that your wing need airflow to be controlled.
As soon as you wing is in plane mode, yaw is not any more controlled by differential thrust. Stability must be given by the airframe itself.

google search for arduplane full parameter list, FLTMODE parameter

2 Likes

@Trobolit Congratulations on achieving flight in qstabilize mode.
For log analysis, you might also find MAVExplorer to be useful:
https://ardupilot.org/dev/docs/using-mavexplorer-for-log-analysis.html

Also, MAVProxy, APMPlanner2 and MissionPlanner can display live plots of telemetry when connected by either USB or wireless modem. I also use APMPlanner2 to generate KML files (showing vehicle attitude and flight path) from dataflash logs for display in Google Earth. example:

This is where flight modes are defined in the source code:

Thanks for the pointers! @losawing
I will try to increase rate P gains even more and observe the results, then play with D.

I did increase Q_ANGLE_MAX to 80 degs, and hovering there both forward and backward was no problem at all (while in q_stabilize)!
After reading about the attitude controls I suspect AC_PosControl is the next main objective while in q_hover mode?
Along with the parameters shown in the last image here:
https://ardupilot.org/dev/docs/code-overview-copter-poscontrol-and-navigation.html

I’ve already set Q_M_THST_HOVER to at least one correct significant digit. But I suspect having one more would be preferred. I did set it after yesterdays crashes, which would explain the first switch to seem like falling out of the sky. The logs indicate a 50% throttle upon switching, that increased, but too slowly.
Will also set Q_M_SPIN_MIN today.

Looking at my last logs and just by eyeballing the elevons on the ground when in FWBA the controls look rather agressive. Given my oversized elevons is it correct to assume that the plane parameters, such as PTCH2SRV, etc, should be reduced quite a lot from the standard firmware settings?

This seems counter intuitive, I know flying wings with single engine don’t have yaw control and work fine with arduplane, but when given the option why not? Just curious! :slight_smile:

This I need to check out, thanks! :slight_smile:

Thanks again!

@kd0aij @losawing
FLTMODE list does cover most of the modes I see, but I also see 10 as ARMED, is this my mistake or is it possible that the matlab logs contain more/other info as well?

Example plot from APMPlanner2:

Tailsitters do have differential thrust for yaw control in FW flight modes:
https://ardupilot.org/plane/docs/parameters.html#rudd-dt-gain-rudder-differential-thrust-gain
https://ardupilot.org/plane/docs/quadplane-frame-setup.html?highlight=differential#single-dual-motor-tailsitter

Mode 10 is AUTO, in log 3 your RC channel 8 is calling for mode 10 at bootup.

Also, check out hover thrust learning: https://ardupilot.org/plane/docs/parameters.html#q-m-hover-learn-hover-value-learning
It will optionally learn and save the hover thrust value while in qhover mode; you need to establish a stable hover (throttle stick centered, not climbing or descending) for at least 10 seconds.

I haven’t tried to make a “board” fly in FW modes. I guess it should work if you have the CG in right place, but stall characteristics might be quite interesting :slight_smile:

Thank you very much for your contribution. My vector two-axis aircraft (bicopter) has been able to fly normally. Now I want to add ultrasonic height determination and optical flow positioning, but I can’t use ultrasonic and optical flow. There is no flow enable parameter for optical flow in the parameter table.(FLOW_ENABLE)

hdx6.param (21.8 KB)

Thank you very much for your contribution. My vector two-axis aircraft (bicopter) has been able to fly normally. Now I want to add ultrasonic height determination and optical flow positioning, but I can’t use ultrasonic and optical flow. There is no flow enable parameter for optical flow in the parameter table.(FLOW_ENABLE)



image

Here a new version of VTOL controlling. https://youtu.be/2UEVRb5xpLc
The 45° Mode allows to fly forward against wind where the plane is not pressed down due to the airflow on top of the wing because the whole plane has to tilt.
I red about a branch where this was tested for Tilt-Rotors in ArduPlane but not continued.
https://www.flexinnovations.com/product-p/fpm3870.htm

I’ve been experimenting with manual “forward throttle” control for tiltrotors for a while now:

It works pretty well with the Convergence and mini-Convergence
Latest PR is https://github.com/ArduPilot/ardupilot/pull/12857

Ups, I seemed to be late. In the vid it looks perfect in SITL
What about a little bit backwards to brake?
My Skywalker needs 100 m until it hovers on spot.

I hadn’t thought about reverse throttle for tiltrotors, but that should be easy to add.
The interesting part would be integrating it with the existing reverse capability…

Do you mean to reverse in FBW Mode?
During the Transition from Hover to FBW the trust changes from vertical to horizontal while accelerating.
The same would mean for the back Transition in Throttle reverse against the fly direction to tilt down for Hover while decelerating.
But then the tilts are in the opposite direction for the next forward Transition. :frowning:
Difficult to explain :wink:

Yes, I was thinking about backward tilt in FW modes.
Applying some backward tilt during the back transition would be independent of that, so it would be simpler to specify.

Using vectored Yaw for my Skywalker, the Tilts are able to tilt backwards max. 25°.
But may be, then also the Backtransition becomes difficulties to mangage the Yaw. The Forward Transition produce a Yaw of about 30°always to the right. The Tilts don’t move synchronously.
And I did not finish the Transitiontuning because of a PC crash after a Win 7 Update. The Transition takes a long time to accelerate, one time with increasing the Throttle manually only. Really bad compared with the same Wing as Dual Mot Tailsitter.


Log: https://drive.google.com/open?id=1QBKdakZpDLXG4jb6BJJ1DqKeFmNEvD8K

Arduplane : Tailsitter 4.00
EKF3
I have some problem about AUV. Actually the altitude of my AUV is reduced but the altitude from QTUN is increased which is not related to altitude from BAR2. Can be seen from the graph shown. How should I fix this problem?
Log : Uploading: 2020-01-11 14-54-47.bin…

I had a similar situation. This is due to the sealing of the compartment with the flight controller. when speeding up, pressure or vacuum was created in the body of the aircraft

How did you solved it?
Baro’s altitude is sensitive while the aircraft is transiting to FW from pressure changing. So if i change EK3_ALT_SOURCE from baro to GPS, aircraft will transit better. But when vtol landing, it will land in altitude inaccuratcy because GPS antenna is not point to the cloud.
I understand right?

hi guys
iam new to pixhawk and want to try build a non-vectored tailsitter
is there a parameter to be my reference?
and how about servo and esc wiring ?

The wiki is the best place to start

https://ardupilot.org/plane/docs/guide-tailsitter.html

Я просто закрыл отсек с полетным контроллером, до этого он был открыт. Могу отправить тебе параметры конфигурации.