Wishful Coding

I was reflecting on all the fun I’m having with my Arduino GPS system, and found something interesting.

I could have used a Raspi, and have some actual RAM, storage and screen. But by constraining myself to the bare minimum, I created all sorts of wonderful algorithms and hacks.

This is maybe a known thing, but it bears repeating: constraints foster creativity. Writing “a story” is much harder than wiritng “a story about the first brick of the city hall of Amsterdam”. By narrowing down the search space, your brain can do a much more exhaustive search.

An example that comes to mind is LuaJIT. Lua is found in all sorts of places, so a small binary size is a virtue. Someone told me it fits on a floppy, which I found is true.

Consequently, it contains wonderful things like this.

[A recursive backpropagation algorithm with backtracking, employing skip-list lookup and round-robin caching, emitting stack operations on-the-fly for a stack-based interpreter – and all of that in a meager kilobyte? Yep, compilers are a great treasure chest. Throw away your textbooks and read the codebase of a compiler today!]

Once upon a time, Guy Steele set a high tax on special forms (syn-tax, ha, ha…), and consequently invented Scheme. Later, John Shutt thought that wasn’t enough, and invented Kernel. Clojure on the onther hand, is only constrained to be practical.

What is your favourite piece of constrained software? How do you set constraints for yourself?

I stumbled upon Open Street Map a few times, and it seemed like a good idea, but when I actually need a map, I reach for Google Maps.

Until it occurred to me it would be great to have GPS navigation on my bicycle. There are a few companies like Garmin that make them, but from what I understand they are not tailored for cyclists.

I thought this would be a fun Arduino project. Buy parts, download map, write code, profit… right? The buying part was easy.

• Arduino Mega
• TFT shield
• GPS breakout

I choose the Mega because it has 8K of SRAM instead of 2K in the Uno. My research showed I’d need it. I did not get the GPS shield because the pins conflict with the TFT shield.

Downloading the map was also easy, but several GB of XML and a few KB of SRAM is not a good match. I decided the right thing to do is to convert the XML to an R-tree and store it in a binary file on the SD card on the back of the TFT shield.

I spent a lot of time learning Rust and R-trees at the same time.

R-trees are fairly intuitive on the surface. It is a tree of rectangles that contain smaller rectangles. So to find nodes within a certain rectangle, you just have to descend in the rectangles that overlap with your query.

To insert a node, you just descend in the node that is the best fit, enlarging it if needed. But at some point the node is full and needs to be split.

Splitting nodes is the hard part, and there are several ways to do it, of varying cost, complexity, and efficiency. How you spit determines how good your tree is. Mine is fairly dumb.

After I had a basic R-tree working, I used Osmosis to load my map data into Postgres, from where I loaded it into my R-tree.

I recursively wrote the bounding box and offsets to child nodes to a file and put it on the SD card in the Mega.

This was an interesting moment where I was developing C and Rust in parallel. The C development had much less friction, a lot of hacks, and many occasions where I drew random pieces of memory to the screen.

After some more hacking and debugging, I had my first map on the screen! Only it took a few minutes to draw.

Studying my code and SdFat revealed a few things:

There where a lot of nodes where it would read each subnode from disk, check its bounds, and backtrack. I figured that if I stored the bounding rectangles on the parent node, I’d have to read a lot less.

SD cards read in blocks of 512 bytes. I made no particular effort to align my nodes. I think this could save some buffering.

So I formatted the SD card (mistake!) and adjusted the file format so that nodes are aligned at 512 blocks and contain the rectangles of their children. The result: It’s even slower! What happened?

I put some millis() in my code, and it turned out that seek() calls where taking over 3 seconds. I googled around and found that most operating systems suck at formatting SD cards.

I reformatted the card with the official utility and seek times magically went down to 500ms. Better, but not good enough.

It turns out that the reason is that at the edge of every cluster(4KB), it needs to read the FAT header where the next cluster is, in case the file is fragmented. (Now you know why defragmenting speeds up your PC)

But knowing that my file is contiguous, I could use a low-level function to read raw blocks. This was a major improvement, and allows maps at low zoom levels to be drawn in under a second.

The current status is that it can draw a map based on your location, show your speed and some other metrics, and zoom in and out. Source code lives here

I was having some knee problems when riding my recumbent bike. So I did some googling and asking around.

Googling told me that it’s best to pedal 90RPM, but not why. Asking around on the Dutch ligfiets group produced a long thread of good info. This post is a collection of that information.

Before I start, I’ll tell you to go see a physiotherapist. Reading things on the internet is not a substitute for professional care. You only have one pair of knees, and I’ve been told cartilage never grows back.

The problem

Gravity, imago, and wiggle room.

On a normal bike your power is limited to your weight. On a recumbent it’s only limited by your muscles. This means you can push harder than is good for you.

Recumbents have the imago of being fast. So you will push harder than is good for you.

On a recumbent you don’t get “gravity asist”. On a normal bike you can cruise along by just lifting and dropping your legs. This doesn’t work so well horizontally.

People are asymetric, but bikes are not. On a normal bike your hips accomodate this asymetry. On a recumbent your hips are less free.

Why 90RPM

The end goal is reducing strain on your knees, so it is obvious that a lighter gear means less strain.

In this regard the human body is like a combustion engine. There is a speed at which it produces the most power, and a speed where it is the most efficient.

90RPM is the speed where you can produce the most power. 60RPM is the speed where you are the most efficient. Approximately, depending on you and your bike.

Rules of thumb

• Keep a constant pace, vary your speed and gear.
• Don’t fight headwind and hills. Reduce gear.
• Shift to first gear when stopping.
• Reduce gear when slowing down.
• Accelerate slowly.
• First accelerate, then gear up.
• Keep your speed at least above 60RPM.
• Pedal lighly, ride slowly.

How much is 90RPM

Three half revolutions per second. Not that much when you get used to it.

A cheap way to find out is to install a metronome app on your phone, and set it to 90bpm. Now make a whole revolution per 1/4, or one leg per 1/8, assuming a 4/4 measure.

If you’re doing it right it’ll feel like you’re just moving your legs, instead of pushing the bike.

Once you get a feeling for it, let your mind go. I cycle much more naturally and relaxed when I’m not watching every move. It’s not helpful to stick to exactly 90RPM in a non-constant environment. Your body will interrupt you when conditions change significantly.

Other helpful things

Adjust the lenght of your bike real precise. It can be a matter of millimeters, due to the limited hip movement mentioned earlier. Too long and you knees will over-strech, too short and you push less efficiently. From what I heard, the former manifests as pain in the back of your knee, the latter as pain in the kneecap.

Some people report that shorter cranks make it easier to pedal fast. This might be especially true if you’re short.

Some people use oval gears, claiming they provide a more constant feeling. The idea is that the gear is small at the dead spot and large when perpendicular to your legs.

Consider SPD pedals and shoes. At a high RPM a lot of energy goes towards keeping your feet on the pedals. Using SPD pedals make it easy to pedal fast, and as a bonus allow you to pull as well as push.