Courier Pigeon

The best way to optimize mail delivery.

Comment

Inspiration

Over the past year, we've seen numerous events close down major highways, arterial roads, and also shut down rail lines. Weather-related events such as blowing snow, layers of ice, unprecedented amounts of snow all contributed to natural causes, but there were also a significant number of disturbances due to human factors: trucker convoys, parades, demonstrations, etc.

ontario highway closure

Throughout all these events, Ontarions still continued to rely on our transportation and delivery backbone to continue getting groceries, goods, and other items. Throughout all of these major events, we noticed that traditional routing applications such as google maps, waze, waymo, etc. all failed to quickly recognize the road closures and re-route accordingly. In fact - they often re-routed hoardes of people onto the same detours, leading to long stretches of bumper to bumper traffic.

We wanted to take the opportunity to provide a better system to aid the drivers and companies working around the clock to keep our infrastructure alive, by giving them a system that pre-emptively provides alternate routes, avoids traffic, & hard-to-drive narrow roads (especially common on highway bypass detours) all while saving fuel and time for the company and the driver.

What it does

In short, Courier Pigeon operates as a fleet management service that synergizes company vehicles with personal and third party delivery platforms, assigning drivers routes scaled to the capabilities of the vehicle an driver.

It allows drivers to minimize delivery times by providing constant updates to the route, accounting for extra package pickups, slowdowns ahead, or inclement weather areas (such as steep, icy roads!). It also automates the assignment of routes, as well as providing real-time live updates for package delivery status, vehicle status (such as fuel/energy remaining, driving habits, or general GPS updates!)

How we built it

Courier Pigeon's core logic is built using Python3, integrated with HTML and JS. This core logic uses Solace's PubSub+ Network as it's primary communication pipeline, allowing independent application instances to connect and communicate with each other over the cloud.

The "supervisor" acts as the main decision and logic hub for Courier Pigeon, being subscribed to any event and handling tasks such as: updating package status to the user! All PubSub events followed a topic format that we decided on: pigeon/<type>/<Van #>/<Package #>

A brief look at the full topic hierarchy is shown here: topic hierarchy

For example, we can have a route that dynamically adjusts itself to incorporate multiple pickups! These changes would be reported by a request event over Solace PubSub, which then tells the supervisor to resequencing & re-optimize the remaining route! This route is then broadcast out in a format similar to this: pubsub reroute broadcasts

Challenges we ran into

Over the past 36 hours, we ran into a few challenges, some major, some minor.

To start, the hardest part was our own skillset. We didn't really have prior frontend experience, nor did we have large amounts of python experience - this continued to prove to be a challenge throughout the entire weekend, but we didn't let that stop us and we still tried our best!

We also ran into constant issues with network port connections. When learning how to use Solace's pubsub+ event broker, we spent nearly half a day googling and trying to see what we were doing wrong - when the issue turned out to be that the connection port had been blocked on eduroam and we needed to switch to either a mobile hotspot, or later on, guOttawa.

Once our Solace issues were resolved, we continued to develop, but we hadn't come up with a thorough system architecture - meaning that we were often faced with the challenge of actually figuring out how certain components would interface with each other - leading to some re-writes, and then a few more re-writes. A particular bugger for this was the difference between latitude, longitude and longitude, latitude between ISO standard and certain APIs.

Lastly, we had the fun experience of realizing that we wrote a large package to support a particular API that was only in beta, meaning that we had to re-write a large portion of package support to use an older, publicly available and free version of that API. We also later realized that the public & free version of the API did not do what we needed to do, so we had to come up with a fairly last-minute solution to ensure full functionality.

Accomplishments that we're proud of

Although we may not have much at the end, we're really proud that we were able to give android app development a shot, as well as web dev, which is not something any of our team had done before.

What we learned

Android Studio makes our laptops overheat. Also, PubSub+, Mapbox are easier to get started on than we thought! PubSub+ especially was very cool and made development a lot easier.

What's next for Courier Pigeon

What's next? You've seen our proof of concept, next time it'll be a full app and website, maybe using some distributed ledger so that we can have a decentralized supervisor network! (no need to run hosted servers? - instead, allow mapbox and solace to handle the routing and optimization part, we can even run our supervisor in the cloud with Solace tools!

Share this project:

Updates