CovidTestDrone

Introduction

The year is 2021, a year that I am quite sure will be imprinted in our history books. This year and the previous have been unlike any we experienced before; we were struck by a blight that nobody saw coming, a virus that threatened our species. This virus was a testimonial to the power of the world, the dominance of nature over humanity, the fact that we are merely chess pieces played by higher orders in the game of life.

Before the pandemic we were all living our lives, stuck in our routines. But the pandemic managed to change the world’s priorities dramatically. It made us look up and realise that our lives, our existence, is granted by the stability and perfection of this world. We realised that this balance is fragile, and that a disturbance at a global level ripples into our own lives.

The pandemic made us achieve something that can be regarded as very rare these days – unity, the unity of humanity against a common threat. Diplomatic walls were taken down while bridges were being built. Humanity collaborated not to destroy one another, but to help each other. Our priorities changed, from exceling in our lives, to working together against a common threat.

We adapted our work and lives to reflect the changes needed for us to get through the pandemic. We looked outside our bubble and took actions that would not only help ourselves, but the whole world. We created protocols where there were none in place and innovated solutions to new problems that arose.

Science is in the front-line of the pandemic. People are working tirelessly all over the world, finding solutions to the many problems the pandemic introduced. While we are all focusing on the vaccine and frontline workers, there are many working behind closed doors: keeping servers running so we can keep in touch with one another, maintaining law and order in this time of crisis and so on. The truth is that all of us play a significant role in curbing the virus, in creating balance in this world. For that, I want to extend a thank you not only to the frontline workers, but to everyone in the world for going above and beyond to rebuild balance in this fragile world.

One of the innovations that helped us the most in the pandemic, was the release of the COVID test. This was the first step in combatting the virus, allowing us to identify a member of the population that had the virus and take appropriate actions to prevent the virus from spreading from that person.

Over time, we iterated over our protocols for administering tests, each country going about a procedure they deem suitable for testing the population. In Ireland, people can get a free test provided by the government after a GP inspection confirms the presence of symptoms of the virus in the individual. There is also the option to get a private test which must be paid for.

No procedure is perfect: it takes on average 1.3 days to be referred for a testing appointment. There is also a waiting time of about 46 hours to get the results back. But that is only if the patient gets tested because they have symptoms. Contact tracing can take up to 5 days and only after that can a close contact be scheduled for testing.

There have also been cases when people had to wait over a week to get tested. The government provides all people that are awaiting to get tested with an income subsidy while they stay at home in many countries. This adds a lot of expenses for the government, so it is in their interest to keep this waiting time as low as possible.

There are many challenges people face when getting tested: it can be very challenging for people living far from a testing centre to get tested for the virus. They would need a means of transport to get to the testing facility. Many people that live in the city use public transport to get around, it is not a good idea to mix with people, especially when you know that you may have the virus.

Others may be living in rural areas and not have a means of getting to the nearest testing facility or simply may choose not to get tested as it would be too difficult. But even if one owns a car, one may not have someone else that can drive one to a centre and may be too ill to get there themselves.

Then there is the problem of the testing centre; dozens of people congested together, waiting to get tested. While there is strict hygiene in place, I would personally still feel a bit insecure being in the proximity of another person that is getting tested for the virus.

And finally, I must bring up the test itself. After talking to people that had the test, I learned that the experience is not something one would look forward to. Tests should not be a pain to sit through.

I asked myself how testing can be improved. Particularly how access to testing can be made faster and more comfortable. What if there were no waiting time or the need to talk to a GP to get a COVID test? What if you could decide to get tested and get your results back the same day? What if you did not have to wait in queues at a testing centre before getting tested? What if you could get your test done from the comfort of your home? What if administering the swab would be comfortable?

Introducing CovidTestDrone

CovidTestDrone enables self-administered COVID-19 tests to be delivered within minutes to patient’s homes via drone delivery and returned to the lab to be analysed. There is no need for patients to leave their homes nor get into contact with other individuals to get tested. Tests can be provided on-demand meaning that there is no need to wait to get symptoms checked by a GP in order to get tested. Finally, the tests provided are precise and non-invasive, creating an overall great user experience.

The application is built around a drone delivery system that allows individuals to receive a self-administered lower nasal swab COVID-19 test at home via a drone and then return the sample to the lab via the same drone after administering the swab.

The application consists of two parts: the drone delivery system itself and the assisting applications built around it. These systems will be briefly discussed below with the help of an abstract process diagram.

For the purpose of this walk-through, the solution will be implemented by a private company. The first step in the process is the purchase of a test. In a private company model, the test will be sold to individuals online. The consumer can purchase the test via the provider’s website and then input their details (address, phone number, etc.). The consumer will then be required to select a time when the test can be shipped to them.

The consumer will then be introduced in the provider’s database. The confirmation stage involves the company introducing the consumer in their consumer messaging client and sending them a confirmation text to let them know that their order was placed and confirm the details with them.

The provider will also send out another text a day and an hour before the shipment respectively to remind the consumer of the shipping. The consumer can reply to these automated messages at any time to be connected with a support employee.

The next step is shipping the test kit. This is where the drone comes in. The drone base is an NXP Hovergames Drone Kit. This is a reference kit that is highly customisable, easy to assemble and maintain, and runs on Dronecode firmware allowing for advanced autopilot deliveries to be executed.

The drone can be monitored live at the base by the workforce through the use of QGroundControl. This is an open source application used to plan routes for drones to execute and monitor them during flight. This means that the exact location, pitch, yaw and roll, and compass readings along with all other onboard sensor readings can be monitored remotely, in real time through QGroundControl.

The drone can also be controlled remotely via QGroundControl: commands can be given to the drone if for example it has to return or if there has been a change in the flight plan. This allows full control over the functionality of the drone remotely if an unexpected occurrence happened.

The drone will stream live footage back to the basestation via the NavQ onboard computer. This device will stream a video feed from a camera mounted on the drone live to the QGroundControl application.

The drone has been customised to carry a COVID-19 self-administered testing kit with it. Self-administered tests are lower nasal swabs and non-invasive, meaning that they are a gentle swab and do not require to be pushed hard in the nose and mouth like traditional swabs. A container has been attached to the drone to securely ship the test in a climatically controlled environment. There are specific guidelines for the transport of specimens to ensure that they do not get damaged; according to the CDC, samples must be shipped to the lab for analysis within 72 hours. During this time, they must be stored between 2-8 degrees Celsius on dry ice.

This shipping container has been designed to ship tests with these shipping conditions in mind to ensure the maximum accuracy of the tests. I built this shipping solution from scratch to ensure its perfect integration with the system.

The container has a locking mechanism that requires the consumer to input a PIN to open the container and extract the test. This ensures that only authorised individuals have access to the test kit and specimen. The device is also equipped with a helpful LED to indicate if the container is locked or unlocked and signalise any errors with the shipment.

The device uses GSM connectivity to transmit key data back to the base. The device gathers information such as its geolocation, as well as if the container is open or closed. This data is reported to an online dashboard which can be accessed from the base. Operators can also control the container remotely via the dashboard – the unlock PIN can be changed and the container can be locked and unlocked together with other functions.

The container is also equipped with a variety of sensors that collect crucial data while in operation and report it live to the backend. The device is equipped with a temperature and humidity sensor allowing the temperature and humidity of the container to be streamed live to the backend ensuring that the kit is held in appropriate conditions.

The container is also equipped with an IR breakbeam sensor which checks if the test kit is in the container and reports this live to the backend. This allows the operator to always know if the test kit is in the container.

The drone will be loaded with a test at the hospital or base station, a route for the drone to get to its destination will be planned using QGroundControl and the drone will then be instructed to take off. When the drone lands, the provider will inform the consumer where the drone landed (e.g. back yard) and will provide the PIN to open the container via the messaging client.

The consumer will then open the container and extract the test. They will then go indoors to administer the swab and place it back in the box according to the guidelines provided. The consumer can let the operator know that the container was put back in the drone and that it is ready to take off. The operator checks to make sure that the container is locked through the dashboard and that the test kit is in the container and then instructs the drone to return to base/deliver tests directly to a laboratory (if in range).

The PIN is provided to the individual in charge of handling the test. If the drone returned to base, the operator would open the container and ship the test to a laboratory. If the drone returned to the lab, the container would be opened, and the sample would be analysed there. The drone can take off from the lab after the sample was extracted and return to base, thus completing a journey.

Market Research

This section will delve into the business and research aspects of the project. It will outline use cases and will analyse the product’s place in the market if it were developed and launched. This section will also delve into finances regarding the development and operation of the project.

Use Case: Developed Countries

The main focus of the project is to provide the population with a rapid and innovative solution to getting tested for COVID-19. In our busy lives, we are all looking for the easiest way to get things done.

COVID-19 testing is not an experience that we look forward to. Besides the fact that we fear for the result of the test to be positive, we also fear the procedure of getting tested. Getting a swab stuck up one’s nose is not a comfortable experience. An account on Medium describes it as “having your brain tickled, or, alternatively, stabbed”.

Some of us may find it difficult to get to the test centre in the first place, maybe we lack a means of transport or there is not a centre located nearby. There is also the problem of time, we want to get our results back as soon as possible so that we can return to our routines. But it may take days to get an appointment at a testing centre in the first place.

CovidTestDrone was designed to resolve all these issues by shipping tests to consumers via drone delivery. This system uses self-administered tests which do not require the nasopharynx probed. In other words, the swab can collect a sample by swabbing the lower area of the nostril and the tongue gently. This test, when administered properly, can offer as much precision as invasive tests.

By delivering the test to the consumer, the consumer does not need to expose themselves to the public and potentially infect others. It is also more comfortable for the test to be administered at home as the patient does not need to stress about getting to the testing centre and back.

Finally, more healthcare workers can focus on treating cases of COVID-19 in the hospital as opposed to testing the population for the virus. This adds efficiency to the system.

The product would be targeted at people of any age. The service will be geared towards people in the middle, upper middle and higher economic backgrounds if it is supplied privately. The test will be priced in line with other private solutions that offer quick results which range between 180 to 250 euro (Ireland).

The location of the individual is very important in the case of this project. The drones can only operate 2 to 3 kilometres away from base. Hence, only a zone with a diameter of 6 kilometres can be served by one implementation. Of course, multiple bases can be constructed to cover more areas.

It is important that the individuals who purchase the test have a place for the drone to land. This would ideally be a garden or a back yard.

Use Case: Developing Countries

While developing the project, I kept hearing about the challenges facing testing in developing countries. Countries like India and Bangladesh were facing significant issues supplying tests at the start of the pandemic. Bangladesh has recently created a testing kit that has a final cost of only $3 but with questionable accuracy.

The problem in developing countries is getting testing kits to remote cities and villages. Bangladesh, as of writing this article, has a testing rate of 18, 167 per million people. This is compared to 712, 544 in England. This clearly indicates that there are not enough tests being carried out. This is due to the challenges faced getting tests to the people.

The drone can be modified for use on a larger scale in developing countries; the drone can ship quantities of 20 to 50 tests to areas that may not have a test centre nearby. Local authorities can administer the non-invasive swabs and then package the tests back in the drone. The drone can then fly the tests back to the lab to get tested. Results can then be sent back digitally or via post.

Only 2% of Bangladesh’s population report having a car. In these conditions, getting to a testing centre miles away can be simply impossible for a person with COVID-19 symptoms. Developing countries can also be confronted with a lack of hygiene and social distancing in testing centres.

Tests can be provided for free as part of a humanitarian project in the region or by the government. This way, people that would not have had access to testing can now get tested for the virus.

The target market in developing countries consists of people living in an area which does not have a testing centre or that live too far away from the centre and have no means of travelling there safely. Tests can be delivered in larger quantities to remote places and then returned for testing using a drone.

The Product in the Marketplace

As previously mentioned, the product can be provided by both private companies and the government. The difference in approach will be detailed in this section.

If the product is implemented as part of a government scheme, it would make sense to restrict the areas where the product is provided to suburbs outside the primate city where access to testing may be limited or difficult to arrange.

Alternatively, the service could be provided in busy neighbourhoods throughout the country where there is a high demand for testing in order to reduce the stress on healthcare workers and hospital infrastructure.

The service can be provided for free or the state could cover the cost of the test and the cost of its analysis while the individual pays for the transportation costs. The system can scale adequately to whatever demand there may be.

However, I predict that the product would be preferred by private companies. This is because they may have bigger budgets for investing in such solutions and may be more open to exploring innovative services. In this model, all costs would be supported by the consumer. The consumer would pay for the service online and then receive the test and send it back for analysis.

A laboratory is needed to analyse the specimen for COVID-19. If the company is operating with a few drones in a limited area, a contract can be signed with a private lab in the area to analyse tests. Under this model, the drone can be programmed to fly the specimen to the lab (after collecting it from the user) and then fly back to base after the specimen was extracted.

Alternatively, the drone can fly back to base and the test can be posted to the lab. I would personally recommend the first option as this is faster and safer provided a lab is in range. If larger areas are catered to using a lot of drones, it may be ideal to also have a testing lab at the base. This is perfect for high testing demand and can dramatically reduce the time it takes to get the results back.

Drone Cost Analysis

This section will walk through the cost of all components needed for the drone as well as maintenance costs. The table below breaks up the costs of constructing one drone. All costs including production are included for both the drone itself, the container as well as the Nav-Q module.

As can be seen, the total cost per unit is around €955. Below is a cost analysis of the maintenance costs per drone.

As shown above, IoT costs for communicating with the backend amount to around €20 a month per drone. This was calculated considering the device being online for 8 hours a day, 6 days a week. Repairs and replacements average to around €40 a month.

Case Study: Product Deployment in Dun Laoghaire

I created a case study to simulate the deployment of the product in the Dalkey-Killiney area in Dublin, Ireland. This includes the following municipalities:

• Dun Laoghaire
• Dalkey
• Killiney
• Cabinteely
• Sandycove

The total population in this area is estimated to be around 61, 000. This area was chosen due to most people fitting in the target market of a developed country. The area is also within range of the drone. The predominant housing type in this area is detached and semi-detached which means that there is room for the drone to land.

The table above shows all the expenses and profits generated by the product over the period of one month as well as capital expenses needed to set the business up in this area.

As can be seen, capital expenses amount to around €29, 000. This includes the purchase of 4 drones (each drone operating 8 hours a day with 1 test cycle complete every hour for a month to cover the population). An office has to also be arranged as the base of operations, this should be a small, 1 or 2 room office. IT equipment including computers needed to operate the drones remotely, a strong antenna and charging stations for the batteries are included in the analysis.

There are numerous current expenses that have been calculated on a monthly basis. Rent for the premises is estimated at €2, 000, in line with average office prices in the area. Drone maintenance is estimated at €160 a month and operation costs at €80 a month. Electricity and other office expenses amount to about €3, 000 a month.

COVID-19 tests should be purchased from suppliers in large quantities either on a monthly or semesterly basis. I estimated the cost to be around €10 a test kit (including packaging) which is what many companies offer when purchasing in bulk. Because the project is not implemented on a large scale, I included a partnership with a private testing lab in the area that can test a specimen provided and return the result for €15 a sample.

Wages for 4 employees that are needed for various tasks are also included at around €14, 000 in total.

Income has been projected at 3 different points. The first (tests delivered at 100% capacity) shows the maximum amount of income that can be generated with the system online 8 hours a day, 6 days a week (this assumes that one test is delivered per drone per hour).

The tests delivered at the 100% market share category shows the income generated if everyone who had gotten tested were tested using CovidTestDrone (average testing rate in Ireland is around 15 people per 1000).

The final category shows the profits generated by the business if it sells to 40% of the market. This is around the predicted market share in the area.

The graph above analyses the profit made by the business over time. As can be seen from the graph, the initial investment should be covered by the profits generated in the second month. From then on, the profits will increase reaching about €300, 000 in a year.

Please note that this business is time-sensitive and can only operate over the duration of the pandemic while tests are in demand.

Please note that these are estimates and do not consider the fluctuation of infections and hence demand over time.

Pricing Strategy

The product is geared towards the premium market. This is done for multiple reasons. Primarily, the service provided, drone delivery, is novel in the field and a premium feature unique to CovidTestDrone. It would undermine the market for the test to be cheaper than other competitor options considering this premium feature.

The second justification for a premium pricing plan is to ensure that demand does not excel supply. The system works best when implemented on a lower scale, hence, if the demand for the product sky-rocketed, it would take longer for the consumers to receive their results. This would in turn blight the reputation of the implementation.

Consumer Opinion

I analysed consumer’s reactions to multiple aspects of the project over the course of conducting it. The general census online is that people would rather get tested from the comfort of their home than be tested away provided the test result is as accurate.

By analysing Google Trends, one can deduce that there is a relatively high demand for self-administered COVID tests. Ireland ranks the 4thcountry with most demand for the phrase “covid home test”. This shows that people are interested in this market.

By analysing Google Trends again for the phrase “drone delivery”, we can see that there is a very high search rate for this phrase with Ireland ranking second globally. This shows that people are interested in the concept of drone delivery and would like to try it out themselves.

Together this data shows that people are interested in the product and have a demand for it.

Competitor Analysis

There are two categories of competitors; government issued tests and private companies providing self-administered tests. The table below shows the services offered by each solution.

As can be seen in the table above, there are multiple services provided by the different types of competitors. There are numerous services listed, each competitor has a tick if the service listed is provided by their solution.

One can see that traditionally administered tests lack speed and are done at a test centre. Traditional self-administered tests don’t offer secure shipping and fast results.

Weaknesses

No system in the world is perfect, including CovidTestDrone. There is one main challenge that CovidTestDrone faces – weather. Being a medium weight drone, it cannot resist strong winds while flying. The device is also not waterproof so flying the drone in rain can cause it to break.

Another potential issue is obstacle avoidance. The device needs to be able to avoid obstacles while flying. I did not manage to implement this aspect of the project but details on implementation, costs and benefits are found in the Future Envisions section.

Unique Selling Points and Strengths

The device’s USPs are summarised in this section:

• Rapid shipping time – less than half an hour to and from consumer
• Secure shipping – the test is shipped in recommended conditions in a special container
• Ease of ordering test – the test can be ordered with ease online
• Non-invasive, lower nasal swab – comfortable swabbing experience
• Test administered at home – no need to go anywhere, no need to be in contact with anyone
• Rapid results – results can be received as soon as the day the test was administered

Application In-Depth

This section will walk through the technical aspect of the drone application and all assisting applications. The solution can be split into two types of applications – frontend and backend apps. The frontend refers to the drone system that delivers test kits. The backend encompasses digital assisting applications such as the IoT Central dashboard.

The Drone

I bought a drone development kit that included all the components and materials necessary to put together a customisable drone. I assembled this drone and used open-source firmware to run on it. This provided me with a starting point for developing the solution.

Reference Kit

To create the project, I chose to use the NXP Hovergames drone kit. This is a kit developed by NXP that provides the user with all contents needed to build a robust and modular drone. The drone is powered by a flight management unit (FMU) – the RDDRONE-FMUK66. This FMU runs on PX4 firmware.

The kit also contains all the hardware (sensors, motors, etc.) as well as the parts needed to construct a fully operational drone. The drone uses MavLink to communicate to a base computer while the drone is flying, this allows the drone to be managed via the base.

I chose to use this solution because of its rapid development cycle meaning that it can be mass produced with ease and all components are provided

open source

meaning that there is no need to pay licencing and patenting. I also liked the modularity provided by the kit – the drone is very adaptable and can be configured based on the requirements of the system, it essentially offers a great starting point for custom drone solutions.

The drone also runs PX4 autopilot which allows for complex autopilot missions to be sent to the drone for execution, this enables the drone to fly autonomously while delivering tests. The use of MavLink and QGroundControl also enable the device to be monitored and adjusted while it is flying adding extra safety and control over the application.

Dronecode PX4 Firmware

As previously mentioned, the drone runs using PX4, open-source firmware. This can be regarded as the operating system of the FMU. The drone ships without any firmware installed and expects a bootloader to be flashed to operate. The PX4 bootloader is open-source and available on GitHub.

The firmware is the code run by the FMU on the drone. This is the software used to interface all the sensors and motors on the device as well as communications and GPS. PX4 is very modular and officially supports the FMU on the drone. This ensures stable operation. PX4 is managed by Dronecode which is a leader in drone systems.

Communication

A crucial aspect of the drone implementation is its ability to be monitored during flight. This ensures that its operation is optimal, and action can be taken if the drone is experiencing issues. The drone is equipped with both a telemetry radio transceiver and a radio controller.

These devices are used for different purposes. The telemetry radio transceiver is used to communicate with the base while the drone is in flight. This radio has a range of 2 to 3 kilometres when equipped with powerful antennae. One telemetry radio is placed on the drone while the other is connected to a computer running QGroundControl at the base. The drone uses the MavLink protocol to report its geolocation, yaw, pitch and roll, and other sensor readings to QGroundControl over the radios as well as its mission status. This system is used for monitoring the drone while flying autonomously.

The drone is also equipped with a radio controller with a range of about 250 metres. The drone can be manually controlled via the radio controller. This will not be used in this project as the drone will only fly autonomously.

Range of Drone

The drone does have a limited range as it uses radio technology to communicate with the base. The range of the drone is depicted by the range of the telemetry transceiver, this means that the drone has a range of 2 to 3 kilometres.

It is crucial that the drone always stays in range for it to be monitored from base. Note that the base uploads all flight data at the start of the flight and not during flight, hence, if the drone were to go out of range, it would continue its flight plan unless a failsafe was implemented.

The problem is that a new flight plan must be uploaded to the drone remotely once it is ready to take off from the consumer’s home with the test, so if the drone is out of range, the flight plan cannot be uploaded.

The range can be extended by changing the transceiver modules with more powerful ones. Though it is important to note that the battery life of the drone must also be considered.

Flight Modes and Failsafe

Dronecode PX4 comes with a lot of flight modes. The flight mode can be changed via QGroundControl. These are split into two categories: autonomous and manual. The project uses a single flight mode – mission flight mode.

Mission mode allows to prepare a flight plan that the drone will execute by dropping pins (waypoints) on a map in QGroundControl. The drone will go from one waypoint to the next until it reaches the last one. Here, the drone can be programmed to land or return to base.

In the case of CovidTestDrone, when the consumer purchases a test, they must mention where the drone should land, a person oversees planning routes to people’s homes at the base, he/she must analyse the landscape and plan a route and altitude to get to the home. They must then identify the landing spot and ensure it is adequate for the landing. Certain obstacles can be evaded by adding waypoints around them or changing the flight altitude.

After the plan is complete, it can be uploaded to the drone using the radio transceivers. The drone will receive the plan and store it locally. The operator can then arm the drone via QGroundControl. The drone will then take off and execute the plan autonomously. It can also be monitored on a map on QGroundControl.

There are a multitude of fail-safes that can be implemented on the drone. These are predefined actions that the drone will take in case an error arises. For example, a failsafe can be implemented that makes the drone return to base or land if the battery is too low to finish the mission.

Components on the Drone

The drone is equipped with many sensors and actuators needed for flight. All these components are listed below.

• GPS
• ESC encoders and motors
• Accelerometer
• Magnetometer
• Gyroscope
• Compass

A GPS module is essential for executing missions. The device connects to multiple GPS satellites to receive its geolocation. This is used to navigate in 3d space while running the flight plan.

The other sensors are used to measure the pitch, yaw, and roll of the drone. These are used to stabilise the drone during flight and ensure it is always level with the ground. All of this is done autonomously by the FMU while the drone is flying.

The FMU will also adjust the motors which are operated using ESC encoders. The drone will fly the mission uploaded while counteracting wind and staying on course.

Propellers and Weight

The drone is equipped with plastic propellers. These are 24 centimetres in length. The drone is mainly constructed out of carbon fibre to make it as light as possible while also being durable. With the normal configuration, the drone can carry up to 1 kilogram onboard. The test shipping container weighs 336 grams and the Nav-Q module is very light, so weight is not an issue.

However, if developing the solution for use under the developing countries use case, this may not be enough to carry dozens of tests as the shipping container would have to be bigger. The weight that can be carried can be increased by increasing the length of the arms of the drone and fitting bigger propellers. The drone should be fine with the existing motors as they are very powerful.

The arms are essentially hollow carbon fibre tubes (9mm radius). Larger propellers can be bought online from retailers.

Battery Life

The battery life of the drone is estimated to about 40 minutes of flight and 1 hour of standby before it needs recharging. I am using a 5, 000mAh, 3S, 11.1v battery. Note that all batteries require XT60 connectors.

The battery life is about ideal for one trip to and from the consumer and standby while the consumer is administering the test. I would recommend a battery charging station be implemented at the base to have multiple batteries ready to go. When the drone lands, the battery can be replaced and the used one charged. The battery life can be extended by using a bigger battery, perhaps a 6, 500mAh battery, if need be.

Security

Security is of the utmost importance when dealing with applications such as drones. It is very important that the drone is always safe from unwanted interference. There are multiple security implementations at different levels in the drone.

Firstly, the drone is secured at a hardware level using NXP EdgeLock technology. This chip secures all data stored on the device including sensor readings and flight plans and prevents unauthorised changes to them.

At a higher level, all communications are secured on the drone. Both the telemetry radio transceivers and the radio controller modules are hard paired together. This means that the drone only accepts commands from the paired telemetry radio module. This prevents burner radios to interfere with the drone and no other controllers can connect to it.

The Container

The container is the device that stores the COVID-19 test while the drone is flying. I fully developed this container to ensure that it is perfectly suited for the project. This section walks through the details of the container.

Enclosure Schematics

The enclosure refers to the construction of the container. The container is made up of 4 parts. These parts are visible in the figure above. The enclosure consists of a bottom plate, a side plate, a top plate, and a door.

The inside of the enclosure is split into two parts separated by a plate. One of the sides is designed to hold all the components while the other side holds the test kit. The test kit is accessible via the door which can be opened to access the test container. The container has a series of holes for different components such as the servo, LED, and antenna. There is also a hole for the USB port of the microcontroller.

The enclosure was designed to be either 3D printed, or CNC machined. I used a CNC machine to cut out the different pieces and then glue them together. All design files are open source and available on GitHub. These are ready to be 3D printed.

If producing limited quantities of the solution, it is more efficient to 3D print the enclosure as this saves time and is more precise. But if the product is produced on a large scale, it may be a better idea to CNC cut the pieces and then manually assemble them.

Microprocessor – Arduino MKR GSM 1400

The Arduino MKR GSM 1400 is the microcontroller I chose to use when building the container. The device runs on SAMD architecture and the chipset is provided by ARM. This chip architecture is unique to MKR boards and offers a low power solution that extends the battery life of the device while maintaining high performance.

As with all Arduino devices, the MKR GSM runs code in a linear fashion and not in parallel. This means that task x is executed only after task y is complete. The device has GSM connectivity built-in which makes it a great choice for the project as there is no need to connect external GSM modules, this increases security and reduces the size of the implementation.

The device also has an operating voltage of 3.3 volts which again helps conserve battery life. The device also has a security chip onboard to store authentication keys. All of these features make the board a great choice for the project.

Other Hardware

There are a few other components used in the project. These are listed below and can be seen in the figure above.

• RGB LED
• Antenna
• Servo
• Button
• Logic level converter
• Keypad
• GY-21 Temperature and Humidity Sensor
• Adafruit IR breakbeam Module
• 1, 4.7µF capacitor
• 1, 1kΩ resistor
• 3, 100Ω resistors
• Breadboard and jumper wires

The RGB LED is used to indicate if the container is open or closed to the consumer and operator. The button and keypad are used for authentication and the servo is used to open and close the container.

A logic level converter is needed in the project. This is because the servo needs 5 volts to work and the MKR GSM can only provide 3.3 volts. The servo is provided with 5 volts from the MKR GSM’s 5v pin that connects directly to the power source. The level is then reduced to 3.3v when connecting the servo data pin to the MKR GSM.

Communication

The MKR GSM uses GSM to communicate with the backend. This protocol was used because of its wide availability throughout the world and data transfer speeds. The project uses Hologram as the SIM provider. Hologram is an IoT communications company. They offer a global plan that scales well to tens and hundreds of devices providing connectivity in all countries. Hologram uses existing networks to relay messages and is trusted by companies such as UPS and Kellogg’s.

The MKR GSM is also equipped with GNSS connectivity. This allows it to get its geolocation from cell towers. This data is sent to the backend so that the location of the container can be monitored live. This can be useful if for instance the container separated from the drone, allowing the location of the container to still be found.

Backend Connectivity

The application uses Microsoft Azure IoT Central. This is a comprehensive, industry-leading backend solution for IoT devices provided by Microsoft. IoT Central allows for thousands of devices to stream data to the cloud. This data can then be processed and displayed on dashboards online.

IoT Central allows for bidirectional communication. The IoT device (the container) can send data to the service and receive commands from it. This allows comprehensive monitoring of the container remotely from the base.

The container reports its geolocation and if it is locked or unlocked to the backend together with other sensor readings. The operator can change properties such as the unlock pin and lock and unlock the container remotely from the dashboard.

Security and Authentication

The container has been developed with security in mind. Starting at a lower level, the MKR GSM is equipped with a key store where keys used to authenticate with IoT Central are kept. This prevents hardware attacks from gaining access to these keys.

All communications with the backend are encrypted using the SAS (Shared access signature) protocol provided by Microsoft. This prevents any unauthorised parties from accessing the data. Authentication is done through the Azure IoT Hub DPS (device provisioning service). This ensures that burden devices cannot connect to the backend as they do not have the authentication keys needed.

Azure IoT Central is created by Microsoft and used by thousands of companies and governments around the world for IoT connectivity. This means that bugs are rapidly fixed if they arise and the service benefits from enhanced security offered by Microsoft.

Locking Mechanism

The container has a locking mechanism to ensure that only authorised individuals have access to the test kit inside. It is important that the test is received by the right person. A keypad unlock mechanism is implemented for the container.

The pin can be set via the IoT Central dashboard by the operator. The 6-digit pin will then be sent to the device which will store it securely. To open the container, the individual must press the red button and then input the pin. They have 3 attempts to get the pin right before they will need to restart the process. The pin will be sent to the consumer via a text message. This feature is optional and can be disabled through the backend so that the container can be opened without a pin.

When closing the container, only the red button must be pressed. All these actions are sent back to the dashboard where they can be monitored in real time. An RGB LED has been added to the design for user feedback.

• A red LED indicates that the container is closed
• A green LED indicates that it is open
• A blue LED indicates that the user is interfacing with the device – button pressed, keypad pressed, etc.
• A white LED indicates that the device is in setup

Battery and Power

The device is powered by a power bank through its USB port. This approach was taken to add modularity to the design; the power bank can be easily replaced and recharged when it runs out. An alternative would have been to connect a LiPo battery to the MKR GSM, but this would be difficult to recharge and would not provide 5 volts to the device (which is needed for the servo to work).

I am using a 2, 200mAh power bank. The battery life of the container is about 48 hours with this power bank. The power bank can come with a screen to indicate how much battery is left.

The power bank could be recharged outside operational hours; this would be cheaper and more efficient than needing to replace the battery with a charged one when it runs out.

Advanced Features

As previously mentioned, the container is equipped with a temperature and humidity sensor. The climate in the container must be kept at specific parameters to ensure the integrity of the test kit and specimen collected.

A Gy-21 temperature and humidity sensor was chosen because of its accuracy, price and small footprint making it ideal to fit in the tight space in the container. The microcontroller will collect data from this sensor using the I2C communication protocol at defined intervals of time and send this data to the backend.

The device is also equipped with an IR breakbeam module. This module consists of a transceiver and a receiver. The transceiver emits infrared light in a straight line and the receiver can receive this light. The two components are placed directly in front of each other on either side of the container. If the test kit is placed in the container, the light beam will be interrupted and the receiver will no longer detect any light. This allows the device to detect the presence of the test kit.

It is crucial for the operator to know if the test kit is in the container at all times. For example, the user may forget to place the test kit in the container and lock the container door. In this case, the operator can check on the dashboard and notice that the test kit was not placed in the container.

Code Architecture

The diagram above showcases the container’s code architecture. This section will briefly walk through it. When the button on the container is pressed, the container will check if it is locked or unlocked. If the container is unlocked, the container will be locked and the change will be reported to the backend.

If the container is locked, the device will check if a pin is required to unlock the container. If one is, the device will wait for the user to input the correct pin and then unlock the container. Otherwise, it will unlock the container without a pin.

The device reports its geolocation, temperature, humidity and if the test kit is inside to the backend at a fixed interval of time that can be customised via the dashboard. The device will also check for property changes in the backend such as a change in the pin and reflect these changes locally.

Finally, the device will check if it received any commands from the backend. The backend can send a command to open or close the container which will be executed by the container. The device can be programmed using the C++ language standard. I used VS Code to develop the code. All code is open-source and available on the GitHub repository.

Dimensions of Test Boxes

The COVID test kit that the drone carries is smaller than a typical kit. The dimensions of the box containing the kit are 70mm*70mm*40mm. This is just about right to fit everything in. The swab may traditionally be bigger than the size of the kit. A custom swab that folds in two can be used to save space, this may also be easier to break in half for it to fit in the test tube.

The Nav-Q Onboard Computer

The Nav-Q onboard computer is the device responsible for capturing and streaming footage live from the drone to the operator. The device is equipped with a camera facing the front of the drone.

The Onboard Computer

The Nav-Q is an onboard computer developed by NXP and EMCraft. The device runs on a bearbones linux distro. It is equipped with a quad core processor and 2GB of RAM. The device also comes with a Google Coral Camera which is interfaced in the project to stream video live back to the operator.

The Nav-Q is a great solution due to its minimal footprint and versatile connectivity. It can be easily attached to the drone and requires minimal effort to set up and operate.

Streaming Footage from Drone

Having a live video feed from the drone is of great help when monitoring the drone remotely. It allows the operator to visualise where the drone is going and identify unexpected obstacles in its way.

The operator can even take over manual control of the drone if need be, or make it hover if an unexpected event happens. This allows the operator to manually fly the drone out of danger or change the flight plan to accommodate for the unexpected event. Overall, this makes the drone flight more safe and easier to monitor.

Running the GStreamer Pipeline

The Nav-Q is programmed to run the GStreamer application to capture video live from the camera and stream it live to the operator’s computer running QGroundControl. This way, the video feed is visible together with all the other tools in QGroundConrol.

The Nav-Q will start streaming the video automatically after it connects to the internet. This ensures full autonomy and allows the device to set up and work autonomously after it is plugged in.

Power

The Nav-Q computer is powered by the drone’s onboard battery. This eliminates the need for a separate battery which would increase costs.

Streaming over WiFi and Future Improvements

At present, GStreamer only supports streaming over WiFi to another device on the network. This is clearly not ideal for deployment on the field. A GSM module should be added to the device when deployed on the field and the code should be altered to allow for streaming the video to external sources outside the network.

This could be achieved by streaming the video live to an adequate server and then querying it from the operating computer.

Backend

The operator backend encompasses all assisting applications used by the operators to monitor the progress of the delivery and program the route to get the destination. There are two applications in this category – IoT Central and QGroundControl.

Azure IoT Central

Azure IoT Central is the backend of the container device. The service is offered by Microsoft and allows IoT devices to send data and receive commands via a customisable dashboard. IoT Central allows developers to create an application and then connect devices to it using Azure IoT Hub DPS.

IoT Central would replace a typical server used to store and visualise data online. Providing state of the art security and many features, IoT Central is a perfect choice for the project.

The diagram above illustrates the data communication protocol in IoT Central. The IoT device (the container) establishes a connection to IoT Central via GSM. The device authenticates via SAS (Shared Access Signature) authentication.

After a connection is established, the IoT device will send telemetry data to the backend. These are data points reported by the device to the backend at fixed intervals of time. The following telemetry data is sent:

• Geolocation
• Container open/close
• Geolocation accuracy
• Temperature and humidity
• Presence of test kit

The device will also send its geolocation every time the container is open and closed. This allows the exact location where the container is opened to be monitored via the dashboard. All this data is visualised on a custom dashboard in IoT Central.

Besides telemetry data, there is another type of datapoints called properties. Properties can be normal or twin properties. Normal properties are constant values that do not change. The container will send details such as its IMEI and firmware version to the backend when it boots up. This helps operators identify devices and ensure they are running the correct firmware.

Twin properties are properties that are present in IoT Central and as local variables on the device. These properties can be changed via the dashboard. When a twin property is changed, IoT Central will send a message to the device to let it know the desired value of the variable. The following are twin properties:

• Container Unlock Option (pin unlock or no auth)
• Container Unlock PIN (6 digit pin)
• LED Feedback (if the RGB LED is being used)
• Telemetry send interval (the interval of time when telemetry data is reported to the backend)

All these datapoints can be changed via the settings tab on the dashboard (shown in the figure below). It is very simple for the operator to change these properties remotely.

The container can also be lock and unlock remotely. This is done through the commands tab on the dashboard. The container state is represented by a switch. The operator can toggle this switch to send a command to lock or unlock the container, respectively.

This enables full control over the operation of the container remotely ensuring that if something unexpected were to happen on the field, for example if the consumer does not manage to open the container, action can be taken remotely to solve the issue. This is key to providing an autonomous system.

A global dashboard can be implemented if multiple drones are in operation. This would plot the location of all containers on the same map. This could be used by the operator to monitor all containers at the same time.

QGroundControl

QGroundControl is an application that allows remote interfacing and monitoring of the drone. QGroundControl is ideal because of its seamless integration with PX4 and the MavLink communication protocol. The application is also free to use.

In a nutshell, QGroundControl enables everything from programming missions for the drone to monitoring its flight, battery level, video stream and other parameters. The application works on Windows, Android, and iOS. It is also easy to use and provides an intuitive interface.

The drone connects to the application via the telemetry transceivers. There are two transceivers: the first is connected to the drone and the second to the computer or mobile device running the application. The FMU will interface the onboard transceiver and QGroundControl will interface the other. The drone will continuously broadcast the geolocation and sensor data.

The drone is always shown on a map on the app and the sensor readings are displayed in the upper right corner.

QGroundControl is also used to plan routes for the drone. These are called missions. To plan a mission, the operator can select a take-off location (this can be set to the current location of the drone) and then plot waypoints on the map. The drone will go from one waypoint to another in straight lines and will then change the heading accordingly and/or altitude and proceed to the next waypoint.

Finally, a return waypoint is placed at the destination. This makes the drone land when it reaches its destination. The diagram below walks through the steps to take when planning the route.

This process is repeated when the drone needs to take off from the consumer and return to base/to the lab (if in range). After the route is planned, it can be uploaded to the drone via the transceivers. The operator can then start the mission through QGroundControl.

Security is of utmost importance when operating the drone. As previously mentioned, the telemetry transceivers are hard wired together meaning that once paired, no other transceiver can communicate with the drone or the computer. This adds a level of security against burner transceivers.

Preparing the Product for Deployment

CovidTestDrone was designed with deployment and scalability in mind. I built a fully operational prototype of the project that accomplishes all the tasks it sets out. There are a few steps that must be taken to turn this prototype into a finished product. This section will walk through them.

Open Source

The project and all third-party software are fully open source. This means that all the design documentation, code, and apps (excepting IoT Central) are free to use. Feel free to check out the project’s GitHub repo to see the source code and design files used for the project.

Open source has always been very important to me. I believe that transparency is the key to developing technological products. The open-source standard allows anyone in the world to develop a version of this product with their own resources without needing to worry about legal burdens. In a world ever reliant on technological innovation, open source takes down barriers for creators and innovators and allows them to come up with solutions in record time.

Scalability

The project was designed with scalability at heart. It is essential that the product can scale to tens and hundreds of units without encountering problems. The drone kit chosen is produced by NXP and is relatively cheap compared to other solutions. The container is built with off-the-shelf components meaning that assembly and production is easy and that all components are available in large quantities.

The enclosure of the container can be 3D printed or CNC machined easily with all design files being open source. This reduces the production time and labour required to put everything together. It can be made of acrylic or another filament as desired.

I chose IoT Central especially for its great scalability. It is designed to suit the demand of thousands of companies around the world with secure and stable servers. Their pricing plan scales excellently when compared with other alternatives and the services provided are brilliant.

Overall, the product can be successfully and easily scalable to whatever quantity is needed.

Creating a Custom PCB for the Container

It would be ideal for a custom PCB (printed circuit board) to be designed for the container. I chose to wire everything together on a breadboard in the prototype so I could make changes to the design easily. A PCB is essentially a custom designed circuit board used to solder all components onto. This is done to ensure all components are soldered in place and there is no electrical interference.

Fritzingis a company that has a program which allows for circuit boards to be developed and sent for printing. The circuit board can be returned soldered with all components mounted and ready to go within days. This is a very useful service that I would personally recommend.

Designing an Enclosure for the Nav-Q Module

At present, the Nav-Q module is attached to the top of the drone without being enclosed. This is not ideal for deploying the product in the field as the device could get damaged by natural factors such as rain. An enclosure can be custom designed, and 3D printed for the Nav-Q device.

Designing a Drone or Using an Existing Solution

The drone kit I used is a reference kit. This means that it is designed especially for constructing prototypes. While the drone can be perfectly suited for mass production and implementation, it is recommended to consider whether a custom-built drone would suit better.

For example, a provider may decide that the container should be bigger to accompany larger testing kits or perhaps deliver multiple tests as in the developing countries use case. The provider may choose to keep the components but extend the arms of the drone and change the propellers. The provider may choose to relocate the container to the top of the drone and extend that part of the drone too.

Launching a Website

Evidently, a website must be built to advertise the business to consumers and attract purchases. I designed a mockup of the website to showcase what it would look like. It is of course up to the company providing the product to decide on the website. Overall, the website should accomplish the following goals.

• Advertise the product
• Describe the product
• Describe how to get tested

Setting up a Base Station

A base station must be set up from where the operation can be monitored. This station should be strategically located at the centre of the area of operation that the drone will cover. The drone can only fly 2 to 3 kilometres from base unless altered, hence the operational distance is 2 to 3 kilometres from base.

It would be ideal if a COVID-19 testing lab were in the range of the drone. This way the drone would be able to ship the sample directly to the lab after picking it up, effectively reducing the transport time.

A small workforce should also be employed to manage the operations. Keeping the case study in mind, I would employ a support member that can handle customer queries, an operator which would plan the routes and upload them to the drone, a technician who can take care of repairs needed and prepare the drones for flight, and a manager which can ensure everything is working fine. A freelance accountant can be employed to cut costs.

Drones and IT equipment must be purchased when setting up the business. The base will need computers (one computer with multiple monitors to track the progress of multiple drones in the sky at the same time for the operator and maybe a larger monitor showing the IoT Central dashboard overview with all devices plotted on a map). Battery charging stations should also be used to charge drone batteries, so they are prepared for use.

Improving the Locking Mechanism

Finally, I would suggest improving the locking mechanism used on the container. The lock is made up of the servo locking and unlocking the door of the container by blocking it with a piece of plastic.

The servo is quite strong, and it is difficult to force the lock open, but if someone really wants to open it, they will probably manage breaking it. I would personally recommend a locking mechanism using a traditional door lock. This project on Hackster shows this in action and provides great instructions.

Future Envisions

This section will walk through some ideas I have that I didn’t manage to implement in the project yet and how to add them to the project.

Use drone power supply for container

The container currently uses a power bank for power. This works perfectly but it would be more convenient and practical for the container to use the drone’s power supply. This would mean that there would be no need for a power bank and only one battery would be needed.

To implement this, a power regulator needs to be implemented to step down the voltage of the battery to 5 volts. This should be connected to the power delivery board on the drone and then to the MKR GSM to provide it with power.

Onboard Computer for Obstacle Avoidance

PX4 allows for onboard computers to control the drone. This essentially allows another device connected to the drone via the USB port to send commands to the drone. This can expand the abilities of the drone by adding more sensors and functions that the FMU does not have.

A great implementation of this is through obstacle avoidance. A companion computer with an onboard camera can be used to analyse the terrain ahead of the drone and run machine learning algorithms to detect obstacles such as trees and buildings and their position relative to the drone. The computer can then calculate a heading and/or altitude change needed to avoid the obstacle and send the command to the drone. It will then process the changes needed to return on track and send them to the FMU.

The NavQ computer can be used for this. The device is specially designed for the drone and so it is easy to put together. I would recommend running OpenCV on it. Models for identifying objects like trees and buildings are publicly available open source and ready to go, they may need a little fine tuning considering they were probably not built with drones in mind. The machine learning algorithms and ROS software used to interface with the PX4 FMU need to be integrated together for this implementation to work.

Drone Tracking for Consumer

Another interesting opportunity is to provide the consumer with a means of tracking the exact location of the drone as it is flying to their home. This would improve the user experience and is inspired by Amazon Prime shipping and Domino’s pizza tracker which provide the exact location of the package as it is being delivered to the consumer.

The easiest way to do this is by creating a data pipeline to export data live from IoT Central to Power Bi (a dashboard service provided by Microsoft). A dashboard can be created to display the location of the package live. This dashboard can be shared with the consumer with a temporary link. This will allow them to view the location of the drone for a limited period of time. A tutorial for doing this can be found here.

Develop Application for Autonomous Route Planning

Another idea is to develop an application that autonomously plans the route to the consumer’s home for the drone. This would consider the elevation at different stages of the journey as well as any buildings that are in the way. It will then set waypoints to avoid these obstacles and save this as a flight plan which can then be uploaded into QGroundControl.

This would save a lot of time spent by the human workforce on planning the route of the drone and would also assure that the route planned is viable. This data can be accessed through Google Maps or Bing Maps APIs.

The application would first draw a straight path from the base to the destination and check the altitude and large obstacles such as tall buildings and mountains in the way. The app will then add waypoints to change the altitude and/or the heading at different points to avoid these obstacles. The app would then create a flight plan which can be uploaded into QGroundControl.

Testing

Extensive testing was conducted to ensure that the systems on the drone function adequately. Testing was conducted in three phases. I first tested the container and NavQ modules separately. This test involved streaming video from the NavQ for one hour and a half and leaving the container on and connected to IoT Central for six hours.

During this time, I opened and closed the container by using the PIN and remotely, as well as changing the settings remotely to identify any potential bugs. Several bugs were discovered and fixed during this process.

I then moved on to testing the drone and QGroundControl thoroughly. I went to a local park and planned out missions for the drone to execute via QGroundControl and then monitored the drone as it executed them. I also flew the drone manually. This helped me ensure that the drone is operating adequately.

Finally, I mounted the container and the Nav-Q modules on the drone and tested the solution as a whole. I did this by simulating a scaled version of the flight plan the drone would have to take to deliver the test to and from the patient.

I opened the container and placed a mock test kit inside and then closed the container. I then planned the route the drone should take and then let the drone take off, fly to the destination, and then land. I connected the drone and my laptop to a mobile hotspot and monitored the parameters and video feed during flight.

When the drone landed, I opened the container, extracted the test, put it back, armed the drone and then uploaded the flight plan to get the drone back to base. I repeated this a couple of times.

The only problem I had was with the range on my radio transceivers. They seemed to disconnect when the drone was more than around 15 metres away. The drone would nevertheless finish its flight plan successfully. I repeated this a couple of times on multiple days.

Constructing the Project

This section will walk through constructing the project and provide a guide encompassing all the steps needed to fully build the prototype. I split this guide into 3 separate sections covering the drone, the container and finally the Nav-Q.

Constructing the Drone

This subsection will give an overview of the steps needed to get the drone kit up and running. Most of it will be links to external guides from NXP.

Step 1: Buying the Drone Kit

The drone kit can be purchased from the NXP website at this link. The kit includes all components needed to assemble the drone together with a tool kit to help you get going. Start off by buying the kit.

Note that you will also have to buy a radio transceiver set adequate to your region, this can be purchased together with the drone on NXP's website. You will also have to buy a battery as this does not ship together with the drone. It is recommended that you buy a 5, 000mAh, 3S, 11.1v battery with an XT60 connector.

Step 2: Assemblingthe Drone

After your receive the kit, you can start putting everything together. NXP has a great series of videos and articles that detail assembling the drone. This guides you through putting the drone together in a few hours. Check them out here.

Step 3: FinishingSetup

After you finished building the drone, it's time to get everything connected and ready to go. There are numerous articles that have to be followed to get the drone ready to fly. I linked these below. Make sure to go through all of them.

• Setting up the Radio Controllers
• Programming FMUK66 for first use
• PX4 configuration using QGroundControl

Please ensure that you also follow the guides on the subpages and follow any external link provided to ensure everything is ready to go.

Step 4: Test Flight

Now that everything is ready, you can move on to testing the drone. Please refer to this guide provided by NXP detailing what should be done preflight, during flight and after flight.

After you finished the preflight checks and are ready to go, make sure you check out drone flying regulations in your area. I have personally being stopped from flying drones in multiple parks and other areas. Make sure you're flying the drone in an open area with minimal obstacles and stuff like cars that you could end up destroying. More cautions and stuff to ensure are listed in the guide linked above.

Once you're ready to go, make sure you bring your computer outside with you so you can connect the drone up to QGroundControl. Connect the drone to the battery, connect the telemetry transceiver to your computer, turn the radio controller on, and get flying.

I personally tested the manual flight mode first by flying the drone in position flight mode (flight modes here). After getting used to the controls, I started playing around with QGroundControl. I started getting the drone to take off and land via QGroundControl and then sending simple missions for it to execute.

There really is a lot you can do, I would read the Hovergames GitBook in detail and then scroll through the Dronecode website to get a taster of all the flight modes and options you can tune.

As a general rule of thumb, don't fly the drone higher than 4 meters when starting off and keep it well within your line of sight. If something goes wrong or unexpected, put it in land mode (I would customise a switch on the controller to land the drone). If it starts going mad, kill it immediately. It's better to deal with the damage to the drone than the damage it could do to you.

There are a couple of issues you could get yourself into. I for one mounted the motors wrong and the drone would essentially shoot propellers at me. This helpful troubleshooting guide from NXP covers a lot of problems. If you can't find it there, the Hovergames Discussion forum on Hackster is the place to go. It's most likely that someone had the problem before you and found a fix for it.

Enjoy flying.

Constructing the Container

After you're familiar with the drone, it's time to move on to the container. This is the part of the project that carries the test kits. This section will walk through building it.

Step 1: Getting the Components

Unlike with the drone kit, the components for the container cannot be found in a kit and have to be bought separately. All the components can be bought off the shelf at different retailers. A list together with links to get these components are found in the Things Used in this Project section above.

Step 2: Connecting the Circuit

After you have all the components, it's time to put them together. Start off by connecting the antenna to your MKR GSM and then inserting your Hologram SIM card in the slot below the device.

After you have the MKR GSM ready, move on with connecting the other components to the device. You may choose to do this using a breadboard as I did or soldering the components together.

Ensure the servo is connected to the MKR GSM via the logic level converter appropriately. Great, now we will move on with the backend.

Step 3: Preparing Hologram IoT

The next thing we need to do is register the SIM card we are using with Hologram and get our account set up. You can follow this guide to get this done. The process is quite straightforward. Note that you will have to input your credit card details to pay for using the SIM card.

Make sure you add a balance to your account of at least €2 before continuing.

Step 4: Preparing IoT Central

Before we can move on, ensure you have a Microsoft account and a Microsoft Azure account. Click the links to create your free accounts if required. Ok, now that you're ready, go to apps.azureiotcentral.com/myapps.

When you reached the page, you may be asked to sign into your account. Ensure you sign in with the Microsoft Azure account created. You will see a button in the top left of the screen saying "New App". Click this button to create a new application.

You will be greeted with an interface similar to this. Input a name for your application and ensure that Standard 2 is selected for the pricing plan (it's free for 2 devices). Select your subscription and make sure to select the region you're in. Now click Create.

And that's it, your app is ready for configuration. We will do that in the next step.

Step 5: Setting up the device Template

Before we move on, please make sure to clone the project's GitHub repo to your machine. Navigate to the /iotcentral folder where you will find a JSON file. You will need this file for this stage.

Start off by navigating to the Device Templates tab from the menu on the left of the screen. Create a Device template by pressing the button on the page. On the next screen, select IoT Device and click Next.

Click on Import a Model on the next screen, upload the JSON file from the GitHub repo. This essentially keeps a list of all variables the device will send and receive from the backend.

You should see the menu on the left populating. The next thing to do is to go into the Customize tab. This allows you to set nicknames for different property states. For example, the device will represent the presence of the test kit inside the container through the boolean Test Kit Presnce. If we expand it from the list, we can change the value displayed if the variable is true or false like in the image below.

This is not necessary but does improve the UX. Finally, click on the Publish button from the top of the page to publish the template. That's that done.

Step 6: Creating a Device

We are nearly there. Now we need to create a device in the backend. Firstly, navigate to the Devices tab from the menu on the left of the screen.

Now click on Create a Device. In the dialog box, give the device a name (avoid using spaces) and select the device template we just created. Click on Create.

Step 7: Preparingthe Container Code

Let's get back to the frontend for a minute. Locate the /container folder in the GitHub repo. This contains all the code we will be running on the MKR GSM. Before we go any further, open the code either in the Arduino IDE or VS Code if you have the Arduino extension.

Firstly, make sure you install the Arduino Devices needed to operate the MKR GSM. A guide is provided here. Install the Arduino SAMD package to continue. Allow the installation of all drivers when requested.

The code relies on a bunch of libraries you will need to get. These are listed below. If you are not familiar with installing libraries, this guide walks you through the process. Some of the libraries are available directly through the Arduino Library Manager.

• Keypad
• Servo
• SparkFunHTU21D
• MKRGSM
• Arduino_MKRENV
• RTCZero
• PubSubClient
• ArduinoHttpClient

After all the libraries were successfully installed, compile the code. If the code compiles without any errors, you are ready to go. If you get an error, read through the message given. Arduino error messages are quite good so you should be able to get to the problem. If you need help, feel free to comment it on this project and I will do my best to assist you.

Step 8: Adding Authentication

Now that everything is more or less in place, we need to add our authentication tokens in the code so the device can connect to the backend. Start off by navigating to your device in IoT Central.

Click on the device and then select the Connect button from the top right of the screen. You will see a pop-up appear with credentials that will be used to authenticate the device's connection.

We are interested in the first two values: the ID scope and Device ID. Open the /container folder from the project's GitHub repo and navigate to /container/configure.h. This file keeps all the keys and settings as well as global variables the project uses.

The file should look something like this. We are interested in lines 15 to 17. These hold the credentials used to connect to the backend. Copy the ID scope field from IoT Central and paste it in the iotc_scopeId[] definition. Then copy the Device ID into the iotc_modelId[] definition. It should look something like in the image below.

Now we need to get the enrollment key for the device. In IoT Central, navigate to the Administration tab from the bottom of the menu on the left of the screen. Click on Device Connection from the next menu. You should be here.

Now click on the SAS-IoT-Devices option from the list that appears. In the next window, copy the Primary Key into the iotc_enrollmentKey[] definition.

And that's it! We have all the variables we need to connect.

Step 9: Flashing and Troubleshooting

We are now ready to flash the code to the MKR GSM. To do this, connect it to your computer via a micro-B to A cable and open the code in the Arduino IDE or VS Code. Ensure the right port is selected and the MKR GSM device is also available. Flash the code to the device and open the serial monitor.

The device will set up its GSM connection and will then get the time from a server. It will then lock onto its location and start connecting to IoT Central. The debug is very simple and clear, so you can keep track of this along the way.

So ideally, your device should be connected to the backend now. If the authentication succeeded, the device will sync its twin properties and start streaming telemetry data to the backend.

But there is a chance that you encountered an error along the way. Here are some errors and quick fixes.

• Not connecting to GSM Network - if you are using a SIM provider other than Hologram, you may need to input your APN data and your PIN number. Add this data to respective variables in /container/configure.h. Also, make sure you're close to a window when connecting.
• Not Getting the Time or getting the wrong time - if you are not receiving a timestamp from the server, try looking for another time server you could use or use GPST alternatively. If the timestamp is offset by a matter of hours, you can adjust this through the timeZone variable in /container/configure.h.
• Failed to connect to IoT Central (rc-2, rc-5 errors) - these errors are caused by IoT Central refusing to sign the connection certificate of the device. There are two things to check here: firstly ensure the timestamp is correct. The MKR GSM will print this out in the console at different stages. Secondly, double check your credentials to make sure everything check out.
• Weird data, components not working - ensure the wiring is correct. Please be careful with this as there is voltage regulation involved and connecting components incorrectly can damage the MKR GSM and the respective components.

Finally, there are several places you can check if data is being sent. Firstly, check in the console. The data points collected will be printed out in a JSON format when they are collected. If data is printed out here, you will know that the device successfully collected data locally.

The next place you can check is your Hologram Dashboard. If your device is sending data via the cellular network, pings will be visible in the dashboard. Click on the device and see if messages are being sent.

If that checks out, you can check the data being received in IoT Central by clicking on the device and then navigating to Raw Data. This will show all data sent in a list over time.

If the table is populated, it shows that the data is getting to IoT Central. Well, I hope that helped. If you have a bug that you can't seem to fix, feel free to comment on the project and I will try my best to help you.

Step 10: Deploying

Now that the device is streaming data to the backend, we are ready to deploy it. In the /container/configure.h file, set the debugging variable to false to not print data to the serial monitor (note that some data may still be printed). You can flash this to the device and then connect it to the powerbank. That's it!

Step11: The Enclosure

Now that the container is ready, we need to enclose all the components and have room for the test kit that will be used. All the design files are in the GitHub repo under /Enclosure. These parts were designed in Solidworks.

You can either 3D print the parts or CNC machine them. The assembly is quite straightforward. Finally, place the components in the container and then glue it together.

The drone kit comes with a stand that can be attached to the front of the drone. I glued this to the top of the enclosure and slid the enclosure into place on the drone. I then attached the powerbank on the back of the drone and connected it to the container via a USB wire.

Step 12: The Dashboard

The last thing we need to do is create a dashboard where we can monitor the data streamed by the container and also interact with it remotely. There are 3 parts to the dashboard. We will go through all of them in this section.

We'll start off by adding a settings view to the device. This is a page that allows us to change the PIN and other settings on the device. Navigate to your device template and then click on Views from the menu. In this window, select to create the first option available.

Now you can customise your view. Name it Settings and choose the following datapoints to display.

After you click Add section, all the selected datapoints will be added. That's it, you're done! By the way, you can find these views populated with data if you click on the device.

Now, let's deal with the device specific dashboard. This is optional. This dashboard will display the data specific to the respective device that sent it. Start off by going back into the Views option from the menu and this time select the second option.

You will be directed to a more rich interface with multiple options. On the left, you will see a menu allowing you to select telemetry and properties to display. To add a card, click on the data point and then click Add Tile at the bottom of the screen.

The design of the dashboard is up to you. Spend some time experimenting with it. You can add maps to map the location of the device, and cards and graphs to display data.

Each card will have options available in the top right corner of the card. Play around with the card type and interpolation. Start adding more cards to the canvas to display all the information in a neat manner. Mine ended up looking something like this.

A reminder that this view is accessible from the device in the cloud and will be populated with the data sent by the specific device. Now finally, we will create a dashboard that can display data from multiple devices at a time.

Start off by going into the Dashboard from the menu on the left. Click the New button to create a new dashboard. This interface is very similar to the device specific dashboard.

The only difference is that you need to select the device group and devices you want to display the data from. If there are multiple devices, the data from all of them can be displayed on one dashboard.

Continue by selecting the telemetry and properties to display like in the device specific dashboard. You can make the design identical to the device specific dashboard if you wish. Note that there are different tiles such as Markdown tiles and image tiles that can be used. I ended up with something like this:

And that's it! The container is done!

Constructing the Nav-Q

FInally, the last thing we need to do is set up the Nav-Q Computer for streaming video from the drone using GStreamer. There are other use cases for the NavQ described in the Future Envisions section.

Step1: Getting the Kit and Setting things Up

Firstly, the kit can be purchased from this website. Before going any further please read through the NavQ GitBook and set the device up using the following guides:

• Powering the NavQ
• Using NavQ as Desktop Computer
• Downloading and Flashing Latest Linux Image (flash to eMMC)
• Connecting to WiFi

Make sure to run sudo apt-get update and upgrade. Also ensure you installed the nano editor.

Step 2: SSHing into the Device Remotely

It can be quite inconvenient to have to connect the NavQ to an external monitor and connect peripherals to it. We can SSH into it remotely using PuTTY. Please install the adequate version from the official website.

The next thing you want to do is get the IP address of your NavQ device. You can do this by running ifconfig -a from the terminal on the NavQ or checking your router home page.

Open PuTTY on your computer and paste the IP address of the NavQ into the field and make sure Port 22 is selected. You will be asked for a username and password (both are navq) to connect.

After you input the credentials, you will be connected to the device remotely. Now let's configure GStreamer.

Step 3: Running the GStreamer Pipeline

Before running the pipeline, we need to disable the firewall on our computer so the stream can get through. Go to settings/Firewall and disable the public network firewall if you're on a hotspot or private network firewall if you're on WiFi.

We need to make a small adjustment in QGroundControl now. Go into application settings and find the Video Settings section. Enable it by changing the source to UDP h.264 Video Stream. This may be in a different place depending on your version of QGroundControl.

All the packages needed to run the pipeline are already included. Run the following scrip in the terminal to turn the pipeline on. Make sure you get the IP address of your computer (same method as before) and input it instead of the xxx.xxx.xxx.xxx.

sudo gst-launch-1.0 v4l2src ! video/x-raw,width=640,height=480,framerate=30/1 ! vpuenc_h264 bitrate=500 ! rtph264pay ! udpsink host=xxx.xxx.xxx.xxx port=5600 sync=false

If everything worked, you should get footage from your camera.

If the stream is not happening, double check the IP address used for the computer and that the script is right. Make sure the firewall is disabled too.

Step 4: Automating the GStreamer Pipeline

Although it is great that the pipeline is online, we don't want to have to SSH into the device and then run the script every time the device turns on. We need the NavQ to automatically start streaming video when it is connected to the internet. We can use a tool called systemctl to do this for us. We will set this up in this section. I also created this section as a guide on Hackster at this link.

Start off by making a new directory /home/covidtestdrone. cd into the directory and create a new file using sudo nano. The code for the file is available in the GitHub repo (/NavQ) and displayed below.

#!/bin/sh
sudo gst-launch-1.0 v4l2src ! video/x-raw,width=640,height=480,framerate=30/1 ! vpuenc_h264 bitrate=500 ! rtph264pay ! udpsink host=xxx.xxx.xxx.xxx port=5600 sync=false

Paste this script in the file and ensure to once again replace the xxx.xxx.xxx.xxx with your computer's IP address. Save the file and name it run-gstreamer.sh. Now we want to make the script executable, paste the following command in the terminal:

sudo chmod u+x run-gstreamer.sh

Great, now we want to integrate systemctl. Run the following command in the terminal:

sudo systemctl edit --force --full covidtestdrone.service

A nano window will open prompting you to type. Copy and paste the following text into the terminal:

[Unit]
Description=My Script Service
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
WorkingDirectory=/home/covidtestdrone
ExecStart=/home/covidtestdrone/rungstreamer.sh
[Install]
WantedBy=multi-user.target

This is a unit file that tells the system what script to execute under which conditions.

Now save the file with the default name. Run the following to check the status of the script service:

sudo systemctl status covidtestdrone.service

You should get a response similar to the one in the image above. Now we need to enable the service.

sudo systemctl enable covidtestdrone.service

Now we want to see if the service functions. Start the service with the following command:

sudo systemct1 start covidtestdrone.service

This will force-start the service. Run the following again:

sudo systemctl status covidtestdrone.service

You should get a printout similar to the one in the image above showing that the script service is active. You should get a video feed in QGroundControl. You can reboot the device now. The video feed should come in automatically.

sudo systemctl reboot

That's it! You're done!

Step5: Attaching the NavQ tothe Drone

Finally, the NavQ has to be attached to the drone. This guide in the NavQ GitBook walks through attaching the NavQ to the drone using components that come with the device.

Nice, everything is done now and the drone is ready to fly!

Reflection

I started working on the project back in August this year. In the midst of the pandemic, I found myself with a lot of free time on my hands and decided to put it to good use. I started ideating on the theme of the virus and came up with a couple ideas. After spending some time researching, I came across the NXP Hovergames competition which was based on creating projects which would use drones to develop solutions to help the world during the pandemic.

I focused my efforts on creating a solution using a drone that would somehow help the world get through the pandemic. I was inspired by services like Amazon’s drone delivery (Prime Air) which provides shipping solutions via drones.

I then thought, what would people need shipped to their homes during the pandemic? I came up with the idea of COVID-19 tests (after looking at vaccines as these are not self-administrable). People need to go to test centres to get tested and this can be difficult for various reasons. What if people could get their tests shipped to their home within minutes and get results the same day? So I got to the drawing board and started developing the idea.

After a lot of reading and planning, I wrote my idea out and applied for hardware in the competition. I was awarded a discount on the drone and the Nav-Q computer and then got to work developing my idea.

I first put the drone together and tested it. After a bit of tuning, and realising that I mounted the motors wrong. I fixed that and got the drone flying. I spent the next couple of months working on the container. I purchased the components needed and then assembled them and started coding.

I started off by interfacing all the sensors; I’d ensure that the container would open if I inputted the correct pin and played around with the other functions. I then connected the device to IoT Central and started streaming data. I then added support for bidirectional communications and the ability to remotely control the container, for example, lock and unlock the container.

I continuously improved the container, adding more sensors and updating the code. When that was ready to go, I assembled it and attached it to the drone. I then started working on the Nav-Q module. I started off by experimenting with GStreamer and getting it to work. It was quite straight forward after I set up the environment.

I then automated the script so that the video feed would automatically start streaming to my computer when the device booted and connected to the internet. I finally assembled the module onto the drone and tested the drone as a whole.

I finished off by taking a lot of photos and preparing the video for the project.

I really enjoyed working on this project.

Links to Contributions

I created a guide to implement a script automation service to allow the NavQ to automatically start streaming video via GStreamer when connected to the internet.

https://www.hackster.io/andreiflorian/streaming-video-through-gstreamer-automatically-on-navq-7b04fc

I contributed to the Hackster Hovergames forum on several occasions.

• https://www.hackster.io/contests/hovergames2/discussion/posts/8093#challengeNav
• https://www.hackster.io/contests/hovergames2/discussion/posts/8092#challengeNav
• https://www.hackster.io/contests/hovergames2/discussion/posts/7910#challengeNav
• https://www.hackster.io/contests/hovergames2/discussion/posts/7066#challengeNav

All my code and design files are open source and hosted on GitHub

• https://github.com/Andrei-Florian/CovidTestDrone