Why a Tiltrotor?
In the past few years of watching a number of VTOL aircraft designs pop up on DIY Drones. It was very apparent we were not the only ones with the desire to fly a plane and never need a runway or prepared landing area. The intriguing appeal of a titlrotor to us has been that a vehicle with vertical take-off and landing capability can be “upsized” for higher payload capabilities without requiring a runway, and the tiltrotor can also offer the range similar to that of a traditional airplane. It is inevitable with a fixed-wing aircraft that an RC plane quickly reaches a weight and dimensions that invariably result in landing gear and runway requirements. Although the tilting Tri-Motor (FireFLY6), , and SLT VTOL are great designs that are paving the road for VTOL aircraft, they all suffer from similar deficiencies:
- Thrust inefficiencies in both Copter and Airplane due to 4+ motors & small props and increased weight.
- The conversion between flight modes is a discrete, rapid event and does not allow for much maneuvering in the conversion phase, resulting in a very fast plane and a very slow copter. It is a brute force approach to avoid the complex control coupling between flight modes.
- Only the FireFLY6 can fly autonomously, but currently requires 2 flight controllers with a “Bridge” in between.
Our primary design goal was to create a tiltrotor that was capable of autonomous flight. We felt that in order to get the most smooth and predictable behavior from the autopilot, we needed good flight characteristics in all flight regimes including the ability to maneuver at intermediate thrust angles. This design philosophy/requirement would ultimately lend itself to a more versatile and controlled departure from hover that permitted maneuvering while converting towards airplane mode. Further, smooth and continuous decelerating approaches to hover with a vertical landing were also attainable with a control strategy that functioned effectively over the entire range of thrust angles. We understood that this was no easy task.
The major design compromise that all the aforementioned VTOL aircraft above have had to make is controlling pitch in a hover. In our opinion, the best tiltrotor solution is to use a swashplate on both rotors like the Rotormast. However, most people who have read this far probably recognize that two swashplates and motors is not very realistic in terms of reliability, costs, and complexity for the average hobbyist / drone pilot. And, that’s not to mention the additional six servos required to manipulate the full-up swashplate. The only way we devised develop this tiltrotor without selling our cars was to “imitate” longitudinal flapping, and forfeit any lateral control power derived from the rotor system. We knew this “imitation longitudinal flapping” would compromise control power and subsequently aircraft hover pitch stability, but we were willing to take the risk and the let the APM handle the stability, as it has the power to do many amazing things not possible without a feedback controller.
The most effective way we could think of to imitate flapping was with the use of 3D Printing. The nacelle with a “tilting” brushless engine was the most difficult design decision we had to make, but worth the risk in reduced complexity and cost. This nacelle design was designed in Autodesk Inventor and printed by Shapeways. The dimensions and mechanical functionality of the nacelle was designed around predicted control moments and the estimated interial properties of the all-up aircraft.
Originally we thought that our “mock” longitudinal rotor flapping was a unique idea that we had come up with ourselves. As it turns out, quite a few people have successfully used this technique. It wasn’t until after our aircraft was flying that we realized that Tom Stanton has successfully used this flight control strategy. (and probably a few others using similar ideas). We also discovered the work done by Gary Gress’s Bi-Copter and quickly realized pitch control without a swashplate had been experimented with quite a bit. So, by no means are we claiming to be pioneers in VTOL or tiltrotor aeromechanics.
The rest of the design choices were relatively straightforward and based on previous experience in the preliminary design of RC-sized aircraft using various software tools. Our airfoils and wing dimensions were primarily designed using XFLR5 with some help from the Autodesk Simulation CFD. An iterative process was used to fine-tune the design of the aerodynamic surfaces once the overall dimensions and all-up gross weight were converging on their final values.
The propeller and motor selection initially utilized eCalc as our primary method of determining hovering thrust and power consumption, while making the “best” compromise for good airplane mode cruise speeds characteristics. Although we thought we did our homework in the preliminary design phase, we went through a few iterations of motors and props after ground and hover testing.
Our fuselage (the most primitive looking design choice) was designed to be as flexible as possible to allow for unforeseen design changes during development. Using Adobe Illustrator, it was not too difficult to create a 2D drawing, and create all the parts on a single sheet of .125” birch wood. The file was sent to ponoko for laser cutting. This generic design allowed us to move parts and pieces of the aircraft around and evaluate the longitudinal, and waterline CG effects. The fuselage went through three design revisions after some important design criteria/deficiencies were learned in hovering flight.
The conversion system was assembled using robotic parts from Servo City. This design was inspired by the iQuad (Now up to iQuad version 2?) Its solid aluminum composition acts as the core structure around which the rest of the aircraft is mounted to; it is the load path for the fuselage, conversion rod, wings, and empennage. A 40-inch carbon fiber rod acts as both the main wing spar and rotating conversion axis for both fixed nacelles.
The wing, vertical, and horizontal tail were created with our own homemade Arduino-controlled 2-axis hotwire cutter used to cut high density foam. We can input any desired airfoil coordinates by interfacing the Arduino through a Processing program that we wrote, and cut exact airfoils, including the tips with taper. The foam was then fiber glassed, vacuum bagged, and the conversion axis and servo wires were run internally to the wing.
CAD was used extensively to make design decisions. Some component designs went straight to CAD modeling before assembly/fabrication in order to size and visualize assembly techniques. Other parts of this model were created after our physical parts were assembled and then updated later. Not only was this a major advantage to bringing ideas from “paper” to reality, it was invaluable in estimating the physical properties such as weights, CG locations, and moments of inertia for our preliminary estimates.
Before testing even began, a few tools were required for us to make intelligent design decisions during our software and hardware development. We developed a 5-axis load cell made of an array of aluminum strips each with strain gauges. Using an Arduino, a lot of parts from radio shack, and Processing code we developed we were able to derive reliable forces and moments in 5 degrees of freedom. This allowed us to get reliable thrust numbers, roll moments, yaw moments and pitch moments in “helicopter” mode. Additionally, the effect of wing proximity to the rotor plane was evaluated. We were also able to approximate control power sensitivities for both RPM changes and servo actuated flight controls. Once this data was collected it made our flight control outputs much easier to approximate in the arducopter code and get “close enough” to start hovering. Quite a bit can be written about our use of the 5 DOF load cell, but to keep this from growing too long, it is sufficient to simply state that it was invaluable to our development.
After control power was evaluated, roll and yaw stability was assessed in a hover configuration by rigging the axis of interest to be free on a bearing.
Roll stability for the tiltrotor in helicopter mode did not differ much from a large sluggish quad. Roll stability was quickly accomplished with only minor tuning and no major code altering. Yaw control with differential longitudinal servo commands was slightly more difficult to implement. Code changes were required to command servo outputs as opposed to RPM changes as used in quads. This also necessitated more tuning, but yaw stability was very solid, and most time was spent achieving good yaw rate outputs rather than heading hold stability.
As expected, pitch control in hover was much more difficult to evaluate than roll or pitch. We were unable to tune the aircraft while it was fixed to a bench like the roll or yaw axis. The combined effects of the aircraft weight, CG location, and thrust vector working against each other while the aircraft was fixed vertically made tuning pitch impossible. The only we option we had was to move forward and begin hover assessments.
Short duration, in-ground-effect hovers were required to tune the pitch axis. We spent many hours at our indoor facility chasing PID settings and decided to move outdoors to conduct out-of-ground-effect hovering flight to test/tune the pitch axis. This was done intentionally without the elevator and vertical airplane surfaces so that they would not be damaged during hover development in the event we had a hard landing.
After almost 20 flight days, 30 take-offs, and 5 crashes, it was starting to appear the hover pitch axis control design might not be a realistic design solution. After spending many hours computing moments of inertia, thrust forces, and thrust vectors and bounding the errors associated with the calculations, something major was missing in the physics in our pitch axis. The only thing, we concluded, not included in the calculations for pitch control were the aerodynamic forces associated with the rotor downwash on the wing. As a “last chance” test we cut the wing tips off so the rotor arc had no wing below it. This resulted in a very stable hover, which got even better with some tuning. To further evaluate the helicopter mode, all axes were tested with moderate inputs including lateral repositions, forward and aft repositions, and 360 deg turns with heading captures. This was also done with LOITER mode enabled, allowing APM to maintain position with very successful results.
At this point a wing design change was required to reduce wing downwash. The wingspan was extended by 4 inches and 6 inches of each wing tip were tapered to reduce the amount of surface area below the rotor. Hover tests were not as good as the flights with the wing tips removed. However, the pitch control authority was much better than when the wing had no taper. At this point we felt ready to start investigating forward flight “conversion mode” to identify any major configuration flaws before we spent too much time in hovering flight.
There was a significant down period between the hover tests and the first forward flight with thrust axis change. Numerous software changes were needed to be implemented to morph the Arudcopter code into a usable tiltrotor code . Additionally, the aircraft hardware required modification to install the empennage and associated aerodynamic surfaces and servos . The elevator was mounted using more 3d printed mounts and the vertical also utilized some 3D printing. Servos were installed and wired back to the APM 2.5. Due to the additional control outputs added, the code was further modified to accommodate ten pwm outputs. .
The transition from hovering to forward flight became a much more complex task than originally expected. As the aircraft moves forward and converts towards airplane mode the Arducopter control architecture for turning no longer works. A “heading hold” strategy still worked with the tiltrotor for low-speed flight, but at higher speeds we needed to adopt more of an airplane-like coordinated turn approach. In essence, we desired a high-speed mode similar the “Drift Mode” in the Arducopter world. One of our early attempts effectively disabled the Heading Hold feature predicated on certain gates, but that proved ineffective because the airspeed at which the rudder provided sufficient control power was relatively high. Simply put, it was impractical to retain Heading Hold during the acceleration to the higher speed because the onus of coordinating any turns would fall solely on the pilot and be a visual task. After several iterations and failed attempts, we finally settled on an approach that was a blend of Heading Hold and a pseudo turn coordination strategy that augmented the heading target algorithm. The turn coordination component used various aircraft state parameters to augment the aircraft heading target, and was gated with airspeed. This technique meant that as soon as the aircraft reached the speed gate the pilot could execute a turn with only a roll input; no Yaw Axis inputs were required.
Other hardware implementations had to be made to control the thrust vector on the RC transmitter. Here is the thrust vector position pot on the left side of the transmitter.
The first forward flight tests consisted of flying down a 1 mile farm road with the pilot in the back of a pick up truck, and the driver monitoring the thrust vector and speed on the laptop. At this point no turning flight was evaluated; only takeoff, forward acceleration to a prescribed speed/thrust angle, deceleration to hover and land. Many flights were spent with very successful speed trials. We slowly managed to hover, accelerate to about 14-16 m/s with the thrust axis tilted only about 30 deg forward from vertical. Pitch was amazing solid, and altitude control was easy and responsive. A cornfield served as our crash protection and acted as thousands of tiny wind socks.
We were unable to keep up with the aircraft in the truck beyond 16 m/s. It was now necessary to begin increasing speed and thrust axis while flying about 1/2 mile orbits and figure 8’s. Our programming for coordinated turning flight was critical at this point to permit coordinated turning without pilot assistance in the yaw axis, and we took a very methodical approach by carefully increasing bank angles at each thrust axis and airspeed combination. It immediately becomes apparent that the the most difficult software changes were now deciding at what speeds to reduce rotor thrust as the primary flight control, and hand over control to aerodynamic surfaces when speed was sufficient. Our original software implementation strategy utilized gain tables with the intent of seamlessly transferring the commands from rotor-based to aerodynamic surfaces based on various state parameters. Unfortunately, the first time we allowed the rotor to stop maintaining/assisting roll maintenance and allowed ailerons full control of roll, we developed large un-damped roll and yaw oscillations. Simply bringing the thrust axis back to an angle that restated rotor thrust allowed us to safely land and review data for changes in aileron gains. Although the aircraft was flying well at this point, more work had to be done with the turn coordination logic and maneuvering control strategy at low speed flight in “conversion mode”. To assist in post-flight data analysis and code development, a side-slip vane was added to the airspeed boom to help us better understand the aircraft’s directional state in “conversion mode” turns. We used this sensor to provide feedback on side slip and correct for large side-slip errors in an effort to prevent significant out-of-trim flight conditions .
As speed and thrust angle increased we predicted that most of our time would be spent correcting pitch problems as the weight of the motors changes the CG of the aircraft by a good amount as they transition to airplane mode. It turned out, however, that pitch was by far the most solid axis and needed very little improvement once it was moving faster than 5 m/s. The most time was spent correcting lateral-directional problems. As we predicted, when the rotors go beyond 30 degrees from vertical, the control coupling is quite complex between roll and yaw. The cross-coupling introduced numerous issues in the control mixing with the rotors. In fact, not only was the cross-talk an issue for instantaneous corrections (equivalent to proportional term corrections ini the PID loops), but the spooling up of integral terms also contaminated to the controllability of the aircraft when off-axis trim corrections were required. Even a slight thrust difference between rotors will drive a unique directional and/or roll trim conditions at each thrust axis setting. As true with all RC aircraft, dual-rotor setups lack any true feedback from the thrust being produced. Sure, we can match pwm signals, but the nuances of each motor’s RPM and the unique thrust produced by a particular prop can be variant. The core Arducopter code works great to trim the thrust in VTOL mode, but what happens when the rotor thrust transitions to becoming directional control in airplane mode? It became necessary to constantly manipulate the RPM (via the control laws) of each motor to keep lateral-directional control at low thrust axis settings close to airplane mode. Completely suppressing rotor-derived control exposed us to the aforementioned, subtle differences in the thrust produced by each motor for the common pwm command. Several near crashes came as a result of these effects and the chosen implementation of control strategies. Each thrust axis/airspeed combination exposed various “holes” in our software architecture. The countless permutations of flight control outputs when being functions of thrust axis and airspeed combinations became tedious to code, and even more difficult to iteratively evaluate. In the end, the software that is currently written, and being flown, uses all nine output channels and seamlessly transfers all the rotor and servo-driven controls to maximize stability and control authority at all thrust axis angles. The employed strategy functions by utilizing a combination of body frame and earth frame calculations. Gain tables and speed gates continue to augment the output signals, but they are implanted using a different technique than earlier software versions. Further, fundamental changes to the PID loop structures were required to properly function with the hybrid reference frames. The result is a tilt rotor that can maneuver fantastically at ANY thrust axis angle.