• Entry 5: is this thing on yet?

    Jorj Bauer • 10/31/2018 at 03:15 • 0 comments

    It's been a while since I've updated this project - mostly because it's been sitting in a trailer doing nothing.

    This is all for the motorized base of Geo, my full-size Imperial Dalek. Since I didn't finish before LIWho 5, I rolled it around on some casters instead. No big deal; I thought I'd come back around to it for LIWho 6.

    Except there is no LIWho 6. The con is done and won't be coming back, so I've left this one rotting in storage. Bummed that my con is gone, I worked on other things... until they came back around.

    LIGeek is organized by the same folks; they reached back out to ask if I'd be part of a panel on building these things. Which gave me some reason to pull Geo out of storage. I figured I should at least try to get the remote drive up and running; I was pretty close last year!

    So after reverse engineering my reverse engineering work to remember where the heck I left it all off, I started building: first a new remote; then some new code for the Teensy; and then I'm back to fiddling with the brushless controllers. While the reverse is working well, I haven't yet wired in the brake line. It's now time.

    You see, these wheels (and the base they're attached to) have a lot of intertia. Once they get spinning they don't really want to stop. My first pass just turns off the motors; the base still continues to roll. Why not run the motors backward? Because I can't. These controllers insist that the motor be stationary for some length of time before switching from forward to reverse (or vice versa).

    I faced the same with Bob (my 40% scale Dalek) which also uses brushless motors. When I finally wired up the brake line, I rewrote its code to use the brake to decelerate; it makes a world of difference in the overall handling (not to mention that it actually keeps Bob in place when I want him to stay still on an incline).

    So I figured I'd wire up Geo's brake line. It's just sitting there doing nothing!

    Sadly, I have no pictures of this piece of the build - it was done fairly hastily. I snipped off the connector and wired in the brake line, nothing to it. A quick bit of re-coding, and one test run later ... only to find out that it's not an active brake line. If I put +5v on this line, it just stops trying to drive the motors; exactly the same result as if I'd stopped trying to make the motor spin.

    Sigh.

    What I really need is an active brake. It's a deceptively simple system, really. Normally you'd spin the motor by pulsing power in to each of the three electromagnet coils in sequence. A, B, C. A, B, C. A, B, C. When you pulse the power in to each coil, it forces the permanent magnets to move forward one partial rotation. Keep pulsing faster and it spins up.

    When you want to actively brake the brushless motor, you just short out each of the electromagnet coils. The permanent magnets start to spin, which induces current in the electromagnet coil; but the coil is shorted, which induces an opposing electromagnetic force. The motor doesn't want to turn at all. Which means that an active brake needs to stop applying current to the motors, and instead short them out.

    I did find that there's a pin labeled EBS with no wire attached - right above the CCW wire from my earlier log entry:

    But in this case, finding the wire hasn't helped me any. Grounding it and pushing +5 through it don't seem to change the braking behavior, and unfortunately, I'm running out of time. Without the brake this build is a bit of a menace; it's really hard to change direction, because I'm at the mercy of Newton. I can probably make do with it and I can almost assure myself that I'll also wind up running it in to something unintentionally.

    Unfortunately, this probably means I'm abandoning these controllers for this build. With a couple weeks left to showtime, I need to button this up and get it working as a whole; it's my least favorite part of the build, the "I'm throwing money in this pit until the problem goes...

    Read more »

  • Entry 4: back to basics

    Jorj Bauer • 05/20/2017 at 13:43 • 0 comments

    So, with the magic smoke released from those controllers, I won't be reverse engineering them any more.

    What, exactly, was the point here again? Is there more to do?

    Why yes, there is. The reason I was reverse engineering these was to be able to control two controllers as one unit - so that they move at the same speed. I thought if I could hijack the built-in logic, I'd be able to build replacement firmware that would do that.

    This, I guess, is the moment when I decide how I'm going to move forward on that given that the original plan didn't work out.

    New plan: using two *new* controllers, which are admittedly slightly mismatched, let's tap in to the sensors and see if we can build an external controller that can both sense and control the speed of them. Together.

    I have two of these:

    ... perhaps I can tap in to the sensors as they're entering the controllers, and be clever enough with the logic driving the two controllers to get what I want.

    There's a slight hurdle. I need a reverse. That's a showstopper, because they don't have a reverse. Let's open it up and see what's in there...

    Well, well - that "CCW" that I've badly soldered looks good. Pull it to ground, and guess what happens? Reverse. Sweet. So, some quick soldering in both and we can start testing...

    Add an extra set of wires coming from the hall effect sensors, to see what we can sense...

    ... with this teensy 3.1.

    In theory, the teensy should be able to read the pulses from the sensors and interpret them to assess speed of each motor. Then with some control circuitry, it should be able to adjust the speed of each to achieve whatever result it wants.

    And, eureka, it mostly works!

    In that last image, you can clearly see the succession showing which direction the motor's moving. And the pulse length is the amount of time that sensor stays active, so it's inversely proportional to the speed. (Slower? Longer pulses.)

    Some judicious application of booze, and add one digital potentiometer, and it's time to start thinking about PID controllers...

  • Entry 3: RELEASE THE SMOKE

    Jorj Bauer • 12/28/2016 at 00:50 • 0 comments

    That durned magic smoke got out. It left behind some black soot and melted connector.

    So how did that happen, you ask?

    Well. From the last entry, it only took 6 more wires - PWM and commutator control lines - to test whether or not I could make the motor move. So, of course, I wired them up.

    Then I realized that the PWMs weren't on PWM pins on the Teensy. "No matter," thinks me, sipping gently on a Jade cocktail (champagne, midori, curaco, lime juice, bitters). "I'll just run the PWMs at 100%, and we'll watch this run up to full speed." Warning bells go off, but I'm ignoring them. "It just won't run by itself." Sip. "I'll code it to move to the next phase from the previous, based on the sensors." Sip. "I'll pull the battery when I want to stop it from running full out." Sip.

    Sip.

    Solder.

    Code.

    Sip.

    Upload.

    Sip.

    Connect.

    "P1" it exclaims! The motor jumps.

    "P44" and "P43" follow quickly after. The motor jumps again!

    And then it stops.

    Dead.

    Just long enough for me to think about what it's doing, and for me to realize I should really give it a push. Right now. Quickly.

    *Poof* goes the magic smoke, as the FET trying to power phase W gives up the ghost, having valiantly tried to move the damn motor in the wrong order. Rest well, FET; you'll always be remembered. Because I wrote this log entry about you.

  • Entry 2: Pictures Are Worth... Spending Time On

    Jorj Bauer • 12/27/2016 at 22:28 • 0 comments

    Yesterday I spent significant time drawing out the schematic of this nameless controller. (Yes, I should probably stop calling it "nameless" because it clearly has a label. In Chinese. But as far as I can tell, its name is "potted plant; not fermenting jug but similar; some sort of house; one" which doesn't do it justice either. So until someone translates it for me, "nameless" they shall remain.)

    I stared with some web searching - has anyone reverse engineered this controller before? - which is a bit difficult when you're searching for "schematics for the potted plant not fermenting jug but similar" nameless controller. But I did wander across a reverse engineered ku63 controller, which is certainly along the same lines. As the guy says on his web page: "Here is the schematic of the KU63 motor controller which may also give insight into other Chinese motor controllers." Because, as he says, it seems common to have multiple very similar products coming from China that share just about the same schematic. So how close is it?

    In some ways, it's fairly close. Eventually I'll import what I traced out in to Eagle and draw it up properly. Until then, this textual description will have to do.

    The power stages use a different MOSFET but the design is very close. There are a couple places in the power system where this newer controller has obviously tried to improve reliability. There are other places where they've clearly optimized for cost (reducing part count, particularly around the throttle). And this nameless controller doesn't have the back-EMF circuitry that the KU63 does.

    Overall, the KU63 work was good enough to give me a head start. It only took about 6 hours to trace out the majority of the circuitry; when I started wondering what the mystery circuitry was for (seriously, there are pins on the CPU that have capacitors directly to ground and naught else - why? - and then there are the transcription errors that show transistor bases connected to other transistor bases for pieces of circuitry that I have no clue why the exist!) I decided to stop decoding and move on to "can I get this to do anything?"

    [Fig. 1: this circuit makes no sense.]

    So, if I want to be the CPU, then I guess I gotta get rid of the CPU, eh?

    A little soldering and prying later, some minor repairs and re-seating the caps I pulled out, and...

    ... not too bad. Two resistors came up with the desoldering, but (a) they're part of the mystery circuitry and (b) I fished them out of the desolderer and put them back in place anyway.

    The worst damage is the traces to the CPU. They look okay above, but that's only because I put them back where they belong. They're no longer adhering to the board - par for the course with me desoldering. I'll manage. I think.

    So I clearly don't want to jam current down the motor until I know what I'm doing. So let's start with the hall sensors, shall we? I have 5 pins related to said, and I've got a Teensy 3.1 lying around that I want to use to control two controllers simultaneously (keeping them in sync). Looking at the schematic for this piece of the circuit, I think it should work with a +3.3v drive instead of a +5v drive, and the Teensy is 5v tolerant of the return. So the controller is wired back up to a motor; some enameled wire comes out and is soldered to the right pads for the CPU, then soldered to the teensy; and a quick program is whipped up to just read the sensors and report when the one on pin1, pin44, and pin43 changes state.

    Apply +36v to the nameless controller - no smoke, that's a good sign - and watch the terminal output while spinning the wheel. First in one direction:

    ... damn, that's satisfying. 1 -> 44 -> 43, very reliably; and it's really easy to feel when the motor is changing phases, so it's no problem to cross-check that it's doing the right thing. Feel the bump in the motor, see the output in the terminal. And does it work backwards?

    Sweet! 43 -> 44 -> 1, exactly as I'd expect.

    The other two pins look like they're some control...

    Read more »

  • Entry 1: from whence we start

    Jorj Bauer • 12/27/2016 at 03:21 • 0 comments

    Before 2016, I'd not worked with brushless DC motors. Being very aware of the Dunning-Kruger effect, I assumed that I would need to learn quite a lot, and that I'd come out the other side thinking myself an idiot. Which is mostly true; I made some ridiculous mistakes along the way. But the flip side of Dunning-Kruger is that it doesn't take much knowledge in a subject to start to get a handhold on it. Once you know just a few bits of the fundamentals, you start realizing what the right sorts of questions are; and once you know the right questions to ask, it's easier to find the answers.

    This translates directly in to my engineering mantra: if you want to bootstrap in to technology that you haven't worked with before, you can follow one of three paths.

    1. You can spend time working with someone that knows what the heck they're doing;

    2. You can spend time researching on your own, which takes substantially longer;

    3. You can spend (often quite a lot of) money to flail about until you figure out a tiny bit, and then iterate.

    Well, not knowing anyone that works with BLDC motors; and not having a lot of time to spend researching; I went with path #3. I needed to rebuild the motorized base; I needed it to use more powerful motors than I'd been able to find as brushed DC motors; I knew that hoverboards existed and were able to move a person. So we bought a hoverboard, disassembled it, reverse engineered a little, and that's when I learned about brushless controllers. By reverse engineering bits of that hoverboard controller I learned enough to be able to ask some of the right questions.

    Which lead me to looking for replacements. The controller in the hoverboard is probably fine, but I found the idea of working around its firmware onerous and distasteful. Why would I want to write software to work around bugs in software? That's just going to cause more trouble later. So I went looking for reliable controllers. But what *is* a reliable controller? What makes a BLDC controller good or bad? I had no idea. Following rule #3, I went out and bought a few.

    It turns out that quite a lot makes BLDC controllers bad. Well, maybe not bad - but not what you want. Some of my mistakes:

    • I bought two brushed DC controllers by mistake. Whoops. I already know how to drive brushed DC motors, and I've got plenty of parts to do so.
    • I bought two nameless brushless controllers via eBay which aren't reversible. I hadn't realized they wouldn't all just be reversible.
    • I bought one controller from a bona fide eBay auction (you remember those? Y'know, before it was just a bizarre storefront?) - it's reversible, but I've only got one, and I need two matching controllers. Well, want two matching controllers. I figured if the others didn't arrive in time, maybe I could find a match for this guy later. And it was under $15 with shipping! (Which explains the state of my basement/workshop.)
    • I finally wound up with two 36/48v brushless controllers (SPD-3648350BLDC) from electricscooterparts.com. These are literally the only brushless DC controllers I could find that were 36v and reversible, and were available in the continental US. Unfortunately, they also have a firmware ... glitch? feature? ... that makes them difficult to use. Again, I found myself writing software that guessed at what the controller firmware was doing so that I got the result I wanted. And in the end, it's okay. I can drive Dalek Bob reasonably well. It's just difficult for anyone else to drive him.

    Now I find myself at the beginning of a build for Dalek Geo (pronounced "Joe") - at a point where I really don't want to be working on the GRP (fiberglass) pieces inside and it's just too cold outside. Which means focusing on the electronics. Which brings me back around to controllers.

    Working backward from where I wound up on Dalek Bob: I don't want to re-use the same controllers, because I'm not satisfied with their firmware. The company says they don't have a copy of the firmware, and don't know if it's possible...

    Read more »