2016 Autonomous Software and Photuris Tiltrotor Development


Background:

Our two-man engineering team known as “Team Tiltrotor” has been developing VTOL / Tiltrotor software since early 2014. Before VTOL / Tiltrotor development we spent over a year developing custom fixed-wing aircraft. Using APM:Plane software, we explored twin engine thrust control and used unique flight control concepts combining the forces from the propeller and the aerodynamic surfaces as attitude effectors, not just to improve the aircraft’s stability, but with the end goal to increase the range and performance. It became immediately apparent that despite the increase of range and performance of the twin engine fixed wing aircraft, the limitations of launching and landing began to restrict the areas in which we could operate the vehicle.

VTOL’s and Tiltrotors:

After using our fixed wing aircraft in the real world to collect video and photo of some of our favorite remote outdoor areas, we decided it was time to use what we learned on the “White Knight Bixler” and combine the elements of multicopter and fixed wing. Knowing and studying the limitations of tail sitters, quadplanes, and other VTOL concepts , history seemed to point us to tiltrotor concepts. It was obvious that all VTOL concepts are complex machines, and that many varying design decisions each come with compromise. Developing a tiltrotor seemed like the obvious path due to following:

  1. A tiltrotor is the most robust and predictable vehicle when in the transitory phase between its Hovering Mode and Fast Forward Flight Mode. Arguably, the quadplane is of similar effectiveness for wings level, level altitude transitions, but not for turning/climbing conversions.
  2. The non-linear effects of aerodynamic wing stall are minimized, allowing multi-axis maneuvering flight in the transitory “conversion” phase.
  3. Increased efficiency by using the same propulsion for both the hover and fast forward flight, rather than carrying unused propulsion and weight.
  4. The aircraft’s fuselage orientation remains constant with exception to the thrust vector allowing for the orientation of flight equipment and sensors (Flight Controller, GPS, airspeed sensor, compass) to remain fixed, and also the “mission” equipment such as cameras.

Some of the negative tiltrotor compromises we had to consider were:

  1. Increased mechanical complexity
  2. Inefficiencies in propulsion in either hover, forward flight or both (fixed pitch prop configuration has conflicting performance requirements)
  3. Complex attitude control at many unique speed / thrust vector combinations

“Tiltrotor 1”

Our first tiltrotor was a critical experiment to understand, learn, and create solutions for:

  1. Tiltrotor airframe design (Aerodynamic, Structural, and Propulsion)
  2. Simple mechanical control of the thrust vector
  3. Stability and Control blending of Copter and Plane
  4. Complete 3 axis attitude control at all thrust vectors and speeds, both trimmed and dynamic thrust vector changes
  5. Test methodology for future designs
  6. Tiltrotor user interface, piloting, and procedures

This project was invaluable to our understanding of operating tiltrotors. We documented many of those lessons and struggles here. Over 30 versions of flight control software were flown through the various stages of development on just the prototype vehicle. The foundation of all our tiltrotor development to date was created with this aircraft. The core concepts that came from this aircraft now apply to all of our tiltrotor designs:

  1. The core of the tiltrotor is effective attitude control at all airspeeds, including airspeeds below the stall speed of the main wing. Aerodynamic control surfaces must be aided by the propulsion system in each axis of control. Cross coupling of aerodynamic and propulsion effectors must be handled elegantly in the flight control software.
  2. The tiltrotor should not be treated as a “two-mode” aircraft (multicopter/fixed wing). The benefits of VTOL flight can be greatly enhanced when flying in blended modes at intermediate speeds in terms of both stability and control and performance.
  3. Prevent the tiltrotor from flying in regimes it is not capable of complete control.
  4. Coordinated aerodynamic flight is critical to predictable attitude control.

Foundation for Future Tiltrotor Development

Tiltrotor 1 taught us the fundamentals of tiltrotor stability and control, and general operation of small UAS tiltrotors. The next step from understanding the aeromechanics of the tiltrotor was to move to the next level of augmentation: Automation. Several necessary building blocks were required to effectively achieve this goal. Some of those early challenges are described here:

  1. We re-wrote all of our Tiltrotor 1 flight code that was created from Copter 3.1, and merged it into Copter 3.2.1 to not only migrate from APM 2.5 hardware to Pixhawk, but also to benefit from several major ardupilot improvements such as EKF.
  2. Moved our development workspace from an arduino compiler to the APM Dev Team’s environment.
  3. Applied our tiltrotor code and concepts to the only production tiltrotor available, the Birds Eye View FireFly6.

These building blocks demanded a necessary pause in our tiltrotor development. Moving our existing APM 2.5 software to a new flight controller, a completely new airframe, and restructuring our software workspace was not a simple task. Understanding the nuances of the FireFly6 was an exciting challenge and revealed several code errors, and subtle attitude control mistakes we had made in our original tiltrotor software. Moving from a bi-rotor tiltrotor to a Y-6 multirotor configuration on a flying wing was a major deviation from our previous tiltrotor work. The FireFLY 6 required us to create some unique code to handle the aft motor set and also handle the pitch control at varied airspeed / thrust angles. Pitch control was more challenging than other axes because of the unique trim conditions at different speed / thrust vectors. After several iterations of code we demonstrated excellent attitude control through the envelope. Like all our projects, the small discoveries along the way required much more time that we expected. But, by methodically addressing each issue and avoiding cutting corners, we created a fantastically flying FireFLY6 software.

Autonomous Development

Development of autonomous flight was now our primary focus with a strong foundation to build upon. We had a reliable airframe, reliable / accurate pixhawk flight controller, refined low-level controllers consisting of nine PIDs, strong attitude control in all regimes, and a strong test methodology for progression. The first step in autonomy was to create the framework for an eventual complex blend of navigation controllers. Recognizing that each of the Copter and Plane navigation controllers are very impressive and effective, Plane and Copter navigation should not simply be used independently on a tiltrotor. Navigation during the transition and conversion between plane and copter required blending 2D navigation, vertical navigation, and also creating some new unique controllers to merge the two modes seamlessly. To truly benefit from the advantages of the tiltrotor attitude control, navigation had to continue uninterrupted at any speed and thrust vector combination. Ultimately, the benefits of our navigation blend would be realized in creating departure and approach paths that allow for simultaneous climbing /turning accelerations, and decelerating turning descents without the need to complete the transition or conversion before maneuvering. This is a very important tiltrotor concept, because it now allows strong stability and control during the most critical phase of flight: The approach to hover followed by the landing. The most obvious benefit of this navigation blend is that it allows you to use the strengths of the tiltrotor against the effects of the ambient wind. By executing descending turning approaches you can effectively navigate around the obstacles in your landing zone, and enter a headwind for the landing phase. Executing a level altitude conversion to hover high above your target landing spot exposes the aircraft to unpredictable wind speed and wind direction. It also consumes significant amounts of energy to slowly descend vertically with an inefficient hovering propulsion system (props are selected/optimized for airplane performance). The vertical descent must be slow enough that the aircraft does not suffer from the aerodynamics of vortex ring state, and wind disturbance against the unused and exposed wing/tail area lead to deviations in position maintenance and attitude instabilities. Testing of this navigation blend was multi-phased. Straight approaches were flown repeatedly, refining multiple aspects of the conversion, deceleration, vertical control, and distance required to complete. Collecting data of the longitudinal deceleration and vertical descent rates, with numerous ground speed / airspeed / thrust vector combinations, was required to understand and design an approach that was within the physical capabilities of the airframe.

APPR to HVR Decel Data

Figure 1: Auto Approach to Hover: Tiltrotor Deceleration Data Collection

This led to the implementation of a tiltrotor glide slope controller that could simultaneously control rate of descent, a prescribed airspeed deceleration, and distance to the desired landing location, all while dynamically changing the thrust vector. We can effectively control each dimension of the tiltrotor approach, and use our control strategy to prescribe multiple “height gates” throughout the conversion. Further, we can control the deceleration between those height gates and account for the difference between air and ground speed. And, finally, combine these concepts with constant 2d waypoint navigation during this process to maintain course tracking and account for winds. It took a significant amount of research, coding, and flying to implement this architecture. Many sections of code from both plane and copter are overlapped, while some work independently with unique entry and exit criteria. We continue to develop and refine the transition logic, and are very close to achieving a robust system that enables us to maximize the effectiveness of the tiltrotor and avoid common VTOL pitfalls.   To-date, we’ve flown over 50 fully-auto missions from takeoff, to airplane mode, back to hover, and vertical landing.

Tiltrotor AUTO Diagram

Figure 2: Tiltrotor Auto Mission Execution

Tiltrotor GS Control 2

Figure 3: Tiltrotor Final Approach

APPR Mode Google Earth

Figure 4: Tiltrotor Auto Data Collection

Tiltrotor Return to Launch (RTL)

With both tiltrotor Stabilize and Auto Mode successfully implemented, a Tiltrotor-specific RTL function was the next required flight mode. At anytime the user may desire the aircraft come back home and land without taking over manually from far away. This is a challenging concept for a tiltrotor because the RTL action may differ based on:

  1. The distance from home
  2. The current flight mode (Hover / Conversion / Airplane)
  3. The current course from home may not agree with ambient winds

We created an RTL function that uses the current mission as guidance for establishing the approach course. This functionality had to access the current mission, and make “smart” decisions based on our criteria. In certain situations it has the capability to append waypoints to the mission. For other cases, we can adapt and inherit certain attributes of the current mission to build an approach. As a fallback scenario, airplane mode operations will default to use a mode similar to Plane’s RTL function, wherein the vehicle will return to home in airplane mode and enter an orbit. The biggest challenges revolved around the decision tree that determines how to come home. As stated above, consideration is given to the vehicle’s current state and relative position to the RTL location. For example, if we’re already in VTOL mode, and in close proximity to home, we should not move the thrust vector and simply execute a quad-style RTL.

Tiltrotor RTL Diagram  Tiltrotor Ground Track Wind Avoidance

2nd Generation Tiltrotor Experimental Airframe

In the past year, the FireFLY6 has proven to be a great platform to develop and test our software on. The aircraft is well ahead of its time as far being a reliable, productionized Tiltrotor. It’s well built, has high quality components, and is very robust to piloting mistakes. While we’ve come to realize the deficiencies of the Y6 configuration from a performance and directional control perspective, it certainly offers great pitch and roll control in a hover configuration. Near the completion of our autonomous navigation code, Bird’s Eye View Aerobotics released its own autonomous code known as “AVA”. To reiterate our previously posted statements, we don’t know anything about its development, nor have we have ever flown the software on our FireFLY6, but it’s obvious to us that it did take a tremendous amount of work. We understand in great detail the obstacles required to combine the two very complex vehicle codes into a single, effective tiltrotor software. The timing was very coincidental, and since we were near completion of our first complete version of autonomous tiltrotor software, we elected to begin moving the software to a more affordable airframe that allowed a greater level of airframe and software experimentation. We felt it would be much more rewarding to demonstrate our Tiltorotor code on our own vehicle. Hence, we chose a small “evolutionary” step to a conventional aircraft and retained the Y6 motor configuration. Further, we wanted to apply our software capabilities to an airframe that offered more fuselage space and could handle larger payload.

“Photuris” (Skywalker Tiltrotor Conversion)

To quickly move to a conventional airframe, with minimal impact to flight control software changes, we chose a conventional Skywalker 1830 airframe for a tiltrotor conversion. The Skywalker is a very popular mapping platform based on internet research and comments from RC enthusiasts. What could make it better than a VTOL version! Several designs were created in CAD software to ensure tiltrotor compatibility for:

  1. Hover thrust geometry
  2. Center of gravity position for all modes and aerodynamic requirements,
  3. Tilt axis geometry / clearance
  4. Thrust line considerations in Airplane mode
  5. Minor structural modifications

Sky_Walker_Tiltrotor

With the use of a CNC machine, we were able to create an incredibly strong and light mechanical system for the thrust vector tilt axis. Many design and mechanical lessons were learned on Tiltrotor 1 that were improved upon in this design. Several analysis iterations of motor / props / batteries naturally lead us to a similar propulsion system as the FireFLY6 for the Y6 thrust configuration (the vehicle dimensions and gross weights are similar). Retention of the Y6 configuration made sense to us since we had already proven our software’s performance on the FireFly. Further, having a reliable, proven code allowed us to immediately explore the Skywalker’s characteristics with high confidence in the underlying software.

Milling Machine
Photuris Photuris Frame

We expected improved aerodynamic efficiency over the FireFLY6 due to:

  1. A higher aspect ratio straight main wing
  2. Improved trim attitudes over the flying wing
  3. Decreased rear motor drag behind the conventional fuselage vs the exposed flying wing aft motor set
  4. Improved thrust efficiency with no wing downstream of the props
  5. Full 90 deg rotation of the thrust vector vs 80 deg on the fireFLY 6
  6. Lower gross weight

We also expected improved attitude control due to:

  1. Two Discrete Pitch / Roll effectors (Elevator / Aileron) vs Coupled Elevons

AP_Mode_Front

Photuris + FireFLY6

Photuris specifications/equipment:

  1. Wingspan: 1830MM (single wing length:850mm)
  2. Fuselage length: 1270MM
  3. Wing area: 41.06 dm2
  4. TOGW= 3.5 kg
  5. (6) Tiger MT3506 650 kv motors
  6. (6) Hobbywing 40A ESC
  7. (6) Carbon Fiber T-Style Propeller 10×5.5
  8. (2) 5200 mAH Multistar 6S Lipos
  9. HKPilot-32 Flight Controller
  10. HK Pilot Power VI Module PDB
  11. Ublox Neo-M8N GPS with Compass
  12. HKPilot 32 Digital Airspeed Sensor And Pitot Tube Set
  13. (3) BMS-375DD Digital Servos 1.6kg / .11sec / 9.6g ((2)Aileron and (1)Elevator) No rudder actuation required with airplane mode differential thrust yaw control

Conv_mode_side

The Skywalker airframe tiltrotor modification increased the stock airframe weight by almost exactly 1.0 kg, consisting of the 6 motors, 6 ESC’s, Conversion axis structure and servo, and nylon engine mounting hardware. We expected to be slightly lighter than the similar FireFLY6 with equivalent propulsion system.

Unfortunately, our first attempt fell short of the FireFLY6 (based on their released TM log). Our current in hover/takeoff climb is about 15% higher (35A vs 30A), and our cruise performance is 70% higher (17A vs 10A). The higher hover current with lower weight indicates we are less efficient in propulsion, but it’s unclear if the degradation in cruise performance is propulsion or aerodynamically related. Perhaps the Skyalker drag is simply higher, but it’s difficult to rationalize where a 70% increase in cruise amperage is coming from (at 14 m/s). We have already begun to amass parts for follow-on testing of different motor/prop combinations to better understand the losses/inefficiencies. Additionally, preliminary testing of deployed flaps shows a marked improvement in trim pitch attitude in the cruise state.

Photuris Performance

Cruise Speed

Avg Amp Consumption Estimated Range

Estimated Endurance

14 m/s

17.3 30 km 36 min

13 m/s

14.8

32 km

42 min

12 m/s 12.8 35 km

49 min

 

AP_mode_back_Cropped

Below is graph of a 10 min period of level flight cruise at 14 m/s with a 2 min period in the middle at 13 m/s. The decrease in speed reduced the average consumption by 1.5 – 2 amps, but only increased the range by 1-2 km in the estimated 30 km range. A 12 m/s speed sweep yielded an average current of 12.8A, which would have put us at 35 km of range. Despite the performance increase, the slower speed showed poor speed stability, high trim pitch attitudes, and degraded handling qualities. The speed scalers will have to be explored to improve the 12 m/s behavior, and modifications to the TECS controller are being worked to better complement the Skywalker’s thrust-axis response. So far we have been able to demonstrate 28 kilometers in a 35 minute flight, backing our predictions. The flight used our original “best guess” motor/prop configuration. And, as stated earlier, we waiting for parts to arrive to continue the performance testing.

Map of Photuris Mission

AP_Mode Perf for website 2

We will be evaluating different prop combinations in the near future and dig further into the propulsion inefficiencies. We are also excited to try some other propulsion layouts such as a Quad tilt on this airframe. Despite the mediocre performance this aircraft has shown so far, we see the long-term potential once we fix the motor inefficiencies. It is a great, affordable test platform that we plan to progress with to improve our software, our hardware, and overall understanding of tiltrotor autonomous flying techniques.