Author: Catherine Zheng
Mentors: Joshua Cho, Matthew Anderson
Editor: Jadelynn Dao
Abstract
This project’s overarching goal is to build a scaled-down version of an Autonomous Flying Ambulance (AFA), an emergency vehicle designed to carry patients and medics to nearby healthcare facilities. In the current 4th iteration of the AFA, researchers are developing a new fault-control algorithm that stabilizes the aircraft when one or multiple motors fail. The algorithm is being tested on a simplified, skeletal prototype to mitigate potential hazards and reduce costs associated with the development phase. While the model’s fuselage was already manufactured, the model lacked the electronics required to fly. The project’s primary task is the integration of crucial electronic components into the AFA prototype, requiring design, fabrication, electronic casing, component wiring and management, and rigorous calibration processes.
Both the prototype and the AFA model use a Pixhawk flight controller with ArduPilot and an onboard computer to run the algorithm. The prototype is designed as an eVTOL (electric Vertical Takeoff and Landing) octocopter, whereas the AFA model incorporates dual functionalities of eVTOL and fixed-wing modes. Being an eVTOL/fixed-wing hybrid, the model easily transitions between vertical takeoff/landing and fixed-wing cruise flight, giving the model the benefits of a more controlled takeoff landing while maintaining the energy efficiency of a fixed-winged plane. Compared to the simple eight-motor prototype, the model’s more sophisticated flight modes allow algorithms to be demonstrated on a higher fidelity aircraft, producing more accurate data and results.
Introduction
As city population grows, traffic congestion increasingly impedes emergency vehicles. A study published in the National Library of Medicine in 2007 found that every kilometer (0.62 miles) added on the road to the hospital led to a 2% increase in mortality [1]. The number has only increased in recent years as cities and suburban areas have become more densely populated. As such, alternative transportation methods must be developed for emergency services.
Recent advances in robotics technology have laid the groundwork for creating autonomous flying vehicles, specifically flying ambulances. These autonomous emergency vehicles are designed for short-distance flights in a restricted area, making them easier to implement than a Level-4 self-driving car [2]. Air transportation is notably faster than ground transportation. For example, one of Brazil’s most prominent commercial helicopter services can complete a 2-hour trip in São Paulo, one of the world’s most populous cities, in 15 minutes [2]. In the context of a medical emergency, time saved in this way can decrease mortality rates.
The first iteration of the AFA was a minimalist multi-rotor featuring a wing and tail for rudimentary control development. This initial model had no fuselage and was similar to the AFA test bed. The second and third iterations enhanced this design by introducing an aerodynamic fuselage and articulated wings, incorporating a foam exterior with tilted motors. However, the motors were undersized and were unstable. The fourth (current) iteration incorporated a robust power and propulsion system, a composite structure, and an upgraded patient transport bay. It was also the first iteration to have control surfaces on the wings.
The current iteration focuses on developing an AFA prototype as a test bed for a new fault-control algorithm. The software algorithm will allow the vehicle to continue its preplanned flight path when one or multiple motors have failed, allowing the drone to get from Point A to Point B safely amidst a motor malfunction. Researchers built a 1/5th scale skeletal model as a testbed for the algorithm to mitigate risks and costs associated with testing on full-scale models. While the testbed and the model share the same electrical payload, their aerodynamic designs differ significantly [3]. Figure 1 shows the testbed and the model side by side.
The eVTOL octocopter testbed (Figure 1a) is designed only to test motor failure, and its propulsion forces solely originate from its eight motors. The 1/5th model (Figure 1b) is both a fixed-winged and eVTOL aircraft, with propulsion forces composed of the lift forces from the wings and thrust forces from the motors. Having a multi-propulsion system on the AFA guarantees additional safety for the aircraft [3] and allows for a more sophisticated demonstration of the algorithm.
This project focuses on the electronic hardware and software integration of the 1/5th AFA model. While the model’s fuselage had been previously manufactured, it still lacked the necessary electronics to fly. The project includes sourcing the electronic components, designing the casing and mounts for the electronics, wiring the components together, setting up the onboard computers, and calibrating the sensors. At the end of the SURF period, the electronics have been connected, mounted, and calibrated, with the drone projected to be ready for a second flight test in September.
Future work for the project includes additional flight tests; wiring for the servos for the aileron, elevator, and rudder; and redistributing weight of the electrical components for better aerodynamics.
Methods
The first step in incorporating the electronics was to source the necessary components. Figures 2 and 3 showcase the electrical and software diagrams of the system (for list of parts, see Table 1 in Appendices).
The flight controller collects sensor data from the sensors and radios, and sends the data to the Banana Pi via MAVROS. This Python package converts read-in sensor data into ROS messages, which are then processed by the algorithm developed by the researchers. The algorithm outputs an allocation matrix that is sent back into the flight controller through a separate serial port. The allocation matrix takes the necessary forces (thrust, roll, pitch, yaw) and maps them to the motor speeds on the eight motors, allowing the drone to remain steady during motor failures.
A switch on the telemetry controller is used to simulate a motor failure. When flipped, the flight controller runs a custom Lua script that overrides the nominal controller and artificially fails a motor.
Hardware Integration:
The first step was determining where and how to place the electronics in the aircraft. To do so, electronic trays where the electronics would be mounted were designed. There were three iterations of the electronic tray designs. Each iteration is detailed below, along with the reason for its redesign.
1st Iteration: In the first design, there were two trays for the electronics. The middle tray, which was mounted onto the middle of the fuselage, had two layers. The first layer held the batteries, while the second held electronics for the power, motors, and the onboard computer. The back tray, mounted at the back of the plane, held the communication radios and GPS of the drone. Figure 4 shows the CAD model of the middle tray, and Figure 5 shows the assembled back tray.
The shell of the plane is mostly made of fiberglass, which is dangerous to drill into; it was necessary to find an alternative way to attach the trays to the plane. Hence, a clipper system was developed (see Figure 6).
The inner two panels served as clippers that clipped onto the rims of the fuselage, while the outer panels were mounting walls for the back tray through the holes circled in yellow. The middle tray was then bolted to the black spacer blocks between the inner panels through the four screw holes circled in red. This design was kept for all three iterations.
One oversight of this design was the weight distribution. Figure 7 shows the forces on a fixed-winged aircraft.
Ideally, the center of gravity should be slightly ahead of the lift force. If a gust of wind causes an upwards deflection in the nose’s attitude, the increased lift force due to the wind will bring the plane back to level. On the contrary, when the center of gravity is at or behind the lift force, if the nose pitches upwards, there are no forces to bring the plane back to stability. Hence, the plane must have its center of gravity before its lift force to preserve dynamic stability.
In the first iteration, the payload was centered with the plane’s lift force, while the tail-end of the fuselage caused the center of gravity to be behind the lift force. To move the center of gravity forward, the batteries had to be moved to the front of the plane, creating a need for a third battery tray.
2nd Iteration: In this iteration, the lower level of the middle tray was removed, and a separate battery tray that mounted onto the front of the plane was created. The middle tray was also simplified to a single-layer tray, showcased in the CAD model below.
Moving the batteries to the front improved the weight distribution. However, the plane was expected to be around 12 kg, with 10 kg for fuselage and 2kg for electronics. The fuselage was estimated to weigh 13kg.
To lighten the plane, the ESCs, PDB, and CAN2PWM adaptors were moved onto the plane’s wing. Doing so allowed the removal of 3 14 AWG wires for each ESC-motor pair (24 wires total). These wires connect each ESC to its motor and run from the plane’s roof to the middle board. Moving the ESCs to the wing also freed up space on the middle board for the communication electronics, allowing the removal of the back tray entirely.
3rd Iteration (Final): In an attempt to decrease the plane’s weight, the ESCs and PDBs were moved onto the wing, which resulted in the creation of a new wing tray (see Figure 9), the shortening the connections between the ESCs and motors, and the removal of the back tray entirely (see Figure 10). The resulting weight of the plane was 14.7 kg, resulting in a thrust-to-weight ratio of 1.4. While not ideal, the plane was still able to fly and maneuver as needed. Future work will need to be done to lower the plane’s weight further and implement a more favorable weight distribution.
Software Integration:
In addition to wiring everything according to the electrical diagram, another component of the project was ensuring correct data transmission between components in accordance with the software diagram. This includes ensuring the fight controller receives signals from the receiver, GPS, and telemetry radio, sending and reading data from the onboard computer, and sending correct signals to the correct ESCs.
Mission Planner’s built-in hardware calibration was used to connect the receiver, GPS, and telemetry radio. Aliases were created for the ports so the flight controller and computer know which ports to send and read data from, establishing a connection between the flight controller and the onboard computer. Then, a node in ROS 2 was launched to check that data was being sent and read between the two components.
Mission Planner was also used to spin each motor via its number, ensuring the correct signals were sent to the right motors. Each motor was assigned a number in the code that correlates with its position, which lets the code know how much power to send to each motor. Incorrect assignments could result in testing failures and an unstable aircraft. Figure 11 shows the motor numbering and direction for the model.
The pinouts from the CAN2PWM adapter dictated the motor numbers, while the three-wire connection from the ESCs to the motors decided the motor spin directions. If the motor position does not match its motor numbering, the pins on the CAN2PWM adaptor (to which the motor ESC was connected) can be swapped. On the other hand, if the motor was spinning in the wrong direction, a solder bridge can be created between two pads on the ESC to reverse its direction.
Testing:
During the initial flight test of the AFA prototype, some motors failed to respond to signals from the flight controller, remaining inactive even at full throttle. This indicated a problem in the communication path from the flight controller to the motors. Closer inspection of the wiring revealed loose connections between the custom board and flight controller and the custom board and power supply, leading to a bad power connection between the board and the CAN2PWM adapters and an unstable signal between the CAN2PWM and the flight controller. Some of the motor ESCs were also wrongly configured to receive PWM instead of DSHOT from the flight controller during startup, which was indicated by beeping patterns when the ESCs were powered on. Further debugging showed that when the CAN2PWM is powered on before the flight controller, the ESCs, by default, revert to PWM instead of DSHOT. Removing the startup delay in the flight controller fixed this issue.
After fixing the board and startup order, the model had a successful 8 minutes of flight time (see Fig 12).
Conclusion
In conclusion, the project focusing on the development, hardware integration, and testing of the Autonomous Flying Ambulance (AFA) represents a significant step forward in addressing the critical issue of emergency medical transportation in densely populated urban areas. Through the three redesign processes, the electronics have been mounted, wired, and calibrated with the weight distribution and aerodynamics of the plane in mind. While the initial flight test revealed communication problems between the flight controller and motors, the project saw significant progress toward building a fully functioning 1/5th model. Future work on weight reduction and weight distribution, as well as implementing servo functionalities, will contribute to creating a more dynamic and versatile plane as the AFA project ventures into the future with its potential to reduce emergency response times and improve mortality rates.
Acknowledgements
I’d like to thank Joshua Cho and Matthew Anderson for their guidance and expertise throughout the project, Dr Soon-Jo Chung for the opportunity to work on the AFA model, Britanny Wright for her contributions to the project, Marcella Bonsall for her donation to the SURF program, and my colleagues for an unforgettable summer experience.
References
[1] Eaton L. (2007). Longer ambulance journeys raise mortality in patients with life threatening conditions. BMJ : British Medical Journal, 335(7616), 367. https://doi.org/10.1136/bmj.39316.411759.DB
[2] Autonomous Flying Ambulance and heavy lifting drones. Autonomous Robotics and Control Lab at Caltech. (n.d.). http://aerospacerobotics.caltech.edu/urban-air-mobility-and-autonomous-flying-cars
[3] E. Tang, P. Spieler, M. Anderson, and S.-J. Chung, “Design of the next-generation autonomous flying ambulance,” in AIAA Scitech Forum, January 2021, pp. AIAA 2021–1514.
[4] O’Connell, Michael Thomas (2023) Methods for Robust Learning-Based Control. Dissertation (Ph.D.), California Institute of Technology. doi:10.7907/2xnct162. https://resolver.caltech.edu/CaltechTHESIS:06072023-134620248
Appendices
Caltech Undergraduate Research Journal 