Servers by jDrones

Where would I change vectored thrust mixing in the source code?

Im building a 2 meter flying wing VTOL (tricopter tiltrotor) where all 3 motors tilt as follows;
in MC mode - front 2 motors for yaw & pitch - aft motor for pitch control
in FW mode - front 2 motors for roll & pitch - aft motor for thrust only

I could use some help on what files in the source code that I would need to alter to accomplish this.

here is a link on YouTube showing a guy that has coded this (and has not released working firmware)

he has a QQ group in China but I can not join it (I think I need to use We-Chat). If anyone can please let me know.

Here are the related links:

Dropbox link with all of his builds and docs. It is being updated but is not well organized

His documentation & his “QQGroup” in China that “Kris” said helped develop this flight model

A store that is selling parts for the build. No replies from my emails.

But if anyone knows what files I would need to look at in the source code please let me know

Note - I have posted this subject before. It is being restarted for the purposes of forming a group to look into it further.



This is the bit of the code you want

I would recommend setting up a model in realflight and using SITL to test.

thank you very much pete!

-Do you know if “tiltrotor.cpp” would also cover vectored thrust in MC mode?

-Any idea if realflight 4.5 works with SITL?



yep, same file abit further down although I fairly sure ArduPlane can already do all that stuff in copter mode.

Realflight 8 if you have it or Realflight 9 if you have to get it.

OK thanks again Pete… Im going to start looking into modding that file.
Im not sure I want to invest in another copy of realflight as my VTOL tiltrotor may not be possible to model (but Im not at all sure about this)


totally possible to do VTOL tilitrotors, see this example from @kd0aij

It won’t accurately model power draw and drag ect, but the physics are correct.

1 Like

I can help you with the code changes, if any are necessary. Just ask.

So it will model the thrust vectoring??? wow! thats impressive. thanks Pete…

David - thanks for the offer… Im going to be trying to figure out whats got to be changed on “tiltrotor.cpp” to do the following:

in MC mode - front 2 motors for yaw & pitch - aft motor for pitch control
in FW mode - front 2 motors for roll & pitch + diff thrust for yaw - aft motor for thrust only

Any ideas of code changes to make those features happen would be greatly appreciated.

The first priority is to get the aft motor to vector fore & aft for pitch control and assist position hold capabilities.

thank you very much!


Currently there is no support for a tilting tail rotor, so you would need to add a new ServoChannel type for tiltMotorRear. I’ll check on where to do that. Then you assign a SERVOx_FUNCTION parameter to that new type value.

You be mostly interest in Plane/TiltRotor.cpp, look at the YawVectoredThrust method. There is where you would make changes to control the tail rotor tilt. I would suggest you just ignore the actual tilt angle changes for yaw on the tail rotor. Just let it tilt forward or back for transitions. I’ll dig a little deeper tonight. You should probably read through the code, it is well documented.

I don’t think arduplane uses motor tilt for pitch control in MC. I believe it’s treated like a regular tricopter/quad and motor speed causes a forward or back tilt of the airframe, just like a quad. I would like to see tilting for fore/aft movement (can’t really call it pitch) on at least the two front motors. That would give lots of control authority even if the tail rotor stayed at 90 degrees until a transition to foreward flight. Basically you could treat the tail rotor as a binary tilt motor, either up or down. It might make your life a lot easier :slight_smile: I’m afraid adding the tail tilt may be a good bit of work to get it right. Basic support should be easy, but the transition could get messy.

you can just us the normal tilt output, 41:MotorTilt

Thanks David and Pete,

I agree David that the aft motor tilting for pitch control would be tricky to dial in and making it a binary would be a lot easier.

FYI “Kris”, the guy in China that made these mods work (and wont release the source), made a new function for the tail motor(#45) that did assist in position control (see the youtube link on the OP).

I believe the #41 servo function only serves as yaw control in tricopter frames which would require a left/right tilt.

the fore/aft tilt of the rear motor serves to add a lot of ability of the airframe to stabilize itself in wind and hold position better. The previous build I used in the px4 source was a standard tricopter VTOL (called the “convergence” airframe where only the 2 front tilted for yaw control in MC) wasn’t very good at dealing with the wind.

the video makes it very evident how much control authority aft motor tilt adds in wind.


its for motor tilt if you don’t have separate left and right, like this for example

Yaw only output is Motor 7 on tri-copters

I looked at using 41, but the tricopter code didn’t seem to use it the way I was thinking. Defining a TailRotorVerticalTilt motor may not be necessary. I’ll look into the coding more tonight. I only spent 3 minutes looking at TiltRotor.cpp. I have an Frsky Telemetry problem I have been working on for days. The _port.write() gets called, but no data goes out on the TX pins. Its bizarre.

I have wanted to build a big tri-copter or quad vtol, so I hope I learn a few more thing looking at the code.

Thanks for looking at it David… Ive been seeing a lot of issues with telemetry lately.

If you want to build a tri, i recommend them. I like the way they fly vs. a quad.

If you come up with anything you want me to try out, I have a test bed built so i can try it right away and get back to you with the results.

I looked at the code some more, and there is no control of forward/back movement by tilting the motors at all. I suspect this is because it was never in copter, and the copter code was used for most of the MR flight. The tiltrotor code mostly deals with transition.

I think that needs to be added first, expanding the tilting to the tail rotor also. I flew my convergence yesterday in a 25+ mph wind and while it did ok, I had to keep the nose pointed into the wind or it would lose position. I was in QSTABILIZE and the altitude control felt weird to me. That was my first flight with ardupilot so maybe QHOVER will be better. I’m get can’t intialize barometer messages, so either my barometer or the whole FC is bad. My last Matek F405-Wing burned up, so I’m looking for an alternative.

thats what i was thinking, that there was no way for the code to mix in vectoring for movement (or position) control … I wonder if the transition code could do it … maybe have 2 transition states where stage 1 is MC flight with vectoring and stage 2 is the transition…

The px4 code does have a mixer but I never could add the aft motor tilt

I dont know if you watched the video but “Kris” had ONLY the aft motor tilting when the airframe was pitched (front 2 did only yaw control) and tied to his radio’s pitch control. I dont have any use for the alternative modes where different combinations of the motors run in FW mode)

The plane Im building is a 2 meter flying wing with about 6 lbs AUW so the more control authority the better. When I flew it with px4’s “convergence” frame code it was pretty unstable (I didnt tune it so thats on me). It did seem to be a lot more sluggish than ardupilot’s code.

Ive had a couple of FCs get sketchy on me too… in fact I bought one of the very first pixhawks from 3DR (back in 2014 i think) and it never did work right… too bad I didnt mess with it for 2 years after i bought it, i could have returned it.

thanks for your thoughts


I translated some of the readme’s of “Kris’s” code documentation and I picked out some interesting things. the whole document is attached… its from a January firmware release.

Firmware Name: ArduPlane-20180502 (V3.9.0-DEV)
=============================================================readme.txt (36.4 KB)
This new version of the firmware code changes quite a bit, from the old version to this version may have to adjust the parameters
Can fly, so it is recommended that novices do not use for the time being, let the friends who are familiar with PID first try.

  1. Synchronize the official code

    Fixed a bug where the tangential angle was incorrect when lotto_to_alt (circled up or down) left.

    Modify the default installation orientation for Here GPS’s ICM-20948 compass.
    Correction of the tailstock type transition from FBWA to QSTABILIZE throttle sometimes suddenly pulls down the bug.

  2. Vertical takeoff and landing (VTOL) optimization
    Replace the old multi-axis attitude control with a new position control algorithm.
    Use a new rate attitude controller during the transition (transition) (the transition is smoother / the height control is better)
    The horizontal position controller runs at full speed of 400hz (old 50hz)
    New L1 distance calculation method (turning will be smoother)

    .New / Transaction parameters
    Q_A_INPUT_TC (attitude control input time constant), the smaller the value, the larger the response, the larger the value, the smaller the response
    Example: Q_A_INPUT_TC=0.5 is very soft, 0.2 soft, 0.15, 0.1 fast, 0.05 very fast

    Speed ??gain doubled, Q_P_VELXY_P, Q_P_VELXY_I, Q_P_VELXY_D parameters may have to be adjusted (tune up)

    .Q_P_ANGLE_MAX Position controller angle limit (0-45 degrees), if set to 0, use Q_ANGLE_MAX

    Multi-axis QLOITER adds brake control, parameters: WPNAV_BRK_JERK, BRK_ACCEL and BRK_DELAY
    Tilt angle Q_WP_LOIT_ANGM (0-45), if set to 0, 70% angle of Q_ANGLE_MAX

  • Added conversion back to multi-axis throttle scaling parameter. If it is converted back to multi-axis, it will increase the value. For example, 60 (%)
    TILT_UP_THR=0 is disabled, 1~99 is throttle zoom%

    • Added low height assistance parameters:
      ASSIST_ALT=0.5 seconds below this height triggers the rescue (0=disable, 1~300=1m~300m)
      ASSIST_ALT_MOD=What mode is used to save the machine (0=disable, 17=QSTABILIZE,18=QHOVER,19=QLOITER,20=QLAND)
      Note: At least the flight must have exceeded ASSIST_ALT + 5 meters in fixed-wing mode, if not, it will not trigger.

There is another thread looking at the same thing, at least for the front rotors. Im trying to think of what needs to be added. Obviously elevator mixing. What about throttle compensation as the tilt angle increases? I also think rear tilt should be limited to prevent problems with backwards flight. Do we also disable the control surfaces in MR? I would like more input on that.

Servers by jDrones