After the near-success of the slide-tube mechanism to convert the fixed-wheel stroller, I started searching for designs that could accommodate a larger turning angle. What I quickly found was that manufacturers don't really design their strollers with future autonomous control in mind. Ultimately I will need to design and build my own tube-frame.

In the interim, though, converting a swivel wheel design seemed the most practicable. These allow a manufacturer to market their stroller as a "jogging stroller" for "fit moms" when everyone involved knows that it'll *really* be used for walking around the mall.

The result is, unfortunately, terrible performance for its stated purpose. While the swivel wheel can be locked, the loose tolerances mean road camber, wind, and debris still affect the direction markedly. In practice it needs moderate steering corrections every 1-2 meters. Add in the weight and it's no great mystery why so many parents give up running when they have children.

The files below are designed specifically for a Baby Trend Expedition double stroller, but will almost certainly work for similar models, and are parametric to apply to different cases. The design accommodates a flat NEMA-17 profile stepper motor.

	Stepper Carrier Bracket
	Angle Drive Gear
	Stepper Drive Gear

Enbiggening the Project

Ultimately this project was spurred by the realization that— while one is tough— having two or more children can absolutely tank a healthy person's ability to exercise.  Research throughout the project has confirmed that strollers— even "jogging strollers"— are just not designed primarily for running. It's literally difficult to fit a side-by-side double jogger out the door, much less push it at any appreciable pace in even perfect (windless) weather.

No more.

I reproduced a very similar motor mount, changed some parameters and made a new drive pulley, and ported all the code to the ESP32. Because of time constraints I'm still using an RC BLDC motor controller, but the ESP32 has a MCPWM peripheral (!!!) that will soon be made use of.

Wireless Control

When I did the reddit thread a common repeating concern was for the safety of the cargo. While a disturbingly high number of people suggested requiring handcuffing oneself to the bars, it's obvious that in 2017 we don't need to do that: we have the technology for wireless handcuffs!

If the phone disconnects the motor is immediately stopped. Unfortunately it's not currently possible to consistently read the RSSI of a peripheral device on the ESP32, but we can vary the transmit power to affect the acceptable range. 

This also gives us a nice readable display and allows a more complicated interface for, e.g. pausing and resuming at intersections or running intervals (short periods of speeding up, e.g. run at your 5k race pace for 3 minutes, followed by 2 minutes slow recovery). 

If I weren't so busy I'd have had lots of opportunities to submit to the Hackaday Fail of the Week tip line.

Learning experiences documented here to help others not make the same mistakes.

• Steering Mechanism: The original screw based design was too slow. I then moved to a cantilevered design with a pivot arm to multiply the force given by a stepper motor. This worked very well, except that the stroller's frame was simply too narrow to allow a reasonable turning radius. My calculations didn't account for the additional dimension of the pulley on one side. It contacted the frame meaning we could only really turn in one direction. The fixed wheel stroller is still so much more stable than the pinned swivel wheel; the fixed wheel stroller it's 100% usable without a steering mechanism.
• CCD Lens: I have a linear CCD soldered up, a steering algorithm in my head, and no way to test it because I can't find an appropriate lens. I made a few trips to Goodwill, but of the cameras I found there were either wild focal lengths or ended up having tightly integrated lenses. I'll probably need to source this from oversees but unfortunately with the lead time it seemed prudent to work on other parts of the project. When I find a source I'll post it in the components section.
• Battery Exploding: Well, not exploding, but the hiss of a large expensive charging lithium ion pack is enough to impress the importance of battery safety on me. I mustered the bravery (?) to grab it and get it outside in case it did flame up, but in the end only a few cells were damaged. The culprit? Bad spot welds from my initial hack of a spot welder came free and focused charging current through the few cells in a parallel bank that were still attached. This necessitated waiting for more cells to arrive, rewinding the transformer with heavier wire and fewer turns, then controlling the weld attributes more tightly (at all). This week I plan to disassemble the entire battery and rebuild it properly, placing the cells in a 3D printed carrier for rigidity. I feel silly for relying on hot glue at this point.

To be blunt, there's been a rough patch. But every time I go out to run with the stroller I'm convinced that it's a worthwhile project that will have a lasting impact on my health (and quality of life) decades out. So we just repeat the process: identify problem, identify (new) solution, implement it!

A quick bit of rough math while implementing the steering control mechanism:

The stroller has two forks that extend out from the back axle 81cm (32in; this is one of the few things I measure that was undeniably designed in inches). The front tire is a whopping 20" in diameter, which is why I originally picked this stroller.

To successfully turn we only need small corrections, which lucky because the forks are only 10.6cm apart center-to-center. A road I often push the stroller on requires a 168 meter (550ft) turning radius, and the tighter circle inside has a roughly 76m radius. With our 81cm wheelbase we only need to rotate the axle

This is .27°. Anyone who pushes a stroller knows how bad it can be if the front wheel isn't aligned; well, there's a quantity to the drift.

At .27° of turn, we will be moving the steering axle (106mm end-to-end), very roughly:

Luckily at these massive radiuses the tolerance to inaccuracy is pretty high, because .5mm is going to be hard to hit with backlash or non-precision hinges. In the real world there's going to be bumps and our steering target (the curb/asphalt transition) will be moving around a lot anyway. And because the computer doesn't care how often it needs to correct steering (although maybe the battery does), we can be confident that this part is very doable.

Let's see how much our deflection will be while not rubbing the tire on the aluminum tubes:

3.3 = (10.6 - 4)/2 where 10.6 is the width of the axle and 4 is the width of the tire

90° - 82° = 8° along the axle. Let's derate it to 6° just to make sure we're not going to rub the tire on the frame.

So, to calculate the turning radius and axle deflection:

Even at the tightest possible turning radius with our 81cm wheelbase, we will have a maximum of 11mm axle deflection. That's some tight turning for a very small input. Depending on how exact the final implementation can be made we might even be able to follow a curb around some city corners!

Note- if you notice any mistakes please comment to let me know!

I have about 25k of "official" distance on the stroller at various speeds and the initial results are better than I'd hoped. It's amazing how useful this is— I find myself thinking of walking or running as a viable option to commute somewhere much more often. Yesterday I needed to drop my son off during my weekend long run (a 20 miler, limited more by his willingness to sit a stroller for several hours)— but because it was only 5km away it was easy to just load him up in the stroller and (not) push him there. I've also taken him to tee-ball practice, and as soon as I build a proper battery mount and get the cargo netting back in place, I plan to use this for grocery shopping (at least until we start to hit 105° regularly).

Power Estimates

It looks like the original 35 W estimate is very close on average, drawing just over 1 amp on flat ground and up to 10 amps on acceleration and up hills. The choice of driving only the front wheel has the intended effect of acting as a limit to acceleration, which also expresses itself as a physical current limiter: after about 10 amps of current the front wheel begins to lose grip and the PID limits the pulse width. This of course means we begin to slow from the promised pace, but it is something that only happens on hills greater than a 6% grade.

I should also note that the current tire is probably ten years old and feels like a worn plasticized rubber— I will be interested to see if a new one grips better, especially for the heavier loads I have planned.

Logging is provided by the speed controller I'm using during testing. Unfortunately, it's rather course data and doesn't seem to be terribly accurate. There are several long durations of a reported zero current where they don't make sense. Even still, it's clear that the 6S6P batter I built is more than enough for the job, and the initial design criteria should be easy to surpass. Once more accurate empirical data can be collected (including with multiple weights to characterize how different-aged children will affect it) a smaller and less-expensive battery can be specified.

The reddit thread has been up for a few days now and is finally off the front page of /r/running, so now would be a good time to discuss the results.

Several people mentioned that they tried running with a stroller but found it too miserable to justify, either because of their physical stature (hunching over or a large stride kicking the stroller) or just the largely increased weight and effort. It seems reasonable to expect this trend to exacerbate for runners with two or more kids.

On the opposite side of the spectrum, a few people seemed to indicate that the stroller didn't change their pace or that they didn't mind its presence. This sounds wonderful, and if we can confer this benefit to anyone else who would like to run I'll consider this project a success.

Pick Your Poison

Most people reported that they tend to push with one arm, usually to the side of the stroller. Only one reported that they run to the left side and hold with their right arm, although which side of the road one runs on would be dictated by the direction of travel in their country.

We could call this the runner's preference, but keep in mind that most people will tire of one position and trade arms (if possible, e.g. shackled runners cannot) or move around in the course of their run.

*Off to the side implies one arm.

For the U.S., these results make me more confident behind the current design of buttons placed on a grip on the right side of the handlebars. These buttons are accessible with a left thumb when running on the left side of the road (against traffic), but also for most people's dominant hand when running behind the stroller.

I recently posted a thread on reddit linking to this project and asking for feedback on how the people of /r/running run with a stroller. I will present the results soon, but in the meantime I'd like to address a topic that came up over and over again.

A little perspective

I want to stress that the results were overwhelmingly positive, but several people raised concerns that they would suddenly pass out and their child would be mindlessly driven into the next intersection. I love that people are asking questions and thinking about the application of the RoadRunner! In that respect, it may be useful to gain a little perspective in order to define the problem clearly and arrive at a better solution.

Personally, I've been running about 10 years now (including the last 786 days in a row) and have yet to lose consciousness. Judging by my peer's lack of knee and elbow pads, they don't seem to even anticipate falling over during the thousands of steps they take every week. So when we're discussing motor control safety, we’re talking about two things: a fringe edge case, and a feeling of security. Both are equally important to the design for their own reasons, and we have the means of solving both. So let’s take care of them!

Mitigating Stroller Insecurity

The choice of the driven wheel (the front only) means that as power is applied, the center of gravity causes the wheel to slip, limiting acceleration. In testing this works great— combined with a speed governor, the stroller does not feel like it’s going to “get away” from the runner, even when the pace is set too high. With predictable autonomous steering, I think this will be even less of an issue.

However, trusting a black box is different than trusting code you’ve written (or even open-source code you’ve read), and the feeling of control is extremely important when you’re strapping your kids into a robot of sorts.

Design Criteria

The safety system must:

• Provide a feeling of security
• Allow the parent to stop the stroller remotely
• Stop the stroller with no manual intervention in an emergency

There are lots of solutions that come to mind, and many were shared on the Reddit thread:

• Hand straps (shackles, if you will) that simply chain the stroller to the parent.
• A somewhat less intrusive strap, magnetically attached, that removes power if disconnected
• A watch-dog timer type solution with a button that polls for parental presence.
• One or two Lawnmower-style grips that must be held onto and kept closed to maintain power
• RF Proximity detection

After reading through responses, lots of discussion, and considering the implications of each, wireless proximity detection seems like the only reasonable solution. The other solutions are so encumbering—and most easily defeatable— that they would be of limited utility.

Solution

Bluetooth LE offers a Proximity profile (PXP) that fits our requirements exactly, and to a lesser degree the Link Loss (LLS) profile. A small remote powered by a LiPo pouch battery will be paired to the main controller. The remote has a belt clip and single stop button for emergencies or just when done running. Because I have some NRF8001 chips on hand initial development will be done with this chipset, but the real design work is around the Bluetooth protocol itself.

The remote plugs into the stroller for both charging, pairing, and storage. Because of the number of easily-available parts, 5V is a convenient step-down voltage to power the logic & control rail. In this same vein, charging will be handled by a MCP7381. Providing a 5V rail also makes it possible to provide a charging port for a phone or tablet.

The connector and storage mechanism needs to be physically robust and sweat resistant. Electrically, three pins are required: a ground reference, charging voltage, and communication. The remote will house a one-wire eeprom. When the stroller senses the remote insertion by way of the one-wire bus going to a high level, it will ensure that its bluetooth MAC address is written to the eeprom. Upon removal the remote automatically pairs with this address, providing a simple, robust, and secure pairing process.

Physically, the connector will encompass about half the remote. Three spring-loaded pins (think pogo-pins) will be at the bottom of the slot. When the remote is inserted, the pins will make contact with pads on the end of the remote. Charging will only be enabled when voltage is sensed on the communications pin.

Because I wanted to get empirical data (and also because I actually need this to continue marathon training) I built a prototype. The new motor mount design is far more robust even though it's less metal, and the stroller did great even up a large hill and in heavy wind.

Very pleased with the initial results.

With all the previous discussion done, the motor mount is largely specified for us. It has a several deductive requirements. The motor mount must:

• Drive front wheel
• Allow steering adjustments (and so be mounted to the axle)
• Gracefully handle large momentary torque and vibration
• Accommodate a 185mm diameter drive pulley
• Accommodate a 50mm brushless motor

There are also a few requirements that follow to make the design robust:

• Accommodate a 35mm idler pulley to assure adequate belt wrap around the small 14 tooth drive pulley
• Allow for reasonable cable management
• Place the motor behind the front wheel to protect it from accidental bumps

In order to not interfere with the front wheel mounting tubes, we need the motor mount to be rather skinny, but not bend. We can accomplish this by using 16GA steel with a reenforcing bend at the top. This design could be stamped in one operation, lending to cheap manufacturing.

This is actually the second iteration of the mount. Testing so far has shown almost no belt slip even with high transient torques (when a PID value may have been typo'd) and low static drag when the motor is off.

Prototype

In the design phase it's often useful to throw around hyperbole to weed out faulty assumptions and hone in on the true design criterion. One of the most important ones that we've noted is that the stroller aid in enabling exercise. Throwing in the hyperbolic possibility of, say, driving in tight circles, it becomes clear that just enabling forward motion is not enough.

While the placement of the our fixed wheel doesn't exactly allow tight circles, it does raise the possibility of having the stroller wander. Having to constantly grab the stroller, yank it back on course can lead to a focus of attention where the stroller will dart off to can make for a decrease in situational awareness and actually lead to a compromise in safety. Testing has borne this concern out.

So with the problem fleshed out, let's try to solve it.

We could:

• Have preprogrammed routes that the stroller autonomously follows
• Make the runner carry a hand-held steering joystick to drive
• Have the toddler steer
• Watch the runner's position behind the stroller and adjust accordingly
• Wait for Elon Musk to get that brain-computer interface working
• Follow some sort of inferred path

Each of these have disadvantages. Having to preprogram a route robs spontaneity and adds an additional hurdle to getting people outside. Carrying additional equipment can be troublesome for form. Watching the runner's position means they can never run alongside the stroller to help pass a juice box, check on a sleeping baby, or grab a quick drink.

Following a Path

Luckily, there is a path almost everywhere I've ever wanted to take a stroller, and it has clearly defined edges that make for reliable computer vision: the curb. Since running strollers are barely too wide and driveways cause bumps that are barely too large, running in the road becomes necessary. Almost all roads on which one can safely push a stroller feature a concrete (light-colored) curb and skirt adjoining asphalt (which is darker colored). In Phoenix, these concrete skirts often continue even through intersections to aid in drainage during the monsoon season.

This can be monitored by a Raspberry Pi with OpenCV and run through a PID loop to maintain a fixed distance from the curb. Because the goal is not to navigate a mall or amusement park, large deflections and tight turns are not required or desired. When the curb disappears (which, by design, we expect to happen regularly) the wheel can be quickly returned to the center position.

Obstacles

While the path is straightforward there are a few obstacles that need to be considered. Be it trash cans, parked cars, or other people, there will be situations where things get in our way. While it would be technically possible to autonomously steer around parked cars, it would require a turn into potential vehicle traffic. Safety, then, would require sensing traffic presence and speed, and then calculating how much time we have to get around.

Obstacle avoidance, then, will be handled by front-mounted distance sensors to alert the parent and communicate to the power control system. We can brake at the last moment if the runner doesn't react. Our goal is to honestly aid runners, rather than making a poor attempt to automate the entire activity.

Kits

By design, the system should not modify the commercial stroller heavily. If the original front linkage can be slid off and the new steering linkage slid on, building conversion kits becomes a real possibility.

Linkage

Most running strollers (sorry, Jogging Strollers) are equipped with a fixed front wheel. This is a reflection of the design goal of predictable forward motion as opposed to tight turns. However, it poses a challenge for steering.

The current design allows the front axle to be loosened and the slipped to adjust forward tracking. My steering linkage will replace the black plastic inserts with a 3D-printed screw mechanism to allow varying one length of the wheel support.

The stepper motor will either need to fixed to the wheel causing the screw to rotate, or fixed to the tube causing the nut to push and pull the screw. The fixed support nuts would then need to slip inside the tube. A final weld should be placed on the end of the screw to prevent a software bug from disassembling the stroller while in motion.