It’s about time I started a thread about my project. I imagine some of you will have seen this work on the ardupilot facebook group, my project page, or eve my Linkedin account. I apologise for the repetition!
My project is a VTOL fixed wing hybrid tri-copter (initially) with a MAUW of around 11kg, of which 1kg at least is payload. The aircraft is approximately 2m long with a wingspan of 3m.
Whilst I plan to sell this aircraft as my main business, I’ve tried to keep a community focus sharing what I’m doing and why. This is a 2yr long project along side my day job, with a few years of exploration before that.
I’m going to keep on with the community focus by sharing my experiences with flight testing the airframe.
I’ve read around the set-up of these configurations, including Greg’s excellent thread here. Obviously the high level configuration is similar to the Nimbus VTOL, but I won’t be able to use their parameters because of the difference in size (and, I don’t want to just copy their param lists - no learning in that / it’s just cheating).
My intention is to take a fairly cautious approach to the flight testing. Something along these lines:
Under operator control (Qstab?):
Simple vertical hop up and down
Vertical take off and rotation about vertical axis
Vertical take off and translations in the horizontal plane
Each time checking control authority and stabilisation. From here I’ll move on to more complex tests, which we’ll cover as they come up. This will lead to some repetition but, that’s expected, and allows me to compare results with known data when I change/add something.
At the moment the aircraft has power on, and the next task is reinforcement of the inboard wings. The tilt rotor mechanisms are out being made and are likely to be the limiting factor for when first flight can be achieved.
I am glad to see you post your project here as I do not visit Facebook. Your approach looks good and is very pragmatic. One thing to consider is that before testing transitions to forward flight, you first test the BARO and GPS sensors; QSTABILIZE, QHOVER, and QLOITER. In this manner, your emergency fall-back mode becomes QHOVER or QLOITER (instead of MANUAL) in case you have a failure in forward flight.
So on a normal APM Plane setup, we use MANUAL as our emergency fall-back mode. On VTOLs, we use one of the Q modes. I don’t even have the MANUAL mode as an option on my VTOLs.
Thanks Greg, that’s good advice. There’s a fair amount at risk here in terms of time, effort and to a lesser extent money, so I’m very happy to take all advice.
At the moment, I’m going through and setting up Parameters to suit the configuration. Lots to look at but mostly is sensible when I go back to the quadplane documentation. I’m using servo outputs 1,2 and 4 for the ESCs so I think I will have to change the standard settings if I’ve understood Q_ENABLE correctly. I need to get my head around bitmasks too!
Update: I think I’m ready for first (hovering) flight now. Bench set-up seems to work as intended, and the only way to know if I have the control authority I need is to go out and do it.
I’ve taken Gregs advice and have Qstab/Qhov/Qloit as my flight modes for now. I have gone through the transition with FBWA and there is an interesting behaviour that I hope never happens in flight:
If I go from QHOVER to FBWA the aircraft attempts transition and then fails because its on my bench without props. It signals failed transition to me on QGC and then goes back to QHOVER. Then the aircraft disarms itself rather than staying in the Q mode! Is this something to do with QGC or a parameter I haven’t set correctly?
Back in March, I was ready to go with the Tri-copter config, or so I thought. During the ground runs I found that the rear motor mount was not stiff enough, and the motor and prop would excite one of the mounts natural modes and it would vibrate excessively.
The day after this finding, the UK went in to lockdown, and all model flying fields and sites were closed. The flying fields were re-opened in June, and during that time I mostly up-dated the digital design incorporating everything I had learnt so far. In the process, I decided to change from 3 to 4 motors. This design is fairly well advanced, but still WIP.
The physical design has been updated to reflect the change to a quadplane configuration (add a motor, move motor to extended wing pylon booms, re-wire the aircraft, re-program the aircraft) and has now had its first few flights.
I’m pleased to say that the aircraft will fly on stock PIDS, even though its AUW is 13kg/28.6lbs. The overall airframe appears to be well damped, and there are no apparent vibrations to be seen. There is much room for improvement from autotune - and that is a job I’ll tackle soon, along with a good position hold.
As I said back in March, I am managing risk with a staged approach with flight tests. The first stage is the simplest airframe configuration in hover. The next stage will be a more complete airframe in hover.
I would like to see the option of tilting the forward motors to counteract headwind at some point.
Congratulations! You will be more happy with a 4 motor design due to the size and weight of your vehicle.
If you are having success, be careful if you plan to use QAutotune for further improvement. As far as I know, Tilt-Rotor Quadplanes do not have the capability to counteract headwind. You need the 4+1 configuration that has a forward flight motor and then you can set the Q_VFWD_GAIN parameter.
Thanks, I’m pretty happy to have this project in the air finally - its the culmination of a lot of work.
After my post a went off to read about QAutotune and have decided that it appears to be quite a risky process unless you have a pretty good basis to start from.
As recommended for quadplanes and see where that gets me. in the meantime I will go off and learn more about manual tuning, as there obviously needs to be improvements in the aircraft handling before bringing QAutotune in to play.
At the moment I am using QStabilise and QHover, I want to bring in QLoiter aswell as poshold and althold. Would you recommend looking at anything in particular with these settings before trying to use them?
Make sure that your HDOP value is below 1.0. If not, check the number of satellites you are receiving. Keep the GPS puck above other electronics and transmitters.
For tuning the hover, you typically only need to tweak these three parameters to get rid of oscillations or increase authority.
Q_A_ANG_PIT_P,6
Q_A_ANG_RLL_P,4.5
Q_A_ANG_YAW_P,3
For forward flight, there is a good description in the WiKi here.
Yes, HDOP is usually well below 1, and usually shows 17-20 satellites.
The HERE GPS is above the FC, RFD Modem and SBUS RX receiver - it’s the highest electronics in the airframe with a good sky view (although beneath one of the nose access hatches).
I went through tuning and vibe documentation last night and compared to one of my flight logs. The Vibes are all well within parameters, with VZ having the largest range (but a running average of -10).
The only area of concern, is a difference between despitch and pitch. The recorded vehicle pitches appear scaled or capped lower than the desired. I think this shows itself in the flight with pitch oscillations under commanded pitch. This is the main handling concern for me - hoping to work on this today.
I set the Q_A_ACCEL_R/P/Y_MAX values as I had seen recommended on the qautotune thread, and found a signficant reduction in handling, especially in yaw - what I would term loose.
Having looked at the parameter list and at the Tuning Process Instructions page (both copter and quadplane), I now see that the values mentioned up the page for Q_A_ACCEL_R/P/Y_MAX are far off the mark. Not sure if something changed over the past 2 years, but, for my configuration of quadplane at least, these are very poor value choices.
I was able to reduce Q_A_ANG_PIT_P from 4.5 (I assume stock) to 4.0. This appears to have the desired effect of reducing pitching oscillations. Needs more flights to confirm.
I managed to break a bonded joint so that needs to be fixed before sticking to the process and suggested values in the quadplane tuning instructions set up and going back out again. Thursday I should think.
Just an idea, we could use scripting to monitor this and update a file on the SD card. If there is some consensus on what info would be required I could do a example.
It seems you have downgraded your initial success. I’ve given my lowest level warning above so now it’s time for the next level warning. I have never used QAUTOTUNE in my dozen or so VTOLs. Granted, it has only been available for the last few projects, which is why I manually tune, if needed. I am not suggesting that it doesn’t work, but rather you don’t need to risk using it since only a few parameters, if any, need to be tweaked from the excellent default values.
Perhaps you can post a .bin log file and explain what “unflyable” means. What mode were you in? Were you trying to hover or fly forward? I typically use QSTABILIZE first to test that I can hover reasonably well and then add in some sensors with QHOVER and QLOITER.
