Category: Melon-scooter

Melontroller and the Melodrama of RazEr rEVolution

chorl7 Comments

This post is also known as Why I Should Man Up and Build More Motor Controllers.

RazEr rEVolution is currently assembled as a rolling frame. This means I’ve successfully managed to build a kick scooter again! REJOICE!

Small detail: the DNIR is installed, but the whole thing still rolls and coasts almost like a stock scooter. This is pretty paramount, IMO, because one of the advantage of hub motors like this which I’ve been telling people is that it still allows you to use the vehicle “normally”. Specialized electric drives (like Melonscooter, in fact) are just difficult to blend into vehicles which are designed to be human powered.

But enough harping on why hub motors are cool. The reason I wanted to throw rEVolution together mechanically is just so I can take it out of MITERS for a little while while I seek a motor control solution….yet again. Overall, I’m still in need of a medium to high power BLDC motor controller that isn’t the size of a house brick and has sensored inputs. Kelly controllers (and associated generic Chinese motor controls of the same genus) are the size of house bricks, and R/C airplane controllers, while cheap and available with high amp capacity, are sensorless and therefore have extremely poor startup characteristics for hub motors. The Turnigy ESC has been performing great on Melonscooter, but only because it has a 4:1 belt drive helping the motor.

In this picture:  (1/4)² inertia divider.

But what about the DECs? The thing that I had the biggest e-b0ner in the world for? Well, they were (and are still) performing admirably driving the Skatemotors. They’re well matched to each skatemotor, power-wise. But the DECs are still industrial motor controls, and with that come some issues. Specifically, they really do control speed. We call these things “speed controllers”, but at least airplane motors and most small EV controllers (including the Kellys, which can be configured in a few ways) are open loop. They’re knob controlled – you turn the knob, the motor goes. You turn the knob more, the motor goes some more, but there’s no guarantee.

The reverse is what causes trouble with rEVolution. The DECs appear to use synchronous rectifiers, which means the motor will brake if the command results in a motor speed lower than the current one. While this is used on LOLrioKart’s controller too, the DECs actually attempt to hold 0 speed unless specifically disabled.

Unfortunately, that last part kind of ruins the ability for the scooter to be kick scooted. Now, they do show this same behavior in the skatemotors, but those motors are substantially smaller in diameter and length – so your inertia overcomes their deceleration much more – and I’ve specifically programmed the Arduino running the two FSR throttle and brake inputs to throw the shutdown line on the DECs if each successive throttle reading is less than the previous one i.e. you’ve let go. So the skates can coast, no problem.

So then why not just use the same arrangement for rEVolution? Well, if I’m going to have to hook up a microcontroller and write software for it, I think I can do the whole system better and possibly learn something while I’m at it.

Shocker.

Anyway, that’s why rEVolution is currently a very elaborate kick scooter. Give me some time…

Here’s some pics of the mechanicals in the mean time!

Assembling the finishing details was fairly easy. The Garolite top plate goes on top of the aluminum frame, and then the steering neck / folding joint sandwiches it. Originally, the four holes were tapped for M6 x 1 screws so I could use the Razor scooter’s stock mounting screws. However, I’ve managed to lose them, and not having M6 screws at my disposal, I dynamically rethreaded the holes for 1/4″-20.

The two cutouts in the top plate are to go around the joint reinforcement screws. I’m proud to say that after a few bunny hop tests, they are holding up well.

Here’s the finished profile of the scooter, showing the interesting side. A Deans-shaped cutout holds a battery connector for charging and the main power switch.

In folded mode. I’ll be honest: This thing is heavy. It’s probably bordering on 20 pounds just because there’s so much \m/etal in everything.

Beauty shot!

Right now, I think the design looks a little “off”. The wheel widths are so disparate and the rear wheel such a commanding color that it just sort of dominates the entire design, and the front looks weak and atrophied by comparison. It’s like a queen ant – small head, huge abdomen. Like Shane did with Pneu Scooter’s new front forks, I might re-engineer the two-piece Razor A3 fork such that it holds a more manly wheel – maybe another one of the McMonster Truck Tires that I hollowed out for the back!

Compared side-by-side with Melon-scooter (which, incidentally, now has head and “tail” lights since I do operate it alot in open traffic…because it’s fast enough to keep up with most area traffic).

It’s not really that much smaller. Still a size class or two down, and currently, much less mobile.

melontroller

I’ve talked about it before, many times, the most recent time after I ended up reverting to the Turnigy sensorless controller. One of these days, I was going to build a BLDC controller that actually works, and is a little smarter than the average airplane monkey. Since I pledged that if I had to ever write code to drive a motor controller it might as well be a system of my own design, I’m going to take myself up on it right now.

One day (okay, midnight-early morning) I sat down and began scratching out a schematic in Eagle. What did I want in this controller?

  • 50 to 60 amps continuous. Real continuous amps. With FETs that can handle this, I’d say a hundred amps peak pulsed is probably doable.
  • Operating voltage in the 36 to 48v range, since I’m unlikely to go higher than the number of cells I have a battery charger for.
  • Single motor, sensored commutation.
  • Current sensing. It’s taken a long time, but I’m finally convinced that current control of an electric motor is b better than speed control. I’m still a die-hard open loop guy, but if I had to implement some kind of actual control loop, it’s going to be the one with a real world physical state variable (torque, current, acceleration, and inertia are all linked pretty much directly)
  • Arduino-compatible. Because…. because.

After a couple of hours of blitzing, here’s the result.


Eagle, what the hell did you do to my schematic?

I literally opened the schematic again after seeing how it wanted to place the components to-be-routed on the board and my gate drives started sucking in the passives around them. That image capture is from after alot of rearrangement.

But the gist of it is:

  • An Arduino Pro-mini
  • IRS21844SLBBQLOLWTF half-bridge synchrec drives
  • IRFS3107 cracked out FETs in the even more cracked out D2Pak-7 package.
    • Seriously, if this whole system works out, I’m asking International Rectifier for sponsorship. Not because I need it, but because they’re awesome.
  • Three ACS714 Hall-based, bidirectional current sensors. One on the DC rail, and two on the actual motor phases. Result? Ability to measure both DC and AC side current in both directions.  Life could get interesting in the future.
  • Two analog and two digital inputs, because I can’t quite decide what I want to do with them yet. So they’re generically named.

And after about 9 hours of advanced ninja board routing, here’s the end result:


Advanced Ninja Board Layout, MIT Course number 6.9000

I’ve sent out the BOM to Digikey and the board itself (just one for now) to Advanced Circuits (who I absolutely adore now because they tooooootally saved our bacon and even gave us a massive discount on the boards for our 2.009 project which we needed EXTRA EXTRA SOON and are therefore the most awesome PCB fab house anywhere, so much so that I’m making this whole block of text one huge link to them).

With some luck, and some code wringing, there ought to be some Melontroller in my future.

The D2PAK fets don’t have that much PCB copper to sink heat to, so my continuous amps goal might be a bit optimistic. But that’s one thing I want to test. I don’t care – honestly, I would much prefer to melt components right off the board because I purposefully commanded them to flow such a high current continously and the know that the design itself is sound, rather than have everything just detonate when I plug it in. The former is a glorious death, the latter a shameful one.

mini-melontroller

Now, the controller above is too massive to fit in RazEr. I’m already mulling over making a much more compact board, possibly with the Arduino on surface mount headers so it can park over the 3 phase bridge. The bridge would also be smaller both physically and ampacity-wise. Mini-melontroller should fit on a standard credit card.

Melon Scooter: Yeah, So It’s Done.

chorl1 Comment

Well, everyone probably saw this one coming: the post where I make up for the lack of mechanical issues and dearth of unconventional machining problems with seemingly neverending tales of electronics woes. The bad news is that I did not find out how to control the Melon with just a relay and a diode. I’m sure it can be done, but further investigation is needed in this study’s focal area.

The good news is that it finally works. I mean, it works as well as all my scooters so far do, which is to say it’s probably on the verge of exploding.

Now for the things that didn’t work.

hexbridge shield

As described in its own post, the Hexbridge shield is an attempt at creating a system for Arduinos to control more power than they deserve to. With twelve total IRFB3207 FETs straight out of International Rectifier’s private corporate Hell, the board could process more than a kilowatt of power.

The six half bridges are nominally divided into two independent 3 phase bridges by the 2 PWM pins of the Arduino it occupies. Now, while one rail of IRFB3207s alone can probably handle the Melon motor with proper current control, the board itself has no current sensing provisions. I elected to activate the other 3 phase bridge and put it in parallel with the first for that extra burst current overhead, since I was aiming to just make a simple open loop BLDC commutator. The way to accomplish this is to disable one of the PWM pins completely (high-Z) and then tie the selector pins together in either software or hardware.

This mode is the “secret mode” of the Hexbridge, and comes with risks such as EPIC CROSS-PHASE SHOOT THROUGH if the paralleled phases are not in absolute sync with each other, such as if the selector pins aren’t ganged together properly.

What was extra cool about the Hexbridge shield was the fact that it fit exactly between the two \m/etalpaxxx. Space efficiency!

I yoinked a few feet of silicone wire from the Media Lab and hooked up the main power wiring for the system. As usual, with things I wire, it’s a mix of gauges, strands in parallel, and absurdism. Yes, that’s double 12 gauge coming out of the shield…. fed, of course by a single Deans connector at the other end.

Hey, I figure too much copper is not a bad thing from a system resistance perspective. In fact, the shady master key switch probably contributes more resistance to the system than anything else.

Because the motor does not come with sensors, I had to craft a sensor board out of some thin tube plastic. This is a departure from how I usually do sensors – which is stuffed inside the motor’s stator slots – because I didn’t particularly feel like taking apart a motor that big.

As such, I could take advantage of the fact that the sensors can be located physically close together to detect the proper magnet transitions.  The formula for sensor spacing in degrees is 360°/P/3¹, where P is the number of pole pairs. So for the Melon, it was just 360 / 7 (since it’s a LRK wind) / 3, or about 17 degrees. Across a roughly linear projection, the sensors had to be about 0.48″ apart. This board was superglued to the exterior of the stationary motor mounting base.

The cheap hall sensors I used (p/n ATS177) exhibited some very weird behavior when I read the 3 lines out with the scope. One of them seemed to be “preloaded” and did not exhibit the 50/50 duty cycle I would have expected from a Hall sensor subject to a constant frequency alternating magnetic field composed of equally sized magnets. It meant that one motor state would overlap slightly with another, which at best could cause the motor to just not start (and at worst cause current spikes).

Here’s the basic wiring hooked up to do a commutation test. I loaded the same Hexbridge-and-Etek code on this assembly, making sure to lock out one PWM and hardwire the two PWM pins together before powering the system on and trying out the throttle. After digging through a handful of sensor:phase combinations, the motor finally started up. It was a little rocky sounding, but it did work.

Now, those of you who pay attention to words I put in bold and the subtle details of my sentence grammar will probably guess what happened.

After 7 seconds of operation, there was a large spark, and the power side of the Hexbridge was history.

The most plausible explanation, as it turned out, was that I neglected to tie the ABC selector pins to the UVW ones – in either hardware or software. I made them all high impedance instead, in software. So not only does that mean one half of the whole thing was never actually switching, the floating FETs themselves might have been subject to dv/dt-induced spurious turn-on.

Uncool.

mini-kelly

I was determined to get this thing running. Maybe too determined. After the Hexbridge exploded, I jumped to my backup plan of using a KBS series Kelly controller, of which we have aplenty in the Media Lab. At this point, I didn’t even care about monster horsepower. I just wanted it to move, because I wanted some transportation (that didn’t involve me actually doing physical work, I mean. Heaven forbid I use my legs to propel myself…)

Kelly controllers have a penchant for randomly exploding, but I must say this one did an admirable job given the adverse circumstances it had to tolerate. It’s a 20 amp rated controller with peak 50 amp ratings and here I am asking it to run a motor which will easily knock down 150 to 200 amps on a bad day.

It did an excellent job of keeping its own current so low that the scooter was able to move maybe 3 or 4 miles per hour, all the while sounding like a moped. The rockiness of the sensors really exhibited itself here.

In the end, nothing happened. I took the Kelly out of the system while it was still undamaged and useful to our Media Lab-y purposes.

oh, damn it all

Fuck it. I’m going back to sensorless.

After a while of stewing, I bought a spare Turnigy 100A controller off Shane (thus funding some of the Pneu Scooter, which I look forward to) and threw it on there with the servo signal interface board.

The new layout with the Turnigy ESC hanging awkwardly off to the side. Instead of stuffing it into the cavity, I elected to drill some mounting holes in the deck and put it in a path where it could get some real airflow, since heat is the killer of power-dense controllers like those.

The R/C meter tucks in between the batteries, and my secret ninja servo converter hides under that, waiting to strike.

And guess what? It works. It’s a power system I originally assembled in 2007, while still in high school. It’s nothing more sophisticated and would blow up the moment I floored the thing from a standstill (so I’m always careful on the throttle until the vehicle is already moving a few MPH). Hell, it even uses the exact same cheap R/C power meter (model-wise… not the physical same, mind you).

I said this thing was just a quick dumb-but-awesome build. It’s Fankart with powered wheels and the ability to navigate city streets. Maybe there will be some running video, but Melonscooter has become my staple commuter vehicle now.

melontroller

But I’m not stopping there.

Putting together such a system isn’t particularly contributory towards making myself a better engineer (or person). I haven’t laid out the board yet, but I am absolutely determined to tame the Melon. And I intend to do this by making a current-controlled BLDC motor driver board that

  • will operate with a 48 volt electrical system
  • at up to 50 real amps continuously and 150 to 200 amps peak (limited)
  • have current sensing on the DC bus and two motor phases
  • be fully regenerative
  • be two stacked boards about the footprint of a common business card
  • be modular, with one signal processing board and one brute force driving/current feedback board
  • and possibly do crazy insane batshit things with motor control.

Oh, it’ll run on Arduino.

It’s a long shot, and will probably cause melonscooter to be the LOLrioKart of 2010-2011 (not that LOLrioKart isn’t already the LOLrioKart of 2010). But it will be the only component of Melonscooter that makes it a worthwhile project, so I’m going to go for it.


f