The Design Phase is in progress! See below for the current project discussion.
For everything in chronological order, click here.
All work licensed GPLv3 unless otherwise specified.
Mobility for families to enable active lifestyles
The Design Phase is in progress! See below for the current project discussion.
For everything in chronological order, click here.
All work licensed GPLv3 unless otherwise specified.
A quick fan to mount on the motor. - Center bore may need to be reamed to 14mm - Mounting bolts drilled to a bit over 3mm and countersunk depending on what hardware you have on hand :)
Standard Tesselated Geometry - 2.63 MB - 05/03/2017 at 23:33
Modified timing belt pulley to allow spoke mounting
scad - 21.92 kB - 04/27/2017 at 22:00
Parametric idler for belt tension and adequate pulley wrap
scad - 2.19 kB - 04/27/2017 at 22:00
Buttons for including in a handle control
scad - 2.42 kB - 04/27/2017 at 22:00
Handle mount for speed-control buttons.
scad - 6.64 kB - 04/27/2017 at 22:00
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).
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.
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.
|One Arm||Two Arms||Off to the Side*|
*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.
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!
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.
The safety system must:
There are lots of solutions that come to mind, and many were shared on the Reddit thread:
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.
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...Read more »
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:
There are also a few requirements that follow to make the design robust:
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.
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.
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.
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.
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.
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.
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...Read more »
“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.”
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.
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.
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).
The Runner Interface is experimental at this point.
|Potentiometer||- Infinitely Adjustable|
- Easy implementation with a lever
- Immediate stop possible
|- Noisy Reading|
- Difficult to set exactly
- Easy to accidentally change
- May react to bumps in the road
- Wastes a small amount of current
- Open loop is prone to accidental starts
|Buttons||- Easy to locate while bouncing|
- Treadmills have nearly standardized for a reason
- Easy to program
|- Difficult to place physically in a professional manner|
- Difficult to instantly communicate intent (encourages repeated presses to arrive at final value)
- As a consequence...
The battery choosing script is now on GitHub. It goes through a popular website's listing of battery cells and tries to build the best pack it can given minimum parameters and quantity price breaks. The cheapest cell will not always make the least expensive pack.
I'd love to make this into a fully parametric web application some day.
Because each LiPo cell has a nominal voltage of 3.7 volts, to achieve our 35 watts of power we would need to discharge at (35/3.7 = ~9.5 amps) continuously. During start up, against wind, or up a hill the required power will be much higher. In fact, for a motor rated at 1500 watts max we would be drawing 400 amps! At these currents even the wires that deliver power to the motor start to look like resistors.
Because of these losses, it turns out that motors (and a lot of things) are generally more efficient at higher voltages and lower currents. This is a big part of why power line transmission is done at such high voltages when your phone only really wants a little over 4 volts to charge.
It can be extremely difficult to balance the wide variety of cells available against cost. So I wrote a quick script to scrape a website's catalogue and make suggestions for me. It did a better job than I did initially, and so for this project we'll start with a 6-series (6s) battery pack. This will range based on its wear level and state-of-charge from between (3.7*6)= 22.2 volts and (4.2*6)= 25.2 volts. At our average 35 W, we will be near 1.5 amps discharge. This lower discharge rate has the added benefit of helping the cells age much better.
Brushless DC motors are usually given a rating called Kv. This can be read as their "voltage konstant" and specifies, generally, how many RPM a motor needs to turn to generate 1 volt. It's usually interpreted the opposite of that, though: how many RPM a motor will turn per volt of potential. This can be confusing at first— doesn't the frequency generated by the controller determine the rotation speed? Well, yes, but only by controlling how "hard" it throws the rotor forward to the next pole; a motor will never spin faster than its Kv rating.
So how fast do we want to spin? Earlier we specified that we need to move at a 4:30/km pace. The test stroller has 20" wheels with a circumference of approximately 1.6 meters. That means it needs to spin 625 times per kilometre over those four-and-a-half minutes. 625/4.5 = ~138 RPM. If we want to do tempo runs at a 20min 5k pace, it's closer to 158 RPM.
The aircraft hobby scene has developed a ton over the years, and good compact brushless motors are available relatively inexpensively. However, with a 20" pneumatic drive tire nothing will have the torque required to start from a stop without some gearing. This is actually great, though, because the most powerful motors have a low Kv rating. At ~23 volts we will need a rating less than (23 * 138) = ~3200. 23:1 gearing would be challenging as well.
Now might be a good time to think about how a spinning motor can effect a spinning wheel. There are a few specific aspects to this and they're mostly related to one fact: running strollers do not have a swivel wheel. Steering is performed as seldom as possible, and made possible by an intention location of centre of gravity near the rear axle. This prevents mishaps where a swivel wheel meets unpredictable ground, self-turns, and the stroller self-topples. Kids can present certain attitude-oriented challenges while running, but violence is never the answer.
Taking this idea further it becomes clear that driving one of the rear wheels will cause yaw-slip and make straight travel a challenge. Counter-acting this by driving both wheels may be feasible, but separate driving wheels doubles costs and seems inappropriate for an application that primarily will go straight. Using one motor (and thus locking both wheels to the same speed) will either prevent turning entirely or require the fabrication of a limited-slip differential. For a stroller.
Driving the front wheel, however, will have the added benefit of allowing the parent to lift the powered wheel off the ground if an immediate stop is required. Generally, as a rule, I strive to put as few bugs as possible into my code, but when children and cars are potentially involved a safe...Read more »