Article

Blood running: it’s not what you think

7 February 2019 | Olly Nural | About a 10 minute read
Tags:


In 2018, I had the opportunity to deliver a presentation at AND’s annual tech summit – known as Horizons. This internal learning event brings together all our ANDis in one place (over 300 of us), for a day long conference with around 30 sessions on the theme of technology: now, near and next. It’s a great opportunity to swap ideas, share lessons learned and generally catch up with each other – and it gave me a great opportunity to share a recent prototyping project using drones.

Here’s my write up of that talk.

 

If you said ‘blood running’ to a friend or colleague, what do you think their reaction would be? Let’s be honest – it sounds a bit ominous: like something you sell on the black market. In reality, though, it represents an incredibly important service that hospitals up and down the country rely on. Blood running is when hospitals require urgent blood that they don’t have in their own banks, and volunteers are called out – day or night – to deliver blood to the hospital. This particular project focused on the question: how can we make this process easier, better and automated? The answer we explored was drones.

Working as a group, I helped create a proof-of-concept drone system that allowed us to deliver blood between two hospitals, automatically pathfinding between obstacles and staying within flight boundaries. Sounds pretty straight forward, right? Maybe, but let’s break down and explain how we got there.

 

So why drones?

There are some key reasons why we chose to use drones for this project (besides the fact they’re, you know, pretty fun to work with):

  1. They’re autonomous, and anytime – no more would volunteers be summoned from sleep at 3am.
  2. They’re long range – high-end drones can have connectivity ranges of up to a few miles.
  3. They bypass most obstacles –  including the limitations of roads, like traffic jams or improvement works.

 

Getting started

The project itself focused on three core areas: the messaging system, the route pathing algorithm and safety features.

 

1. The messaging system

 

We needed to understand how to communicate with the drone and give it instructions. The first step was to connect to the drone, which was actually very straightforward: we simply had to connect to the WiFi hotspot that the drone was emitting, and then install the Robotic Operating System (ROS). ROS is a set of software libraries and tools that help with the development of robotic applications.

Next step was to dive into how data was communicated back and forth between ‘ground control’ and the drone. To understand this, we first thought of typical HTTP communication methods, and then compare how that might work with the drone.

The key things to remember with a typical HTTP request are:

– We make a request to a location we know
– We expect a response within a reasonable time

Drone get index.html

 

Communication with drones is a little different – they operate on a publish/subscribe model. But what exactly does that mean?

 

Drone publish subscribe data diagram

  A simple publish/subscribe model for communication with drones.


To receive data 
from the drone:

  1. First, we identify a topic to listen and subscribe to. This means we will be notified whenever something is sent to that particular topic. For example,  http://localhost:8080/current_x_pos
  2. Drones constantly publish data such as location and movement based information to defined topics.
  3. By subscribing to the relevant topic, we can receive data back from the drone.

Note: in the diagram above, the topic in the middle is acting as a channel from which to send and receive requests.

 

Sending data to the drone is a similar process:

  1. The drone is automatically subscribed to a set of topics. For example, http://localhost:8080/cmd_vel
  2. Next, we need to publish data to that specific topic – in this case, it could be a set of linear and angular x, y and z co-ordinates
  3. The drone receives that data, and acts upon it.

And that’s it! That’s the basis of how to communicate with a drone – but what do we say to it?

 

2. The Route Pathing Algorithm

 

Before I dive into the actual algorithm itself, let’s first identify our aims for the drone’s navigation system:

– The requirement to navigate around known, static obstacles, like buildings, trees. We should be able to input a ‘world map’ that contains all of our obstacles, and the drone should be able to plot and fly a safe path through, avoiding all of them.
– Geo-boundaries; virtual perimeters for the real world geographic area describing where the drone is allowed to fly, defined for each flight.
– In the future, we want to be able to dynamically update the world map as the drone flies, and have the ability to recalculate the route after updating the map.

 

Due to these aims and requirements, we decided to choose the widely used and performant A* algorithm.

 

A* Algorithm

The objective of the A* algorithm was to find the most efficient and accurate path through a node graph from a start node to an end node. To see what I mean,  take a look at this really useful GIF:

Astar progress animation

A pictorial explanation of the A* Algorithm

 

This simple GIF shows:

– Empty circles, representing the open set – or nodes that are yet to be explored;
– Filled Circles, representing the closed set – or nodes that have been explored.

Note that the colour of each Closed Node represents the fitness of a node, calculated by a heuristic. A heuristic is just a function returning an estimation of the distance between the current node and the end goal. In this case, it is the Euclidean distance that is simply ‘as the crow flies’ (or as the drone flies).

The algorithm:

  1. Starts at the beginning, with the start node set as the current node;
  2. Grabs all the unevaluated open set nodes around the current node, and adds them to a big list, ordered by the heuristic. It puts the one it thinks is the best at the top.
  3. It then takes the best one from that list, and makes it the current node.
  4. It then repeats step 2, and evaluates all nodes around it.
  5. And it keeps on repeating!


Once we find the end node, and by always selecting the ‘best’ available empty node each time, we know the first path found that got us to the end goal has to be the most efficient. This is the basic process for finding our route, but how does this actually translate into something useful for the drone?

Meet the world map.world map drone

The ‘world map’ is sent to the drone to find routes. A little less glamorous than the name suggests, perhaps.

This 2D array is the representation of the world the drone has to navigate:

 

2 = padding for the geo-boundary
1 = obstacle
0 = safe to fly space
A, B = start, end
x = chosen route

Since we know the size of each node (in this case, we measured 1 metre), we then just need to convert this into movement commands using the topic mentioned above.

For example, if we need to move right for 3 metres, we can issue the following command for 3 secondshttp://localhost:8080/cmd_vel

 

{

linear: { x: 1.0, y: 0.0, z: 0.0 },

angular: { x: 0.0, y: 0.0, z: 0.0 }

}

 

By moving the drone at a steady 1 metre per second, we can easily control the distance at a granular level.

We built a small, lightweight interface that allowed us to input our start, finish and the geo-boundary co-ordinates – and we made it look a little nicer than the map above!drone mapping

3. Safety First

Of course, flying drones doesn’t sound like the safest thing to do – especially when dealing with potentially precious and dangerous liquids transported over large distances. Therefore, we implemented a few safety measures early on in the project:

– Emergency stop – during a flight, pressing any button on the keyboard would instantly terminate the flight and land the drone safely.
– Geo-boundary padding – by putting a 2 metre padding around the sides of our geo-boundary, we could drastically reduce the chance of the drone accidentally exiting the safe boundaries.
– Minimum fly height – whilst testing, we flew the drone at 2 metres high, but when we finished, the drone flew at roughly 8 metres in the air.
– Restricted areas – only specific areas in England are legal flight areas, so we ensured we were only flying safely and legally.

 

And did it work?

Yes! We built a successful prototype that allowed us to enter start and end locations, and hit go. The drone would then calculate the route, and safely and autonomously navigate through its surroundings to reach its destination.

 

Looking ahead

Ok, so I’ll admit it: this talk allowed us to share and celebrate some pretty cool tech that was also incredibly fun to play with.

But, more importantly, it explores the potential of drones to save lives – something a number of companies are already exploring. Take Zipline, for example, they have developed a system that transports essential medicine over vast and otherwise untraversable terrain in Rwanda.

This sort of technology is rapidly becoming a reality, and I look forward to seeing what other critical challenges drones can help us solve.

Read More From This Author

Share this blog post

Related Articles

Careers

We’re looking for bright, dynamic people to join our team!

  • React Native Engineer (London)

    React Native Engineer (London)

    Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.

    Technologies you will be using

    I'm Interested
  • Tech Lead (Reading)

    Tech Lead (Reading)

    Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.

    I'm Interested
  • DevOps Lead (Reading)

    DevOps Lead (Reading)

    Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.

    I'm Interested
Discover More Roles