---
title: "Pico Router Changes Directions"
description: "The Pico Router project is narrowing its focus and turning into a third-party C++ routing library for constrained embbed hardware targets."
canonical_url: "https://www.victoryanson.com/blog/pico-router-changes-directions"
last_updated: "2026-09-17T20:55:44.598Z"
---
### TL;DR
Pico Router is narrowing its focus from an ambitious all-in-one disaster-relief firmware project into a reusable embedded C++ routing library. Rather than building custom hardware integrations and tooling, development will prioritize a clean routing abstraction with bounded, predictable memory usage. Near-term work will focus on cache-aware graph storage and scalable tiled map access, potentially borrowing ideas from software-managed caches and spatial partitioning explored in related projects, while keeping disaster relief as one possible application.
## The Original Vision
Pico Router was started under ambitious conditions with ambitious goals in mind. The pitch from the very start was to build a fully-fledged autonomous offline routing systems for disaster relief purposes. This included all the bells and whistles. My plan was to not only embed a routing engine on an MCU, but also support all kinds of peripherals and tooling (IMU, OLED display, GPS processing).
As you can probably infer by my tone, I bit off more than I could chew. That's all right though. I had originally homed in on a very particular use case in order to make all the initial planning of the project slightly easier. Besides, disaster relief is something I genuinely care about. However, what was also true was that Pico Router was my first "big" embedded firmware undertaking, making it easy for me to underestimate the scale of what I proposed. In the end, I didn't set out to solve every imaginable problem in the world of embedded routing engines. My goal was rather to offer a novel solution for a specific hardware target and hopefully learn lots along the way. In that respect, I think I'm well on my way to achieving my objectives.
## Where Is Pico Router Today?
Today, Pico Router is at version 0.1.0 with most of basic functionality in place. Here's a quick overview of implemented features:
- Fixed-size graph representation for nodes and weighted edges
- A* pathfinding with Euclidean-distance heuristics
- Conversion of OSM data into binary graph files (`osm-convert`)
- Raspberry Pi Pico 2 firmware target with UART output
- Basic GitHub Actions CI
- Devcontainer-based development environment
- GoogleTest unit tests for paths and routing behavior
Pico Router's current terminal banner
### So what's the problem?
The major problem here is scope creep. I derive a lot of satisfaction by doing stuff manually at this abstraction level. Nevertheless, I quickly tied my hands with emulation platforms, custom benchmarking, IO interfaces, etc. This helped me learn that there's a major difference between making a multi-versatile system and "just making things work".
## What Exactly Is Changing?
The main direction change boils down to the project going deeper and narrower rather than the current, wider approach. I want to move away from writing custom firmware for an all-in-one device in favor of a clean abstraction around the edge routing only. In essence, this means Pico Router is going from a full firmware solution to a third-party library.
### Does that mean that the disaster relief use case is being left behind?
Not necessarily. Perhaps the most effective thing to do is letting other developers decide themselves how embedded routing is best applied within their system, whether that's disaster relief or anything else for that matter. The key is that the fundamental promise remains: **bounded, predictable memory usage**.
### What abstraction level are you going for?
Especially at first I'd like to keep things as straightforward as possible. Ideally I'd start off with something like:
```cpp
RouteResultObject pico_router::get_route(uint32_t start_node, uint32_t goal_node);
```
Of course, the actual API will likely become somewhat more involved than that. A route request may need to specify the graph or routing context and the returned result will need to communicate more than simply a list of nodes. At a minimum, I'd expect something resembling:
```cpp
struct RouteResult {
RouteStatus status;
Path path;
uint32_t total_cost;
};
```
The important point however is that the caller shouldn't need to know how the route was calculated.
### How will Pico Router integrate as a third-party dependency?
The goal is to make Pico Router be easily available where embedded developers can conveniently access it. I'd honestly like to once again not go overboard and make it initially accessible as a standalone C++ library through a CMake install. Later I could start releasing pre-bundled binaries if there's any need for that.
Another thing that does look attractive is releasing Pico Router with a dedicated Zephyr thread to make RTOS usage smoother. Once again though, I think time will tell on this one.
### What features will need to change?
Fortunately, not too many of the existing features will need to be outright removed or change significantly. The current progress covers only the most fundamental parts of the system. Still, the short and long term roadmap does change more drastically. Where I was quite intent on getting a hands-on demo as soon as possible not too long ago, the focus now shifts towards creating a foundational stability to build on.
In the short-term I'll drop most work on `osm-convert` and focus on optimising the graph representation for cache aware accessing. Moreover, doing some 'back of a napkin' calculations it became clear to me that even extremely compressed graph representations will quickly fill a micro-controller's flash storage. I'd therefore also be interested in experimenting with a tiled graph structure to allow for bigger sized maps using partial accessing.
Following this logic, I see an opportunity to perhaps make some kind of software based tile cache to fetch larger graph chunks into RAM from SD storage before being accessed by the CPU.
Example of tiled graph hiearchy ([source](https://nextcloud.osgeo.org/s/2P4dfmn5D4xZCno?dir=undefined&path=%2FLumbardhi%2F28.06&openfile=6610351))
## Future Projection
All in all, Pico Router is still evolving and changing and I'm positive about where it's heading. I have deliberately not yet pushed for a formal community introduction of the project seeing as everything is still quite raw. Hopefully by the end of this year I can release an alpha to get some much needed feedback.
Nonetheless, I'll continue writing on here regarding interesting Pico Router developments.