I’ll spend some time in RealFlight to see if I can reproduce these stability problems. It would be nice to understand whether this is a limitation in the physics accuracy or a difference in our model.
Yes I understand for your development it’s important to know if you can trust SITL. I was aware, that there is a difference between Simulation and the Reality. But was also surprised how great this is.
Perfect behavior in SITL and perfect chaos in Reality.
I’ve checked the physics again but can’t finde where to set the weight. (950 gr without Ballast, Test 8 +125 gr, Test 9 + 172 gr)
The CG in RF8 is a ~170 mm, in Reality 140 mm as used with vectored Tailsitter.
The axis of the upper motor is 10 mm higher to get the the center of upper/lower mot at the vertical CG (Plane mode)
The elevons correspond with RF8 they are deeper (55 mmm) than orignal (40 mm)
Thats all I found. I hope you catch the phantom.
May be it’s the CG for Hover Mode. But I’m afraid this will not work in Plane Mode.
After a long time fighting with this Copter Tailsitter I will stop this project and go back to my Dual vectored Tailsitter to regain trust on VTOL Systems.
As retired we have a lot of time, but not for a long time.
Thanks for assisting my project.
Agreed, a lot of time, but probably not for long enough
Best to focus effort where it’s most likely to succeed.
Maybe I’ll try putting wings on this: Design and build of a coaxial drone
And have you seen, forward hover is produced by tilting the mots. Not by tilting the whole wing as a copter.
Also perfect hovering as 2 Mot Tailsitter.
Thanks, I hadn’t seen that video yet, and I didn’t know the X450 had a tailsitter mode. Tridge tried that with his Convergence, but ran into trouble with the tilt servo linkages.
A tilt-tri with that tailsitter mode and a good thrust-to-weight ratio could climb much more quickly and efficiently than without it, although he doesn’t demonstrate it in this video.
Ï 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?
@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.
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.
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.
