or, The Concise Summary of the Reasons why I Hate Everything about Electronics and Software and Therefore Do Not Understand Why I Insist

on Constructing Complex Electromechanical Implements Involving Them; A Memoir by Charles Z. Guan.

One day I will actually write a book on why I keep building custom electric vehicle components knowing full well that I hate electronics and software and that it always blows up the first …. few… times or is generally just a pain to deal with.

Alternatively, I could complain on the Internet and then go right back to doing what I was before. But before all that, a video.

There you have it. After the past week of rebuilding and debugging of the electronics, I have a LBS that…

• Doesn’t use the Turnigy 80mm brushless motors like I said it would
• Doesn’t have the wireless hands-free controllers like I said it would
• Doesn’t go nearly as fast as I said it would…in fact about 2/3rds the previous design speed.

…so what did I actually build? I’m not sure, but it looks kickass and rather cute at the same time. It reminds me of some kind of miniaturize fancy construction equipment (you know like they make miniature cows or something). It’s very square and squat, the appearance complemented by the disproportionately large track pods…and honestly, would look at home in the MIT anime (I’m making one, I promise) as-is.

Last time, the Shark adventure ended with the motor controllers exploding upon application of power. Kind of reminds me of a certain other basket-case vehicle”s history. Not wanting to resort to just putting some Victors or something on it, I went ahead and made an entirely new board from my panel of 6 that I ordered, and being slightly more intelligent this time, tested it on a current-limited bench power supply first.

First runs of  motor controller designs seem to either work, or explode spectacularly due to some fundamental error in judgement. I couldn’t get the new board to not dead-short the power supply. Any time the IR21844s were enabled, the boards would instantly become roughly 6-ohm loads and heat up quickly. 6 ohms? That’s a clear sign that FETs are turning half-assedly on, or half-assedly off, being unable to reach either the blocking state or the fully on, conducting state. Now, these controllers have already been live-edited once – I left out a critical connection in the current sense circuit, so I was checking for more unrouted connections and other signs of rushed board routing.

It was more useful to look at the schematic.

 

Unlike the Segfault boards, the issue in this case is what’s not connected. As in, the Vs (high side FET’s source) and M terminal (motor output, also known as the high side FET’s source) weren’t connected. This meant the high side can never really turn on… or turn off, or anything really. The gate might as well be left floating.

Great.

Well, at least this is an easy Little Blue Wire fix.

After verifying that, yes, the controllers no longer were power resistors, and that they responded to a PWM input with a proper output, and that my lack of attention and dismissal of EAGLE’s frantic cries of “YOU HAVE REMAINING AIRWIRES!!!” had done me in once again, I installed the controllers back into LBS. I decided to take the more cautious route and test everything on a power supply.

This is where the three hours of software nightmare began. Using the crude motor actuation code I made last week, I was able to get the motors to move forward and backward, not under radio control. This was just to verify the operation of the controllers and make sure the current sensors were working.

I began writing a more sophisticated driving program that took inputs from a handy R/C car radio (the HK GT2 if you’re interested). The first program was very simple, just taking the servo pulses centered about 1500 microseconds and linearly mapping them to motor PWM values… about a bone-simple as you can get. Hell, even people in 2.007 managed that one. I even taught people in 2.007 how to do that. It also read the status of the rider-detect switches and latched the contactor accordingly. This was one thing I wanted to get right, since I wouldn’t want my rideable 2.007 robot to run away.

But no matter what, I could not get the motors to respond reliably. The contactor would latch and unlatch unpredictably, the motors would twitch and some times lock on full speed. The ADC pin that the rider detect switches were connected to would seemingly turn into an output at will, driving the circuit low (and of course causing the contactor to open and the motors to stop). Then, it would randomly cut back on.The Arduino would frequently lock up, and the serial port some times spewed nonsense repeatedly until the board was reset.

Initially, I thought it was a grounding issue, since the 2.007 Arduino Nano Carrier has some limited protection features built in on its logic power supplies that could have been messing with system ground levels. I tried rewiring the board to run off a separate power supply, figuring that the contactor closing could have been introducing noise into the 15 volt supply that fed the board through the ground.  I tried disconnecting everything at the advice of master Course 6 guy, and that pretty much ruled out any hardware being the cause of the problem as the board continued to twitch, reset, and lock up. The next step was to knock out functionality in the code, line by line, isolating the problem to one line of code.

Was it the math involved in processing the throttle and steering pulse inputs? Nope, with the exception of some possible variable typecasting issues, which were cleared with no impact on the problem.

Was it the multiple consecutive pulse reads that could have resulted in some weird timeout behavior? Nope. They did that in the class all the time and it worked fine.

Was it issues with Arduino built-in functions such as constrain () or map() and the inputs being incorrect or out of bounds? Nope, even reduplicating the functions explicitly didn’t solve anything.

And finally, after commenting, correcting, and deleting just about everything, we arrive upon the last line.

LMOTOR and RMOTOR are constants that designate digital output pins, and ICMDx is the byte being sent to the PWM times on those pins. If you see what is wrong with these two lines, you get a cardboard brownie.

Spoiler warning: The syntax for analogWrite is PIN,VALUE… not VALUE, PIN. I was telling the board to write a PWM command to… I’m not sure, pin 9000 or something. This probably caused the process to jump to a random location in memory, causing all kinds of weird shit to happen. In other news, Arduino functions don’t have error checking for this stuff?!

After this minor detail was redressed, the rest of the code  and original wiring scheme was restored and it worked just fine. Everything. There were no noise problems or anything of the sort. The vehicle responded to radio commands like one of my robots would, and it was driven around as a robot for amusement for a few minutes. Then after making sure the basic driving code behaved as expected, I spent a further five hours adding in such luxuries to the program as radio failsafes (stopping upon loss of radio signal, instead of spinning wildly in a circle as it did up until that point…), more intelligent processing of the rider switches (in other words, not holding the last good throttle value and causing the vehicle to take off immediately upon reactivation), and throttle-steering ramping. The ramping was critical to making the vehicle actually controllable since it more or less just forced a constant acceleration and made the radio controls less sensitive to minor movement.

tl;dr i hate software

Like many Course IIs (and closet VIers), I still view software as a time-consuming impediment to finishing projects, that is made primarily of black magic and guess-and-check. That thing you leave until the very end when the mechanical and electronics are hooked up and ready, despite being the one factor that makes or breaks a project. I’ve kind of lost the ability to “think in software” like back in my high school AP Computer Science days – lines of code that seem perfectly reasonable to me now usually are huge logic errors when executed. It’s more of an annoyance than anything, and I suppose only writing more code will exercise those skills again enough to make programming expedient.

It’s not even real software. It’s Arduinos.

Anyways, back to things that matter. I’m not bitter at all, I promise.

Drive testing revealed that the electronics were getting really hot. The CIM motors are 12 volt motors by nature, and pretty powerful ones at that, so placing them into a 20 volt environment made their current draw that much higher. The locked-antiphase control meant that there was an idle power consumption – namely about 50 watts. Add to that the very high scrubbing friction that the tracks experience when turning and the fact that most of the testing was done at low speed (no forward movement alleviation of the turn) and you had motor case temperatures exceeding 60 celsius and controller temperatures not much below that.

Well, I couldn’t really care less about the CIMs at the moment, but I wanted to make sure my precious custom controllers don’t smoke themselves. Solution 1 was just dropping a slightly trimmed server heatsink under the FETs. This turned out to be not too effective, since the D2PAK FETs don’t have that good of a thermal resistivity from the plastic face. Additionally, the board was still edge-fastened, causing the whole thing to bow a little bit and really not letting the FETs have any heatsink contact. More time drilling holes (to use the center mounting holes) would have alleviated this problem, but…

Forced air works just as well in this case. I took out the heat sink and hot glued on a pair of small 1U rackmount server fans, and all was good. The fans run off the 15 volt supply, and the stiff breeze over the board and components that stick out relieved the heating issue – it is at least some finite amount of airflow such that all components and copper traces contribute some to heat removal.

Before this was added, I think the capacitors were acting as a heatsink for the FETs. Hey, copper leads, aluminum plates…

I realized I never actually posted a picture of the rider switches, so here is one. A submini snap-action switch and a 3d printed mount that clips over one of the mounting bolts for the pivot joint. When a rider is present, the slotted pivot presses on the switch. Only one switch has to be engaged for the vehicle to be activated, and when no switches are engaged, the vehicle shuts off the main contactor after 2 seconds.

One little afterthought which can be seen in the video is this wheelie tail. I designed this in about 10 minutes early one morning and cut it out an hour afterwards, so there was really no thought put into it…such as the fact that it’s made of mystery scrap plastic (behaves like Delrin, so I assume it’s something similar) and has huge stress risers at the pivot point.

It also revealed a discrepancy between the CAD model’s tread thickness and the real life one. The tail was supposed to ride about 2 inches off the ground, but in reality this was less than 1 inch, which prevented me from adding wheelie rollers of any reasonable size. In the test video, they are simply shown dragging on the ground. Hey, Delrin is a low friction plastic… stop judging me.

I will probably remake these, as there’s plenty of scrap left to be further up and slightly less out, and mount roller skate wheels on them. Or the wheels from the skateboard that was parted out to build it.

Recharging, after an entire night and morning of drive testing. I’m slowly getting the hang of this thing. All the drive testing in the video took out about 8 amp hours out of the 24 or so onboard – I’m not sure what distance this translates into yet.

next steps

So I’ve built a robot. Hey, I think I’ve done that before!

When testing LBS, my fears of the wheelbase being too short to stay on top of were realized. If you accelerate or brake too hard, the entire vehicle just lurches forward or backward. This is grounds to give the vehicle a little bit of “Segway action”. While it will not balance you outright, the springs in the suspension allow the vehicle to tilt forward and backward enough to sense an angle. While I previously said that the board wouldn’t be involved in the control, I didn’t think about the implications of having a slightly tiltable suspension. I was more thinking of pure weight-shifting scheme which would cause issues with accelerating reference frames. I think the vehicle can at least be programmed to stay under you. That is, upon acceleration, it will recognize a tilt occuring in the opposite direction and slow or stop the acceleration to compensate. I’m probably also going to experiment with forward and backward lean control for the throttle if the acceleration adjustment does work out – after all, if it’s trying to stay under you, there’s no reason that leaning can’t be the only control input.

 

Two weeks ago, I put together the CIMulink modules for my “trackboard” (as it has now been termed by a certain MIT professor). It then proceeded to sit under a table again for another week before I decided to blitz-finish everything so I could tool around on it come graduation day. As you might guess by the title, that didn’t quite go so well. But hey, when have I ever tried to build something involving a custom motor control solution and have it work on the first try?

The long story, spanning roughly the past week, follows:

You can’t have an electric vehicle without batteries, so the first order of business was putting together a gigantic pack of A123 DeWalt Drill Battery cells™. Originally, LBS was to run on a 12S pack for 38 volts nominal. However, the CIM motors are essentially 12 volt motors, and can be run up to 24 volts carefully. So I’m splitting the original 12S6P configuration into two 6S6P packs in parallel – or just 6S12P. This means it has something absurd like 26 amp-hours onboard, but the voltage is nominally 19 volts, a safe middle ground for the CIMs.

I used my usual tactic of Assnormous Busbraid & Ship-Soldering Iron with Gigasolder to make the connections between the cells. Soldering to Li cells directly is always looked down upon, but it’s possible if you’re fast and can dump heat quickly, so the soldering tip has to be massive and also well-tinned.

I added the cell taps and secured the top and bottom with sticky-back foam rubber, and then proceeded to Giant Kapton Tape the entire thing. I don’t have heat-shrink this large (do they even sell that stuff?) nor can I find a 55-gallon soda bottle, so GKT was the next best solution. The Giant Kapton was originally purchased as a build surface for Make-a-Bot, but it’s been more useful in this role.

I received the first batch of Small Cute Full Bridges from MyroPCB like this past Wednesday. I tried Myro out as a vendor evaluation this time – usually, my source for pretty finished boards is Advanced Circuits. Basically what I learned from this is that I should use Myro if I need a whole pile of boards for something (since their prices are lower), but if I need it OH GOD RIGHT NOW, I’m going to stick with AC. The quality of the boards seems to be on par, and Myro does offer the option of different colors without extra charge, so maybe that’s a feature to keep in mind.

Because LBS needs two controllers, I just decided to split off two boards like chocolates from the panel of 6.

And here they are assembled!

Here’s the underside. The switches are IRFS3004 low-voltage crackFETs from IR, the leading dealer of totally bitchin’ semiconductors. These things have the Rds-on of a chunk of copper. Seriously, what do you use them for in real life?

I’d have used my usual IRFS3107 parts, but because the electrical system of LBS is only going to be 20 volts anyway, there’s no point in using a 75 volt part.

The core processing power of LBS comes from a 2.007 Arduino Nano Carrier. This board was designed for students in the class to run their robots with, and features a Gravitech Arduino Nano, 3 amps of 5 volt rail for servo driving, and convenient breakout pins for digital pins for servo connectors, and a socket for an XBEE radio. It also has a breadboard section, which I’ve exploited to the max here – I needed the analog inputs and PWM-capable pins that weren’t available on the headers.

The pair of 2N7000 tinyFETs on the bottom right are signal inverters that generate a locked-antiphase PWM between the two inputs of the SCFB. I decided to pursue locked-antiphase again, like I did on Segfault, because it enables the command variable to be continuous (i.e. less software for me to think about)…and because the Arduino just doesn’t have 4 independent PWM pins. Two additional headers supply the SCFB board with 5 volts and power the ACS714 current sensors.

And last but very important, the capacitor circuit next to the 4-pin header group at the top is an interface for the rider detect switches.

As usual with boards I blitz and then send for fabrication without validation, there are Little Blue Wire (well, green wire) edits to be made. Fortunately, on this board, there was only one – I didn’t actually connect the output of the current sensors to anything. They went to a low-pass filter which was on both sides of the board, resistor on top, capacitor on bottom, to save space. Unfortunately, I neglected to actually connect the two layers.

The fix was to just join them at the signal wire using a jump. It certainly isn’t as catastrophic as when I cross a bunch of ground and common pins on the Segfault boards.

After this fix was made, my current sensors no longer “read” full negative current.

Alright, it’s mid-day on Thursday, so the electronics installation is happening NOW. In this picture, the batteries have been loaded in, the EV200A contactor (super legit and a total steal from Ebay) and distribution bus terminals have been installed. I’ve also put in the standoffs for holding boards away from the conductive surface below them.

The rider switches aren’t visible here, but they are small microswitches attached right under where the skateboard mount pivots. When I step on the board, the rubber shock mounts will deform and the switches will conduct, supplying 5 volt logic power to the RC circuit on the Nano Carrier breadboard. When I step off, the circuit discharges after about a second. I can then disable the contactor in software.

To drive the contactor and power the Nano Carrier, I was originally going to use a spare 12v DC/DC converter of the same type I used on LOLrioKart.

This would have worked if my electrical system was still 38 volts, but it isn’t. That DC/DC unit cuts out at anything below 36, which has certainly contributed to many embarassingly lame LOLrioKart demos.

Since I didn’t have a better idea, I just threw together a whole pile of 7815 type regulators. The load on the 15v rail will never be more than 1 amp anyway – unless I start piling on the gaudy lighting.

And everything has been messily mounted. What a nest…

To actually switch the contactor, I rigged up a single MOSFET low side switch. In the most convenient discovery possible, a servo header has the same pin arrangement (Signal, 5 volts, ground) as a typical TO-220 power MOSFET (Gate, Drain, Source). In a low-side switch, the source is grounded and the drain is connected to power through the load. So all I have done above is splice in the contactor coil negative terminal into the servo connector, and the FET routes power to ground when commanded.

The EV200A contactor has internal coil suppression, too, making this the easiest rig ever. This part worked great.

I threw together some quick evaluation software for the Arduino that read current sensors, tripped and latched the contactor, and took in servo signals from a radio. All of those functions were confirmed functional, so naturally I wrote some motor driving code next…

I’ll be honest: you probably saw it coming.

Oddly enough, there wasn’t total epic destruction – the traces on the board blew like fuses. The FETs, in all likelihood, are still fine. The symptoms, though, are indicative of Epic Simultaneous Cross-Conduction (shoot-through current) on both boards.

Something went terribly wrong. The 21844 gate drivers are supposed to prevent cross-conduction. To have the board fail in this manner means that they either were prevented from doing their job, like being damaged to begin with, or something was fundamentally wrong with the way the circuit was constructed.

Several factors differentiate the SCFB from my other motor controllers like Melontroller, the Segtrollers, and LOLrioKart’s controller.

• The switching frequency was set to 32khz since it was easy to do (read: found on the Internet so I didn’t have to look through the chip manual to find the registers to set and clear), but that is potentially too fast for the IR21844 and IRFS3004 combo to handle.  One test that can be formed to confirm or refute this problem is resetting the switching frequency to my usual 4khz and putting together another board identically without changes to the rest of the circuit.  However, too-fast switching would be more likely to cause increased heating and lower power delivery to the motors instead of instant destruction.
• The gate drives were receiving PWM (the software was active) before the motor drive boards received any power. They are on the opposite side of the contactor as the software, so do not receive ANY battery voltage before the contactor is engaged. The sudden application of power with the gate drives attempting to switch could have caused an indeterminate state where both switches conducted briefly. A change to resolve this problem would to be activating the motor PWM only after the contactor closes (it’s probably good practice anyway).
• Alternatively, the gate drives could have been damaged by the inrush. There was no precharge circuit for the contactor. When it closes, the application of voltage to the bus capacitors on the board is instant, and that could have overwhelmed the linear regulator on the board (which supplies gate drive voltage) briefly, or a million other things that can happen when a massive inrush current pairs with a instant step in voltage. It’s definitely good practice to put a bypass resistor on the contactor so the logic can have power (and thus have determinate states) at all times.

The result of all this? Well, I decided to just stop at this point since I had to go set up a demo table in 6 hours. These boards have promise and will definitely be revisited and the whole power system rethought.

That’s all for now. I hauled the trackboard over to the demo table anyway, since it’s visually impressive, and it perhaps got the most “What IS this thing?” questions of all presented projects.