OSM-based offline bicycle routing on a Cortex-M33 bare-metal device

Help and support
1

Dear OSM Community,
I’m reaching out on behalf of a cycling technology company developing GPS bike computers and other cycling electronics.
We are currently researching an offline navigation solution for a new generation of our cycling computers. Our hardware uses an ARM Cortex-M33 bare-metal MCU rather than Linux or Android, so the routing engine needs to run entirely on the embedded device without relying on cloud APIs or a smartphone connection.
Our current technical requirements are roughly as follows:
ARM Cortex-M33 bare-metal environment
Fully offline routing and navigation
Local route calculation and re-routing on the device
No Linux, Android, or cloud-based routing service
Limited RAM and computational resources compared with PC/mobile platforms
Bicycle-specific routing
OSM-based map and road network data
Commercial consumer hardware
We have reviewed several well-known OSM-based routing engines, including OSRM, GraphHopper, Valhalla, BRouter, and Navit. However, most of these projects are designed for PC/server, Linux, or Android environments and cannot be directly deployed on a resource-constrained Cortex-M MCU.
Therefore, we are particularly interested in the following questions:
Are there any existing OSM-based routing projects or embedded navigation implementations that are suitable for highly resource-constrained MCUs such as ARM Cortex-M?
Are there any projects that have implemented compressed or hierarchical routing graphs specifically for embedded/offline devices?
Among projects such as Valhalla, BRouter, Navit, or other OSM routing solutions, which would you recommend as the best technical reference for developing a lightweight embedded bicycle routing engine?
Do you know of any existing OSM → compressed routing graph pipelines that could be adapted to an MCU environment?
For bicycle routing, which OSM tags and road attributes would you consider essential for building a compact routing graph while maintaining reasonable route quality? For example:
highway
bicycle
access
surface
cycleway
incline
oneway
turn restrictions
From an OSM data licensing perspective, we would also appreciate guidance on using processed OSM data in a commercial cycling computer. Our potential architecture would be:
OSM data → PC-side preprocessing → proprietary compressed routing graph → offline storage on the cycling computer → local routing on Cortex-M33.
Are there specific ODbL or attribution considerations we should be aware of when distributing such a processed routing database as part of commercial hardware?
We are not necessarily looking for a ready-made routing engine. We are mainly trying to understand the best technical direction and avoid duplicating work that may already exist within the OSM ecosystem.
Any recommendations for relevant projects, developers, mailing lists, forums, academic papers, or commercial/embedded OSM routing solutions would be greatly appreciated.
Thank you for your time and for the work the OSM community has put into making open geographic data and routing technologies available to developers.
Best regards,
John

2

I don’t have a direct answer, but there is one aspect of your question that definitely raised my eyebrows and probably those of lots of others too:

ARM Cortex-M33 bare-metal environment

surely you are going to be running some kind of lightweight realtime OS on the hardware, not doing that would seem to be a mistake* (probably with a POSIX compatible api)?

* as in you will end up writing one yourself.

3

First of all, you should get yourself to the State of the Map conference in Paris this weekend where you can talk to people who know about this stuff. I would be happy to talk to you about it (I run cycle.travel) and there are other people there who know lots about the subject too.

You have two challenges and they are largely separate:

  • Constructing a routing graph from OSM data
  • Building an efficient router that can work on your constrained hardware

Don’t let one dictate what you do with the other. Broadly I think you’ll find lots of prior art in the “constructing a routing graph” bit, perhaps less in the second half. That said, there are plenty of papers about speed-up techniques for routing graphs, which you could assess for feasibility on constrained hardware.

Lots of them. But you don’t ship the tags in the graph, you boil them down into a small set of road categories (you won’t need more than 32) and a weighting for each edge.

5

Yes, that could be the only way.

6

Thanks — this framing is very helpful, and we agree on both points: treat graph construction and the on-device router as separate problems, and boil OSM tags down to a compact set of road categories with per-edge weights instead of shipping raw tags.

We’re building a cycling computer on a constrained MCU, so the heavy graph construction will happen off-device and only a compact graph plus a lean router will run on the device. A few follow-ups if you have time:

  1. For graph construction, would you recommend a specific toolchain for producing a compact bicycle routing graph from OSM (e.g. Routino, or your own cycle.travel pipeline)?
  2. Is there a reference set of those ~32 bicycle road categories, and how are edge weights derived (surface, gradient, cycleway preference, etc.)? Even a rough sketch of cycle.travel’s model would be a great starting point.
  3. On the router side, with a tight RAM budget and flash-backed storage, which speed-up technique would you implement from scratch on a no-MMU MCU — contraction hierarchies, ALT, or plain A*? Are there key papers on these techniques you’d recommend?
  4. Is there prior art — papers or projects — on running an efficient router on highly constrained hardware? Any references you’d point us to?

I’m based in Shenzhen, so I won’t make it to Paris this weekend, but I’d be glad to follow up here (or by email) whenever it suits you.

Thanks again for taking the time.

7

You write limited RAM, does that also mean limited flash?

For the projects you mention BRouter is the best reference. It is the only router that can work off-line, you just have to download the .rd5 it needs once.These are data files per 5x5 degrees of the globe, see Index of /brouter/segments4/.

These .rd5 files are pretty good compressed, you could likely reduce the size a bit by filtering lookups.dat and regenerating the .rd5. I do not expect a size reduction > 20%.

I see a ARM Cortex-M33 is in the Raspberry Pi Pico 2 board, dual ARM Cortex-M0+ core @ 200 MHz?

I would say, buy a cheap old second hand android phone and install BRouter on it. Do some experiments, you will see that short routes (<10 km) are fine but longer routes are problematic. Then scale the spec’s of that smartphone to the ARM-M33 and you have an idea on what is possible.

8

Thanks for the detailed and practical advice, much appreciated.

Our RAM and flash are quite limited. We can put the map data on an external SD card, but the firmware, routing index and cache still have to fit in the on-chip RAM and flash.

BRouter is a useful reference for us — it works fully offline and uses the compact .rd5 data files, and your idea of filtering lookups.dat to shrink them is interesting. However, since BRouter is an Android/Java app and the Cortex-M33 has far too few resources, it’s hard for us to apply it directly. We’ll instead study its .rd5 data approach and re-implement the routing logic in C.

The phone experiment you described is still a good reality check for us — it shows roughly how routing cost grows with distance, which helps us size what’s feasible on our hardware.

Thanks again for sharing the experience!