AED Drone Delivery Over Cellular 5G Powered by Indropilot

vid1: AED drone delivery drone tests, both autonomous mode where the drone autonomously flies, delivers, and returns, and the manual mode, where the pilot has the full control using a gamepad with assisted navigation by the autopilot

Introduction

This project aimed to test and benchmark the efficiency and reliability of using drones in a BVLOS (Beyond Visual Line Of Sight) operation to deliver an AED (Automated External Defibrillator) package to patients in need during an emergency. The results were compared to the usual way of dispatching an ambulance or paramedics to the location.

The project system was powered by the Indropilot platform (Refer to the article about Indropilot project for more details) and was an extension to project NERDs (Refer to the article about NERDs project for more details), Although both were separate projects, they overlapped in schedule, hardware, and software, providing a good opportunity to test out the Indropilot drone delivery feature in a real scenario. This project demonstrated the potential for using advanced technology to improve emergency response times and save lives.

Project Requirements

• Drone to deliver the AED package to a specific location
• Drone operated in a BVLOS operation, able to fly for long distances
• Drone will be flying over 5G with a fallback to LTE, including C2 link (command and control), telemetry, and video streams in low latency
• Drone response time must outrun the average response time to dispatch an ambulance
• Drone delivery time of AED package must outperform the average time for an ambulance to reach the location.

Operation Site

Image1: The BVLOS missions, each line represents the approximate flight path, and the longest one is around 7km

The operation site for this project was located in ON, Canada. At least 6 missions were conducted, with the longest mission being a direct flight path of around 7km. Almost all missions shared the same launch site, where the drone was launched automatically as soon as the dispatch signal was received. Simultaneously, an ambulance was also dispatched to the location. The delivery locations were pre-determined, either by manual pinpointing on the drone navigation map or by GPS coordinates, to simulate a real-life scenario where the emergency dispatcher would be given an address for the location. Once the drone reached the location, a winch would be deployed to drop the AED package. The pilot had the option to fly the drone back to the launch site or land in a nearby location if the battery was not full enough.

Client Demo

or the project demonstration, the client conducted extensive tests of the drone in several scenarios beyond what was required. For that purpose, they visited AreaXO facility in Ottawa. The tests were:

• BVLOS test over 5G commercial network
• BVLOS test over 5G private network
• Testing response time all the way to package delivery (for reference, the average response time in Muskoka¹ is 1 min 34 sec; this is the average time from when a 9-1-1 call is answered by a dispatcher until an ambulance is assigned for highest priority calls)
• Test out several scenarios like fail-safe in case of power failure, cellular signal failure, and switching between autonomous mode and manual mode mid-air in case of any emergency where the pilot needs to take control

All of these tests were successful, as shown by the client's response in the video. The drone flew over the cellular network and was ready in less than 30 seconds from a cold start. During the tests, power and signal were shut down to simulate an emergency fail-safe, and the drone flew back to the launch site and landed safely. It is important to note that the power failure simulated was for the SBC component responsible for C2/Telemetry, not for the whole drone including the motors. Otherwise, it would have dropped like a dead fly from the sky :) More about that in Indropilot project.

The client demo was captured in several videos, which are available below. I will try to update these videos with additional footage later if possible, as I was busy flying and operating the demo during the recording. Unfortunately, I do not have a video with a proper angle like the one above. However, the available videos provide a good overview of the client demo and its success.

vid2: AED drone delivery demo with the client, and you can see their happy response!

Hardware

Image2: The drone and the AED package

The project hardware consisted of several components to make a single module, which included the SBC, 5G/LTE modems, flight controller, sensors, FPV cameras, drone airframe, and definitely, the winch. I highly recommend reading about these components in depth in the NERDs project - components section, as this project shares many of these components, design, and architecture except for the SDR and 4K camera.

Hardware block diagram

The block diagram for drone delivery is shown below for both power and signal block diagrams.

Fig1: Power and signal block diagrams for the AED drone delivery project.

Winch component

The project used a winch to deliver the AED package to the ground. While other options might be easier to use, like a parachute to drop the package, TC (Transport Canada, the government entity that regulates drones/RPAS in Canada) prohibits using any parachute system in drones unless it is guided. That would create several extra challenges, so we decided to use a winch for this project.

The hardware -Daiwa Winch² is a high-quality winch specially designed for drone delivery. The winch includes a thread end detector switch that protects against pulling the line in too tightly and thus straining the device or breaking the thread. The gripper includes a spring mechanism that automatically releases the package when it touches the ground.

From the manufacturer site

Drone-mountable to enable delivery of items without the need to land. Cooperative control of multiple units offers a new approach to inspection of buildings and bridges, tasks conventionally regarded as challenging. Enables activities in places inaccessible and beyond the reach of human beings. Using GLOBERIDE’s advanced fishing reel technology, the electric winch offers a high level of safety and enables the performance of delicate work. Opens up possibilities in all kinds of fields including transportation, measurements and recording.

Image3: Daiwa Winch with its hook

Specifications

Fig2: Daiwa Winch Size

You can also read the winch manual here, However, these instructions listed here are under the assumption that the winch will be controlled by an RC controller and connected to a Pixhawk flight controller. This is not the case for this project as one of its requirements is to control both winch (and drone) over the internet -5G/LTE network-, so those instructions listed there will not apply. For that purpose, I designed both hardware and software for the winch driver with the proper integrations needed.

Fig3: Daiwa Winch driver diagram - I am adding my diagram here in case someone would like to utilize design in their build.

(CLICK ME) For reference, the Jetson Nano J41 header as follow:

Fig4: Jetson Nano J41 header - GPIO

Software

For the software part, I made an embedded driver for winch (using Rust language), built API, and made nice little dashboard for all metrics the winch operator might need. All of that was integrated within Indropilot platform that I built during NERDs project (Refer to the article about Indropilot project for more details). Additionally, I integrated a camera view within the dashboard pointing down so as operator you can see package delivered in real-time. Initially, the video feed was through webRTC³, but while it was fast latency wasn't as good as the direct setup I built for FPV. Especially with that setup, it had FEC (Forward Error Correction) to enhance footage (Read about FEC in NERDs project FEC in NERDs project for more details), so had to disable in-browser camera for that project and use NERDs setup for maximum performance and lowest latency.

image4: Winch Dashboard

As you can see, the dashboard provided:

• Selection of the serial port to which the winch is connected (the winch's main interface)
• Winch uptime (the time since it was powered)
• Voltage indicator (useful to know if voltage will drop due to overweight (higher current) or other factors)
• Tension (useful just like the voltage one)
• Throttle (the speed of the winch)
• Motor and controller temperatures, are important to keep under control
• Indicator if the package is at the edge of the winch or not, important to know when to stop the winch or it will cut the string as an emergency
• Duty cycle, aka winch speed; you can control winch speed by moving up and down from that panel
• Clutch button to stop it midair if you wish
• Zero reset to reset parameters
• Arrows to control the direction of movement, up or down
• Reset button
• Downward camera.

The software part will not be covered here; more on that in Indropilot project.

image5: You can see winch module is activated within the platform (green) in "winch controls"

Testing

Testing the project was not an easy task. For one, the winch was designed to be controlled and integrated for RC/Pixhawk boards, not as this project needed. So I had to reverse engineer both control and monitoring protocols to properly integrate it into our platform, both hardware and software segments. Additionally, testing actual functionality was a time-consuming and risky process (more on challenges below) as winch might work as expected for 1-meter string length and then change behavior per manufacturer settings.

Risks And Challenges

If there is a project, there are risks! This project, despite being small in size and technical complexity compared to others and rather an add-on project per se, had many risks and challenges. I can summarize them in bullet points below:

• The project was rather an R&D PoC and not a fully-fledged one. The client wanted that PoC to build a use case for their clients. So there was no proper planning, testing, designing, or even a defined schedule. In fact, the client tried PoC with another team before and it failed, making them more skeptical about investing in budget or schedule.

• The project was introduced during last stage of bigger more complicated projects I was working on, NERDs project and Indropilot project, While this project was less complicated in terms of technicalities, it was far worse in time-consuming:

  • Working with components: The winch lacked technical documentation. Only technical details were what was listed in the manual above; nothing about IO, firmware or similar. I ended up reverse engineering signal protocol, building the driver from scratch and adding it to the platform.
  • Testing: Testing winch was not like testing software or some hardware like servos. You would have to actually place it on the relatively high area to test tension and other metrics (if there's no tension aka weight winch won't work so any test should have dummy weight). While it was partially done during lockdown I had to do that in my house as you see in vid3, Even later there was basically no high surface as high as 20m to test behavior and simulate drone altitude. That means for all driver tests I would need to actually fly the drone! I ended up flying it modifying driver code on the fly -quite literally-, sometimes in -20C while outside keeping an eye on the winch.
  • Flying a drone of that size also meant extra effort and time, from going through pre-flight checklists to calibration that needed at least two individuals to do, as you can see in image6 below, to having a pilot and VO (Visual Observer) at your disposal whenever you changed something in the code, among other tests.

• Logistics were not in a better place either. The global chip shortage during that time, logistics of the winch unit, communication with the Japanese team, and even operation and mission logistics like transporting drones, site surveys, etc.

-Operation risks: In the table below, I tried to collect major risks for such operations, especially when some missions are ~7km flight:

Table1: The major risks and their triggers for Muskoka AED drone delivery operation.

image6: The process of calibrating the drone (Alta X) requires at least two individuals

Conclusion

The successful completion of this project has had a significant impact on both the client and the drone delivery industry. The client was extremely pleased with the results, which demonstrated the potential for using drone technology, cellular (5G), low latency, and reliable communication for beyond-visual-line-of-sight missions in real-life scenarios.

This project serves as a step forward for the drone delivery industry, showcasing the potential for using advanced technology to save lives. The ability to deliver an AED package to a patient in need during an emergency faster than traditional methods such as dispatching an ambulance has the potential to revolutionize emergency response.

In conclusion, this project has demonstrated the power of technology to make a real difference in people's lives. The successful delivery of this project is a testament to the potential for innovation and progress in the drone delivery industry.

Back to top