Have you ever felt the urge to control multi-horsepower electric motors?

with an arduino?

Doesn’t quite work like that…

A few months ago, I did. During that time, Super LOLrioKart and the mini-CityCar were both looking for a compact 36 to 48 volt, 1-brushless-and-1-dc motor control solution of roughly the same power requirements. The attentive reader (all -2 of you) would notice that a few months ago, I didn’t yet possess the skills to design printed circuit boards, and I would be hard pressed to make a good power converter on the back of an Arduino protoshield, or a chunk of perfboard.

Actually, I’ve tried before, and it failed miserably.

But the cool thing about the MITERS clique is that there is alot of cross collaboration. Being mechanical engineers, Shane Colton and I naturally build electronics, power converters, and motor controllers (because those are totally things that mechanical engineers do). And so, at my constant (b)egging, he created the Hexbridge shield, and then refined it to version 2, which is more compact and… more functional.

And now, the (impending) torch has been passed to me. So my goal is to make this thing run a standard sensored brushless DC motor, kind of like a more elegant FVM. It would be the first time I code up a BLDC controller of any kind, Arduino or otherwise, and is the logical step after creating the Kartroller’s H-bridge drive.

The rundown on the Hexbridge shield (/Hexshield): 12-48 volts (nominal) operating range. 30 amps or so continuous operation, more (50-60+) with special attention and addons such as trace reinforcement. Six half-bridges grouped into two gangs of three, i.e. enough to make two BLDC motor controllers. The two gangs each operate off 1 Arduino PWM pin (namely, D9 and D10). The FETs are D2PAK IRFB3207 units, good to several quintillion amps and according to folklore, will desolder themselves long before burning up due to heat!

Because you the user programs the Arduino part, it really can be anything.

As noted, more shields can fit on top of the Hexbridge.

In this case, I’ve put together the Arduino WireBrushLess Tower, the future wireless brushless DC motor controller. The XBee radio module takes commands over the air and the Arduino can read them via its serial port. The idea is to have all of these controllable from a command console in order to make vehicles that go whichever direction you feel like without worrying about tangling control cables.

The small protoboard area next to the Xbee acts as a convenient signal interface stage. The long header presents 3 Hall Effect sensor inputs, logic power, and ground.

For now, I’ll forego the “wireless” part and just use a knob to control the thing. So, the small header is designed to take one knob as input.

In a coming post (when I get around to it), I’ll explain how the knob can actually be a very special magnetic absolute position encoder… for, you know, keeping track of the position of wheel modules which might spin more than 360 degrees at a time.

Here’s the knob wired up, along with some hall sensors.

… but from what are those hall sensors originating from?

The brushless Etek is my favorite Absurdly Large Load to test small controllers with. Everything from Turnigy airplane controllers to the DEC module has seen this thing. It’s both the largest “normal cheap motor” after Briggs and Stratton ditched the original Etek, as well as the smallest “big motor” that is easily available on the grey market.

I quickly whipped up some Arduino code using FVM as a guide for the state table. Overall, the process and structure are similar to what I made for Kartroller 6 – first arrange the outputs to account for the state of the system, then apply the throttle signal. In the case of Kartroller, the states were “forward” and “reverse”. With a BLDC motor like this, there are six states to cycle through to achieve one electrical revolution. “Reverse” on a BLDC motor is just stepping backwards through the table.

Here’s a video (10 megs .MOV) of some of the testing done with the Etek motor. Of course, it’s not a particularly strenuous test at all – the power supply limits itself to 3 or 4 amps at most. What it does show, however, is the built-in synchronous rectification topology that the IR21844s facilitate. Non-regenerative motor controllers will just let the motor coast if I let off the throttle, but a synchronous regenerative one automagically shuffles current in either direction to match the voltages between the motor back EMF and power bus.

Now, the problem with a power supply is that they generally do not approve of having current backfed into them. The voltage will spike as a effort to fight the inflow of current, and this power supply knew when to avoid getting hurt… That is why makers of regenerative controllers always advise putting a battery (or hugeasspacitor) in parallel between a power supply and the controller.

Well, that’s all for now. There are still three whole half-bridges left unused…

I’ve been waiting to use that title for a long time.

Building the ‘blades has been quite an exercise in unfamiliar territory. First, the skates will be using the Maxon DEC modules, which are essentially experimental with respect to the project, me having seen no other vehicles that use them (seriously – all other Google results seem to just be press releases). Having access to the DEC modules was the impetus behind me finally learning PCB design and layout.  I just discovered the magic that is force-sensing resistors and how they can be used as an analog throttle.

And now, as the final and pivotal step in closing the proverbial control loop of the Deathblades, I shall link the throttle with the DECs using XBee radio modules.

SOOOOOO CUUUUUUUUTE. It’s just like a really obese centipede with a silly hat! That transmits and receives data!

These little 2.4GHz, 802.15.4 radio modules are very popular in the DIY and maker crowd because of their level of flexibility. They can form star, mesh, and mixed topology networks, and can act as wireless serial bridges. But much of their popularity (at least of the Series 1, not so much the newer models which adhere more closely to the standard) is the ability to act as an airwire. The XBee can be configured to pass two analog signals in the form of 0-100% digital PWM, and then up to 6 more digital I/Os, all without involving another microcontroller in the loop. To make my life even easier, Digi International provides X-CTU,a useful GUI tool for configuring the radios to do your bidding.

I yoinked two Xbee Adapter boards from MITERS’ neighboring student activities so I could easily throw together a breadboard assembly.  Each unit here is receiving 3.3 volts from the FSR board regulator. I set them up such that the transmitting unit receives the analog FSR voltage on AD0/DIO0 and an “enable” signal, on AD1/DIO1.

On the receiving side, the radio has PWM0/RSSI hooked to the oscilloscope, along with its own AD1/DIO1. Digital I/Os are paired, but the analog ones have their own pins.

Conveniently enough, RSSI was connected to a red LED on the boards.

Configuring the radios to act as analog and digital airwires. There are relatively few settings to change, and most of them revolve around how to use the I/O pins. I referenced Rob Faludi’s XBee I/O page (props for being the number 1 Google hit for the exact words “Xbee Direct I/O”) and Digi’s own knowledge base page on the matter. Needless to say, RTFM came in handy also.

The things I changed from the default firmware settings for the transmitting side, all values in hex:

• Pan ID (ATID)  = 9000, because… well, I could.
• Radio ID (ATMY) = 1, just a number again.
• Destination Address L (ATDL) = FFFF, which is the broadcast setting for the simpler 16 bit addressing mode. If I wanted the transmitter to only talk to one other radio, this would be the ATMY of the other radio. But I ultimately want to control 2 other modules, and simple I/O mode doesn’t allow changing of the address on the fly, so broadcast will have to do. Fortunately, there are settings for which radio IDs you should listen to.
• Digital I/O 0 (ATD0) = 2, for this pin’s ADC mode, hooked to the 0-3.3v output.
• Digital I/O 1 (ATD1) = 3, for this pin’s function as a digital input, mapped to DIO1 on the other modules trained to it.
• I left ATIU off because I didn’t need the packet information from the radio’s serial ports.
• Number of samples before transmission (ATIT) = 1. I don’t know what the effect of changing this to a higher value does – perhaps to filter out noise or slow the rate of updates, but I decided to just transmit everything.
• Sampling rate (ATIR) = 1. The sampling rate can increment in 1ms resolutions. I decided that 1ms was fine.
• Input address (ATIA) = FF. This is the which radio is commanding my I/O lines option. In the case of the Tx, I set this to 0xFF, which is the “nobody” option, because… well, this is the transmitter. The receiver would have this set to 1, the ATMY of the transmitter. This was crucial. I missed it the first time and the bridge most definitely did not work.
• PWM0/RSSI pin mode (ATP0) = 0. The transmitter won’t be putting out a PWM signal, so there is no need to set the pin.

From this, it seems that ATIA = FFFF and ATDL = FFFF will cause all radios to affect all other radios. I’m sure this is not actually the case, because that sounds like a nightmarish scenario.

Next, I set complementary values for the receiving side:

• PAN ID = 9000
• ATMY = 2 , this was arbitrarily the 2nd radio in my little network. It could have been the 987th.
• ATDL = 1, because it should talk only to the transmitter, not broadcast.
• ATD0 = 0, or disabled, since I’m not using DIO0 as a digital I/O.
• ATD1 = 4, for this pin’s digital output mode with a default setting of LOW. Logical low disables the DEC’s outputs, which I want. DIO1 is hooked to the enable signal on the FSR board.
• No ATIU, ATIT, or ATIR (left unchanged or default values)
• ATIA = 1. This trains the receiver to radio ID #1, which is my transmitter.
• And finally, ATP0 = 2, to couple it to the analog-to-digital coversion of DIO0 on the transmitter side.
• I set pin timeouts (ATT0 and ATPT) to 500ms so all the outputs return to their default states if no valid updates are received within that timeframe.

What does all this result in?

Well, first, nothing if I don’t hook up the VREF pin on the transmitting XBee. Which I didn’t. Comparing 3.3v to #NaN always results in bullshit.

But here’s a video of the wireless signal transmission working. The RSSI LED is being used as the PWM output here, and its brightness varies as I push down on the FSR.

The scope clearly shows the 16kHz square wave coming out of PWM0 as well as the changing state of DIO1. On the FSR board, I made an (adjustable) comparator input that drives DIO1 high only after the FSR voltage exceeds a threshold. In the video, it’s about 30%. This acts as a very (very) rough control deadband so random hand flicks don’t cause the motors to turn on.

The downside is that the minimum throttle at activation is 30%. Clearly, this will be adjusted to taste. More sophisticated glue circuitry will better approximate a deadband curve, but this is enough to prove the concept.

One catch: the DEC modules run 5 volt logic but the XBee runs on 3.3 volts! So I lied – even at full throttle, it means a direct signal would only have me crusing at around 66%.

Lame. So to validate one of the experimental parts of the “Double DEC’er” board, I made a small buffer that outputs 5 volts. Two 2n7000 signal FETs are wired sequentially in common-source mode, which makes sure the signal is still rectified. The 5v, 16kHz output is trivially filtered back to a smooth analog voltage by a 1Kohm + 1uF RC filter.

The actual DD board uses SOT parts for smallness.

But did my crazy broadcast plan actually work?!

I set up a 3rd XBee  (had to hunt down a 3rd explorer board for this one…)  in the same fashion as radio #2, except with ATMY = 3.

The presence of a variable red light on both modules indicates to me that they are linked successfully. Probing DIO1 on radio 3 results in the same enable line toggling.

So to wrap up the whole deal with PAN ID, broadcast, radio ID, and destination address (for my own future reference and sanity, as it took me forever to distinguish between them…).

• An XBee with ATMY x and ATDL y will talk to an XBee with ATMY y and ATDL x if they are on the same PAN ID z.
• An XBee with ATMY x and ATDL FFFF will talk to any other XBee on the same PAN ID z. But the others will only talk back if their ATDLs are set to x. The others may still converse amongst themselves if their ATDLs and ATMYs are appropriately set.
• Changing the PAN ID effectively creates another network, and there can be more XBees with ATMY’s x and y which will in turn only talk to eachother.
• Changing the active channel will create the above scenario all over again.
• A billion fucking XBees can therefore be in the same general vicinity and will probably still all work.

I hope this is all correct. If it’s not, CORRECT ME. Otherwise I might go through life spreading the same lies and misinformation that I believe in, which puts me awfully close to being a politician.

Time left until Otakon: A month and a week. I think I can bang up a decent cosplay by then.

waiting on you, advanced circuits

I was able to hop onto a lab parts order early yesterday and throw in some force sensitive resistors and prototyping miscellanea. Thanks to the miracle that is modern supply chains and logistics, I had them on my desk in less than 24 hours.

Now, if only Advanced Circuits could finish my Double DEC’er boards that fast. I mean, without costing a significant percentage of my undergraduate tuition.

Oh, speaking of the Double DECers, here’s the latest board iteration featuring discrete 3.3v and 5v regulators. The amount of power I wanted to draw from the 5v line was cresting the limit of the DECs’ onboard regulators, so I added one that runs directly off the battery input. Also, a power LED.

I figured it was safe to stop there for now.

And here’s (part of) the controller parts roster. On the left is a Lilypad Xbee holder and prototyping antiperfboard. Lilypads were designed to be used with wearable electronics, and I figured that the controller qualified as a piece of wearable electronics. These things are actually huge. They looked tiny and cute in the pictures, but are actually about 2 inches in diameter. I foresee no fitting problems, however.

I got four coin cell holders. The controller power will, for now, come from 2 CR2032s in series for a 6 volt power source, which will be regulated to 3.3 volts.

The XBee 2mm headers are for the Double DECers, so I don’t have to solder my poor XBees to the board.

Anyways, here’s How Shit Go Down™ with the FSRs.

Their resistance decays as 1/R with linearly increasing pressure. There is a very high (megohms) unloaded state, and a minimum force must be applied to enter the hyperbolic region. After a certain pressure is applied, the decay saturates at a steady value until you compress it out of existence. Actually, all this is in the datasheet. Why am I explaining it?

I elected to begin experimenting with the “buffered voltage divider” on p. 16. As fig. 9 illustrates, the voltage response is highly nonlinear near zero force. However, with a low load resistance (Rm), the logarithmic curve is approximately linear at higher forces.  And with a high parallel resistance inserted across the FSR, the Precipitous Voltage Cliff is smoothed out to a zero force intercept with a value of approximately (Rm /  Rparallel + Rm) * Vref.

I exaggerated this approximately linear curve even further by using a 1Kohm load resistor, which seems to put me on the edge of the FSR’s 1ma per cm² current tolerance. Next, I set up the op amp buffer as an adjustable noninverting amplifier (as seen in figure 10). Tuning the blue potentiometer effectively let me set the force slope.

Now I had a response that was kinda-sorta-not-really-but-close-enough linear within an adjustable force range. To supplement, I put a slow RC filter (t ~ 0.5 sec) on the output of the amplifier.

After having enough fun playing Squeeze the Resistor, I began to attach it to spots on the wrist plate for ergonomics testing.  The results:

• Palm area: Good wrist bend force response, but had the unfortunate side effect of also responding when I opened my palm all the way. This was due to the way the sensor was oriented – a normal force could come from either forcing the hand down through the wrist or pushing the palm out by uncurling the fingers.
• Other side of same area: Very little response at all, because the force didn’t really go that way.
• Behind the wrist on the flat portion of the plate. This is the 1st class lever equivalent of the first configuration, so it suffered from the same undesirable side effect. Pushing out with the palm also meant that this area of the plate was pushed upwards (with the main wrist strap as a fulcrum), triggering the sensor. Clearly, any response having to do with “opening of the hands” is bad, because that means if I’m trying to recover from an impending faceplant, it will just faceplant me harder.
• Right under the wrist: Now this was actually promising. While the motion is reverse (i.e. now I pull up with my wrist), the side effect was eliminated – if not, it was a transient at most.

Crap, should have made the damn wire longer.

And so I actually settled with the original motion I was going to reserve for a brake or reverse mode. Now, something that can clearly solve this issue is having multiple FSRs such that different ones are triggered depending on hand position. The ability to distinguish between the open hand and limp hand with wrist pressure positions clearly mean the difference between go faster and oh shhhhh–.

However, that would require some software processing of the multiple signals, and I want to just start simple for now.

Here’s a short video illustrating wrist bend control. In the video, the control looks sensitive with respect to distance displaced, but that distance comes with substantial force applied against the wrist straps and plates. It’s actually quite easy to maintain a certain voltage position, and the “muscle twitch” response is well damped due to the filter.

The moving line scale is 1 volt per division, and the maximum output voltage is just under 3.2 volts. The system runs on a 3.3 volt bus (XBee native voltage) using the LMC6484 rail to rail I/O op-amp to take maximum advantage of the low voltage swings.

Next mission: Transmit this 0-3.3v signal to another board using the XBees in direct I/O bridge mode and decode & buffer the output to 0-5v.

(more…)

MITERS is the greatest thing that has ever happened to the world (or specifically just me), but while it has copious amounts of tools, test equipment, machinery, and an almost gratuitous amount of parts, it lacks space. Having been to other non-academically affiliated hackerspaces (such as Freeside Atlanta), I realize how outclassed we are in our capacity to host projects. Despite that, we’ve stacked up a whole bunch of “large”, generally vehicular contraptions, including the beloved LOLrioKart.

LOLrioKart takes up a good portion of floor space in the back half of the room and is occasionally used to store all my crap. It’s also a pain to move around because of its mass, and a pain to work on the electricals because they are all very low to the ground. If I want to test the drivetrain, I had to lift the kart and balance it on a set of automotive jacks. Don’t even mention that time I had to swap the battery packs…

So for a while, I had wanted a lift or crane to suspend the kart from. I didn’t take the idea seriously until Spring term ended, when I started looking for options. I became partial to a ceiling-mounted hoist because of the ability to send the kart all the way to the top for storage and extra floor space.

The kart only weighs about 200 pounds empty, which is a essentially trivial load in the world of winches and cranes. MIT building N52 used to be a factory, and factories in the early 20th century were built to last forever. The ceilings are all solid concrete, more than a foot thick. Essentially, almost anything would have worked, and I briefly considered just gearing down a beefy DC motor instead of buying a specifically designed winch or hoist motor.

But as luck would have it, Craigslist produced a pristine example of an ATV winch for sale locally, so I quickly jumped on it.

This Master Lock (I thought they just sold locks, but I was wrong) unit seems to be a pretty standard offer in the world of cheap generic utility winches. It made some substellar sounds when loaded and the drum finish was pretty rough, but I’m going to assume that it won’t kill me. Too badly, anyway.

The mounting holes in the winch frame were located in a place where I couldn’t access them with a powered screw driving tool. They were designed to be mounted to brackets first, which are in turn mounted to your choice of stationary reference frame.

…so I had to devise my own. This 3/8″ aluminum plate was just hanging out in the cave of materials. I could probably have waterjetted any number of small robot parts from it, but hey.

The two large middle holes are countersunk on the other side to fit 5/16″-18 socket head cap screws. The six surrounding holes are countersunk to fit some 1/4″ flathead concrete bolts. MITERS had a large stock of “tapcon” style concrete screws (which do not use anchors), probably from back when we bolted stuff to the ceiling all the time.

Because bolting things to the ceiling isn’t exactly a precision machining activity, I used spraypaint and sprayed a pattern into the ceiling, using the mounting plate as a template.

The winch itself is mounted using two 5/16″-18 socket head cap screws and grade 8 nuts and washers. This should not be the first failure point.

A little while later…

I borrowed a hammerdrill and a 5/32″ concrete bit and went to town on the ceiling. Reportedly, the hammering noise was ungodly loud, even on the third floor. I guess that’s what happens when you bang on a solid concrete building.

I learned that a hammerdrill is best used not under intense drilling pressure, but rather under modest pressure. If you push too hard, you dampen the chiseling action and the effect is diminished. This was well reflected in me taking almost half a minute to drill the first hole – but the last only took 5 seconds.

Unfortunately, attempt #1 to mount the winch didn’t go well. I made the mistake of reading a different box of screws (which specified a 5/32″ drill). 1/4″ tapcon screws need a 3/16″ drill. The difference meant that I managed to shear off the screw halfway into the final depth.

Epic fail.

I quickly went back with a 3/16″ bit to expand the other holes, and the rest went well. Friends and cohorts spotted the high-altitude work and helped hold the 25 pound winch up while I drove in the screws.

But after much sweat, concrete dust, and loud construction noises…

FLYING LOLRIOKART

Well, at least I know my five-bolted rig can hold up 1 LOLrioKart. The only power supply strong enough to supply the current demand of the winch was a big Optima lead-acid battery.

Because this is a shady winch being held up by shady screws into shady century-old concrete, we started piling heavy things into the kart to see if we could find the maximum load. Helmets and face shields were aplenty during this exercise, because even if the kart was only 1″ off the ground during it, the falling 20-odd pounds of steel were a concern.

Things piled into the kart include two truck disc brakes (60 pounds), the lead acid battery (50 pounds), the Defibrillator (a.k.a the kart charger, 25 pounds), one brushless Etek (25 pounds), a huge linear power supply (25 pounds), and a milling vise (40 pounds). Powered lifts and interrupted drops were attempted to put force on the mounting, but it was solid. I think it’s proved itself.

Assuming I did install the screws correctly and that the concrete is not crumbly, each 1/4″ concrete screw is rated to a maximum of 1,100 pounds assuming a 1.5″ depth. There are five holding the plate to the ceiling for a cool ultimate tensile strength of 5,000 pounds. Even accounting for imperfections, the winch should stall long before the screws pull out. It’s still unlikely that I’ll ever allow anything more than the kart by itself to be hoisted, or items of similar weight, because it can get overhead and that can end badly.

Yup, it’s a hoverkart. Any questions?

After two weeks of nervous, anxious anticipation…

SMALL CUTE HALF BRIDGE BOARDS! They’re so clean… so shiny… so detailed… so…

… expensive…

I ordered 4 (+1 free) from Advanced Circuits shortly after posting about them. Over the course of 2 weeks, I got no less than 1 postcard, 1 thick envelope (which I thought contained my boards) full of brochures, a round PCB drink coaster, and three sales representative calls asking me how I’m doing and whether or not I had any order questions.

And with the boards, I got a little packet of free microwave popcorn.

Advanced Circuits is like a grandmother or gift-pushy uncle. I’d actually appreciate it if they laid off the customer appreciation and just got me my damned boards faster. That means more than any random token ever will.

Anyways, 5 is enough for one split-pi converter and 1 3 phase motor driver bridge. So there may be some more minor power conversion experiments in the future.

While waiting for the boards and the WHERE THE FUCK ARE MY BATTERIES, STILL? for Deathblades, I decided to make a second iteration of the “Double DECer” board.

Alot cleaner, isn’t it?

Shortly after finishing the previous iteration and  debating myself over component placement and available volume, I discovered there was really no problem at all.

In designing the most recent drawing of the ‘blades, I mistakenly constrained the top of the battery pack to be 5 millimeters under the edge of the aluminum sides. When I changed the battery pack spec, I only changed the part dimensions and not that constraint. In reality, then, what seemed like only 5 millimeters of space was actually 23mm. I thought it was a little weird to have a 31mm tall battery fill up a 54mm cavity almost to the brim.

I then remembered that PCBs can have two sides, which was instrumental in creating the new layout. If I put the Xbee and DECs on opposite sides of the board, then they won’t conflict with eachother volumewise!

The new layout reflects this. On the “top side” sit the Xbee, glue circuitry, bus capacitors, and I/O connections. The DECs, now turned to face eachother, occupy space on the board’s bottom, and the “overhang” they provide is used to park the 3.3v regulator. All the control pins are right there and there’s no more cross-board running of signals.

I was even able to add some real mounting holes. The outer dimensions are within Eaglol’s 4 inch X-limit, and the board is 1.5″ wide.

This is a board that is actually worth sending out now.