Ï would be interrested in this forward Hover Mode. We have vectored Yaw and it should work the same way to get “vectored Forward”. The Roll with Throttle is good. Forward and “limited” Backwards would be great on the same way as Yaw and not with a additional Switch/Knob as already thought. Backwards would be also helpful to stop after Backtransition.
Hi all - really cool work in this thread. I am new to the scene and am exploring designs for a Copter Tailsitter and the most efficient route to flight.
Since I am new, please feel free to slap me around a little, especially when I ask silly questions. I’m drinking from the fire hose and need to find some focus.
First off my task list is to understand in broad strokes how to add a hex frame configuration to Copter Tailsitter. My goal is to explore control with no control surfaces; only torque and thrust control. To be clear, I will not be using rotating motor pods.
Can one of the forum elders help or point me in the right direction?
Q_FRAME_TYPE and Q_FRAME_CLASS to hex and x/+ or whatever. Q_TAILSIT_MOTMX some none zero value.
Currently the only way to do control surface free flight is to flash master/dev and setup the Q_ASSIST (82) RCx_OPTION and switch to force enable.
2 Likes
@robinasu Welcome to the ArduPilot forums!
You can use QACRO mode to explore the complete flight envelope of your copter tailsitter. Since it’s an acro mode, you can fly in any orientation with the copter controller using the motors for stabilization. Use QHOVER or QSTABILIZE as bail out modes. Be sure you have the CG right before you try fast forward flight.
When hovering, yaw control of my biwing was done with control surfaces and motors differential torque. I think about 90% of yaw authority came from control surfaces and the sum was good but not great.
A well known trick to improve yaw authority of a multicopter is to tilt permanently motors. This is something I have successfully tested on my biwing (about 10° inward). A good example is given by the amazon delivery drone (the hexa tailsitter one). Without control surfaces you will need more than 10° and small wing to be less sensitive to wind.
1 Like
Guys, thank you for the tips!
-
From looking at the code it looks like QASSIST is used to supplement a non-tailsitter quad plane’s control surfaces and has some parameters to satisfy (angle deviation, etc) before QASSIST kicks in. My first thoughts are these activation parameters might need to be tightened up. Do you have any comments on this?
-
I am assuming the QACRO mode is used along with the Q_FRAME_TYPE, Q_FRAME_CLASS, Q_TAILSIT_MOTMX, and Q_ASSIST (82) RCx_OPTION. Is it that simple to get going using QASSIST?
-
The QASSIST and QACRO mode seem like a fast way to go to get started. From an architecture point of view, what would be the optimal solution? For example, with a hex multicopter tail-sitter not using rotating motor pods and Q_TAILSIT_MOTMX=0, why not send roll, pitch, yaw and thrust to some multi-copter mixing block? I am assuming this block could be APMotorsMulticopter, but I am not sure of the key differentiators between AP_MotorsMatrix, AP_MotorsMulticopter, AP_MotorsMatrixTS, and AP_MotorsTailsitter. My thinking is multicopter frame yaw maps to tail-sitter frame roll, multicopter pitch maps to tail-sitter pitch +90deg (depending on how you look at it), same for multicopter roll to tail sitter roll; may have the orientations off here.
To configure as a hex copter tailsitter, you need
Q_FRAME_TYPE = 2
Q_FRAME_TYPE = 0 for plus or 1 for X
Q_TAILSIT_MOTMX = 0x2F = 47 (must be nonzero for tailsitter behavior)
That will result in instantiation of AP_MotorsMatrixTS using the standard AP_MotorsMatrix control logic for a hexacopter, and all of the VTOL modes will use the copter controller.
Multicopter yaw does map to tailsitter body-frame roll, and pitch for tailsitters shifts by 90 degrees when switching between VTOL and FW modes.
Also look at Q_TAILSIT_INPUT: https://ardupilot.org/plane/docs/parameters.html#q-tailsit-input-tailsitter-input-type-bitmask
A value of 3 will result in the tailsitter responding to roll and pitch the same as an airplane would in both VTOL and FW modes.
1 Like
Hi Mark, thanks for your comment. I spent some days getting familiar with QGS and the latest ArduPilot master download through QGC. I first set:
Q_FRAME_CLASS = 2 (Hex)
Q_FRAME_TYPE = 0 (plus)
Q_TAILSIT_MOTMX = 0x2F = 47 or 10111100
First, the bit mask 10111100 appears to be 5 motors. Do I not understand something? I tried 11111100 as well (motor 1 through 6 checked) and I could not get more than 5 motors spinning not matter how many motors I selected or which channels I connected the 6 ESCs. It also seems like the QGC check boxes 1, 2, 3 etc correspond to 8, 7, 6, etc; I couldn’t find any consistency so I must have a number of issues going on. It was late so could have been tired. I used arm/manual mode and throttle 100% with power cycling the battery to activate/calibrate the ESCs.
Did I miss a parameter setting or misunderstand you all? I would like to configure a hex tail-sitting multi-copter with only thrust attitude control - no control surfaces.
Sorry for the typo: the bit mask should have been 0x3F = 0011 1111 = 63 = 2^6-1
That represents all 6 motors with motor 1 being bit position 0 through motor 6 at bit position 5.
This mask specifies which motors are active in FW modes (so some of them shut down in FW flight). But they should all run in multicopter (VTOL) modes. You can use the MIssion Planner motor test function to verify that your ESCs and motors are working properly: https://ardupilot.org/copter/docs/connect-escs-and-motors.html?highlight=motor%20test#checking-the-motor-numbering-with-the-mission-planner-motor-test
Not a problem - I had a hunch you meant 0x3F but things aren’t working so I wanted to be sure. Initially, I tried to use the standard Mission Planner 2 download, but it wasn’t playing nice and would not load using OS X 10.15.5. I downloaded 2.0.27-rc1 and now MP2 loads, but the USB connection to my Pixhawk1 doesn’t work correctly. I removed the old FTDI driver and installed the Apple signed driver from the FTDI website- still nada. I also went back to the QGC and started over with fresh firmware.
Starting with a fresh flash of Plane “master,” only the Q_ASSIST option is available. Should Q_ASSIST be “enable” or “vtol_auto?” I have been using VTOL_AUTO. After I reboot the PIXHAWK, I can then see all the other “Q” options to configure the tail sitter. I set Q_FRAME_CLASS = 2 (Hex), Q_FRAME_TYPE = 0 (plus), and Q_TAILSIT_MOTMX = 0x3F = 63, ARMING_CHECK to nada, then reboot the pixhawk. My SimonK ESC’s are connected the to the Pixhawk main out’s #1-6. I then proceed to calibrate the ESCs and that’s when things get weird. I also removed the power pins from the ESC’s to disable the ESC BEC.
If all that sounds ok, I will dig into getting AP2 working and will try to mess with the ESC PWM calibration parameters. I guess I can dust off my Win10 image and parallels. What do you use to develop?
I don’t know what those Q_ASSIST options are; I don’t see them in the source code or the wiki.
I use mavproxy on the bench and it also has the motortest command implemented.
I also use QGC on an Android tablet at the field.
My last Apple computer was a Lisa 2 
My first Mac was a IIgs.
Will the 1M “small” master version have all the Q features we’ve talked about? Using QGC I flashed the 1M master firmware. I then power cycle the pixhawk and on pixhawk boot there is only the Q_ENABLE parameter until I set Q_ENABLE to “VTOL Auto”. Maybe I should download the correct firmware and load it from my local disk.
After you set Q_ENABLE=1 or 2 you must refetch parameters to see the rest of the Q_ group.
Here’s the documentation on Q_ENABLE: https://ardupilot.org/plane/docs/parameters.html#q-enable-enable-quadplane
The only difference between enable and vtol_auto is the initial state on entry to AUTO mode.
The relevant wiki pages start here: https://ardupilot.org/plane/docs/quadplane-overview.html?highlight=q_enable
As to what features are present on 1MB boards, I think that is now board-specific: https://ardupilot.org/plane/docs/common-limited-firmware.html#common-limited-firmware
Which FC are you using?
Thank you for the resources, Mark. My FC doesn’t have any logos or markings. It looks like the picture, below, but with no Holybro logo or any other markings. Based on the age, I think it might be a Hobbyking HKPilot32. I got it from a friend. Mission Planner says its type 9 brdrev, 0 bored, 5 fwmax, 1032192 chip, 10036419 chipdes, STM32F42x, Y, so I am guessing FMUv2?
I like Mission Planner and understand some of your comments from previous posts about refreshing parameters after using it. I think QGC on OS X works a little differently right now, so I will use MP1 for now. I was having a devil of a time with windows USB drivers. I then updated my FC’s boot loader and things were working better. After I deleted all the usb drivers and started over it driver-wise it was communicating. I also installed the latest stable hex copter firmware and it seems to work great. The ESC calibration was easy and all motors were working during manual “motor test.” Then I loaded the dev (master) firmware and played around with the Mission Planner graphical configuration options and noticed the servo mapping had servo 1, 2, 3, 4 mapped to the rud, throt, elev, air. I mapped all the servo outputs to motor #'s 1, 2, 3, 4, 5, 6, 7, 8 and that seemed to help. The ESC’s now calibrate using the manual method, and with the props off and in QAERO, I can see the servo outputs moving in the Mission Planner graphical servo setup. They move as if they are mixing. Does this sound correct?
Regarding take-off, can anyone recommend a good method for a “more safe” take-off? 
Should I start off in QHOVER and get some speed, then switch to QSTABILIZE or QAERO, then back to QHOVER in an emergency?
What is the jist of QSTABILIZE? Will it just keep the craft level within some QSTABILIZE parameters?
If your motors work when running Copter, they should also work with quadplane, since there should be no difference except for default channel assignments.
Check the wiki for answers to your other questions; they should all be in there (and let us know if not):
https://ardupilot.org/plane/docs/quadplane-support.html#quadplane-support
Thank you - I have been looking through the wiki, but I don’t have practical experience. My current plan is to explore the hovering Q modes and explore any related parameters. When it comes time to attempt a transition, my initial thoughts are to transition to FBWB. How does this sound?
Are there any major tuning or flight mode parameters you all would recommend looking at before a first flight? I should probably look to make sure any altitude settings are good compared to my surroundings. Do any other important parameters come to mind?
Also, let me state this: I’ve ultimately responsible for my actions. I’m really looking for broad strokes input.
Here is the mapping I configured:
Does this look correct? Hopefully I just need to connect my ESC’s in the right order and start some hover tests.
Every time I would reload the firmware servo #'s 1,2,3,4 would be set to the rud, throt, elev, air functions - makes sense since the firmware is primarily a plane firmware.
The default channel for motor 1 in a quadplane is 5, not 1:
https://ardupilot.org/plane/docs/quadplane-frame-setup.html#motor-ordering
Would the servo mapping look like any of these cases for a hex copter tailsitter using no control surfaces (only thrust steering):
Case1:
ESC1, MainOut1 (pos 1) --> (function) Mot5
ESC2, MainOut2 (pos 2) --> (function) Mot6
ESC3, MainOut3 (pos 3) --> (function) Mot7
ESC4, MainOut4 --> Mot8
ESC5, MainOut5 --> Mot9
ESC6, MainOut6 --> Mot10
NC, MainOut7 --> disabled
NC, MainOut8 --> disabled
Case2:
MainOut1 --> Aileron
MainOut2 --> Elevator
MainOut3 --> Throttle
MainOut4 --> Rudder
ESC1, MainOut5 --> Mot5
ESC2, MainOut6 --> Mot6
ESC3, MainOut7 --> Mot7
ESC4, MainOut8 --> Mot8
ESC5, AuxOut1 --> Mot9
ESC6, AuxOut2 --> Mot10
I read the wiki but I’m confused about where to hook up the ESC’s for a hex application on the pixhawk and how to map them with the parameters.
You should be fine with motors 1-6 on mainout 1-6. Just be sure you have SERVOn_FUNCTION for each channel set correctly, since the defaults won’t be right.
The reason the plane defaults have aileron, elevator, throttle and rudder on channels 1-4 is that channels 1-8 on fmuv2/3 are provided by the safety coprocessor and can be used as a failsafe (manual mode).
But since you don’t have any control surfaces, that’s not useful.
1 Like
I understand the channel mapping now- Thank you. The “Motor Test” commands are still rejected for some reason, but ESCs are calibrated and work well.
Can the tail sitter code use ultrasonics for landing? The option using Mission Planner 1 is greyed our.
I have the airspeed sensor setup and it seems to work well.
All systems are pretty much a go for static testing and tuning.