Prototype Tiltrotor Development using APM 2.5 We are a two- man team who has spent the last year designing, building, and test flying a tiltrotor using the APM 2.5 as our flight controller. We are NOT posting here to sell a product, or start a Kickstarter, but we would very much like your feedback on our design. About us- We are both aerospace engineers each with 10+ years experience. We were introduced to the ardupilot community about 2 years ago, and immediately recognized the power of the open- source hardware and software at a very affordable cost. We spent the first year flying the APM 2.5 with the plane software learning all the ins and outs on a Bixler. Eventually we felt confident in expanding our skills to custom aircraft and custom software, building and designing a few aircraft with some minor tweaks to the software.
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 tiltrotor 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 dimension that invariably results in landing gear and runway requirements. These characteristics also require more pilot skill where mistakes are extremely costly. Although the tilting Tri- Motor (FireFLY6), quad motor Wing copter, and SLT VTOL are great designs that are paving the road for VTOL aircraft, they all suffer from similar deficiencies: 1. Thrust inefficiencies in both Copter and Airplane due to 4+ motors & small props and increased weight. 2. 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. 3. Only the FireFLY6 can fly autonomously, but currently requires 2 flight controllers with a Bridge in between. We are well aware that the tiltrotor is not a replacement for a quad. It will never have the low speed maneuverability that a quad does. We like to think of the tiltrotor as a fixed wing airplane that can hover. Not a combined quad and plane. Design 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 2 full- up swashplates. The only way we devised to develop this tiltrotor without a massive budget 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 inertial 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' 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 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 0.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?) 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. Testing Ground Tests 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, with each beam having a full Wheatstone bridge. Using an Arduino, a lot of parts from radio shack, and Processing code we developed, we were able to derive accurate 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 document 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 the differential RPM 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 axes. The combined effects of the aircraft weight, CG location, and thrust vector working against each other while the aircraft was fixed vertically and made tuning pitch impossible. The only option we had was to move forward and begin hover assessments. Flight Tests 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 10 flight days, 20 take- offs, and 5 crashes, it was starting to appear the hover pitch axis control design might not be a viable design solution. After spending many hours computing moments of inertias, 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 translations, forward and aft repositions, and 360 degree 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 rotor 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 nacelle movement. Numerous software changes 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 printed components. 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 to 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 pickup truck (tethered in, and thoroughly secured), and the passengers monitoring the nacelle and speed on the laptop. At this point no turning flight was evaluated; only takeoff, forward acceleration to a prescribed speed/nacelle angle, deceleration to hover and vertical landing. Many flights were spent with very successful speed trials. We slowly managed to hover, accelerate to about 14-16 m/s with the nacelles tilted only about 30 degrees forward from vertical. Pitch was amazingly solid, and altitude control was easy and responsive. An adjacent cornfield served as our crash protection and acted as thousands of tiny windsocks.
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 nacelle while flying approximately 1/2 mile orbits and figure 8 s. Our programming for coordinated turning flight was critical at this point to permit turns without pilot assistance in the yaw axis, and we took a very methodical approach by carefully increasing bank angles at each nacelle and airspeed combination. It immediately become apparent that the most difficult software changes were now deciding at which 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 predicated 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 nacelles back to an angle that reinstated 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 the 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 sideslip and correct for large side- slip errors in an effort to prevent significant out- of- trim flight conditions.
As speed and nacelle 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 in 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 nacelle setting. As true with all RC aircraft, dual- rotor (or propeller) 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 nacelle 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 nacelle/airspeed combination exposed various holes in our software architecture. The countless permutations of flight control outputs when being functions of nacelle 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 nacelle 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 implemented 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 nacelle angle setting, and trim- transfers control power to fit the needs of the current nacelle angle.
What s next? Autonomous Flight We have a lot of work to complete before a full autonomous flight can be attempted. The vertical axis is expected to be the most daunting challenge in front of us. The blending of VTOL strategies and Airplane Mode altitude management will require hours upon hours of pilot- controlled flight to characterize the vehicle s climb/descent behavior. In parallel to the vertical axis evaluation/code development, we ll also be integrating the L1 Navigation algorithm. We already foresee a few key areas of the navigation scheme
that will have to be modified before it will function properly on the tiltrotor platform. However, many of the expected regime- dependent nuances should be vetted while flying the L1 build- up maneuvers. Pixhawk Early on we struggled with the choice between pixhawk and APM 2.5. When we started the tiltrotor project our comfort level was much higher with APM 2.5 and the Arduino world of coding in general. In 2013, it looked like we would be spending lots of time learning to code Pixhawk rather than focusing on designing a tiltrotor. At some point we will have to learn to work with the new hardware and benefit from EKF, terrain following, and all the other amazing Pixhawk capabilities. As of right now the APM 2.5 has not limited are ability to create a tiltrotor, and will continue to be our primary hardware as we progress. Tiltrotor 2 Someday we would like to take this prototype to the next level. We would like to incorporate all the things we learned from this design into the next revision. From assembly improvements to aerodynamic/performance enhancements there is a lot that can be enhanced. This design is scalable to accommodate payloads of choice, however we have not considered payloads other than cameras for our next tiltrotor. The biggest factor related to increasing the size and weight of our current design is the cost associated with larger motors, ESC s, batteries, and 3D printing, etc However, we are highly confident that the core code we ve developed can be scaled with ease, as long as the appropriate gate and gain schedules are correctly redefined for the new airframe. Your Opinion? We are engineers, not businessmen. The Open Source community is quite a unique way to invent. We recognize that this project would not even be remotely possible if it were not for the years of development of the Ardupilot Project. The code available to us to as a starting point is truly a work of art, and we don t think the majority of people with go pro- equipped quad copters can appreciate the complexity and capabilities of the software. I am sure the most common question we will get is will you be sharing your code? We have both struggled and argued about this idea. In one hand, the ardupilot developers /community have given us the tools to succeed in this project. If I knew our hard work was going back to them, we would be happy to it give back. In the other hand we have worked very hard, spent a good amount of our own money, and would like to benefit from our hard work. If we were to give this code out, and Company X were to start producing and selling tiltrotors a year later, frankly we would feel ripped off. The line between what we (as a two man team) have created and what we (as the Ardupilot community) have created is very blurred. We would love to hear more opinions from experienced contributors to the Open Source world. What would you do, and why? Do you have a mission that you d use the tiltrotor for? What would you like out of a VTOL aircraft that your quad or plane couldn t currently do? Is there a payload that you have in mind for a tiltrotor? We have no doubt that there are lots of missions for high speed VTOL aircraft. Is the tiltrotor the answer? We really don t know, but we are really proud of what we have designed and are excited for the next generation of our aircraft.