“I believe it’s jogging or yogging. it might be a soft j…apparently you just run for an extended period of time. It’s supposed to be wild.”

Keep Moving

Most runners, once they get going, are loathe to stop. It's either a good situation where they're feeling good and loving every minute, or the sober realization that starting again would be more painful than just continuing to grind.

Further, with all due respect to Jeff Galloway, every race or group run I've been involved in has featured runners at a consistent pace. Many even push the uphills and coast the downhills. Relentless Forward Progression.

To satisfy our design criterion that the project make going running easier, we need to respect the patterns inherent to how people exercise. For us, that means a P.I.D. controller.

011100000110100101100100

The digital world is often hilariously exact, but in a way that is completely oblivious to intention. In many programming languages, 3 + 0.6 = 3.5999999046, because the computer is dutifully reporting how many slices of a number are closest to 0.6, not actually interpreting the question as a human would.

For speed control, this can be an issue. If we tell the stroller to go 13kph, it's straightforward to calculate motor RPM based on gear reduction and drive wheel circumference. A transfer function can then be determined to define "effort" (in the current case, a pulse-width corresponding to throttle input).

But what happens when, as happened this evening on a test run, a gust of wind blows head on? The effort level will now correspond to a lower wheel RPM than anticipated by our transfer function, and the whole rig slow down. The opposite situation will happen barrelling down a hill; it's best not to apply any effort there.

We could try to model these things, but ultimately one comes to the conclusion that the real world just isn't predictable. Enter the PID algorithm. PID adjusts the "effort level" based on how far off we are from where we want to be. It checks three times in three different ways, and adds all the results together to determine what our next effort level should be. Currently, we check every 100ms.

• Proportion just adds a percentage of how far we are off. If we want 1500RPM, but are at 1000 RPM, our error is 500 and proportion will add P * 500 to the output
• Integral looks at how fast the error is changing, and adds a slice of that. If our last error was 500, and our current error is *still* 500 even after applying the last proportion, integral will now respond with a slice of (500+500=1000).
• Derivative acts a damper to oscillation and is usually negative. It looks at the speed at which the actual RPM changes and dampens it if it moves too quickly. If we make a change which is responded to very quickly, the next PID output will be much smaller under the assumption we're nearing the target.
  

Hardware

For the first iteration to empirically test power needs I'm using an off-the-shelf airplane ESC, a Castle Creations Edge 100. This accepts, every 20ms, a 1200µs to 1900µs pulse communicating throttle. This PWM signal is generated by an ATXMega32A4U development board I made a few years ago.

The ESC delivers the motor RPM using a square wave out of its auxiliary wire. This is fed into the XMega on PORTD.0 and a timer counts the edge changes. From here we can calculate motor RPM (and thus wheel RPM).

Input

The Runner Interface is experimental at this point.

Initial testing has shown that a boat-style throttle lever on a potentiometer is inappropriate for running. Besides noise mitigation and erroneous readings causing false starts, it's just too hard to change while moving.

As I have kits in mind, one unwritten requirement is that we modify the commercial stroller as little as possible. Button controls can be added by essentially clamping a bent Twinkie to the handlebars.

the curve keeps the controls near the brake lever, and the positioning allows the left thumb to increase or decrease speed. I've noticed most people prefer to run to the side of the stroller to remain closer to it without shortening their stride, and it's only safe to run on the opposing (left, here) side of the road. Personally I'd rather have my child closer to the curb than sacrifice him as car buffer, so that puts me to the right of the stroller steering and pushing with my left hand.

Next Iteration

Given the initial success of these tests, the next steps will be developing a concise display showing set speed, battery level and distance traveled. Removing the middle man and developing my own BLDC inverter is also being planned. This will enable much tighter PID integration, much more intelligent braking, and to a (unfortunately very) small degree regenerative braking.