Archive for the 'Chibi-mikuvan' Category

 

Chibi-Mikuvan: Experimenting with the Trackstar 200A and the Hysterical Current Limiter

Jul 04, 2014 in Chibi-mikuvan, Motor Controllers

As usual with something I’m working on, let me open this update by yelling at Sparkfun Electronics. Remember when I said:

I couldn’t get it to change baud rates, however, despite trying that command a few times…

This was regarding the serial LCD kit I got for the Chib-Mikuvan digital dashboard. I meant that in the sense of no matter what I tried, I couldn’t get the baud rate change command (0×81) to take effect. So what the hell? It seems like it acknowledged the command, but it wouldn’t carry through a power cycle no matter what. There was nothing on the tutorial page about why this might be the case, but there were definitely a bunch of confused commentors, a few of which were having the same issue (but no answers) The firmware link didn’t go to the firmware, but to the command page. I found, along the way, a few custom user-designed firmwares for the LCD that claimed to fix all of the ills, but I was in no mood to deal with those.

As usual with the “open source” product world, it seems like forum comments and Git repositories are an acceptable form of documentation.

Finally, after some fumbling, in a product page comment post that was three years old, I found:

Tip: ensure that you are not sending any data to the backpack for the first second after powerup. If this happens, the backpack will revert to 9600 baud as a safety measure in case you don’t know what baud rate you set it to. Note that connecting this to an Arduino’s serial port WILL send data to it when the system is powered on, as the bootloader will try to connect to a host computer if present. If you connect the backpack to another set of pins using NewSoftSerial, this won’t be an issue.

Wait, could that have been the issue? Is that why everyone, no matter what, tells me to use a software serial port, without explanation as to why? Or if there is one, it’s “Well because it might interfere with the USB communication when you’re programming the Arduino”. Why the hell is this information not front and center on the front page of the product, or at least mentioned in the “datasheet” page? How is this a remotely acceptable form of product support, making your customers rile through forum posts and internet comment threads to find relevant thread that a comprehensive datasheet or product page should have in plain view? This isn’t the first time I’ve had to deal with this kind of “let the community be your tech support” from open source hardware producers either. Anyways, stay tuned for more details as to why I had to change the baud rate on this thing. It’s been working fine after I wasted about an hour trying to make up for undocumented behaviors.

In the last post, I had mentioned that the digital dash was a critical ingredient in seeing how much current this thing actually pulled during acceleration. I wanted to understand if I could run a race entirely using “tuned finger control” or not: the vast majority of R/C type motor controllers, like the Trackstar 200A unit I decided to use, don’t have current control or even current limiting, so a little twitch of the throttle at higher throttle levels can result in huge battery current spikes, which would cause trouble with the PPPRS regulation fuse. I’m glad to say that it served its purpose well:

This video featuring test pilots Dane and Mike. Unfortunately, it showed that my predictions were true: That the motor could pull spikes of 150-200 battery amps at most speeds just by blipping the throttle. This would cause some pretty instantaneous embarrassment, even though the MIDI type fuses specified are slow-blow types.

Now, the system also happily drew 200+ (pegging my current meter) amps at low speeds too, so the motor-side current must have been incredible. I tried, near the end of the video, to “current limit” by carefully ramping in and out of throttle. This only worked to a degree – any mess-ups resulted in spikes of high current. That’s what you get when your motor is more or less a dead short.

It was clear from that night of testing that, if Chibi-Mikuvan wasn’t going to consume 50A fuses every lap, I had to do something in software or hardware to limit the battery current draw. But what?

My ideal system would let the motor current be whatever it felt like – to exact maximum acceleration at low speeds – so long as the battery side current didn’t exceed 50 amps for more than a brief period. The MIDI type fuses are actually very tolerant of overloads, as their datasheet shows – the minimum opening time for a 200% overload is 3 seconds. That, for me, means hopefully enough time to push several hundred amps out to the motor as it spooled up, before falling back to a more reasonable current limit (which it seems like is 60A or so).

Since I don’t have direct PWM percentage access, and the DHAB-S/34 current sensor pulled out of the Fusion battery only has a 250Hz (???!!!) bandwidth, and I can only update an R/C controller so fast, I can only do “average” current control – there will always be spikes and transients. This wasn’t going to be some kind of kilohertz-bandwidth torque controller, but that isn’t the idea anyway.

I spent a few on and off moments thinking about how this might be feasible, including producing quite a few whiteboard sketches that ostensibly seem to be full of science, but which I assure you are mostly made of gibberish (Engineering folks, back me up here…)

What that diagram-like abhorrence says is basically the following: Don’t limit the battery current unless it exceeds a certain minimum threshold; then, manipulate the input signal such that the current draw stays under a time-dependent limit that starts high (such as 100 or 150 amps) but decays quickly to a sustainable current like 50 or 60A.

Sounds simple enough? I was mostly in battles over how to accomplish the “manipulate the input signal” part. How should it be manipulated? The downside of not having access to the PWM % of the output directly is you don’t really ever “know” how fast the motor is spinning OR how much average voltage is being put out by the controller at any point in time. Now, I did consider rigging a sensing line to the output of the motor to capture the PWM % information, but I wanted first to see if it’s possible to do with ONLY the (non contact, not soldered or hard-connected) current sensor. Sensing the PWM % would be a direction to take if I truly wanted to shave the yak and build an intricate torque control loop around an R/C controller, which seems… excessive. Fuses, being thermal systems, don’t care that you’re carefully controlling your current at thousands of Hz.

After a while, I decided to be sensible and work on this in stages. First, I can’t make the current draw stay under anything without an algorithm that first can manage it. For this, I turned back to Ragebridge and its “Hysterical current limiter“.

I designed RageBridge on the same principles – the motor current can be whatever it wants, up a point, then that is all it’s ever getting. It was done this way as a rebellion against the recent trend in “self protecting” robot controllers which shut down if you go over their current limit. As someone who drives robots like a maniac, I couldn’t stand this at all. To me, “current limiting” meant behavior like a bench supply: Once you go over a current threshold, the voltage floats to whatever is needed to maintain that current, including shorting through your stalled motor. That’s basically what Ragebridge does, usually with a +/- 5 or so ampere accuracy. Good ’nuff for the application.

The gist of how it works is: The output command is only allowed to “ramp” up or down at a certain rate, related to the controller’s loop time (delta-t) and the amount of output units it’s allowed to deviate by each time the loop runs. At each timestep, current is sampled; if the current is over the limit, then the controller will forcibly reduce (or increase) the output command at a rate much steeper than the user-controlled ramp rate. Aside from some second-order effects such as propagation delay/leg present in the output, motor inductance, etc., the current will change on the next cycle. If it wasn’t enough (still over current), the controller will modify the output command again. And so on. The result is a current waveform that looks a bit like a sawtooth.

In that screenshot from RageBridge testing, the current sensor is reading negatively i.e. the downward slopes indicate more current being drawn. As you can see, the current increases to a certain level, then is knocked back down again, then takes several cycles to build back up to that level.

RageBridge handles this bidirectionally, and it handles both regeneration and driving current, so there was a whole ton of state machine code in that thing that I don’t hope to repeat again. In Chibi-Mikuvan, I really only care about driving current, since the way the controller performs braking doesn’t seem to “regenerate” much based on what we saw in testing. That made the code easier.

However, it was still more math that had to be done in the loop. Up until this point, I had no clue 1. how long my code took to run, or 2. if the Trackstar 200A controller could even handle high-frequency inputs. If it was limited to 50 or 100hz R/C command inputs, there was no point in trying this at all – by the time the controller got around to processing your new command, your motor is already halfway back to China. From keeping tabs on the low cost multirotor & drone world, I know that the majority of R/C controllers these days handle servo pulses via interrupt and so can run right up to 499Hz (500Hz being where a 2ms-long servo pulse signal goes continuous).

So step 1 was finding that information out.

I changed the REFRESH_INTERVAL in the Servo library for Arduino to run at 490Hz. Didn’t want to get too crazy right away, in case the Trackstar needed time to think between inputs.

Notice that the drive chain has been removed – if it somehow interpreted this as “LOL OK”, I didn’t want it taking off on me.

Success! The Trackstar took the 490Hz input without issue. I decided this was close enough to start developing the rest of the code.

The next issue was seeing how much time the code, as it stood, took to run. I wanted to increase the loop frequency to 500Hz to take advantage of the fast inputs.

Well isn’t that lovely! Something like 5% processor usage at the 100Hz it was running at. I diagnosed this by inserting a fast pin turnon/turnoff at the beginning and end of the loop. I could conceivably increase the loop to 500Hz with no problems, but I did want to see if I could optimize the code a bit to lessen the run time anyway.

The extra wide band seen above is the LCD writing code. Remember my beef with Sparkfun? That whole hour was spent trying to see if I could shrink this time by increasing the baud rate. Here was the random-dude’s-firmware-free hack I had to make to get it to, you know, work as advertised.

This is a hardware “enable” line I made with a dinky little 2n3904 transistor that prevents the LCD from getting power until I explicitly activate it in the code. That way, the Arduino can shit packets everywhere when it starts, and it doesn’t turn on the LCD until after setup() is done. Oh, and then it will artificially wait a second to make sure before issuing commands!

With this, I was finally able to change the baud rate.

…but I found out it was basically incapable of talking at 57.6K baud. So not only does it have undocumented behavior, but it doesn’t even meet its advertised speeds. Well then. I settled on 38400 baud, which was good enough.

Another speed-up-the-code thing I did was to knock off a significant figure from each of the readings. The minimum resolution of the current sensor with a 10 bit ADC is something like 0.05 amps anyway, so it wasn’t worth 2 digits of decimals to tell me. Likewise, with such imprecision in the V and A readings, there was no use having 2 digits on the watts reading either.

In the end, all this effort only took the write time down 500us. It’s certainly not nearly ratiometric between 9600 and 38400 baud, so I suspect the overhead of Serial.print and Serial.write might be more at play here. Nevertheless, there’s still 1000us left to do other stuff, including a few lines of subtraction for the current control code, so I left it.

After inserting Ragebridge genes into Chibi-mikuvan’s code and seeing it seemingly, allegedly working without the chain drive hooked up, it was time for SCIENCE

This. This is actually the most terrifying thing I have ever built. Worse than LOLrioKart, Segfault, or Deathcopter. This is Sciencekart.

Well, okay, I didn’t have a DSO Nano or one of those fancy cordless oscilloscopes, but I did have a 12v lithium module, an inverter, and lots of gorilla tape.

I scoped a bunch of things while driving around the empty hallways staring intently at the oscilloscope screen, with one hand on the throttle and the other perched over the RUN/STOP button. If they say texting while driving is bad, they clearly have never tried oscilloscoping while driving.

The signals I looked at were the R/C pulsewidth output in microseconds and the raw reading from the current sensor. I basically just gunned it from a stop for a bit, let go, then gunned it again, and so on. Square waving the throttle is the biggest rookie mistake for people not used to driving R/C throttles, and this basically eliminates that problem. It doesn’t account for “startup jump” since the controller’s starting routines are often dead-reckoned, but that’s where I come in.

I’m glad to say that it works! Clearly, not with decimal amps accuracy… perhaps now I don’t even need the time decay curve – the error of the controller alone is enough -_-

This is the sawtooth waveform the Hysterical Current Limiter generates. This was captured at around 25% top speed after I punched the throttle to 100%. The current sensor’s zero point is at +5 divisons (0.5V) on the vertical scale; I’ve moved the zero voltage line waaaaaay down to capture the peaks of the waveform more effectively. At 10mv/A sensitivity, the max current, as can be seen, is actually peaking at 100a. It’s interesting to see that the minimum current in this case was more or less 50A, the programmed limit!

My guess as to why? I think this is in part because the motor is so low inductance that the current changes much faster than the controller can keep up, and there is little back-EMF from the motor to help at low speeds. The controller only gets a little time below the current limit as a result: any increase in the command results in a ton more current flowing again. I will need to find a somewhat emptier hallway to capture higher speed waveforms, but based on eyeballing, the spikes decreased as speed increased.

I’ll continue experimenting to see how to reduce the error, but right now, it works great as-is (if not a little anemic now because it can no longer pound 150 amps). If the error is large, then I won’t really be able to utilize the ‘time decay’ method as well, but it could be fine just setting the current limit to “60A, pretty-pleeeease” and keeping it there.

Here’s a test of me driving straight towards a wall:

This was one of the early tests in which I set the current to only 40A to make sure the concept even had a chance of working. From still frames, I could see numbers like 40.6, 45.0, 32.5, and the random spike to 79.6 at the very beginning when the startup loop exits. During the cruise portion, the amps ranged from 29 to 48 or so. Promising start for now!  Tuning can occur from here as I drive around more with sciencekart!

Expect some more testing video this weekend possibly with the oscilloscope still attached.

Chibi-Mikuvan The Extended Universe Edition: Water Cooling Loop and Digital Dash

Jun 21, 2014 in Chibi-mikuvan

It must be awkward observing your own viscera from the perspective of your own husk.

Now that the summer season here in the shop has settled down and people are well on their way to wrecking my laser cutter, I’m advancing on the checkoff list before the Detroit Maker Faire and its associated PPPRS race. I’m like, signed up noncommittally and everything. Through a web form. That’s some serious confidence right there.

water cooling

Last time, I mentioned the water cooling circuit and electronic dashboard. Recall that the motor I ended up investigating and deciding on is a water-cooled boat motor, and I’ve been running it without any water cooling. This has been somewhat tolerable – it is actually quite efficient, and even during the hard garage runs, I was able to do 2 or 3 back to back and not feel that the motor was nearing burnout temperature. However, all of this is was done in mild weather, at night. I’m sure that if the daytime temperatures were much higher, it would be a greater risk to run the motor that hard. Bottom line is, why buy a water cooled motor and not water-cool it!? I could have sprung for its longer air-cooled cousin if I didn’t want to mess with that.

The water cooling circuit I had imagined was going to be quite simple. This wasn’t going to have to dispose of a kilowatt or more. I ran some rough numbers and expected that at 100 amps continuous (all day, which will never happen), the motor is going to only dissipate about 150 watts. A modern workstation PC’s graphics card along can shit more than that at any point in time. The plan was to base this system off a computer liquid cooling rig. I scouted eBay for used water cooling kits for a little while before Mike handed me a Powermac G5 pump and radiator, first revealed a few posts back.

So that was taken care of! The only missing from this kit was a reservoir. Now, I could have been crafty and just made a whole closed loop using the pump and radiator alone, but a reservoir would be helpful for topping off the system and allowing expansion space (I have zero cred here – real-Mikuvan’s coolant expansion tank is the hose looped back onto itself and pointed away from the battery so any spurting pressurized coolant goes straight down…)

So that’s how I went to the grocery store, bought a jar of pickled olives, and ate the whole thing. That was a very uneasy evening.

I made some “panel mount” barb fittings for 6mm ID Tygon tubing and attached them to the can lid using my favorite adhesive/sealant, Goop. It’s rubberized, so it’ll be both watertight and somewhat flexible. The other end of these fittings end in a non-barbed tube that I extend down into the jar as a pickup and……dropoff? tube.

It took a while to come up with a component placement, since the only left over space was immediately behind the seat and in front of the electronics case, which is not a very good airflow spot. So I did what I could for the location. The big board it all sits on is 6mm hardboard. I purchased several (dozen) sheets from a local wood products distributor as prototyping material for 2.00gokart and the shop in general, so plenty was left over. I’m just going to use this hardboard as-is. It’s not very afraid of water (unlike MDF), and is quite rigid.

The jar mounting bracket was produced on an Up Mini, one of the handful of hobby-class 3d printers accessible by students in my shop. I designed it while shuffling component placement in my head – I knew this bracket would be needed, just didn’t know exactly where yet.

Installing the tubing was quite straightfoward. Near the motor, the 6mm tubing steps down via a custom 3d printed adapter to 4mm tubing to attach to the motor. Hello, flow restriction. Designing these adapters was a fun excursion into the world of fluid systems design. They were made using the lab Objet (high resolution resin printing) machine.

McMaster wanted to charge me $7 each for these damn things, so I figured having a $33000 state of the art rapid prototyping machine knock one out …uhh, I guess I really have no case here. I think these fittings will still work if made with a hobby FDM printer, but there would likely be sealant involved to fill the filament low spots.

Testing on a power supply, I found out that the pump wanted 0.4 amps at 12 volts by itself. Yikes – the little hacked 5V BEC units I was using to produce 12V (I have hogsheads of these) can realistically only sustain about 1 amp when jacked to their new output voltage. I was already needing 1 amp for the contactor.

Solution: Just whip up another one in like 5 minutes. AUX runs the pump, LOGIC is dedicated to the Arduino, contactor, and sensors. I have 0.5 amps left to add gaudy lighting.

Here’s the completed water cooling loop! After a little leaking, all the O-rings seem to have found their seats and I haven’t noticed any more drops on the ground.

I ran this thing around the shop “track” (meaning the conveniently rectangular closed loop building at night when everyone’s gone) for half an hour, doing 55 lap or so (I may have lost count). I ran the battery straight down, and the motor could best be described as “lukewarm”. Maybe warm water for hand and face washing temperature. This was with no additional airflow to the radiator besides what leaked behind the seat through that cutout in the mounting plate. Without power data to back it up, I can’t really draw firm scientific conclusions, but yes.

As the weather gets hotter here, I’ll most likely set up the 2.00gokart test track one weekend and just try and keep running as long as possible. I think the addition of this system will help the reliability greatly.

the digital dash of science

One thing that has been bugging me about Chibi-Mikuvan is indeed the utter lack of science on it. Because of my use of the 150A Anderson connectors, I don’t have any instrumentation that can jack in the middle between the battery and motor controller. I mean, besides making yet another why-did-you-even-bother-adapter.

I conceived the idea of rolling my own wattmeter, or perhaps Anal Cyclist Cycle Analyst, after finding the datasheet for the current sensors that are integrated inside the Ford Fusion hybrid battery, the LEM DHAB S/34 series. It was easy enough to read, as an isolated Hall Effect loop sensor, and I could put it any where. It’s also easy to rig a voltage divider to sense the battery voltage. With those two pieces of information, I was basically satisfied (I could go totally insane and add way too many features and datalogging to boot, but…)

First off, removing the ridiculous connector shell on the current sensor and attaching a pigtail of wire to it. Protip: The cheapest source of 4 conductor shielded high quality cable is old USB cables. Almost all of the signal cabling on this thing is made of hacked up computer cables!  8 conductors? Ethernet. 9 conductors? DB-9… nobody uses those any more. USB has 4 conductors and an outer shield that could be another.

Next, I swung by Microcenter and got a Sparkfun serial LCD kit. Imagine my surprise when I found out it was not one of their integrated one-board sLCDs, but a cleverly packaged Arduino. Well hell, I could have made that with the onboard Arduino. Oh well.  I was looking for a sLCD in particular because I wanted the simpler interface, and not actually having to resort to using all 8 pins of an Ethernet cable to run the otherwise parallel signals.

I designed this mounting bracket in about half an hour, to be slowly worked on by the Up Mini, while I wrote LCD code. For some reason, I’ve been all about those flexural snap fits lately.

Here it is being produced. I’m basically an Up salesman, so I’ll take this opportunity again to plug these machines. They just work. Extremely well – they’re still the only machines I’ve dealt with which produce truly breakaway support lattices. Even an old Dimension BST machine.

I have a personal Up Plus, and the shop has an Up Mini.

Getting this LCD up and running was quite easy. I basically followed the Sparkfun datasheet and instructions. I couldn’t get it to change baud rates, however, despite trying that command a few times. So for now, it’ll just talk slowly. (I typically run my Arduino-related serial things at 57.6Kbaud).

I used the remainder of the USB cord to run the LCD from the handlebars to the electronics box. This wiring job is almost approaching unserviceable – I’m strongly considering a full refactor into something more accessible and serviceable prior to the Detroit Maker Faire, now that I know what connections need to be made and what could be done better. For instance, I have a few 12V, 10A DC/DC converter modules that could replace the two smaller hacked ones and run all the gaudy lighting I want. 

On the breadboard are some of the signal interface circuitry for the current sensors and voltage sense. Just simple R’s and C’s, they form low pass filter networks to help smooth the sensor readings. I’m not sampling thousands of times a second here…

With two cables now snaking up to the handlebars, I used some left over wire-twizzlers (proper name: spiral wire or cable loom) to constrain them. It looks almost professional!

Here’s the end result!

I spent way too much time in the code measuring the length of the digits to keep them at the correct offsets such that the units’ letters (V, A, W) didn’t move. The digits have enough space in front to add a negative sign for regenerative braking. Volts have 2 digits, Amps has 3, and Watts has 4. The LCD refreshes 5 times a second, which makes it a bit flickery, but I still can catch glimpses of the levels that the measured physical variables hit.

I’d say this setup is definitely more dashboard than instrumentation. Instrumentation would imply I investigated and know the level of precision attainable with the parts and the potential error and uncertainty in each one of those indicated measurements. Which, no. This was calibrated with a Harbor Freight voltmeter. There is literally nothing between it and just flat out guessing.

Here is the current version of the Chibi-Mikuvan running code. I’m posting it primarily because of the LCD interface code – the rest of it is a big fancy servo tester knob (I have fathoms of those).

I’ve been thinking of a potential next step with this code, now that I have the ability to read the battery current directly. The idea is to use something similar to RageBridge’s current limiting scheme in order to follow the time-current curve of the PRS series fuse. The fuses specified, MIDI style fuses from Littelfuse, are slow-blow ones which give you a moment of surge current capability, so I’m thinking about a way to try and push that envelope with current limiting – no matter how hard you punch the throttle, it will stay (ideally, just barely) within the transient limit of the fuse.

Something I have to think about now, though, is how to make a “Chibi-Mikuvan adapter” to hitch it to real-Mikuvan, though if we have enough go-karts coming from here, it’s easier to just borrow or rent a trailer.

Chibi-Mikuvan: More Stickers is More Power, Right?

Jun 04, 2014 in Chibi-mikuvan

VAN SWITCH!

The semesterly action has died down to the extent that I no longer know what to do with myself. This is the gap of three-odd weeks between the end of the spring semester and the beginning of the summer action. As usual, the IDC is hosting mobs of Singaporean students as well as MIT students involved in The Collaboration. Like last year, I’m about to indoctrinate a fair percentage of their current freshman class with the Church of Chibikart. The specific implementations of this summer’s Silly Go-Kart Church Camp will be discussed soon. There are omniwheels.

During this break, I am of course going to be working my various problem children who need my attention. Most of this will involve facilities upgrades and improvements of the current robot or silly go-kart fleet.

  • Changing Überclocker over to easily-swappable Banebots wheels – I talked about this near the end of the Motorama event report. The 40A durometer “McMasterbots” wheels are very great for traction, but they wear out quickly and I have to individually machine each wheel to fit my hubs. Hypothetically, once switched to fast-swap hex hubs, I can replace an entire wheel set in 5 minutes flat.
  • Finishing Chibi-Mikuvan’s liquid cooling loop and creating the telemetry system / electronic dashboard.
  • Maybe even working on repairing the 1lb and 3lb bots (yes, including Colsonbot) for the Bot Blast event this coming July!
  • Maybe maybe some more real-van bodywork.

Truth be told, I’ve actually been spending most of the past week, and likely much of the coming weeks, designing something which I think is gonna be pretty damn interesting. This is a far out enough concept that I want to flesh it out concretely before taking it public, so you’ll have to deal with this artificial cliffhanger for a bit longer.

In between, Chibi-Mikuvan has been accruing more stickers. It is a well known principle in auto racing that stickers make you faster!

Well, perhaps a different type of sticker. They most likely didn’t mean….

Miku stickers!

It’s amazing the huge range of quality you are presented with when you search for “miku sticker”. I gradually homed in on one sticker/decal house with an eBay store, based in Malaysia, that had the highest count and variety of Miku stickers. The characteristic I was seeking the most, though, was huge. Loads of stores had the tiny notebook sticker or cell phone decal, but only this place had them in 33″ tall, and in high quality with the transfer layer.

Granted, the shell isn’t that tall, so some parts of Miku will necessarily be lost. I decided this was fine, though, as most itasha decor seems to focus on making the most recognizable parts of the character as large as possible (I need LED rims). I think for this version I’ll spare the fully custom paint job – it’ll be stickers on white to start with.

What followed was days of arduous experimental Miku-placement, researching and answering the toughest of unresolved issues in this field such as “Is it tacky to have more than one Miku per side?” (The above example would indicate no, it isn’t).

Dry erase marker and masking tape was the layout method of choice. I scribbled roughly where body lines were going to go in order to come upon a satisfactory placement.

This one, at least, was fairly obvious. It was of the exact correct height and aspect ratio to take a ride in the rear window impression.

And on the left side.

I was conflicted on whether to use only the two largest ones, or also include the others. The two in question are of the same art style and by the same artist (KEI), giving a more cohesive look, but of course had poor coverage. The two art styles shown here definitely clash a little.

After placement was finalized, I rough-trimmed the stickers to shape, applied them, then very carefully precision-trimmed the bottoms with a craft knife. In all, the results were quite good.

I actually ordered another pack of stickers – this time, with more logos and banners (the single lone Hatsune Miku logo wasn’t enough!). They should arrive soon.

The right side, for now, will lay a little more bare. Maybe all the new ones will go on this side!

I moved onto the issue of car number. The two numbers traditionally associated with Miku – “01″ and “39″, are both taken already! Sadness. Well, I’m certainly not going to try and claim the 01 number from the team until I beat them.

So at least for now, let’s roll with “3939″.

The door decals were printed on sticker vinyl by my good buddy Ted, who knows graphic things and stuff and whatever. I tried printing them, but my poor CMYK only printer can’t handle the BRIGHT NEON MAN-GENTA coloration of Miku’s graphic logo (the 初音ミク bit) – it kept coming out orange-red. Apparently, professional printers just have a BRIGHT NEON MAN-GENTA color channel. The lettering itself was made using Inkscape.

I carefully knifed the number out by hand (and ruler) – no cut templates were made. I supposed I could have fed this into the vinyl cutter if I had planned this better. In ambient room lighting, it looks tacky because the background stands out, but in bright outdoor light, it’s not as noticeable.

replacing the Trackstar

Little known fact: For one reason or another, after the previous garaging video, the Trackstar 200A controller died. It didn’t die in flames – rather, one phase simply stopped driving. So in fact I could ‘skateboard’ Chibi-Mikuvan up to 5-6mph, hop in, and it would actually still keep on driving. However, with a dead phase, it couldn’t start or run at low speeds. Inertia! It works!

Having one of the student teams this past spring suffer a Trackstar failure in almost exactly the same fashion, I began to suspect that the up and down jostling and high frequency impacts of being used in a vehicle was causing the signal board to come loose inside. As documented in One Thousand and One Hobbyking Amps, the signal board on these things is held on by 1 small header, and allegedly retained by rubber foam tape. However, when I pulled that unit apart, the board came off really easily, with not much compression of the foam tape visible.

It’s my hunch that impacts shake the signal board header loose just enough to cause one bank of FETs to possibly become disconnected from the driver chips, and since the power board doesn’t appear to have any gate protection hardware (pulldown resistors and Zener diodes), that phase probably died instantly from cross-conduction or dV/dt damage to the gates.

I decided that the power board was not worth saving for a few reasons. First, it’s a massively heavy (6 ounce or heavier) board with copper conductor bars soldered to it – rework would have been borderline impossible. Second, it’s potted for waterproofing, as far as I can tell. The FETs are sandwiched right next to the conductor bars.

Hence, I gave in and just ordered a replacement. Damn you, Hobbyking!

This time, the first thing I did was to crack it open. Shown on the right is the number of tools I needed to use to do this. I have no clue what the hell these screws are supposed to be, but some prefer a 2mm hex, some a T9 (!?) Torx, and two of them Phillips.

Next, I took out my favorite contact cement & robot wheel retread compound & waterproofing coating & what have you. E6000, and its related adhesive Goop, are some of my favorite adhesives. In this case, I’m using it far more as a structural filler. I put 3 big globs of it on the near two corners and far edge of the board.

I’m basically resigning this controller to be never repaired, but that’s fine.

After replacing the controller, I joined in another MITERS silly vehicle proving session in the garage. This time, I couldn’t get the dashcam to stick to the helmet any more, so had to rely exclusively on random people filming, which always ends so well. The art and science of holding a camera steady is one that is only developed through a habit of documentation – most people can’t do it. This is all the useful video I was able to get that wasn’t jittery, out of focus, or cut too short.

That sound at 0:16 which is oddly reminiscent of a gear falling out of a gearbox is…. yeah. Under heavy motor braking, once again the pinion got yanked off its taper by the action of the helical bevel gear. It proceeded to screw itself back in once I hit the throttle really hard. I need to remake that entire input shaft at this point, since it’s doubtlessly been gouged up and damaged by the slipping gear. I’m also going to reduce the maximum motor braking force back down to 25% – I left it at 50% for this test – for actual racing, since it seems to be a point of reliability trouble.

This run, I beat my previous time (57 seconds) by 2 seconds since I carried more speed through the end turns. I’ve figured out how to get this thing to not understeer near top speed – the answer is lean all the way forward. I believe this puts me within 2 seconds of the all-time garage record by Tinykart.

Left to do on Chibi-Mikuvan is making the water cooling circuit, for which I have all the parts for already. The next thing to do after that is to make spare everythings: battery packs and entire motor-gearbox assemblies are first. This way, if I have a motor or gearbox failure in battle during the race, it’s easy to swap and get going again. Eventually, I want to set up the 2.00gokart course again and run one full simulated race scenario – as many laps as possible on one battery, a battery change, and a tire change.

I’ve signed up for the Detroit Maker Faire race, which is a feasible one to get to, so shit will get real soon!

The Turbulent Rise of Chibi-Mikuvan

May 02, 2014 in Chibi-mikuvan

After much engineering ado, it’s time for tiny van shenanigans!

This test was the first done with the NiMh modules from the Ford Fusion battery whose construction was detailed previously. I’d say subjectively the pickup is as strong or even stronger because of the added traction of doing it outdoors, coupled with the much larger wires (no more 12 gauge and Deans connector bottleneck) of the LiPo test pack. However, since I don’t have (yet) a Wattmeter-to-150A-Anderson-Powerpole adapter, I haven’t metered it proper. I do know that indoors, I’m traction limited at 3600 watts (as in no matter how hard I gun it, the rear wheels will just slip, leaving a thick trail of itself on the waxed linoleum hallway floor and making the reesarch center administration murderous).

One of the potential plans is to get a Cycle Analyst digital dashboard system or similar. Or, since I already have processing power in the back, and the salvaged current sensors from the Fusion pack, to just make my own.

The terrible sound at 0:47 was the pinion of the angle grinder gearbox slipping its taper seat, unscrewing itself, and then falling off. It continued to jiggle and tumble in the gearbox as I pushed everything back upstairs. It’s now repaired – I didn’t torque the locking screw properly the first time because it’s in a hard-to-access spot where a regular hex wrench couldn’t get to.  After this experience, I cut down a standard L-shaped hex wrench until the short leg did fit.

To complete this round of build details, here’s the last bit work on the battery pack before the outdoor test.

After adding the tie rods to hold the endcaps together, I decided that an intelligent thing to do would be to make an easy way to lift the battery with one hand. I used the left over black 1″ wide cargo strapping which was part of the ratchet strap holding the electronics deck down, along with some rivets and washers, to make a handle. This worked out great, and I have enough of the strap to make 2 more batteries at least.

This is how the battery mounts in the frame, with the two knobs on the sides. Since this is a less than half sized battery from the original design, and the two knobs up front are directly opposite one another on the same axis, the pack can pivot forward and backward right now if the knobs aren’t super tight. Clearly not optimal. I’ll probably just resolve this by adding two bars to the front and rear of the battery pack, such that once dropped into place, they can no longer pivot.

Once I confirm that design, I have enough modules from the Fusion battery to make three more spare packs. The knobs allow the battery to be dropped out quickly, so having a ton of spares on charge during a PRS race makes sense.

And a “press shot” outside in the parking lot.

What’s missing at this point is the water cooling system for the Trackstar motor.  After the numerous high-power takeoffs during the test, the motor was hot but not unhappy hot – I could still hold onto it. But, it’s clear to me that if I want to run above 1000 watts for a long time, it’s going to need the water cooling loop. This will come after the 2.00gokart race when things quiet down a little bit.

It also doesn’t have the wye-delta switching contactor assembly I wanted to incorporate, but I’m of the opinion that the speeds attainable by the Delta termination is utterly unnecessary for an event like PRS. The project top speed under this condition is north of 40mph, which is a domain already well optimized by, like, real Mikuvan.

Here’s the final details…

Cheat Sheet

Motivation

I started this project as a museful distraction in October of last year after returning from the New York Maker Faire and mingling with the Power Racing Series folks for the third year. Having seen the league grow immensely, I decided to finally enter something while exploring new and unusual components for hobby builders (my usual MO) while also wanting to see a change away from the “model year bloat” I saw in many teams, who started using heavy forklift motors and other salvaged industrial components. Hence, the focus on R/C electronics and non-lead chemistry batteries.

Work on the project began more in earnest with this season of “2.00gokart“, since I figured I needed to have an instructor vehicle to troll my own students with.

The project was my first jump into making a composite bodied anything, motivated in part by the bodywork repair I’ve had to perform to real-Mikuvan.

Build History

In chronological order up to the previous post, here’s the process of Chibi-Mikuvan creation from conception to implementation:

Naming

The project is named Chibi-Mikuvan after its principal design predecessor, the Chibikart twins which were the “prototypes” for the design class I teach today, and my 1989 Mitsubishi Delica known familiarly as Mikuvan.

It has little to do with Chibi-Miku-san though a few large decorative decals would not look out of place on the shell. I’m an avid follower of the crowdsourced synthetic Japanese future girl-pop that you’ve never heard of world of Hatsune Miku and Vocaloid. That’s literally the most concise way to fully describe it, as I have learned over many difficult discussions about what the inglorious shit is it that’s playing all the time in my shop.

Components

Specification

  • Top Speed: 25mph (as-geared, Y-termination)
  • Acceleration: to 25mph in < 3 seconds
  • Braking distance: < 30ft from top speed
  • Skidpad: Uhhh, gimme a sec.
  • Clearance: Still not enough for the Maker Faire cable protectors
  • Drivetrain: RR layout, 1 speed, spool axle (no differential)
  • Dimensions: 50″ L, 28″ W, 24″ H
  • Weight: 113lb with battery
  • Seats: 1, though if Chibikart was any indication to go by, up to 7.

Bill of Materials

Here’s the latest iteration of the BOM (5/1/2014 version), which contains at least 95% of everything on the thing, short of the trivial like zip ties. I went into much more detail than the average PRS list; the quality is a little more closer to what I expect out of my students when it comes to found parts and used parts. Everything, to the degree possible, is given a Fair Market Value which sort of artificially inflates the cost a little. While technically over the PRS $500 statutory budget, I believe this is a more realistic representation of the cost needed to replicate this once.

The BOM has 3 cost categories. First is the actual money I spent. I had a fair amount of parts already on hand, but did have to buy things full-price like the Ford Fusion battery pack and the motor & controller. Next is the PRS rules based accounting, exempting some things like brake parts. Finally, what this vehicle would cost under my 2.007 EV Design class rules, where some raw materials are provided to the students so they only need to count materials if they need to be purchased additionally.

Future Work

I plan to finish building the water cooling rig in the coming weeks, as well as play with the nice automotive-grade Hall Effect current sensor salvaged from the Fusion pack. For the telemetry/dashboard, all I’m really interested in is instanteous volts, amps, watts, and cumulative watt-hours spent, and all of that info can be gleaned from a voltage sense (easy) and current sense (also easy with the sensor). I do need to build more battery packs, and create or buy a dedicated Giant NiMH Battery charging solution. I have a Hyperion 1420i charger that can blitz into this pack well, but having more chargers would be essential in a race scenario.

Also, make more silly magnetic stick-on anime faces.

And as usual, some fun times in our proving grounds, the spirally garage:

Chibi-Mikuvan Intensifies: Mechanical and Electrical Updates

Apr 30, 2014 in Chibi-mikuvan

As the 2.007 Silly Gokart Race draws closer (by which I mean it’s this weekend), so does the completion of Chibi-Mikuvan. Since last week’s outer shell work, I’ve brought the frame to mechanical and electrical completion, and have tested it under power. Technically it’s now “internet-complete”, which is a term I defined to mean that a project is finished enough that the Internet wouldn’t know the difference. It’s like “internet famous”. Here’s the somewhat chronological recap, as usual – a few things didn’t happen in a purely consecutive fashion but it’s much easier presented that way.

While the layers of resins and paints and the like were slowly crosslinking, I returned to working on the drivetrain. I last left it in a state where the frame could roll around, but the motor wasn’t mounted to the angle grinder gearbox yet, nor did I make the adapter shaft for it. I had planned for the angle grinder gearbox shaft to be keyed and for the pinion gear itself to be broached, but that would have necessitated buying a 10mm bore bushing for a 1/8″ (or 3mm) keyway, which was also nonstandard. What? Hell, if I haven’t remembered to make or buy the bushing by now, it’s clearly never happening.

That same day when I pulled up the design files, I decided to abandon the keyed shaft and return to something I last did in 2005 with my old 12lber Trial Bot: a tapered shaft and matching tapered bore. Tapers can transmit power with full material contact instead of relying on several small, discrete fastening elements like a key or set screws. They can be the strongest coupling method per volume because of the full contact and least concentration of stress.

The idea would be to machine a certain taper into the gear, machine the same but slightly shorter taper into the shaft, and then mash it together with a fastening screw. I chose a taper angle that would be self-locking to prevent the screw from having to hold rotational torque – this implied a taper of less than 10 included degrees. The design constraint here was that it had to start at 10mm diameter, end at 12mm diameter, and do so in the space of 17mm, the size of the gear.

Well that turns out to be 6.75 degrees, so I just rolled with it.

Shown above is technically the finished product – the gear on a tapered bit cut into a 12mm piece of precision-ground shafting steel. On the other end is an 8mm reamed hole to fit the motor shaft. I then took this scrupulously machined shaft and repeatedly hacked it up with a Dremel to make the clamping slit…. precision!!!!

To make the taper, I decided to exercise Tinylathe. I set the compound to as close as 3.4 degrees (roughly half of 6.75 degrees) as I could, and busted out one of my old miniature carbide boring bars for the job. The pinion steel was tough, but clearly not hardened, so this step ended up being much easier than anticipated.

The angle grinder gearbox made axial alignment of the pinion easy, since by default it’s just rested against the bearing. Spiral bevel gears are supposed to be very high precision devices, but I’m not so sure about these.

After assembling and closing everything up, here’s what the gear drive looks like. The sprocket has a big notch milled into it to interface with the spindle wrench flats of the angle grinder gearbox. The big nut is just to keep it in place axially, and it will be replaced by a smaller, more mild-mannered nut.

The coupling to the motor is done by tightening a 12mm shaft collar over the split section of the adapter shaft. This is a method I’ve used many times when one shaft is larger than the other, and is very simple to implement – drill an axial hole, then slice with a Dremel (or more legitimately, a slitting saw)

With the drivetrain basically done, I began plotting what to do about the electrical system. I was going to just lay out the contactor deck salvaged from the Ford Fusion battery on a piece of plywood or hardboard and lay the other components next to it for starters. I decided, though, that the three contactors on that assembly were just totally overkill for the end goal – I have no reason to need a precharge contactor AND discrete battery positive AND ground isolating (battery negative) contactors. Really all I need is a single positive side contactor with the precharge system built in on it.

Once the stock contactor deck was out, I began getting creative with the packaging. It occurred to me that I had several 7.62 NATO ammo cans which fit very well in the rear box frame. This was a complete accident, but a satisfying one. The ammo can could fit all the components and keep them water and splash resistant, since every year at the New York Maker Faire, it somehow rains. I took a while to arrange the components in a manner which made sense.

I decided to pursue a vertical solution with two levels, keeping the big power on the bottom and the signal interfacing on top for easier access. This is, of course, all predicated on the reliability of the power components, the Hobbyking motor controller in particular. In the design above, though, it’s still not too hard to get out if needed.

I left a large gap on the right side, by the ammo can’s hinge, so I can put the Hella master cutoff switch in the area (it sticks down pretty far) and a fuse block on the outside to make the mandatory fuse easily accessible.

The white component in the design is an “isolated ground stud”. I elected to use this method instead of a large terminal or bus block because of the limited number of ground connections I needed – basically one big wire in, and one big wire out. I remembered using these in FIRST Robotics before the power distribution became all fancy and modular.

The ground stud itself is a custom 3d printed job using a Makerbot, with a broken Hella switch’s terminal inserted through the bottom as the stud.

The first step in processing the ammo case was to remove the handle to make way for the switch and fuse block. I drilled the spot welds out to remove the handle anchors. The cutouts for the Hella switch and fuse block were made with a Dremel cutting wheel.

The Hella switch is now installed along with the mini-ANL (or MIDI, depending on who you buy it from) fuse block. I designed some wire guide/grommet/panel mount things which are installed into their own cutouts on the sides. These were designed with three tiny holes which I could drill out to fit different wire and cable sizes. They’re split into two pieces so they can install over a wire I thread in first, instead of having to deal with pre-installation, which makes the whole system more flexible in case I change something. Remember, this was practically designed on the fly.

Laser cut MDF lower deck with power components installed.

I prepared some auxiliary components, including the 12V rail supply and the precharge resistor. The 12V supply is a chopped up 5V R/C BEC unit like eNanoHerpyBike’s – I have a pile of dozens of these things, so it’s easy to grab one and go. The primary 12V consumer will be the roughly 0.9 amps needed to supply the contactor coils, and a very small amount otherwise running logic and fans.

Installing the first deck now. In this design, I chose to have the DC/DC unit pull power from ahead of the precharge resistor. What this implies is that the 12V and logic systems are powered on as soon as the Hella switch is turned on, ensuring that the logic is in a deterministic state before the ESC wakes up – the precharge resistor causes a delay in its turn-on since the voltage fed to the ESC rises slowly. Subsequently, if the contactor is opened for any reason, the power to the  ESC is soft-killed while the logic power remains on.

The second deck contains a 2.007 Arduino breakout board and a terminal strip to make outside-world connections with. The 2.007 board is currently only being used for its Arduino Nano, though the breadboard opens the possibility of adding some more custom signal processing circuitry, if needed.

I cut out a MDF plate that closes of the bottom of the box in the rear portion of the frame. It has two slots to allow the use of a small ratchet strap to hold the entire thing down. Perfect fit!

Here’s a profile view of the go-kart side of things. Overall, the setup is fairly clean and all of the powertrain is confined to the rear.

And yeah, that chain needed tensioning. I ended up using a half-link (example) to shorten the chain just enough that the slotted mount of the rear bearing blocks were enough to take up the rest.

In this configuration, with a makeshift 7S lithium polymer battery jacked into the massive 150A Anderson powerpole connector, I rode it around to test the Trackstar controller‘s startup response. As with all sensorless R/C starts, it was jolty, but the controller is smart enough to slow down the open-loop forced commutation frequency if it detects a no-start (cogging or “pole slip”) condition, then try and ramp up from there. It’s clearly designed for ground applications.

With the very high gear ratio present in the system, it’s able to take off basically within half a second of applying throttle each time. If the motor lands in an unlucky spot, it does cog, but recovers quickly.

I do want to use the liquid cooling feature of the Aquastar motor, so I had to sequester a water pump and radiator from somewhere. Luckily, a MITERS member had a spare cooling rig from an old PowerMac G5. I would just need interconnecting tubing and a little jar as a reservoir.

Power Mac G5 liquid cooling pump pinout

It took me a great deal of Internet wandering and the sacrificing of one of the pumps to find out the pinout of this connector. So if you don’t get this information anywhere else, here is the pinout of the Power Mac G5 liquid cooling pumps, the kind with the 6-pin connector. Did I mention that this is the pinout of the Power Mac G5 liquid cooling pump with the 6 pin connector? By the way, this is the pinout of the Power Mac G5 liquid cooling pump with the 6 pin connector. I even added image descriptions to the image itself saying that. Google is about to delist me for black-hat SEO, I’m sure.

To turn the pump on, ON must be connected to the 12v rail. It’s a very quiet centrifugal type pump.

I put aside the pumps for the time being to finish the last bit of visual detailing for the outer shell. I’m not going to be fancy and add working tail lights (yet), so for the time being they’re patches of orange and red paint. I basically reused the “inverse stencil” method again, covering the area in masking tape and knifing away what was not needed using the drawn lines as a guide.

Here’s the taillight painted details with the first bumper sticker! Okay, Beantown, you win. Beantown Taqueria is the nemesis in my ongoing fight against obesity and heart disease, but a very delicious nemesis.

Moving back to the powertrain now, here is a set of shortened battery pack endcaps I machined. But wait! Wasn’t the battery going to occupy the entire floor area?

It was also going to weigh about 60+ pounds. I test rode the chassis while holding a 55 pound Class-D fire extinguisher, because I love being ironic and also because it was the most compact object to weigh that much. This was such that I could simulate the battery’s weight. Conclusion: The sensorless starting routine is getting really borderline.  Adding 60 pounds to the combined weight of me plus vehicle (about 70lb of vehicle and 150lb of me) is a 27% weight increase, and the gear ratio is no longer enough to guarantee starts!

Alright, so 1.0kWh of battery was going to be ridiculous. I decided to cut the battery to a third of its original size. In a PRS race scenario, I’ll have to run for at most 15 minutes between required pit-ins and driver change (in the endurance race format), so as long as the battery is quickly swappable, it should work fine. The new battery, 28.8v and 16Ah, will weigh only about 22 pounds.

Hence, I redesigned the battery caps to only hold 6 of the Ford Fusion modules, and mount by only two of the four mounting holes.

To make this battery, I started taking slices off the cake and rearranging the cells inside the module. Some of them needed to be flipped around in their casings, so the positive and negative terminals could face the correct way. I discovered that the rubber isolators that they put around the cells are designed to only fit in one way, so the casings could no longer close if I just flipped the cells. Those had to come off – they’re the rings to the right.

I reused the bus bars that came with the battery pack to make the interconnects. There are two modules in parallel per “cell group”, and 3 groups in series, to make 28.8V and 16Ah.

Here they are, stuffed into the endcaps as a test fit. There are some touches I have to add, such as, you know, output wires.

So this is the progress of Chibi-Mikuvan up until last night. I’m intending to have it running, maybe not liquid cooled, by Saturday’s 2.007 EV race. I also have half a mind to drive across the country to Bay Area Maker Faire (not driving it, mind you…) and enter in the first PRS race of the year.