Bike computer project

Status
Not open for further replies.

MichaelMC

Well-known member
Bike navigator/computer project

This this an ongoing project to develop a bespoke bicycle computer & navigator based around the Teensy 3.6 MCU.
In this thread I hope to log current progress and any milestones achieved, with today being such a milestone. This is MkII. Mk1 is complete, in-use and developed around the power hungry and bulky Arduino Due.

You may have seen this thread: This was the first milestone; building a vector backend for the font render. Given the nature of this project, bitmap fonts would not have been suitable.

Second milestone was developing applications which would parse, strip and convert raw OSM (OpenStreetMap) vector map files in to something usable and exactly required for the task at hand. This initially resulted in generating over 100k 'polyline' files and around 1k POI (PointsOfInterst) data files. The 2GB SD card didn't like this. Those 100k were then further reduced to ~6k files by packing each file in to one 16x16 file with a small lookup header. POI files were then reduced to around 450 by further eliminating what wont be displayed and what is of no use (I don't need to know that green patch is a Golf course).

Third: Produce an initial proof-of-concept desktop application with the intent of amalgamating the vfont library, developing the various algorithms required to select, load and render various polyline, polygons' and POI data files with the memory constraints of a Teenys 3.6.
This can be seen here:

Today: Finally we have everything running on the Teensy: What this is showing is a Garmin bicycle activity, as recorded during a stage of the Giro'd'Italia race, converted to a floating point latitude/longitude array and then run through the engine. This shows a per frame render time to be around 10~20ms, based upon zoom level and objects rendered. Anything greater than 1 second wouldn't have left much time for for the important stuff, such as 10hz GPS data acquisition & processing.


Next:
(1) Implement the AntPlus library code as posted previously.
(2) Write a new library for UBlox GPS modules concentrating solely on the UBX (binary) protocol.
(3) Develop an interface (initially on a desktop), and with that, a skeleton application core to form the basis of the computer.
(4) Whatever I've forgotten.
 
Last edited:
Really cool! FYI, my startup has an open-source (MIT License) uBlox library for the UBX protocol if it's helpful:
https://github.com/bolderflight/UBLOX

If you have any feedback on the library, I'd love to hear it. Great work so far, looking forward to seeing how this project progresses!

Brian
 
Really cool! FYI, my startup has an open-source (MIT License) uBlox library for the UBX protocol if it's helpful:
https://github.com/bolderflight/UBLOX

If you have any feedback on the library, I'd love to hear it. Great work so far, looking forward to seeing how this project progresses!

Brian

Cheers.
What I'm doing on the Due in runtime configuring the GPS module as per user display page (UI) ubx packet requirement, keeping processing overhead, and therefore latency, as low as can be. A one off base-station config isn't suitable here.
This is my ubx config code View attachment ubloxcfg.zip. Note the glorious use of magic arrays. This has to go, hence the ground up rewrite.

I like your MPU9250 library, I'll probably use that as it is as this project also contains an MPU9250 module.
 
Cheers.
What I'm doing on the Due in runtime configuring the GPS module as per user display page (UI) ubx packet requirement, keeping processing overhead, and therefore latency, as low as can be. A one off base-station config isn't suitable here.
This is my ubx config code View attachment 11238. Note the glorious use of magic arrays. This has to go, hence the ground up rewrite.

I like your MPU9250 library, I'll probably use that as it is as this project also contains an MPU9250 module.

That makes sense. We were going for simplicity over strict performance, so we picked a single packet that has all the needed information for most vehicle applications rather than selecting the packet with the smallest size. Putting in uBlox configuration and supporting more packets has been on my "To Do" list, but it's pretty low priority at the moment.

We also have a driver for the BME280, a lot of bike computers have an altimeter for ascent / descent so that might be useful:
https://github.com/bolderflight/BME280

Best,
Brian
 
Been working on Points-Of-Interest (POI) performance. Now its at a level I'm happy with and without microstuffering or the dreadful render times when anything POI was on scene.

In this video it shows a 2km view window but with the load restrictions of the smaller (see above) 170m viewport for the target 320x240 display, where the vector blocks can be seen loading and unloading:
 
I think this is a really neat project. I once thought about trying something like this but never got past looking at some vector data.
 
Status
Not open for further replies.
Back
Top