VTOL -- freeman2100 vertical take-off and landing fixed wing +pixhawk

I looked at your log and it confirmed your findings. At some point on the way to WP20, the speed reduced to below the Q_ASSIST_SPEED setting of 14. Up until then, everything looked fine. It appears that the Q_ASSIST_SPEED feature created a bad “save” on the low speed flight. I am not convinced of the actual cause of this issue but I have always wondered what would happen if a Q_ASSIST_SPEED was triggered on a tilt-rotor quadplane. I have been told that it should work but I have never tested it on a tilt-rotor, only on a traditional quadplane VTOL. I’ll continue to investigate. I was using the custom MFE firmware.

Something very odd happened when the Q_ASSIST_SPEED feature enabled while in AUTO mode. The plane rolled left and went nose down. It then continued to spin like it was free-falling to the ground.

I think the crash had several causes. Main cause was that it developed heavy phugoid oscillations (Phugoid - Wikipedia) from which Arduplane could not recover. The reason for these increasing phugoid amplitude was that the throttle/Speed control run far outside of the optimum control range. In my opinion, the reason for the latter is simply a incorrectly parameterized value for TRIM_THROTTLE (45%) in combination with the target velocity (TRIM_ARSPD_CM) of 1800 cm/s.

One after the other:
During the last 3 minutes before the sudden spin, the average airspeed (red line) is 17.89 m/s . This average speed meets very well the target speed TRIM_ARSPD_CM 1800 cm/s and as an average well. The average throttle position (CTUN.ThrOut) required for this speed is 28.53%. This is significantly less than the 45% parameterized with TRIM_THROTTLE. Therefore, the speed regulation is far from the optimum. The throttle position oscillates with the phugoid frequency of about 1/second with gradually higher amplitude. The same applies to the airspeed, which varies between 21.38 and 14.28 m/s in nearly levelflight!

If you now look at Pitch (yellow lInie in the following graphic, ATT.Pitch), the increasing Phugoid Ampitude becomes clear. The nose of the aircraft varies between -11 and +17.5° !!! Tendency increasing!

Now the seconds before the spin and the spin:
While the aircraft was in the “level” phase of phugoid motion, the throttle position was longer at zero (17:36:13). So the airspeed continued to decrease and now triggered Q_ASSIST at 13.1 m/s. At the same time, the TEC system regulated nose down and began to apply throttle to the front motors again. At the moment when the tilt servos start to tilt the front motors (RCOUT.C9, blue line in the following figure) the rear horizontal motors get throttle. The tilting of the front motors towards the horizontal position is unfortunately slow (Q_TILT_RATE_UP 45 = 45°/s). So it would have taken 2 seconds until the front propellers would have swung into the horizontal position. (Note from a lot of tiltrotor experience: with the tiltmotor VTOLS, I always parameterized Q_TILT_RATE_UP to the maximum possible speed. I don’t understand why people switch this to lower values) .

With nose down, the tiltable still straight forward tilted front engines gave full throttle and the tail engines (in fixed horizontal position) also started (unsymetrically ), which in my opinion threw the airplane even more into the nose down spin.

In my opinion, the airplane would not have come into this borderline situation by the increasingly strong phugoid amplitudes, which is no longer controllable for any autopilot, if the throttle control (TRIM_THROTTLE must be the throttle position with which TRIM_ARSPD_CM can be flown in horizontal flight) had been parameterized appropriately beforehand.

Q_Assist also works on the tilt-Vtol. So far, I have not experienced any nasty surprises from normal flight positions.
Plane 3.9.2beta release - #6 by tridge

I have Q_ASSIST_SPEED set slightly lower than ARSPD_FBW_MIN but still higher than the stall speed. This has nothing to do with the crash, but the forward transition is finished at ARSPD_FBW_MIN without Q_ASSIST being activated afterwards.


1 Like


At last sunday I attempted a transition with an experienced pilot. But the transition didn’t complete. I suspect the pilot didn’t increase throttle. The log is in the link. Couldn’t figure out why. Also the plane did some diving while trying to land it, luckily it was able to stabilize itself.


Can some one tell me what should I do?

Hi everyone, this thread is extremely usefull and i’m learning a lot. Here are some pics of the progress in my building. My goal is to have 2 working cameras on board (canon g9x for rgb, and micasense rededge-m or flir vue 640pro) Now im working on understanding the CHDK trigger and understanding mavlink protocol for insert telemetry data into the flir.
By the way, its kind of confusing the schematic for pixhawk about where will be every connection in the main out and aux for all de esc and servos.
I have to build the pitot tube because I live in Argentina and importing this cost me some shitty crazy amount for shipping.

Processing: 9651C32B-0F81-43AA-82D7-6709FA50D285.jpeg…
Processing: 9E7409CA-64B7-4D8F-ABB6-E73AAFEA9639.jpeg…
Processing: C27BFAB5-599F-4146-A952-1FCAA7F42ABC.jpeg…
Processing: 844EC1CF-EA5B-4FE4-8FD7-8E863A2D223C.jpeg…

Thanks to Tim French I now have a Freeman2100. I tuned it yesterday for 4.1.x firmware.

I’ve put the key 4.1.x parameters here:


Thanks Tridge. So do I install first the latest 4.1 firmware to my pixhawk and then load your 4.1 params?

yes. Note that I only put the params that are different from what MFE had. You still need to setup the servo functions, frame class etc. This just gives you the tuning I used.

If I had already installed the original MFE params and flown the Freeman then doing what I said in the previous post would be ok? Would that be the same thing for the Striver - install first the original MFE params and then load your updated params?

yes, sorry for not being clear, updating fw then loadng my params will work

1 Like

I noticed that your Q_TILT_RATE_UP is 30 while the original MFE Q_TILT_RATE_UP is 60. Will this not slow down the front tilt motors transistion from forward flight to hover in Q_ASSIST situations?

yes, it will. Higher values lead to some oscillation in back transition however.
I’m working on a change to allow that to be higher without causing instability in landing.

Wealth of infomation, great photos as well!

hello, i wonder if some one can helpme a little with my freeman2100, im stuck in the parameters. i cant arm the motors and calibrate esc. i have a warning that i need AC3.3+ version. woud you share your firmware and param file? because i cant make it work. thank you

Hi Tridge,
I would like to test official firmware instead of MFE version and I wanted to load your set of parameters, but one got my attention… INS_HNTCH_MODE … I had it set to 0 and you have it set to 1 which is based on description recommended for multicopters… So my question is:
Is really OK? If I set it to 1 might I use HNTCH parameters which are in your set of params or do I have to go throught recommended procedure?
I would use option 4 but it is just for boards with more them 2MB of memory but Pixhawk 4 which I use has exactly 2MB so I am not sure if it would work…

Btw… two parameters are not matching mine … Q_BACKTRAN_MS and Q_TILT_ENABLE Do you know why?

Thanks Jakub

yes, it is fine. You do need the other HNTCH parameters as well.

none of the boards have “over” 2MB, so option 4 does work fine with Pixhawk4.

that is from the 4.2.x test version I was running. It should fly fine with 4.1.6, although there are some improvements in 4.2.x.
Cheers, Tridge

Hi everyone, finally i made the maiden flight of my freeman2100 in quad mode, i tried Q Stabilize, Qhover and QLoiter.
everyting went ok because it did not crash, but the control looks “lazy” and drifting. also there is a vibration in motors. and the yaw drift a lot. im trying to understand the log, but if someone can helpme reading why i have this oscillation and is so slow in respondig to pitch, roll and yaw, maybe something with PID’s. in my setup i use a tattu 6s22000mah (yeah, its a heavy battery)
here are a video and the log file.
video: https://drive.google.com/file/d/1R2s2gCwyz69-jbRE3DkpdleyKdiR6oV7/view?usp=sharing
log: https://drive.google.com/file/d/196kVDU4gRar5qDJbM-E-Ov-ywazPdINP/view?usp=sharing

1 Like

@GregCovey or @tridge can helpme wit this issue that i post previously?

I had a look, and there are a few key issues.
First off, the harmonic notch is not properly setup. As you didn’t have INS_LOG_BAT_MASK set I can’t do it precisely for you, but I suggest the following parameter changes:

INS_HNTCH_ATT         80.0000
INS_HNTCH_BW          56.0000
INS_HNTCH_FREQ        111.0000
INS_HNTCH_REF         0.3760
Q_A_RAT_PIT_I          0.2000
Q_A_RAT_RLL_I          0.1500
Q_A_RAT_YAW_P          0.0700

that sets the harmonic notch to what I use, but also enables the logging needed so the next flight log will give enough information to get the filtering right.
I’ve also fixed your AHRS_EKF_TYPE, which was set to 2, but EKF2 was enabled, which means you were flying on DCM, which is likely why it felt soft.
Other things:

  • you need to redo the compass calibration outdoors with GPS lock. The compass calibration is very bad, and had no scale factor set. Make sure the compass is well aware from any wires carrying significant current
  • for the next flight, do a full 360 degree yaw while flying in QHOVER. That will give me data to check your compass calibration

Hi tridge today i tried to set HNTCH filter parameters…
I just enabled INS_LOG_BAT_MASK =1 and LOG_ FILE_BUFSIZE = 64 … Flown VTOL in QHover mode at center throttle stick about a minute and land disarmed.

Download loaded the log and plot the log using FFT but there is no IMU1 acc and Gyro information.

Default LOG_BUFSIZE = 80 tried that also but same result…is that I’m missing anything to get peak frequency?.