Understanding the need for more efficient transportation options within the 100 to 500 km range—a segment where travelers often face a dilemma—was a pivotal starting point for this project. Studies indicate that many people still opt to use personal vehicles for trips within this distance, despite the journeys being lengthy and uncomfortable. This preference underscores a significant gap in the market, as existing transportation options either lack convenience or are not cost-effective for intermediate distances.

The first major step was determining the optimal configuration for an eVTOL aircraft that could ultimately address this gap. The goal was to combine the efficiency of fixed-wing aircraft with the versatility of drone-like VTOL capabilities. Relying solely on direct lift, as drones do, is highly inefficient for covering longer distances due to the substantial energy required to maintain lift without the aid of aerodynamic surfaces.

To enhance efficiency for potential long-range applications, it was essential that all propulsion devices used for vertical lift in VTOL mode could also contribute to forward thrust during level flight. This dual functionality ensures that the aircraft can transition smoothly between modes without the need for additional propulsion systems, thus reducing weight and complexity.

In designing the prototype, I considered the minimum requirements for stable VTOL operation. At least three engines are necessary to achieve reliable control—much like a tripod provides stability with three points of contact. Therefore, the initial design features a tri-engine setup, with each engine capable of rotating about the pitch axis. This configuration allows for precise control during vertical takeoff and landing, as well as efficient propulsion during forward flight.

• VTOL Mode: When all engines are oriented upwards, the aircraft can take off and land vertically, providing the versatility needed for various operating environments.
• Level Flight Mode: Rotating the engines forward allows the aircraft to transition into level flight, leveraging fixed-wing aerodynamics for greater efficiency over longer distances.

The transition between VTOL and level flight involves complex dynamics and presents significant engineering challenges. While this transition is critical for the final product intended to cover intermediate ranges efficiently, it is an extensive undertaking on its own. To keep the project scope manageable and ensure successful completion, the current focus is on developing and testing the VTOL capabilities of the scaled-down prototype.

By prioritizing the VTOL aspect initially, the project establishes a foundational understanding of the control mechanisms and stability required for vertical operations. This approach allows for incremental development, where insights gained from the prototype can potentially inform future work on the transition dynamics and level-flight efficiency necessary for the final aircraft intended to address the 100 to 500-mile travel gap.

During the VTOL mode, the aircraft functions essentially as a tricopter. Traditional tricopter designs typically position their rotors at the vertices of an equilateral triangle to ensure balanced thrust and stability. However, adhering strictly to an equilateral triangle imposes excessive restrictions on engine placement and weight distribution, which can hinder the overall design and performance of the aircraft.

To achieve greater flexibility in design, we opted for an isosceles triangle configuration for the placement of the three engines. This arrangement allows for more adaptable engine positioning and better balancing options while still maintaining the stability required for VTOL operations. Regardless of the geometric configuration, an engine mixing algorithm is essential. This algorithm translates pitch and roll control inputs into precise adjustments of engine power to maintain stability and control during flight.

Calculating Net Moments and Developing the Engine Mixing Algorithm:

The initial step involved creating simple diagrams to analyze the net moments exerted on the aircraft by the three engines. By defining the position vector of each engine relative to the aircraft’s center of mass, we calculated the torque produced by each engine using the cross product of its position vector and the corresponding force vector (thrust). Summing these cross products provided the net moment acting on the aircraft in its local coordinate system.

While this approach seemed straightforward, it quickly became apparent that the system could become mathematically overconstrained. This overconstraint arises when attempting to solve for engine thrusts that simultaneously satisfy multiple rotational and translational equations of motion, leading to conflicting requirements that cannot be resolved with a simple solution (see below for overconstrained initial calculations).

To address this issue, we restructured the problem by decomposing the engine forces into two components:

1. Base Force: A uniform force applied by all engines to counteract gravity and provide the necessary upward acceleration for lift.
2. Moment-Inducing Force: Additional forces adjusted by the engine mixing algorithm to generate the desired pitch and roll moments for controlling the aircraft’s orientation.

By separating the forces in this manner, the engine mixing algorithm focuses solely on calculating the moment-inducing forces needed for rotational control. The base force is then added uniformly to all engines to achieve vertical lift. This approach simplifies the calculations and avoids overconstraining the system, ensuring that the aircraft can be controlled effectively without conflicting demands on engine thrust.

The engine mixing equations already efficiently handles pitch and roll commands, converting them into precise engine power adjustments. To integrate yaw control without complicating the calculations, we utilize thrust vectoring on the front two engines, appending the necessary adjustments at the end of the process. When these engines vector thrust, they lose a small amount of upward thrust; to counter any moments this loss might induce, the rear engine’s power is adjusted by the term ‘LossCompensation.’ This approach not only maintains simplicity but also enables independent and precise control over each movement axis—pitch, roll, and yaw—enabling a full range of control over the aircraft.

(FL: Front Left, FR: Front Right, BK: Rear)

With the engine mixing equations finalized, the next step involved developing a simple flight control software to test and validate the system. To accelerate the process, Unity (the Unity game engine) was chosen as the development environment due to its built-in physics engine and rigidbody system, which makes simulating the dynamics of an aircraft under multiple forces straightforward and efficient.

The structure of the scripts are as follows:

• Drone_FCS (Flight Control System): This script handles all flight control-related functions, including engine mixing, auto-level, and free-flight modes.
• PID_Controller: A custom-made class for creating PID control objects, allowing for precise control tuning using customizable variables.
• Virtual_IMU: This script simulates an IMU sensor, returning data such as gyroscopic Euler angles, angular velocity, and translational velocity. While real-world IMUs do not typically provide translational velocity, we can use numerical integration to estimate it when eventually working with actual hardware.
• Control_Inputs: A script to handle Unity’s input system, which allows the use of keyboard inputs.

The purpose of this simulation was to verify that the engine mixing algorithm properly converts desired pitch, roll, and yaw inputs into correct engine power outputs. It should further verify that the PID class functions as intended when used to create active stabilization methods.

The link below directs to a shared folder of the C# scripts:
https://drive.google.com/drive/folders/1rz_NkIuN5CVMHi8JFqeMS3FGT6XaqbZJ?usp=sharing

Free-Flight Mode

To quickly validate the engine mixing algorithm, I implemented a free-flight mode within the Drone_FCS script, which applies the calculated engine power directly to the engines. This approach uses an open control loop without active stabilization, making it difficult to precisely control the aircraft. However, this serves the purpose of validating the engine mixing equations. Below is a snippet of the free-flight method and its dependencies:

        private void free_flight() 
        {
            float Mx = Pitch * pitch_limit; //Pitch, Roll, and Yaw variables are input values
            float My = Roll * roll_limit;
            float Mz = Yaw * yaw_limit;

            engine_mixing(Mx, My, Mz, MaxEngineForce * Throttle);
        }

        private void engine_mixing(float Mx, float My, float a, float F_base)
        {
            float lossCompensation = MaxEngineForce - MaxEngineForce * Mathf.Cos(a * deg2rad);
            FL_engine_force = My / (2 * w) + Mx / (4 * l) + F_base;
            FR_engine_force = Mx / (4 * l) - My / (2 * w) + F_base;
            BK_engine_force = Mx / (2 * t) + F_base - lossCompensation;

            run_engines(FL_engine_force, FR_engine_force, BK_engine_force);
            yaw_TVC_transform(a);
        }

        private void run_engines(float FL, float FR, float BK) //Apply forces at engine locations
        {
            frame.AddForceAtPosition(FLM.transform.up.normalized * FL, FLM.transform.position);
            frame.AddForceAtPosition(FRM.transform.up.normalized * FR, FRM.transform.position);
            frame.AddForceAtPosition(BKM.transform.up.normalized * BK, BKM.transform.position);
        }

As shown in the attached video, This initial test confirmed that the engine mixing formulas work as expected, converting control inputs into the appropriate engine outputs. Note that this is without any kind of closed-loop control:

Automatic Leveling Mode

The next function tested was automatic leveling, which maintains a level orientation by keeping pitch and roll angles at their initial values. For simplicity, I used Euler angles in the current implementation, though future iterations may incorporate quaternions to handle extreme conditions more robustly. Below is the code for the automatic leveling function:

        private void auto_level(float pitch_imu, float roll_imu, float yaw_vel, float y_vel, float deltaTime)
        {
            float pitch_setpoint = Pitch * pitch_limit;
            float roll_setpoint = Roll * roll_limit;
            float yaw_setvelocity = Yaw * max_yaw_rate * deg2rad;
            float y_axis_setvelocity = Throttle * max_climb_rate;

            float controlled_pitch = Mathf.Clamp(pitchPID.Compute(pitch_setpoint, -pitch_imu, deltaTime)*0.1f, -1, 1);
            float controlled_roll = Mathf.Clamp(rollPID.Compute(roll_setpoint, -roll_imu, deltaTime)*0.1f, -1, 1);
            float controlled_yaw = Mathf.Clamp(yawPID.Compute(yaw_setvelocity, yaw_vel, deltaTime)*10.0f, -yaw_limit, yaw_limit);
            float controlled_throttle = Mathf.Clamp(throttlePID.Compute(y_axis_setvelocity, y_vel, deltaTime)*5.0f, 0, MaxEngineForce);

            Debug.Log("CThr: " + controlled_throttle + " setpoint: " + y_axis_setvelocity + " vel: " + y_vel);

            engine_mixing(controlled_pitch, controlled_roll, controlled_yaw, controlled_throttle);
        }

One limitation of this hover function is that it is based on the IMU’s orientation rather than the aircraft’s true orientation relative to the engines. This means that if the IMU is mounted with any slight misalignment, the aircraft could shift, even though the software believes it is maintaining a fixed orientation. However, for code validation and testing the PID controller, this implementation worked as intended, as seen in the video below:

Further Development In Progress

The software simulation in Unity has been a success so far, but further enhancements are planned. The next major function to be implemented is position hold, which will add another layer of control on top of the automatic hover. I envision using a complementary filter, where the primary control is based on automatic hovering, while the secondary control corrects translational velocity errors through a PID controller. In theory, if the controller operates at high update frequencies, relying purely on PID with velocity correction would suffice. However, due to real-world hardware limitations and the inherent error introduced by integrating acceleration to compute translational velocity, the hybrid approach—using both gyroscopic angle hold and velocity correction—may prove to be more reliable.

Currently, the scripts in Unity run at a fixed update frequency of 125 Hz (with 100 Hz also yielding visually identical results). This is an important consideration when porting the software to real microcontrollers, where achieving similar update rates or higher will be necessary for stable performance.

To physically implement the PID controller, I designed testing equipment to support code development and hardware integration.

The objective is to achieve PID-controlled balance of a 1-DoF seesaw with an engine mounted at each end, using input from a radio controller to set the desired tilt angle. This setup acts as a simplified tri-copter simulation, offering a crucial verification stage before progressing to more complex development phases.

The testing platform features a single revolute joint supported by two ball bearings. The rotational arm includes mounting plates for electronics, enabling the installation of IMU units and microcontrollers.

The engines are powered by a single LiPo battery connected via a Y-split adapter. At present, there is no dedicated support for the power wires, but future iterations may incorporate wire brackets to minimize resistance and interference with the rotation.

The chosen microcontroller for this project is the Teensy 4.1, selected for its impressive clock speed of 600MHz and the wealth of online resources available for support. The FS-iA6B 6-channel receiver was used to handle input. For the 1-DoF testing platform, this receiver is more than sufficient, as only two channels are necessary (throttle and one axis of control). The receiver converts radio commands into a PWM signal, which is then translated into numerical values through software decoding.

To mitigate the impact of vibrations on IMU data, a passive mechanical damper was developed. Without this damper, the sensor data was rendered unusable, as engine vibrations severely distorted IMU readings, introduced excessive noise, and made differentiation of the data meaningless. This issue initially caused the PID controller to perform poorly.

The addition of the mechanical damper effectively resolved these challenges, ensuring reliable sensor data and enabling effective PID control. Although some vibration still persist, the hardware DLPF can mostly filter them out.

The new SDP (V3) introduces 1-D thrust-vectoring front engines, allowing for yaw control during hover. Building on prior experience, this version maintains a modular design and includes machined brass inserts to enhance precision and durability.

The SDP V3 plays a pivotal role in validating the initial flight control software. It is equipped with nearly all the mechanical features required to thoroughly test hover control functionality.

Three 50mm EDF engines are mounted in an equilateral triangle layout. The front two engines can rotate +-90 degrees around the the local pitch axis, generating yaw moments during hover.

The central frame houses a 4s LiPo battery that also functions as a center of mass adjustment weight. It is secured by lid featuring a standardized mounting pattern for attaching modular components.