Picnic is in the business of delivering groceries. To do this, we operate a fleet of hundreds of small electric trucks, whizzing across the streets of Europe every single day.

With hundreds of vehicles in operation, the risk of road incidents is a fact of life. Making sure that these incidents do not happen is one of the company’s largest overarching goals.

As part of this company-wide effort, those of us in the tech team figured we could find a way to systematically reduce those incidents, both in frequency and in severity. In other words, we wanted to come up with a streamlined solution to improve safety.

Towards a Solution

As a tech team, our first challenge was to figure out a way to monitor how the Runners (those making the deliveries and driving the EPVs) drove while on a shift.

Our Runners have a dedicated app that runs on industrial-grade Android devices. One of the major functions of the app is to provide navigation instructions, which means that while driving, the device is strapped to the EPV’s dashboard. This means that at all times when the EPV is actually moving, we have a device that is fully capable of measuring that movement fixed to the vehicle.

Could we use the information we could gather from these devices to improve safety? It was time to find out!

Measuring Acceleration

We quickly realized that the most vulnerable moments are when the EPV is turning, as turns can indicate crossings, roundabouts, or any similar situation where attention can be divided between several stimuli. Therefore, our first step was determining how feasible it would be to actually detect turns using the device accelerometers. One of our analysts went out in a borrowed EPV with a 3rd party accelerometer app running, drove to a remote location, and started doing some, well, interesting turns.

After some Hollywoodesque driving in a safe location, we did learn that the device accelerometers were perfectly capable of registering when the vehicle is turning.

With the concept proven to be fundamentally workable, we set out to enable accelerometer readings in a test version of our app.

Making Use of Accelerometer Data

As it turns out, there are complications to using accelerometer data in a running application. The accelerometer presents a low-level interface, providing high-frequency, chaotic data. This is not a problem if we are in a position to record everything and simply plot the result, but what we wanted was to detect the higher-level concept of tight turns.

The first problem was smoothing out the data. Instantaneous accelerometer readings jump around significantly during normal driving, meaning that in order to make sense of the readings at any given time, we needed to process them.

Fortunately, we did not have to hire an expert in signal processing to come up with a workable solution. We started computing a live recursive average of the data, using the following formula:

y[n] = y[n-1] +α(x[n] — y[n-1])

Here, x[n] represents input reading n, used to compute an output y[n]. The nth output reading is computed by using the previous reading y[n-1], the nth input reading x[n], as well as a “stiffness factor” ɑ. The stiffness factor is a number in the interval (0;1] which determines how rapidly the output signal converges to an average. Notice that by setting ɑ to 1, no averaging takes place, the raw input is simply used. The closer to zero, the more the new output reading will be smoothed out, taking longer to converge and being less sensitive to fluctuations in the input.

When this recursively computed output reading goes above a certain threshold, it is a sign that something of relevance is actually happening. More factors needed to be taken into consideration before we were ready to decide that the detected acceleration increase is in fact a hard turn, however. We also need to consider a minimum duration required to register the acceleration as a turn, as short bursts of high acceleration are more characteristic of the device being dropped or bumped. We also need to consider the time that has passed since the last recorded acceleration event, as we don’t want to split a long turn into multiple events.

To summarize, we can configure our acceleration detection using the following parameters:

• Stiffness factor: the sensitivity to sudden changes in accelerometer readings
• Intensity threshold: the value above which we consider the acceleration to be too high
• Detection duration requirement: the minimum duration required for an acceleration violation to register as a turn
• Cooldown duration requirement: the minimum duration allowed between turns to register them as independent events

The actual values currently used for the parameters were determined experimentally (meaning, the original test trip done by our analyst was not to be his last, not by a long shot) and over time, we became quite confident in the detection. We now only start recording data for persistence in our back-end systems when the necessary conditions are met.

By the way, raw accelerometer data is voluminous enough for the storage strategy to be relevant, the numbers being of an entirely different order of magnitude than anything else emitted by the Runner App. In one trip, for example, a Runner usually performs about 10–20 deliveries, resulting in about 1000 location updates. But with our current parameters, we record roughly 50,000 accelerometer readings. Because of this, we ended up spinning up a new, dedicated microservice to handle the datastream. But that’s a topic for another blog post. 😉

The Current Situation

Clearly, storing accelerometer data is not enough to guarantee safety, we also need to do something with it.

The first value we extracted from this data was an overview of the most hazardous locations in each of our delivery areas. Every vehicle hub already has a safety map of hazardous locations (low bridges, tricky ramps) hanging on the wall which allowed us to augment the known hazard with empirical evidence of harsh corners and areas where the Runners are prone to drive too fast.

Before we began recording acceleration, we had been recording speed and location, feeding into a live view used by local managers. By combining all of this data, we were able to construct an accurate picture of where speeding is likely to take place.

This already allowed Runners to improve their driving, but the most significant action was the introduction of the personalized Driving Coach.

Each Runner now receives a weekly Driving Safety Level, with a score between 0 and 100. Besides that, the Driving Coach coaches in an informal way, by giving suggestions on how to improve the score. Its feedback is designed to implicitly motivate Runners to improve their safety, rather than doing it because we ask it of them. One of the key insights, was that the feedback should always be as positive as possible, and that correct execution of the given tips lead to both a better score and a safer situation on the road.

But does it work?

In short, yes.

In the first months, we have seen significant improvements in every kind of behavior we can measure and since a few weeks, the project has been fully implemented in the Dutch operation

Both harsh corners and speeding are down by over 30%. In fact, when looking at the readings associated with individual streets, the difference is easy to see. Here, a red dot is associated with a reading indicating high speed, a green one with safe speed. The picture on the left is from readings in the first week of the program, the one on the right is after 8 weeks of running it.

Beyond overall statistics, we hear our Runners talking about the Driving Coach. They want to increase their score and believe staying on the correct side of the bar is important to them. Everyone wants to improve safety, and this tool helps the Runners do that.

Where to go from here?

With big data come big plans! Currently, we are working on making the safety overview maps available live on the Runners’ devices. Instead of a static map on the wall, each Runner will be shown an up-to-date map of their scheduled delivery area. We have high hopes this will be effective in making sure that our Runners will always be aware of the general local hazards, while still not bombarding them with unnecessary information.

Another avenue of exploration is shortening the feedback loop for the calculation of the Runner Safety Level. Currently, this is calculated using a regularly scheduled job, but how much better would it be if the Runner would learn their score right at the end of the trip? Safety, gamified.

Shortening the feedback loop logically leads to thinking about live feedback. We can imagine a future where we can use the data we have on our delivery areas, combine it with our devices’ ability to record data on the fly and provide immediate updates.

But no matter where this effort will take us in the future, we can be certain that at Picnic, we will continue to use tech to improve safety.