RazEr rEVolution: End Menial Labor

When we last left rEVolution, I was halfway through the process of turning my hands into bloody, tattered stumps. It’s a ritual that occurs with the construction of every hub motor (which means I went through it four times to make the RazErBlades).

And by all that I mean winding the motor. Here’s the end result, terminated for presentation.

I ended up keeping the “split dLRK” winding style – making 6 teeth wound AabBCc and the other 6 aABbcC.  They’re terminated in separate non-connected star points on the underside. The leads are grouped by their respective phases – motor 1 is the classic white-red-black, and motor 2 gets yellow-green-brown.

My patience deterioration is very clearly shown in the picture. I wound this motor starting from the Aa side and proceeded counterclockwise. You can see a decay in the quality of windings and the neatness of layers right after the aA phase on the left. Then by the last one, it’s all gone to hell.

To maintain engineering rigor, I took measurements of the DC resistance of each phase. This will pretty much determine how much current the motor can ever pull.

I proceeded to defenestrate engineering rigor (MITERS has very large ceiling-height windows, so this was easy) by scribbling the resistances hastily on the workbench. In dry-erase.

From the picture, you can deduce that the C phase of motor #2 is about 10% short of turns. Yeah, I think I pretty much stopped caring by that point. The other phases should have 39 to 42 TPT, but I’m guessing 35 or less made it onto the last C phase if I’m lucky.

Fit test!

I tried giving the motor a test spin using a sensorless controller (essentially by bootstrapping off Melon-scooter), but neither half-motor exited the “starting” regime. This was concerning. Did I terminate them wrong? Wind something backwards just a little bit?

A few minutes of diagnosis revealed that the motor was technically running smoothly, but the controller just didn’t increase throttle. Applying voltage to each half-motor in each combination of the 3 leads (i.e. A to B, A to C, B to C…) produced 6 identically spaced angular positions each time – which is indicative of correct winding, since that’s pretty much what your controller does anyway, just alot faster and without colliding alligator clips.

I pretty much just declared it to be a fault of shitty sensorless aircraft controllers being unable to deal with inertial loads or high friction systems.

Without a supply of hall sensors, I put the frame and motor away and started thinking about the other parts of the electrical system.

EVs generally have 3 big components – motor, controller, and battery. With the latter two, you can shoehorn anything in as a motor. With motor and battery, you can be a dumbass like me and control the vehicle with a mildly more civilized form of touching 2 wires together. But without a battery, what am I to do – run the whole thing from a bag of lemons?

Luckily for me, people have figured out how to stuff the equivalent of tanker-loads of lemons into lithium nanophosphate cells. Above is the 12S2P A123 DeWalt 36v Lithium pack during mid-assembly.

I managed to find some terrifyingly wide copper braid this time, and I think the cells just look so much better with them instead of the \m/etalpaxxx‘ quadruple braid. The massive interconnects just scream this pack will dump enough amps to destroy you and everything you ever loved.

Another serving of giga-braid later and the pack structure is complete. I decided to split the pack into 2 6S packs again for balancing purposes, but this time the pack isn’t two separate entities. Shane supplied me with Real Legit JST-XH Connectors of Battery Balancing (+14, for pin count), or otherwise I would have probably resorted to 7 pin-header again.

Bottleshrink returns once again, but this pack is so long that I needed the midsections of 3 bottles to completely enclose it. Luckily, it fit 2 liter bottles fine, and I just pulled a few out of the recycling bin.

A quick check of the cell levels revealed that these cells are in fact still quite healthy despite sitting for an unknown period of time.

Of course, that all went to hell on the first charge, and I had to spend an hour manually bringing each cell group up to full.

back to motters

Given that the motor itself seems to be correctly wound, I surmised that all my problems would go away as soon as I added the requisite hall sensors to the slots.

And here they are, temporarily CA’d in place as a soldering fixture. LRK-style motors need a physical 120 degree sensor arrangement, but I’ve always found cross-stator wiring work to be awkward. Therefore, like on the skatemotors, I take the B sensor and flip it around for a 60 degree, every-two-slots layout.

I secured a chunk of 6 pin cable to the access slot in the shaft using epoxy. At the same time, I elected to secure the phase leads to the other side of the motor. The whole epoxy-globbed mess was then introduced to my epoxy curing oven fixture implement hair dryer hanging by its power cord from the ceiling.

After the first round of epoxy set, I finished connecting the sensor wires. Unfortunately, I managed to break off the output pin of the B sensor… and so ended up having to install the opposite one anyway.

Luckily, this design left plenty of space near the edge of the stator, so running the wiring all the way around the motor wasn’t as difficult.

The sensors got their own layer of goop. I kept finding buckets of different epoxy fillers around MITERS – this is “cellulose” filler, which probably just means paper dust.

It claimed to be less cancer-inducing than either the silica or phenolic microspheres, so I gave it a shot.

After another hour or two of watching glue dry, I put the motor together. Here it is – Dual (Non-)Interleaved RazErMotor!

But does it work?

That’s a gooooooooood question.

Using the Kelly KBS which sort of miserably failed at running Melon-scooter, I was able to briefly power up and spin the DNIR to full speed. Qualitative observation tells me that at least I didn’t get it that wrong. The fact that it moved at all meant that I got the sensor arrangement correct for the “split dLRK”. Now, for this test, I just paralleled the equivalent phases of each half-motor. Once I put together the RazerDEC board, each motor will be powered by its own controller, but triggered from the same sensors.

The speed was visually in the “correct” range and it started and ran smoothly with no signs of improper winding or termination.

that is, until it started sounding like a moped.

Oscilloscope diagnosis of the sensor outputs showed that every mechanical revolution, all 3 sensors were blanking. This caused confusion for the controller for a split second until the sensors outputted a valid signal again.

Well, this is disappointing. The sensors – which, mind you, I had JUST encased permanently in a cellulose-epoxy matrix – seem to be having power issues once per mechanical revolution. I’m fairly certain it’s power, anyway, because there is no physical way for all 3 sensors to read the same field orientation the way they are set up.

This actually means it shouldn’t be hard to fix – my guess is that somewhere, a bare solder joint is nicking the metal can once per revolution and causing a short between sensor 5 volts and ground. A further test to confirm (or dispel) this would be to look for dips in the 5 volt line during each revolution.

In the mean time, there’s no pics of it running, therefore it didn’t happen.

Dragon*Con 2010: The Real Wrapup…Finally.

hey charles, don’t you owe all of us a dragon*con 2010 event report or something?

Yeah, yeah. The beginning of term, lack of motivation, and the lackluster (but entertaining) run of the robots at Robot Battles meant that I just Haven’t Gotten Around to writing up D*C2010. But I seem to be on a streak of making up for missed writing assignments this week with all the site updates, so… here we go.

Welcome to Dragon*Con. If you missed my description of it last year, don’t worry. It hasn’t changed a bit. The atmosphere is still as eclectic as ever, and the crowds just as dense. Actually, they were probably denser. D*C is one of the biggest conventions in the continental United States.

But I’m not a fan enough of anything to really enjoy the con for most of its con…tent. So let’s move onto the robots.

Also, I like girls with big guns.

Right. Anyways, robots.

Like last year (and years past), Southern Polytechnic rolled out their VEX robotics kits and sponsored an open build-off on Saturday. The participation was pretty intense, with young children showing up strongly. At the end, there was a ball-gathering competition.

sunday sunday sunday

Time to stop diddling. The “Microbattles” event is held on Sunday, before the big competition. NK hasn’t been here since 2008… in fact, when this version was first built.  So NK is running 2 years behind the development curve. How have its opponents evolved since then?

Oh…

The robot caliber this year is seriously advanced compared to years past – alot of it, in my opinion, due to the fact that the other Southeastern builders that I used to smash robots with have also now advanced to college machine shops and have become spoiled like me.

I mean, except Thomas up there, who’s just magic.

Cake, from the Georgia Tech crew – another one of the high-caliber machined and fabricated bots.

On the other end of the spectrum are things like this, which are built by people who are just out to have some fun and entertain the crowd.

Speaking of the crowd…

The Robot Battles events seem to always have outstanding attendance no matter what. The International ballroom has a seating capacity of several hundred (the exact number escapes me). At several points during the event, it was standing room only in the back of the room. And at least once, who I can only presume was the Hyatt Regency’s fire code liaison came booming over the room intercom instructing everyone who was standing to leave.

Disappointing, but oh well.

NK made a run through the tournament bracket before being Caked in the winner’s bracket finals. Cake, being a lower hitter, won every collision. I originally was going to forfeit any matches involving the high-energy weapon bots since I was more interested in maintaining NK’s operational status, but hell, it was the finals.

So I went for it. Overall, NK came out pretty undamaged for the amount of ass-kicking Cake dished out throughout the tournament.  No prizes this year, but the finals match was stunning.

Here’s NK’s highlights for the Microbattles tournament.

clocker and arbor

The day after was the big robot tournament.

Dragon Con is my annual robot party, since it’s precisely at the end of summer and represents the last bit of fun I’m allowed to have before flying back for the academic term. So I spend all summer building or upgrading the robots, among other activities, and bash it all up at the end.

This year, I brought both Arbor and Clocker. It’s been a while since I’ve run a 2-robot tournament, but with Robot Battle’s more laid back atmosphere, it wasn’t nearly as stressful as Motorama. In fact, I rather liked it.

Most of the usual suspects were back, with hacks, mods, and upgrades aplenty. Here’s (Big Blue Saw Presents) Jaws. Also back in the mix was Dale, Evil Robotics, MH, Found Objects, and others.

But this year also saw quite a few newcomers. The Armed Robotic Critters, for one, came with a whole fleet of critter-themed 12lb and 30lbers. Overall, attendance this year was back above pre-2009 levels. 2009 was sort of a bad year for the competition due to several builders having to skip the competition.

Then you have Sporkinok.

Really it’s not even an antweight, but Seth brought it (and a 12lber) anyway. Just for Grins and Chuckles™.

Only at Robot Battles…

….does this kind of stuff happen. You know what’s really hard to catch when you’re a 12 pound robot? A 1 pound robot.

I really can’t say enough about the level of audience energy at Robot Battles. The Regency 6 and 7 ballrooms combined sat over 1000 people….and again, during the event, was reduced to standing room only. The event also encourages the audienec to participate by helping start, end, and occasionally judge matches.

Yeah – you don’t come here for SRS BIDNESS TERNAMINT. You come here to put on a show.

Clocker did great for a while, but then immediately suffered another left-side drive failure. What the hell?

A quick examination revealed that the left gearbox output shaft was poorly assembled (read: did not press hard enough) and slipped its interference fit. Now, what was really weird was that shifting the whole shaft axially some times caused it to re-engage just enough to give the robot differential traction. So Clocker ran sporadically, but was crippled at other times. When the drive disengaged, I just threw on a Zip Tie Ratchet.

Here’s Clocker’s highlights video from the competition. I managed to execute another Robocopter spin with Jaws around a minute and some in.

That’s the move I designed Clocker to perform, and it did so admirably. Unfortunately, the clamp motor was unresponsive, so I couldn’t throw Jaws off the stage. As close as it turned out to the camera guys, this was probably for the better.

Oh, Cold Arbor.

As nice as the upgrades I made were, it still didn’t stop the saw from just catching and binding. I pretty much expected that to happen again, since this milling blade was made for multi-ton machines – not a 30 pound robot. Arbor was visually very impressive and garnered alot of audience applause, but ultimately it suffered two losses because it just couldn’t do anything.

If Arbor is to be actually competitive, I’d have to rethink the whole concept of the robot. Right now, it comes down to an issue of severe uncurable positive feedback – the forces of cutting are squarely directed into jamming the saw further into anything it contacts.

If you observe a regular cold saw or even power miter saw in action, you’d notice the saw’s swing is more vertical than horizontal. In other words, the tangential force of cutting is directed perpendicular (or nearly so) to the direction of saw motion.

Arbor’s movement is very horizontal – made even worse by pivoting the saw at the base of the robot. Therefore, the force of cutting is directed downwards and back into the robot, which is the same force vector I’d generate by cranking downwards on the saw with a pry bar. The net result is that any impact of the blade has to be compensated with massive torque inputs – realistically, more than the worm gear output can probably handle or anything short of an Etek can generate.

overall

Neither a win, nor a fail. I went to the event to put on a show (since there’s really nothing to win), and I think the bots did that just fine. I’m still keen on the concept of an actual working saw bot, however, so don’t expect Arbor to just disappear into MITERS. It will be rethought (possibly while I make sure Clocker’s gearboxes don’t let loose ever again, EVER).