The Eucatastrophic Revival of the Land-Bear-Shark

chorl2 Comments

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.

 

The Triple Weekend Update Part III: Playing With Inexpensive Chinese Ducted Fans

chorl2 Comments

introduction

I already am publicly known to have an unhealthy obsession with Inexpensive Chinese Brushless Motors (ICBMs). But did you know that I’ve also recently grown an addiction for Inexpensive Chinese Ducted Fans? There’s no smart acronym for “ICDF”….except for maybe the Iraqi Coastal Defense Force or something.

Hey Charles, do you have enough of these things yet?

For one reason or another, over the past month or two, I’ve just been buying random ducted fans from Hobbyking (where else?). At first it was out of a desire to find a good propulsion source for Chuckranoplan 0004, which I promise is still under way. But then with the advent of Fanscooter and its derivatives, I’ve been thinking about ways to use these cheap EDFs effectively…. or just in large quantities, to get higher thrust values for any propulsive task I can think of.

background

Now, real EDF systems from European and American boutiques are known to be great performers and are well-built – generally made of metal alloys or laid up from carbon fiber and dynamically balanced. These are the things that tear ass at upwards of 50 to 60,000 RPM in model fighter jets that go 200 miles an hour or more.

The problem is that they are EXPENSIVE. Like, dear Robot Jesus are they expensive. The TF8000 is generally my calibration point for how much I can’t afford a quality large EDF setup – the fan itself, without a motor, is $600. The motor is usually an exotic German make (like Lehner or Hacker) that costs $700 to $1000 by itself. Throw in the extra bigass controller you need to run that motor and you’re looking at nearly $2,000 for a single thruster setup. Granted it is like 30 pounds of thrust, but still – how do these guys even?

I mean, besides massive funding.

 

That’s why I have decided to explore the parallel design space loci a little, since it doesn’t cost too much for me to do so. Hobbyking currently has two large EDFs, both in the 5 inch (120mm) range, and I got them both.

  • HK #OR003-00113-7B Haoye 125mm rotor, 7 blade. This one has been around longer, but I only got it recently on a whim. It has a set screw type propshaft for 6mm motor shafts, and a removable nosecone. The construction seems to be pretty standard “cheap EDF” – unreinforced plastic (ABS, judging by the smell… read on to find out), but the rotor looks to be glass filled nylon. The price is $30, and the maximum motor diameter is about 50mm or so.
  • HK #102F “ChangeSun” 120mm rotor, 4 blade.  For 40 bucks, I threw one in on a parts order for Chuckranoplan. I like the construction of this one much more. The propshaft is a collet-type one, not a set screw, and the shiny aluminum nosecone is also a nut. The rotor and casing are both made of fiber-reinforced nylon and both are very stiff…which fiber is, of course, dubious – carbon fiber is claimed, but why do I not believe that? The maximum motor diameter is 52mm.

 

Finding motors to drive these fans was difficult. HK doesn’t have purpose-build EDF motors larger than 36mm (the type which has a tailcone and longer shaft). I also was not too please with the reviews on their large inrunners (up to 45mm diameter), and I hate inrunners anyway. The only thing left that was in stock were 600-class helicopter motors. I ended up getting a T600-880 and then a T600-1100 – two different winding variants of the same motor so I could test different battery voltages. There were some motors with potentially higher power, but they were not in stock and if I backordered them, I would probably get them some time in late September of next year.

Just to give an idea of how stupidly big this thing is… here it is next to a commonly scale item. The outer casing on this is about 130mm.

I also bought this cute little prop balancer from HK after feeling that I would need it.

A few unrecorded test spins of the fans revealed their very, very Chinese nature – the rotors themselves were severely off-balance. Using the über-cool magnetic levitation feature, I attached little chunks of rubber magnet stock I found at MITERS to the interior of the rotor using CA glue until I was satisfied.  That step was easy enough. At least the Haoye unit had a straight propshaft (set screw notwithstanding): the ChangeSun’s propshafts were completely and utterly useless. They fit the motor shaft well, but they were drilled off-center and wobbly, and the aluminum alloy was also rather soft.

Seriously, what a corner to cut. The rotor itself and casing are both very nice injection-molded parts, but the one critical component to connect them is garbage. Because of this inherent Chinese-ness, I can’t recommend them to anyone who isn’t willing to put some work into polishing them up.

For the ChangeSun 120mm fan, “polishing up” meant putting the 5mm adapter on a lathe and carefully reaming the bore to 6mm. In order to eliminate one major source of uncertainty in this, I elected to perform the operation on a nicer campus student shop machine.

Four blades versus seven… which one will win?

As usual, I’m interested more in the static and quasi-static (read: slowly moving forward) thrust of these fans. I’m not likely to build something that travels very fast or anywhere near the “prop speed” for these things, so my testing would focus on static thrust characteristics.

The T600 motors seem to be a good fit for both, but is a little tight on the Haoye 125mm (This would later prove to be a little tighter than I imagined). On the Haoye, the vent holes of the motor can stick out just enough to make it look like it was meant to be there…as well as providing a better airflow path.

On the contrary, the motor is pretty much flush with the backside of the ChangeSun 120mm fan. The vent holes are therefore much less effective here. This may have implications for continuous high-power operation of the whole assembly. A longer (read: more powerful) motor would be better for it.

In the picture, I was executing the auto-“Hey, hold this while I plug it in” test on the Haoye fan. I didn’t hold on for too long…

procedure

To measure the static characteristics (thrust, RPMs, power consumption), I set up the Fankart test rail. The EDFs are screwed to some cut-off 2×4 sections, which are in turn clamped to the linear ball bearing platform. I rigged up an electronic pull scale behind it, and located the controller (and Turnigy power meter) near that.  You can already see the dot of retroreflective tape I attached to the rotor so it can be measured using laser tachometry.

I make “laser tachometry” sound ultra-sophisticated, but it’s this one. You should get one since it’s useful, but it needs reflective markers – a sharpie mark won’t do.

Next up was the Haoye fan with the T600-1100 motor already loaded. At the very start, I noticed the current draw was much higher than I would have expected. But the ESC is (allegedly) 80 amps, so I kept going anyway.

At somewhere near top speed, the fan suddenly locked up…and then this happened.

The destruction was instant.

Model airplane controllers really amaze me in how close the components are pushed to their absolute maximum ratings. They also have absolutely no protection whatsoever – at least, in this case, the protection wasn’t fast enough to respond to a sudden locked rotor at full throttle. The thing lit up and actually started shooting jets of fire.

Yeah, it’s pretty gone.  The shorting current was enough to blow off several wires completely and heat up my double 14-gauge battery jumper. So when this happens to your plane in midair, does the whole thing just light on fire or something?

I literally had to hammer out the motor from the casing. Something went terribly wrong…

Yes, that is a ring of melted ABS plastic hanging out of the motor. I know it’s ABS because it smells like all three cancer-causing constituents of ABS plastic, and is the smell that Make-A-Bot constantly creates when it’s in operation.

It looks like a severe case of… well, severe case interference from the distal end of the motor can to the walls of the housing. What this tells me is that the T600 is just a bit too large in diameter to really fit the housing, and the vibrations induced from operation are enough to make the can scrape the inside. At high speeds, this translates into quick rapid heating that melts the housing and turns the plastic goopy.

I assume at some point enough plastic goop is hanging onto the motor to drag it to a stop. No data was recorded on this run because I was too entertained by watching controllers explode.

While the long-term solution for this problem is to find a different motor, the short term one is to just bore the housing out. I took everything out an extra millimeter so the motor had plenty of clearance.

After that, I remounted everything and, using a different controller, put the test rig back together.

results and discussion

The test on 10S LiFePO4 cells with the T600-880 motor yielded:

  • 19100 RPM
  • 2.9kgf static thrust
  • 95.5A peak
  • 30.01v minimum.

I elected to not even try the 1100kV motor in the Haoye fan after this, since it would probably just try to pull a thousand amps without getting much work done. Judging by the very low RPM figure, the readings are reasonable. It’s clear to me from looking at the fan blade geometry that the Haoye is designed for a very high vehicle speed. The blades are very heavily pitched (actually perpendicular for the most part) and not very swept or twisted at the tips (not much washout, a plane word I learned). From the findings on Fankart, this would make for worse static thrust per power consumption, and the results reflect that here.

Further tests with the ChangeSun fan on 12S LiFePO4 (38.4 volts) found that it’s very well paired with the T600 motors at that voltage.  I got the following data points:

  • 31.1Vmin, 53A continuous, 2.8kgf static, 24800 RPM with T600-880
  • 30.0Vmin, 86A continuous, 3.8kgf static, 28500 RPM with T600-1100
  • 36.7Vmin, 75A continuous, 4.1kgf static, 28540 RPM with T600-880 on 12S LiFePO4

I also decided to not test the T600-1100 on 12S since it was clear the continous current was going to be over 100 amps, and the motor will definitely not take that much. I think even 75 amps max is pushing it for the T600-880 motor.

I think to prevent future friction stir welding situations, the motor should be a large inrunner, preferably with an aerodynamic tailcone. The problem is that HK doesn’t carry huge inrunners yet, and real inrunners (from say, Neumotor, Lehner, Hacker, etc…) would be kind of lame to pair with a cheap fan. So if you know any Chinese inrunners in the 50mm size class and of more than 2+kw continous power, let me know.

conclusion

Wait…what the fuck is this, a 2.671 paper?

Anyways, the conclusion here is that for a little over $150, you can get a solid 4 kilograms of thrust from the HK102F “Changesun” fan paired with a T600-880 motor, running on a 100A Turnigy HV controller. 12S LiFe cells is very much equivalent to 10S traditional ltihium polymer, and if you pair it with a DEAR GOD WHY DOES THIS EXIST 10S pack like this 5.0Ah pack from HK, then for less than the cost of like, one fan blade on the TF8000, you can have a full 4kg class power system for around $300*.  Most likely, that battery can feed two T600-880 powered fans at the same time – 150 amps continous (75 amps each) is only 30C, which is within the rating of the battery, and have a system capable of 8+ kg thrust.  Put two of those system side-by-side, and you’re looking at something which can lift Überclocker straight up in the air.

Just saying.

Oh yeah, if you want to hear what a (balanced) one of these sound in action:

*You better have a machine shop to clean up those propshafts though. I have not tried running the CS 120mm fan with the stock propshafts. They scared me too much even on low speed.