Pneu Scooter: Δt2

Pneu scooter large tasks:

1. Stator and rotor. Δt1

2. Deck fabrication. Δt2

3. Batteries. Δt2

4. Wind motor.

5. Motor-to-wheel adapter fabrication.

6. Optical encoder.

Time step #2 takes out two whole tasks: deck fabrication and batteries. They kinda go together, since the deck is primarily a box for the batteries (and secondarily something to stand on). I've learned my lesson about sheet metal decks, and I don't have the patience or waterjet access required to design complex interlocking tab/slot decks. I wanted to make billet scooter - a deck machined out of a solid block of aluminum - but my fabrication skills and personal discretionary funding are not up for that. So, I settled for the next best thing, which is a deck machined from a single aluminum u-channel.

It started as McMaster PN 1630T351. Cutting it to length was easy, but taking an inch or so off the legs was not trivial. My first thought was to clamp it base down in the mill and face the legs down to size, but this would have taken several very noisy passes. The final "solution" was to stuff three 2x4s in the space between the legs (which is conveniently 4.48"), clamp the whole stack sideways, and slice through the legs with a 1/2" end mill. This left a fairly rough surface, so I went back to Plan A for a finishing pass. The wheel well was a quick bandsaw + finishing job.

Then came the part I was dreading. 14 instances of blind-tapped 4-40 holes into the legs, plus six more into "firewalls" in front and back. It took the better part of a Sunday afternoon. I became progressively more careful because breaking a tap off in hole #20 of 20 is not a good thing. I actually did break a bottoming tap, but luckily it was in one of the firewalls which is an easily replaced piece of polycarbonate.

Should have used t-nuts...

The good thing about tapped holes like this (as opposed to t-nuts) is that it gives me a fighting chance to make the deck splash-resistant, something that would help if this is to be a true commuter vehicle.

I really like the construction of this deck. It's a good deal sturdier than BWD's sheet metal construction. The polycarbonate bottom is "abrasion resistant" (we'll see how long that lasts...) and allows the battery to be bottom-loaded instead of squeezed through an impossibly small hole in the front like BWD. Speaking of the battery:

Mystery battery is mysterious.

Actually, it's the same battery as BWD: a 20-cell A123 26650 pack in 10S2P configuration. (It's exactly like two 36V DeWalt drill packs in parallel.) In fact, for all you know that's what it is... The total pack is 33V and 4.4Ah. Unlike BWD's pack, this one is soldered instead of welded and great care was taken in laying out balance and power leads since I thought the deck space was going to be tight, especially width and height dimensions...

...Turns out I did so well that it slipped right in from the front anyway, with room to spare. The power leads come off the back to where the controller will be. I chose to put the balance leads up front for access through some kind of yet-to-be-designed flap in the front firewall. Turns out Digi-Key sells JST-XH connectors, the standard for small battery balance leads, in many sizes for pennies each. To them, I can attach the closest thing I will ever have to a battery management system:

LiFePO4...so consistent.

That's it for now. Next will probably be motor winding...

Pneu Scooter: Δt1

I'm off the Singapore in about three weeks to visit the brand new Singapore University of Technology and Design. It should be an awesome trip - my third time in Asia, but my first trip longer than two weeks. Since it will be all cold and wintery in Boston by the time I get back, I sort-of want to finish Pneu Scooter before I go. Not that I'll have any time left to ride it, but it's just good to have some kind of deadline to force me to do it. (As a graduate student, it now takes me at least twice as long to do things I used to be able to do...)

So, here we go, time step #1:

I don't know why there is mixed fruit in this time step.

I really dislike adhesives. But they are a necessary evil and I am trying to get the sticky parts of the scooter build out of the way early. Gluing the stack of stator laminations together is one of those unavoidably messy processes involving three quick clamps, CA glue, some two-ton epoxy, and a sacrificial brush. The CA quickly wicks into the laminations, tacking them in a few places, then the epoxy makes a final coating on the outside surfaces.

You'll notice the two 1/16" plastic end laminations also glued to the stack. These are slightly oversized versions of the steel laminations that serve to protect the corners of the stack, preventing them from digging into the thin enamel coating on the magnet wire. This is in lieu of a complete epoxy coating on all the steel surfaces (or slot wedges). Hopefully the extra-large air gap will allow enough wiggle room for the epoxy coating and slight skew of the stack. If not, some creative lathe work may be in order.

This is the main wheel-motor shaft, made of 7075 (for the alloy cred). In the wheel-motor design, the shaft is stationary, so it's tapped on both ends for attachment to the rear deck forks by way of 1/4-20 machine screws. The two roll pins slide into a slot on the stator laminations, keying them in place and transmitting reaction torque to the shaft. Finally, the milled slot is one of many ideas I've stolen from Charles about how to build these things. Rather than drill cross holes and try to pass wires through the center of a hollow shaft, as in BWD, the three wires will simply lie side-by-side in the slot to pass through the bearings:

The slot faces upward, while most of the bearing load is borne by the bottom half under normal usage, so this doesn't significantly hurt the structural loop. So, please don't use this design for your inverting roller coaster with in-wheel motors (!!! That would be awesome!), but for a scooter it's fine. The pass-through wires are only 16AWG, but short and surrounded by aluminum, so they will definitely not be the I²R bottleneck.

Here's the stator-on-a-stick, next to the new rotor, also glued and drying now. The reason I don't have incremental pictures of building the rotor is because it literally took 10 minutes. It's made of three 1/4" plates of low-carbon steel, waterjet cut to the same time-saving shape as BWD's rotor laminations. The magnet indents remove all of the hassle of spacing and gluing (though it is still quite possible to crush your fingers). So, it went together so fast and my hands were so sticky that I couldn't take any pictures of the process.

Anyway, that's the current state of things. Next I will need to tackle one of many remaining large challenges: either machining the deck, winding the motor, machining the critical wheel adapter plate, or making the battery pack. Or, you know, all of those. Only the next time step will tell.

Pneu (New) Scooter

And the winner is...

...the skinny pneumatic wheel.

After careful consideration, this is the wheel of choice for my new kick scooter project, beating out three other options. It addresses one of the most significant problems with BWD: the flat, hard, urethane wheel treads. A pneumatic tire will afford much better ride quality, not to mention vibration and shock absorption for the frame and electronics. And at 6", it will be able to clear larger cracks in the sidewalk or the road. But, it's still closer to the kick-scooter look and feel than large electric scooters with 8-12" wheels.

Pneu Scooter, as it will now be called, is my new attempt to play with the engineering trade-offs of electric scooters. Size, weight, range, power, noise, ride comfort, and durability are just some of the interdependent knobs you can turn. I wish I could make a cool visualization to show how I'm (blindly?) feeling my way around this design space, but I can't, so here's 1,000 words instead:

Starting with size. I should be very clear that I'm making a kick scooter. A kick scooter is like a Razor scooter or a Xootr, not like the kind you sit on. Going a step further, I'm not interested in a bulky/wide electric kick scooter such as...well, pretty much every commercially available one. Stealthy electric kick scooters are all the rage these days, enabled by lithium-ion batteries and cleverly-designed in-hub motors. The problem is, 125mm hard urethane wheels or the equivalent are no match for the 200x50 (mm) pneumatic tires on most commercial electric kick scooters. At 150x30 (mm) these wheels are a good compromise.

This is what happens when you mix SolidWorks with MSPaint.

IMO, it totally looks like a normal kick scooter with these wheels. Maybe not the little kid's Razor scooter...but it could easily pass for one of the slightly larger models. The key difference is that, as depicted in an artist's rendition above, it can ride over sidewalk cracks without the freight train effect thanks to the pneumatic tires. Can it hop curbs, clear speed bumps, jump potholes, or ride over railroad crossings...probably not. But hopefully it will have just enough shock absorption to protect the important stuff from the normal scooter environs of asphalt + sidewalk.

Unlike BWD, Pneu Scooter will only have rear wheel drive. BWD had an "excessive" amount of torque anyway, and having one hub motor will cut down on weight and complexity. Speaking of the hub motor, the reason you don't see it in the above render is because it's on the other side of the wheel. (I tend to ride right-footed, so I lean left.) Here's a close-up render from the other angle:

The hardest part of using these wheels is adapting BWD's hub motor design to mount directly to the wheel rim. Ultimately, there's no way to make this wheel/motor combo as stealthy as, say, Project RazEr. It's going to stick out, the only visible clue that it's not a regular kick scooter. But it is still more compact and more quiet than a belt drive. In fact, with sinusoidal commutation it could be nearly silent. Here's a closer look at the motor construction, as planned:

The stator is made of leftover BWD laminations from Proto Laminations. These are custom ~83mm laminations that, no offense other-mini-hub-motor-makers around here, kick ass compared to copier motors. They're optimized for torque. To complement these, the rotor will have 1/4" thick NdFeB magnets, just like BWD. These allow an extra large air gap without too much performance loss. For the rotor can, I'm trying something new. I don't have any more Proto rotor laminations, but I also really dislike the idea of relying on adhesives to hold magnets in place. So, I sent BWD's rotor file to Big Blue Saw's low-taper waterjet service, to be made from 1/4" cold-rolled steel plates. 

The rotor sees less time-varying flux, since it's dominated by the permanent magnets, and so solid steel will suffice as far as eddy currents are concerned. But, unlike a plain cylindrical can, this will have indents for aligning 14 magnets, which will make assembly a lot easier. This trick on BWD probably saved a full day's worth of spacing and gluing magnets. This rotor and stator are shorter than BWD's, which will trade a bit of torque for speed, all other things being equal. Just something to keep in mind when choosing the number of turns for the winding.

The most important part on the whole scooter is this one:

It's responsible for basically all of the alignment of the rotor and stator, and is my attempt to mitigate the risks of using the plastic wheel hub itself as part of the motor's structural loop. This adapter, made from aluminum, has features on both sides which interface with the outer surface of the wheel rim and the outer surface of the rotor can, hopefully making them concentric. Seven countersunk 4-40 screws hold the adapter to the rim, while seven through-bolts into tapped holes in this part hold the rotor to the adapter. This is the "scary" part of the build, but hopefully the extra-large air gap and outside bearing will help out here, too.

The shape of the wheel lends itself to this design mostly because the concavity in the hub matches up with where the motor windings will be. This will allow plenty of room for termination and wire exit on the wheel side of the stator. Here's a cross-section showing the space inside the motor:

If anyone says "three bearings" in the comments I will hit them with Alex Slocum's book.

The exact winding (configuration, wire gauge, and termination) is TBD. I will be targeting a torque constant roughly equal to BWD's front motor (0.20 Nm/A or Kv = 47rpm/V). But, it will have a denser winding, utilizing all twelve teeth instead of six, so it should be able to pull more Amps. I would be happy with 30A-40A peak and 15A continuous at up to 33V. Having holes in the wheel hub raises some interesting cooling possibilities, though I will probably want to seal those for weatherproofing instead and just live with lower continuous current.

To supply the power and range, the deck is essentially a battery holder made out of McMaster PN 1630T351 aluminum U-channel:

It'll have exactly the same batttery pack as BWD, a 4.4Ah LiFePO4 battery at 33V. So, 2xDeWalt. Unlike BWD's front-loaded pack, this one will be bottom-loaded. This means real structure at the front of the deck where the Razor handlebar will attach, the bane of BWD's existence. Fool me once...

Lastly, the controller will be the 3ph HD, mounted upside down to the semi-infinite heatsink / deck. Sadly, it will probably not be playing music while moving, since it requires a host computer to stream the MIDI file. But, maybe in a small room as a demo. Otherwise, it'll make a good load test for the HD under normal operating conditions at 500-1,000W input.

That's the plan. Time to press play.

Wheels!

I acquired lots of wheels this week.

The motivation: With so many scooters being built around here these days, I felt left out. Not that I don't have an electric scooter already; amazingly BWD still works just fine. Or rather, the only problems with it are more fundamental ones that can't really be fixed. For one, the frame, especially the folding joint and its mount to the deck, lacks complete rigidity. But most noticeably, the wheels are flat, 1.5"-wide slabs of 1/4"-thick, 80A-hardness polyurethane. That's not much shock absorption, and makes for a particularly unenjoyable ride on anything but smooth asphalt. Not to mention the impending fatigue death of the motors, frame, and electronics.

I don't think this is a problem with BWD's design, specifically. Kick scooter wheels in general are not designed with ride comfort in mind. I don't plan on doing any offroading, but I really would like a kick scooter-sized stealth EV that can operate equally well on asphalt, bad asphalt, and sidewalk. It would make commuting around Cambridge much more feasible. So I started investigating alternative wheel options in the 6" range, to allow for BWD's motor size plus some additional compliant material of some type.

Wheel Option #1: The Reach

The McMaster Tweel

This was the most risky and ambitious option. (Since I'm already talking about it in past-tense, you know there's a catch.) It's a tweel, which is a special type of compliant solid wheel. This particular one is a 6"x2" model from McMaster-Carr (#5002T63). It was a $100 gamble, since I had only the crappy McMaster sketch to go on. And, well, I lost. It's actually really hard. Even with the tweel ribs, the 95A urethane would not yield any smoother a ride than BWD's wheels. I guess I should have inferred that from the load rating of 1,000lbs. The profile is also flat, which makes turning more awkward. Oh well. It makes a really cool desk ornament, and might some day be useful for something, so I'm not returning it.

Verdict: Useless for scooters, but good for impressing office visitors.

Wheel Option #2: McMonster Truck

This is also in the 6"x2" category. It's actually part of a McMaster-Carr caster (#22925T18). It's a rather wide aspect ratio for a kick scooter wheel. (Razor scooter wheels are more like 4"x1" or 5"x1".) It's not as absurd as BWD's 5"x2", but it's still not as sleek as I would like. It is pneumatic, though, which offers far superior shock absorption than solid urethane tires.  Other things it has going for it are a durable low-profile tire and an easy-to-work-with rim with a flat reference surface for attaching a custom hub.

Verdict: Durable and easy to work with, but not aesthetically appealing.

Wait. Wasn't there a good reason why it's difficult to add hub motors to small pneumatic wheels?

Oh, right. That.

Yeah, a pneumatic mini-wheel-motor-thing would have to contend with the valve stem of the inner tube, which invariably protrudes into the space that would normally be occupied by the motor. On bikes, this is no problem, since the hub motor is much smaller in diameter than the wheel. But on a scooter, you need as much motor volume as possible to get power out of such a small device. The torque is limited by size and the speed is limited by lack of any gearing, so having a large air gap to outer diameter ratio is important. (If you want to learn more about how to design a miniature in-wheel motor, you should read this Instructable.)

I seriously debated just putting a belt and pulley on the thing and calling it a day. But the direct drive solution is just so much more appealing now that I've seen it work a few times. So, a compromise: a direct drive motor coupled to the non-valve-stem side of the wheel. It should occupy not much more volume than a timing belt pulley, but will run silently for ultra stealthiness. Whether you want to think of it as a motor attached to a wheel or a wheel attached to a motor is up to you. I would still call it a hub motor, since it is an outrunner directly coupled to the rim. Since the motor will occupy some extra axial length, a wheel thinner than 2" would be preferable. Which brings me to...

Wheel Option #3: Not to be used above 3MPH.

This is a light-duty pneumatic caster from aptly-named Caster City. What I really like about it is that, from far away anyway, it looks like a kick scooter wheel. But, it's really a 6"x1.25" pneumatic tire. Here's a profile comparison of Wheel Options #2 and #3:

The smaller wheel is also significantly lighter due to the plastic hub. My first impression was that it would be virtually impossible to adapt this hub to a custom hub motor, since it has no flat surfaces to work with and the crappy bearings looked integral to the hub. Turns out the bearings were so crappy that they popped right out with little effort...

...leaving an actual flat and cylindrical reference surface! Somewhere to start, at least. But wait, there's more. That pocket is actually exactly the same size as the bearing pocket in BWD, so it could potentially accept the same 1/2" ID bearing. I was not planning on using the wheel rim as part of the motor structure (in fact, I was actively avoiding this), but in this case it's just so tempting. What would be required, then, is a way to attach rotor plates to the wheel itself without putting too much load on the thin-ish plastic rim. MITERS whiteboard free body diagram:

Definitely not to scale. The motor should be thinner than the wheel.

First of all, I know there are three bearings on that shaft. Let me finish, Kanye. Force from the ground goes through the tire and rim, then into the two wheel bearings and the shaft, where it is carried out to the mounting forks. (Remember, in this design the shaft is stationary.) The motor itself is merely hanging off the wheel, screwed into the rim through an adapting plate. The third bearing helps align and support the motor, but ideally should not be carrying much of the ground reaction force. I know that if the entire thing is modeled as a rigid body, this doesn't work. But in real life, accounting for rim compliance, I think this makes the most sense. (There is an analogy to power/signal ground loops in here somewhere...)

So, it's a risky mounting solution, but it would be very compact. The windings would actually stick a bit into the volume of the wheel, so it is more like an in-wheel motor than the rest so far. I would worry about using the plastic rim as an important structural component of the motor, though. And the there's also this:

...I will blatantly violate this warning (at my own risk).

Verdict: Lightweight and stealthy, but of questionable structural integrity.

Wheel Option #4: What is it?

This Edmond Wheelchair caster caught my eye, and not just because it's red. It's a latecomer to my wheel party, so I don't have a physical one to play with yet, but the Shox tire is interesting. It's a flat-free pneumatic alternative that may offer similar shock absorption, according to the website. I won't know for sure until I get it. In any case, the hub looks very similar to Option #3, so motor mounting provisions should be the same. This one doesn't have a valve stem, though, so everything is still on the table, including a completely in-wheel motor.

Verdict: Jury still out until I see it up close.

That's it for the wheel report. Next post should be the decision. I will also detail the motor plans a bit more, but it will essentially be BWD leftover hardware:

MIDI For Your Motor

 Might as well start off with the good part...before launching into a post about how much I hate programming. 

What's going on there? Well, it's what I said it would be: a functional brushless motor controller that plays three tracks of MIDI music while it's doing its normal motor controller routine. In other words, it can still control the speed and/or torque of the motor independently of the music being played. So, not exactly the same as some other music motors like the classic[al] scanner or these musical steppers. It uses the PWM frequency, not the mechanical frequency, to play notes. And since there are three phases to play with on a brushless motor, it can play three tracks on one motor.

Before last week, I had taken care of what I thought to be the two hardest parts of making a motor controller that plays MIDI files. Namely, the motor controller part, and the MIDI part. Without too much trouble, I ported the 3ph Duo controller code over to the STM32F103 and found plenty of left-over processing power [to squander on processing MIDI]. Also without too much trouble I wrote a MIDI file parser in Visual Basic (shut up) and even wrote a rudimentary visualizer so I could see the notes.

Then I got to the part where I needed to send the MIDI data to the motor controller. So began the epic combo of mechanical, electrical, and software problems that tied me up for a week. First, the stupid USB connector on the board stopped connecting.

Stupid USB connector.

Then, the stupid XBees from 2006 with firmware/malware version 10C0 stopped responding to commands altogether.

 Stupid 10C0 XBees.

Basically, with both of my communication channels nonfunctional, I had no way of even programming the motor controller, let alone sending it MIDI data. So I did the MechE thing and procured all new USB connectors and XBees. The XBees were easy to change. The connector, since I am averse to using the heat gun, involved some brute force desoldering, but ultimately gave way.

Hardware problems really can't stop me in my tracks, though. At least, not any longer than Digi-Key's two-day shipping. Cue total software meltdown. Here's the problem: I can't buffer the entire MIDI song on the STM32F103C4. It's only got 16KB of flash. Each note requires at least 3 bytes of data, one for the note number and two for the time stamp. And the Top Gear theme song, in particular, has thousands of notes per track. So I needed a clean way to send pieces of the song from my Visual Basic MIDI parser to the controller.

The first attempt was a 16-note buffer. Transmitting at 57.6kbps, with 3 tracks of 16 notes, 3 bytes per note, and 8 bits per byte, plus extra bytes for checksums and the actual motor control stuff, this should finish in about 30ms. The problem is, the buffer is filled asynchronously while notes are still being played. (Everything is event-driven, if you're an OS programmer, or interrupt-driven, if you're an embedded programmer.) So, I needed a clean way of making sure that while notes are being filled in, they don't interfere with the ones being played (and vice versa). I tried a system of double buffers and locks that I thought was clever, but no matter what, I kept running into problems of skipping notes or playing notes ahead of their timestamp in groups of 2-5, depending on the MIDI tempo.

After two days of that, I scrapped the entire buffer system and wrote a new one from scratch in 30 minutes. The key realization was that, while I was somewhat limited to 16-note transmissions by the XBee speed, my buffer could in fact be larger... So, I made a 32-note buffer and just insert the 16 transmitted notes 16 places ahead of the note being played. Thus, they never overlap. (If they do, it means a bunch of packets have been dropped or the guitar solo is a just a little too aggressive.) On a scale of programming nightmares, this is nothing compared to the 3ph Duo, but it was a bit frustrating.

Next: Bigger motor. (Don't you know me by now?!)