Archive for the 'Melon-scooter' Category

 

Tiny(melon)Troller?

Dec 13, 2011 in Melon-scooter, Motor Controllers, Project Build Reports, The Next 3D Printer

In the spirit of eventually working towards running in-house developed equipment on all of my vehicles , I decided to man up and finally pitch Tinytroller at the final boss fight of scooter controllers: controlling the Turnigy C80/100 “melon” motor that runs melon-scooter.

Melon-scooter has been out of service for about a week and a half – the chopped Jasontroller worked extremely well until I let it out of my sight one Friday night at MITERS when a bunch of freshmen and new members were in attendance. When I attempted to leave later, I found that the motor was shorted through the controller and there was no response from it when powered on. And of course the froshlings had all quietly left by then, with nobody telling me that my scooter was behaving a little strangely and not like… going and stuff.

Hmph.

Anyways, I’ve found derpybike to be quite useful in the mean time. Since the failure was totally not under my control, I can’t quite tell what went wrong. When I opened the case of that controller, nothing appeared to be burnt or detonated, but some FETs are most definitely shorted through and the drive circuitry is dead. I’ll probably just order up another Jasontroller (or use one of those 500W bricks?).

The C80-100 is a pretty formidable control challenge for a homebrew motor driver because it has both very low resistance and very low inductance. I measured the line to line resistance to be around 20 milliohms – meaning any little twitch or fuckup by Tinytroller can send pulses of hundreds of amps through the system. The low inductance means the current through the stator cannot be modeled as approximately constant, especially at my relatively low (8khz) PWM frequency, wreaking havoc with non-robust current controllers. It’s built similarly to many other huge electric flight motors, so if I can control the Melon, I can probably take on other scarier airplane motors too.

Melon-scooter normally runs sensorless since I originally built it with a Hobbyking 100A airplane ESC, then subsequently a sensorless Jasontroller. To use it with Tinytroller (which is not yet sensorless), I had to append sensors in a similar fashion to Straight RazEr. It’s that red thing by the motor:

I bodged together Make-a-Bot’s heater one more time (last time, I swear!) and used the last 2 feet of my 3mm ABS filament to make this sensor mount. Unlike Straight RazEr’s mount, this is a two-piece since I needed to fit it into the very close gap between the motor and my frame.

Like so. Unfortunately I made this one a little too close – the ABS plastic actually rubs alot on the motor. It doesn’t seem to be affecting sensor operation, but it just makes an ugly scratchy sound. Oh well – it will have to do for now.

The first test was performed on 24 volts so I could (more) safely full throttle the motor in order to time the sensors properly. For a while, I was trying to find the absolute minimum point of phase current draw at no load, full speed, which corresponded to the point of optimal sensor timing. Wandering even a little outside this region caused the current to increase very quickly, some times up to 40+ amps no load… that’s 1000 watts dumping into the motor just spinning while sitting there. However, Tinytroller handled the mis-timed excessive current draw just fine – no fiery death like I expected.

I was able to get the motor current down to 7.5-8 amps no load, where it has generally been.

I did still have plenty of PLA plastic left, and I was going to print out a Nice Case for Tinytroller that enveloped the whole thing and had custom wire entrance and exit holes and whatnot, but decided PET film tape was enough for now. I made a little greenhouse (literally?) for Tinytroller which should keep most of the gunk out of it.

Plus, I figured it was going to explode anyway, so why waste time on a nice case?

All bundled up and connected.

I tried something a little different with this attempt at running melon-scooter. While Straight RazEr’s control scheme relied on a single throttle, with the bottom (released position) being a slight brake (negative current), neutral coast somewhere in the middle, and the top being full driving current, I put a handlebar throttle next to the thumb throttle on melon scooter and had Tinytroller read both.

The handlebar throttle controlled the amount of driving current and the thumb throttle controlled the variable regenerative braking. When neither was actuated, neutral coast (zero current) was commanded. Actuating one blocks out the reading of the other such that the readings don’t conflict and sum to a net zero, though that itself is a valid control scheme too.

After making sure it did indeed survive a no-load spin on the 12S battery pack, I threw the deck back on and went for a test ride. If it was going to explode, it might as well do it while the motor is running full bore on 40 volts. The no-load speed was measured to be 4330 RPM, a fair amount slower than even the Jasontroller’s 4700 RPMs. It could be attributed to sensored control with the sensors at the point of zero timing advance (sensorless will always tend to be faster) or it could be my battery being low after not being charged for a week.

The low speed terrible sound was still present – and boy was it ever noticeable on the melon. The “terrible sound” is a bug feature that has been with Tinytroller ever since I added the timer interrupt routine. It can be clearly heard as a clacking sound at very low speeds in the etek test video. I’m completely unsure as to where it comes from, and I can shift the Band of Terrible Sound up and down in the PWM output range if I add various length delays to the interrupt service routine & state changer. This just tells me my timers (1 and 2 on the ATmega) must be running into eachtoher somehow.

Regardless, Terrible Sound mode results in very high current draw for the duration of that “band”, and with the massive windings and rotor of the melon, it was felt as a very strong rumble or high frequency ripple torque. I can’t imagine it being too good for Tinytroller. As soon as the band of terrible sound is passed, the ride instant becomes smoother and more controllable, but transitioning back into the band results in the motor suddenly slowing and becoming rough. Considering that the Band of Terrible Sound occurs at a useful low cruising speed of about 4-5 mph, this is indeed quite a problem. I might have to dig deeper into the ATmega manual to find out what timer registers are being refreshed or reset when I dont’ expect them to be.

poor tinytroller

Melon-scooter managed to make it 90% of the way around the block before it suddenly flaked and shut off. I was able to cycle power and have it function again, but only for a very short while. After which it seemed that at least two low-side FETs were shorted, since the motor was reluctant to turn even with the power off.

Before that, during bench testing, I had noticed my big red key switch becoming flaky and occasionally shutting off or dithering on and off, power-cycling the controller many times. It very well could have been a flaky switch that shut off from vibration, and the sudden power kill would result in huge negative voltage spikes which could have destroyed components.

I’d hate to think that the only thing that took down Tinytroller this time was a flaky power switch, but the performance was fairly smooth and flawless once the Band of Terrible Sound was passed. Slowing down was difficult – re-entering the Band of Terrible Sound meant I  had to hold on to prevent the handlebar from punching me in the stomach as the motor suddenly acted like I had jammed a rock into it. Getting something reliably working is, in my opinion, 90% of the challenge of actually making a useful product or project, so I’ll just continue the Tragedy of the Tinytroller some time.

more 3d printers

I’ve also been sketching out some more designs for the Next 3D Printer. Adding a filament guide to the interior of the machine that had to be flexible enough to reach the far corners of the axes while folding up neatly and predictably has been a fun engineering exercise, and I now understand why commercial 3d plastic extrusion printers are so damn huge. I need alot of buffer space to run the set of wire and cable guides which hold the filament and the electric umbilical.

However, one thing I did decide on and finish designing was my new Z axis. In the first post about the new machine, I sketched out an idea for a combined chamber heater and build surface heater. Well, that idea has since been turned into reality Solidworks.

Hey, it’s like the exact same thing. The resistors are 10 watt types, currently spec’d to be 0.22 ohms each and to be run in series for a roughly 1.8 ohm string, which ought to net me about a hot 80 watts of heating power. The surface itself was made transparent for imaging purposes, and actually is supposed to be aluminum and not clear plastic or something.

I’m not a thermal systems engineer, so I just whipped up a radiator pattern for the resistors that kind of made sense in my head.

Some more design progress on the Z table. The parts here are “edge stitched” together in my usual style with tabs, slots, and interspersed t-nuts. Four LME12UU type linear bearings comprise the guide system, two on each side, held apart by spring washers. I’m reusing the central leadscrew nut from MaB because for some reason it cost $30 and I still have 5 more feet of the same leadscrew, and I’m not buying a whole new one. The structure is mostly 1/4″ aluminum beams and 1/8″ bracing plates – I’m trying to minimize the use of giant 1/4″ stock on this machine, but because the Z table is so big (250mm square build plate, with a total length of about 290mm front to back!) it was warranted here.

Did you know that they make PC case fans that are 250mm across? I didn’t know either until I accidentally found one on eBay while looking for real industrial 200-300mm class fans. In fact, they make case fans up to 360mm. Why the hell do you need a fan that big on your computer?

It turns out they don’t actually move much air at all – I ordered a sample one from xoxide for kicks, and it seems to be for case modders and PC builders who want to take the “large but slow moving air mass” school of case ventilation to the absurd limit.

But that’s actually exactly what I need – I’m not trying to build a hair dryer  or a heat gun, but something which will gently fan the sweat of my 8 power resistors onto the back of the build plate. Time will tell if they survive 60-70 celsius (I’m guessing not), but for now I have one designed in. More industrial grade fans are spec’d out if I need them, but if these fans do work out then more gaudy internal lighting for me. Maybe it’s time to start case modding your 3d printers.

The Plight of Melonscooter and Pushing the Limits of the Sensorless Jasontroller

Nov 08, 2011 in Beyond Unboxing, Melon-scooter, Project Build Reports

Poor Melonscooter.

About 2 weeks ago, a major storm system rolled through Boston as they tend to do during fall. With my new anti-wet-pants device, I was fearless in flying through the rain with melonscooter. However, what I didn’t keep in mind was that the anti-wet-pants device only deflected water from going upwards. With that path blocked, there was no place for it to go… except over the top of the motor and straight into the rain gutter that is the back of the frame. You know, where one of the battery packs was. I didn’t think  much of it – after all, water evaporates, right?. What I didn’t realize was just how much water got into the frame this way.

Shortly afterwards, I noticed Melonscooter regularly flaking out and and losing power. The final straw came when, on a full charge, it couldn’t even make it down the long stretch of Vassar Street that is my daily “commute”. The power would start out fine, but get progressively weaker until the power system went into undervoltage shutdown. This only happened at voltages under 30 volts. So, I immediately figured that the batteries were very, very unhappy. It must have been declining progressively before, but I only really noticed it when the effective range got under a mile or so.

The first sign that something was wrong was when I pressed on the clear plastic wrapping of the \m/etalpaxXx and saw air bubbles moving around. Water had totally infiltrated the rubber foam padding. So, I tore all of that off, and…


AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

It’s like operating on a cancer patient only to discover more cancer. The packs have been through alot, but it looks like a week or two in contact with water finally did them in. Significant copper corrosion was visible and most of the cells had vented. The cells were so waterlogged that the blue ink stripe had run and bled through the paper. This pack was pretty much utterly trashed, with even the mighty Cell Log refusing to read it.

Melonscooter has 2 of these packs, left over from Fankart. The front battery was dirty, but otherwise had regular voltage levels on all cells.

Oops.

Shortly after the rain let up, I had actually added a “mud flap” in front of the rear wheel, under the stern deck, such that water was deflected back downwards and not onto the motor. Unfortunately by that time it was too late.

It was time to break out the box of nice things and start over. Melonscooter was built from found parts, and the batteries came from Fankart, with associated bullet connector incompatibility and a mix of Deans and everything. Starting from scratch was therefore a chance to clean up the electrical system significantly. I decided to build the new pack to the same capacity and voltage specs (12S4P), but make them mechanically one “brick” to save space in the frame.

Because the cells had leaked electrolyte and water had been sitting stagnant in the frame, the bottom was also covered in rust. I thoroughly cleaned it out with steel wool and various potentially carcinogenic cleaners, and gave the frame interior several layers of spray-on clear primer. This was when I discovered that the original black paint was just sprayed straight onto the metal – there was no sticking whatsoever, and I could blow huge chunks of paint off with a compressed air nozzle.

There was, however, one very important reason to consolidate the two batteries into one. When I did that, a Jasontroller fit perfectly into the leftover volume. I mean perfectly as in so close I had to make sure my wires exited the pack correctly. It’s like this was the application that Robot Jesus commanded me to use a Jasontroller for.

So I’m going to do exactly that. I had already modified this Jasontroller with IRFB3207 power FETs and shunted its current sense shunt to half its previous value, so part of my goal was to see how far I could push this thing in terms of wattage.

Okay, I know everyone has seen me make battery packs like this before. Sadly, even the biggest of my big heat shrink did not fit over 4 parallel cells. Not wanting to empty out two 3-liter bottles of disgusting cheap soda again, I elected to just Giant Kapton the pack with rubber foam padding.  The balance leads exit from the side of the battery, a lesson learned from LandSharkBearGrylls’ epic battery flameout. Here is the finished pack getting a first charge-balance.

Before I installed the Sensorless Jasontroller, I decided to give it a haircut. All the functions I really didn’t care about were desoldered or cut off, leaving only throttle, motor, and power.  This made for a much smaller bundle of wire to hide.

the jasontroller experiment

I had already dropped the shunt resistance of the controller from 4 milliohms to approximate 2 milliohms. The idea is to keep dropping it incrementally until I am satisfied or something detonates. First, though, I tested the controller as-is with the 2 milliohm shunt. If all goes right, I should see about 700 watts through the system, making a current draw at 40v of about 18 amps or so on the battery side, at full speed.

Full speed measurement is essential since these controllers limit average phase output current due to the arrangement of the shunt. Because of the properties of a buck converter, which all motor controllers are to some degree, phase current is multiplied at partial throttle – a 10A battery current at 25% throttle could mean 40 motor phase amps. Only at 100% PWM do the amps match. Incidentally, maximum “power” will occur at this point to if the load is sufficient – Melonscooter certainly does not pull 1000 watts just freely running on flat ground, so the max power point will still come at some point in the launch cycle.

The test took place on the small back street bordering MITERS, State Street, which is long enough to get up to full speed and still well-paved since this is only its second winter. It was also short enough that it forced me to slow down turn around at each end, which let me test how each level of hackery handles launching transients.

The instrumentation of choice is the Turnigy Power Meter, which keeps track of peak power, peak amps, minimum volts, running volts and amps, watt hours consumed, and all that nice stuff.

Result of test #1, 2.0 milliohms:

Hey, that’s like… double of 350!

I neglected to actually measure the temperature of the controller case, unfortunately, but nothing made unhappy noises or smelled bad. By the time I was able to open the controller up again, the FETs were cold.

Clearly it was time to turn it up (or…. down?). I added more solder globs to get the shunt resistance down to 1.5 milliohms, for an expected wattage of 930 or so.

While I neglected to take a picture of this run, the wattage attained was 895W, which is slightly lower than anticipated but likely within reason since my measurement resolution at such low ohms (with a crappy multimeter and power supply of dubious accuracy) is lacking.

I next tried the magic 1.0 milliohms (which is really more like 0.8 to 1.2 milliohms, I’m guessing). This should be a cool 4 times the power throughput of the stock controller. Beyond this, the theoretical power is going to rise asymptotically, so this was probably my last good data point:

A cool 1300 watts – close enough to 1400. I was definitely feeling some unhappiness during this run – the controller would some times cut out for a fraction of a second during the launch.

There was something else which concerned me enough after this run to address before continuing. After the first two, what was hot wasn’t the FETs, but the input capacitors. These things could see many amps of ripple current, especially if the battery input wires are long and skinny or cheap and Chinese. Or fucking both.

The stock buscaps on the Sensorless Jasontroller is two 470uF, 63 volt electrolytics, and they were hot. While they are rated to “105 degrees C”, hot capacitors is a sign that the ripple current is too high or beyond their rating. One way of reducing ripple current is to add more buscap.

I elected to use the cleared wire forest space to install 1000uF more capacitance in the form of a cap ripped from an old switching power supply. It could only fit laying down, so short and fat wire leads were used to connect it to the battery input terminal. I figure the resistance of this length of wire isn’t any worse than thin copper foil traces.

Here’s the fix. The cap itself is retained with a dab of Goop.

After this hack, I was fairly confident in moving forward with dropping the shunt to 0.5 milliohms – or thereabouts. I was really working on the edge of measurement accuracy here, so judging by the result I either didn’t come close to 0.5 milliohms or something else has become the limiting factor:

Still, holy crap. 1800 watts through this thing is about as much as I’m comfortable with for now. After all, I *did* want Melonscooter to work. The good news is that the additional input capacitance has eliminated the stuttering on launch I experienced before the addition, and acceleration is now smooth and constant from startup.

It was decided to lock in this shunt value (which looks be about 0.75 millohms, since given constant battery voltage, 1800w is about 5.25 times 350 watts, so the shunt should be about 4/5.25 milliohms.) An unknown amount of power is probably being lost to wiring resistance and trace resistance at this point, too, since the controller’s long power traces are probably contributing several mohms to the thing.

So there you have it. How long will the Jasontroller last at these power levels? My guess is probably until everything melts again in the spring. The ambient air temperature right now is around 40 degrees F (5 C), which is great if you’re a motor controller being overdriven 5 times, and will only get colder for several months. Once the ambient temps get up to, say, Singapore levels during summer, I expect to encounter thermal death. Melonscooter is very open-air (partially a curse, given the weather around here), so the controller gets plenty of air-over cooling, especially at top speed. I might have to add forced air cooling if I am to try and sustain these power levels.

Because the shunt is now like 50% solder, it probably has a nontrivial thermal resistivity coefficient. Ideally, I’d open it up and replace it with a known 0.75 milliohm shunt resistor. As the whole board heats up, the blob of solder’s resistivity will increase. To a degree, this probably a good thing.

Meanwhile, Melonscooter has successfully made the run back to west campus, full throttle all the way down Vassar Street. Can it do it again!?

Updating the Melon Scooter

Sep 22, 2011 in Melon-scooter, Project Build Reports

It’s been a year since I finished melonscooter. Barring the occasional controller experiment, it’s rarely been talked about or mentioned, and it doesn’t even have a vehicle page, which is something I should fix. This is mostly because it has worked reliably and has been more of a tool than a project (correctly implying that my project vehicles never really work that well). It’s well in the triple digit miles by now, and has saved me countless hours via not walking anywhere, therefore likely contributing to my early demise through obesity, heart disease, and maybe faceplanting into a bus or two. It’s also fairly well known around campus as a sign that I Was Here™, and occasionally gets me trolled by the campus police since it is actually capable of violating some internal speed limits (the top speed being roughly 25 miles per hour depending on things like headwind, tire pressure, and battery remaining, but is always above 20 or so)

The original design was put together in a weekend with very little forethought, and it definitely left alot to be desired. Namely, the entire drivetrain is open to the air above. This implies that whatever the tire picks up is going to end up in the air, and ultimately must land somewhere. When it’s been raining or otherwise wet out, the choice landing spot is straight up my legs and back. Thus, melonscooter is usually in hiding whenever the weather is anything but sunny and dry. This being New England, the chances of that happening as summer ends approaches zero. In the past, I’ve done silly things like tape together wheel covers and fenders:

I forgot what that torch was for.

They would usually work okay, but were just too hackish to keep using (and the cardboard ones would just melt after one trip anyway).

This was actually the single biggest impediment to using the thing regularly. The electronics and batteries were reasonably weatherproof (the controller having been moved inboard since the above photo was taken) so the only issue was me being unhappy with a trail of road grime extending from my back down my pants legs.

With the summer ending once again, I decided to just get it over with and do something about it. There were some other issues with melonscooter that I had complained about before, so I figured in one upgrade I’d take care of them all.

So here’s what the back of the thing looked like as of yesterday. Another problem with this is that the huge wheelie tail wasn’t actually all that stable. It was mounted directly to the wheel forks that were punched out of the soft steel frame tubing, so standing on the tail would actually force the axle mounting slots apart and leave it very floppy. It got to the point where I was vice-grip-crushing the axle mount slots back together every few weeks. Adding that secondary nut and bolt ahead of the main axle bolt helped a little, but the wheelie tail was still “soft” and a little wobbly up and down.

I also had no cargo space whatsoever. Trips to the grocery store or convenience store were made moot by the fact that I could only carry back what I could stuff in a backpack or reasonably hang off the handlebars. This was inconvenient to say the least.

The plan I cooked up was to make an integrated motor mount and “stern deck” kind of like the back of Straight RazEr which would clamp or bolt onto the frame rails and provide both wheel coverage, a place to stand, and potential for cargo space. After staring at the stripped down back end for a while and taking in-place measurements of where the wheel and motor were located, I came up with the following.

It’s a primarily 1/4″ aluminum, waterjettable upper deck. Due to the frame geometry and motor clearances,  I had to move away from a convenient clamp mount into through-drilled holes. A clamp would have required the volume occupied by the brake mount and I would have had to move the motor upwards a half inch or more so the rotor side could clear (the original mount had the can hovering less than 1/4″ above the frame rail). I didn’t mind fixturing and drilling some holes.

The solution for the cargo space issue lay in the standard 13″ milk crate. These things are common and give you a good cubic foot or more of storage space, and it’s common to see them on the back of bicycles. So I figured I’d make myself a detachable mount for a an ISO standard milk crate (does that standard exist?). The bars pass through a vertical plate with 2 holes, which is the primary support, and I’ll machine some clamps to hold them on the close end (those big hand knobs are for closing the yet-to-be-made clamps). The maximum extension is 13 inches, and I’ll fasten a crate to the bars with some crafty zip tying.

I was planning on making it foldable or telescoping, but this is not exactly a scientific exercise…

So let’s begin by milking the teets of the Institute and getting my parts waterjet-cut from 1/4″ aluminum. This was from the same stock that Straight RazEr was born of – I actually did buy something like 50 pounds of aluminum on eBay recently. I ordered some 24″ rod stock to make the rack of crate mounting from, but they had not yet arrived.

By the way – all the pictures this time will be horrible grainy 640 x 480 because I accidentally set the camera on my cell phone (which is actually pretty decent and has autofocusing) to 640 x 480 somehow, and didn’t notice until I uploaded everything. There’s at least one good picture, I promise. That thing takes pictures which otherwise are just good enough for me to not bring my big camera everywhere now.

I committed myself to a night of assembly by totally parting down melonscooter. I took the opportunity to clean up everything in the frame, which was covered in road junk and rusty in some spots.

While the batteries were out of the frame, I gave them their yearly balance charge. The cells have only drifted apart about 30 to 40mv this whole time, so this didn’t exactly take long.

This is what the “stern deck” looks like when fixtured in place. It picks up right where the folded polycarbonate deck leaves off. The standoff at the front of the new structure (not visible in this pic, but in the CAD image) was the reference surface for aligning the whole thing to be level. After that, it was a quick drilling job (disturbingly quick for something that’s supposed to be steel, mind you) to put the 8 holes into the frame.

Eight countersunk 1/4″-20 bolts later, the stern deck is mounted. It turns out that 1.25″ was the ideal length for this job, but I only had 1″ long screws in standard socket head. The only 1.25″ (or rather, over 1″) screws I had were flatheads. This was fine, since countersunk flathead cap screws always make something look more hardcore. I also test fitted the wheel and motor to make sure I didn’t get it totally wrong.

A view from the other side. Because the steel frame is just that soft, I used some Keps-type locknuts with 2 layers of washers: a small, standard 1/4″-20 washer pressing against a 1/4″-20 fender washer. The fender washer’s huge surface area allowed me to crank down on all of them without caving the thin wall tubing inwards.

All the electronics drop back in as they were before, except I took the chance to reroute some wires so they don’t…. hang down as low.

Priorities first: got to make sure the gaudy lighting is properly reinstalled. Putting in the countersunk flathead screws turned out to be a good move, since I couldn’t find another place to mount the CCFL inverter that was within reach of the new glow tube location – under the deck. I ended up Velcroing the inverted right to the side of the motor mount plate.

And here is everything wrapped back up. I’ll finish the Rails of Crate Mounting after the rail stock arrives. I’m also heavily considering making a similar attachment for the front of the frame for even more space. And balance: the added weight of  infinity Mountain Dew 2 liters is liable to making this thing wheelie like crazy.

See, I promised a good picture of it…

A Wild Melontroller Appears!

Nov 25, 2010 in Melon-scooter, Motor Controllers, Project Build Reports

Charles! I choose you! Use SOLDERING IRON!

After a week and a half of anticipation, Melontroller 1.0 arrives just in time for me to spend the entirety of the Thanksgiving weekend blowing it up.

I used Advanced Fucking Awesome Circuits‘ $33 per board service, and the results are epic as usual. I elected to just spring for one board this time instead of panelizing or ordering more, since I wanted to make sure the design actually worked. The above is the bottom side of the board, where the crackFETs sit.

The top side is the horrible mess of 1206 component and SOIC components.

And an Arduino.

I suppose this layout isn’t that dense at all, but playing the routing game in Eagle was still a bit mind-boggling, and some times mildly frustrating. Much of it stems from the fact that I’m trying to maintain a 2-layer board. 4-layer boards would make all of this much easier, but they are also way more expensive to manufacture. I don’t think I’m quite that hardcore yet.

While the boards were in manufacturing, I placed several consecutive Digikey orders for the components that will eventually need to fill it out.

Here’s the scene. It looks kind of like a shady back-alley surgeon’s office, except with electronics.

Mid-assembly with most of the SMT passives and all ICs mounted. Excuse the blobbing – this was done with 1mm diameter solder (bigger than the damn pins themselves) and an iron with a tip so dead that I had to regularly sand it in order for the solder to stick.

That’s some serious bonage. I think it’s time to get MITERS new soldering irons.

I whipped out the Big Guns to solder in the output FETs. It’s a 100 watt Weller iron with a single 3/8″ wide tip. Not very scientific, but it flowed some serious eutectic.

Of course, I also managed to bridge together the single gate pin with all 5 of the source pins a few times, but that’s what they make desoldering braid for.

Notice the exposed conductors on either side of the FETs. Those will also be braced with some bus wire or braid in order to strengthen the trace where it is the narrowest.

And the last components to go on are the Arduino (on headers) and buscaps. This thing has some serious buscaps. I don’t know why on earth I specified two whole Joules (3x 680uF on a 60 volt system) of buscap, but they’re almost comical looking. It’s almost to the point where I’d need a precharge circuit.

I haven’t written the software or done a load test yet, but the circuit powers up without shorting the power supply, so that’s a good first sign. Over the break, I intend to write some BLDC square wave commutation code and see if I can run the MITERS Public Etek. After that, it’s time to put sensors on Melonscooter once again and see if this thing can live up to its name.

In the mean time, in classic me-fashion, I’ve already started designing version 2 before even finishing (or in this case, starting) version 1.

It’s actually not as bad as it seems. This is the exact same circuit, but better organized and routed. First, the layout is practically identical across all three phase drivers.  Second, the pull-ups and -downs are better organized and placed right next to their respective pins. Also, the outputs now use plain board pads instead of through-holes. No particular reason for this change.

Also, even more buscap.

Alright, not really – the buscap bank had to be trimmed to a mere 1,300uF. Boo-hoo.

The most important aspect of version 1.1 is that it’s a full half inch smaller in the X dimension. This can actually get even smaller, but right now this is the limit of what I’m comfortable designing, routing, and soldering. My ultimate goal is to reduce it down to the size of the average Turnigy 100A.

But don’t let the picture mislead you – melontroller 1.0 is only a little longer than a credit card, and 1.1 is shorter than one. That’s already pretty damned small for something that should handle at least 40 to 50 amps with some airflow.

reduction to practice

I’ll just leave this here.

Melontroller and the Melodrama of RazEr rEVolution

Nov 13, 2010 in Melon-scooter, Motor Controllers, Project Build Reports, RazEr rEVolution

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.