Real-time delivery tracking with the Picnic Delivery Radar
Picnic is an online, mobile and app only supermarket providing affordable grocery shopping with free delivery in the Netherlands, Germany and France.
At Picnic we respect our customers’ time and aim to provide a service reflecting that. We guarantee to deliver groceries during a one-hour delivery window selected by the user between one day and one week ahead. On the day of delivery we communicate a narrower 20-minute window. And this is only the first step in keeping the customer up-to-date. In the Picnic App customers can track their delivery in real-time using the Delivery Radar.
What is the Delivery Radar?
Picnic customers can track the vehicle containing their delivery on the Delivery Radar. This map shows the progress of the delivery from the Picnic hub (the local Picnic warehouse from which the vehicles depart) to their address. On the map the current location of the vehicle, its route and the expected time of arrival at the destination are displayed. And all that is updated in real-time.
The photo and the name of the Picnic delivery person (who we call runner) is displayed as well so that the customer knows who will deliver their groceries today.
Once the vehicle arrives at the customer’s house the Picnic App plays a car horn signal, notifying of the runner’s arrival even before the doorbell rings.
During special events (e.g. Christmas and Valentine’s Day) we decorate the Delivery Radar with special assets.
Similarly, as part of a business collaboration with Nespresso, we add a trailer with the Nespresso logo to the vehicle if the Nespresso cups are included in the delivery.
However, implementing such simple ideas comes with challenges.
Challenges
First of all, the Delivery Radar must be accurate enough to inspire customer trust. But both customer and runner personal data, such as current geolocation and home address, must be secured to ensure privacy and meet GDPR regulations.
Secondly the animation of the vehicle movements should be smooth to keep user experience pleasant.
And last but not least, it should support dynamic assets to bring additional functionality to the app and possibilities for business.
Accuracy vs Privacy
The question “How to make an accurate delivery radar without displaying real locations?” sounds similar to “Can you tell me where you are without telling me where you are?”.
With the Delivery Scenario concept we can answer both these questions!
The Delivery Scenario concept
A Delivery Scenario is a route from the Picnic hub to the customer’s address through all other delivery stops in between (we deliver to multiple customers in a single trip) calculated for every customer individually. This route is represented by a sequence of points. Each point is the forecasted geolocation where the vehicle should be at an associated timestamp.
Simplified Delivery Scenario model:
12:00 — (52.36,4.80)12:01 — (52.37,4.81)…12:02 — (52.38,4.82) — intermediate delivery stop start12:05 — (52.38,4.82) — intermediate delivery stop end…12:11 — (52.39,4.83) — delivery stop start12:15 — (52.39,4.83) — delivery stop end
When the delivery trip starts we build routes through real customer addresses using Google Maps Directions API. At this point the trip’s route and how long each delivery will take have already been computed by the Distribution Planning systems. We do this as late as possible, namely when the vehicle leaves the hub, which allows us to take into account the most recent traffic situation. So the route we get is accurate and up to date, even though it doesn’t guarantee that the road situation cannot change during the trip, which is acceptable since our goal is not to show the current location of the vehicle, but to show the progress of the trip towards a specific customer.
Then we perform an adjustment of the built routes with the algorithm inspired by Ramer-Douglas-Peucker (RDP) logic.
Our implementation transforms the forecasted route into a derivative one which travels along approximately the same points (within a defined margin of error), and which consists of roughly equally spaced points, where adjacent movement points are never separated by more than a predefined distance. In simple words, we move around the original route points and generate additional ones in between.
During this process the intermediate stop points where the vehicle is predicted to park for prior deliveries are also moved such that their locations are obfuscated.
In the end, the route a customer sees in the app is an adjusted prediction of the route the runner could take if they strictly followed navigation suggestions. Of course, in reality the runner can drive at a different speed and choose other routes, which is also acceptable for our case.
But if the Delivery Scenario is fully anonymized by definition, how can we trust the Delivery Radar? The answer lies in the Delivery Scenario Service.
The Delivery Scenario Service
The Delivery Radar receives Delivery Scenario information from the Delivery Scenario Service, a microservice responsible for building Delivery Scenarios and tracking their progress.
The service listens to the updates from the Runner App (a separate mobile application for Picnic runners, you can learn more about it in Picnic blog) and derives the delivery trip status and vehicle GPS location from them. Using this data the service can always tell where the vehicle is, relative to the idealized trip defined by the Delivery Scenario.
When working with event-based communication originating from mobile applications you need to be ready to deal with late, unordered and missed events caused by connectivity issues, battery outages, sensors’ quality, app user mistakes, etc. To handle such cases we have several fallback levels in the vehicle location calculation logic.
If the GPS location is known and up-to-date (i.e. not older than a preconfigured amount of time) we base the location calculations on it. But the device GPS can be erroneous or the vehicle may have strayed from the Delivery Scenario route. To address these cases we need to solve the geometric problem of finding the closest point on the Delivery Scenario where the vehicle should be to reflect the delivery progress correctly.
Given the following case
knowing only the up to date vehicle GPS location is not enough to correctly determine the point on the Delivery Scenario route since we cannot just select the closest one. Instead we are looking for the point p on the Delivery Scenario through which the route from the last reported Delivery Scenario progress point X1 to the vehicle GPS location point G has the least total distance (with the Delivery Scenario part of the route normalized to reduce the triangularity effect), which can also be expressed with a formula:
where D(X1, X2) is the total route distance between the points X1 and X2. Such calculations ensure that the Delivery Scenario progresses smoothly without the sudden vehicle jumps caused by the erroneous GPS location updates.
When the GPS location is unknown or outdated we extrapolate the vehicle location based on its average speed and total trip duration. We select the Delivery Scenario point having the associated time closest to the extrapolated value. This logic can be expressed with a formula:
With this formula we predict where the vehicle should be in the Delivery Scenario by knowing its average moving speed and its trip start time.
Together with the Delivery Scenario location we calculate the expected time of arrival by extrapolating the vehicle movement based on its average speed. Then the Delivery Scenario progress is communicated to the Picnic App where it is rendered on the map.
Delivery Radar animation
Once the delivery trip starts the Picnic App displays a notification informing the customer that delivery progress can be tracked through the Delivery Radar. Once the Delivery Radar fetches the Delivery Scenario, it renders it on the map and starts polling for Delivery Scenario progress updates. And during this process the animation happens.
In Picnic we developed a simple rendering engine with a configurable frame rate showing the vehicle as it moves along the route, including turns, speed ups and slow downs. Having this functionality is enough to make the animation smooth. But this part contains its own challenges as well.
The Delivery Radar gets Delivery Scenario progress updates on dynamic intervals (decreasing while getting closer to the destination to improve the Delivery Radar accuracy on the last delivery mile) plus communication latency which requires us to make a decision on how the vehicle should move before the new position is known, to keep the movement smooth. Since the Delivery Radar is aware of the Delivery Scenario it can extrapolate the vehicle position after the next progress update interval and start moving the vehicle to that point. Once we receive the next position update we extrapolate again and tweak the movement speed to keep vehicle position in sync.
Another edge case is a “teleporting effect” which happens when the vehicle location is very much different from as of the latest progress update, for example after some time of app inactivity. In such cases, to keep the vehicle movement smooth, we split the leeway to parts and speed up the vehicle to catch up with the Delivery Scenario progress in several progress updates. Then we slow down the vehicle and turn back to the original animation strategy.
Dynamic assets
On the Delivery Radar we can use different images for vehicle, truck trailer, runner photo and various UI decors which are provided dynamically.
Before the response from Delivery Scenario Service gets returned to the Picnic App it gets intercepted by the Delivery Scenario Enrichment Service. This service decides which enrichments should be applied to the Delivery Scenario and enriches the response with the metadata about them. This metadata contains the image references to be rendered by the app. Once the app receives the enriched delivery scenario response it fetches the required images using the received references, from another microservice backed by AWS S3 where images are physically stored.
Such a solution allows us to manage the Delivery Radar and other UI parts of the Picnic App without the need to upgrade the app to the new version.
Summary
You may think of the Delivery Radar as a delivery progress bar which does what it should: communicating to the customer how soon they can expect the delivery at their door, while ensuring the security of their personal data. Though if you decide to follow the vehicle on the Delivery Radar by bike you have a chance to see it somewhere on the road or in the neighboring street.
At Picnic we respect our customers’ time and aim to provide the service reflecting that. And I think we do it well!
