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

Eventually, the issue was not data corruption but incorrect handling of Coax and Single copter. However, if your parameter data got corrupted, you can create a full reset as described above. (Please note that you will also lose all cached map data as well)

1 Like


Made some motor mounts and using the motors from the believer im going to have a 12+2 freeman!

Ashes to ashes, Foam to dust …

It did a slow roll and hit inverted at speed. SD Card is toast (literally :slight_smile: )

1 Like

Mike,

Sorry for your loss. That’s an expensive fire!

No SD card sucks too. What mode was it in when it did a slow roll? Auto?

Wow!
Sorry you lost your aircraft. I hope you figure out what went wrong. Thanks for sharing the terrifying photo.

It was in auto. Just have the log sent to MP from from the rfd900,
All that’s left is some carbon ash.

Hi everyone ,
I have done reset FC px4 cube v5
I need param & firmware with no problems , for freeman 2300 vtol
i will be so thankful to you …
Ala- admay

Hi Aladdin,

MFE keeps all their files on-line here at GitHub.
Freeman Firmware Builds
Frame Parameter Files

Cheers!

Hi GregCovey
Thank you so much ,
have you faced any problem with that param?

Why did my VTOL drop? perfect takeoff, flight within standards, suddenly, at the end of the flight, it starts transition mode (away from the HOME point), because it has reduced too much Q_ASSISTENT speed was 14m/s, and turns on the rear engines, then it goes into a spin and falls !

LOGS: LOGS - Google Drive

FIRMWARE 4.0.9 official, I have some Vtol freeman and other Nimbus, all ways using same parameters !

I see probability in BEC of servo trail failled. I like to confirm that !

Hi @Mike_E, It’s very hard to see that ship on fire! I know exactly what this is like! I’ve mounted some VTOL since 2018, and it’s not common to have an accident, my first one was to reverse the direction of the compass, after takeoff, first transition, it goes in inverted flight!!!

Last Friday, another accident, at 200m altitude, Sony miniaturized the A6000 on board, unfortunately. The plane made another flight before, first I lost a BEC and made an emergency landing, I load the BEC and go to a new flight to test, I feel the problem was in the bec wire!

I hate it when they crash from mechanical problems.
Gonna wait until I get the Striver working before getting another Freeman …

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.

Rolf

1 Like

Hi,

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.

https://drive.google.com/drive/u/0/folders/1hB-WzZc1loFrB_TWijLkV-vhGoaFLwBB

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:
http://uav.tridgell.net/MakeFlyEasy/

3 Likes

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