Land-Bear-Shark and the CIMulink

Has it really been 2 whole months since I shoved LBS under a bench and sort of forgot about it? That warrants a break in my project timeline!

Since then, it’s been slowly migrated all over MITERS as people make space to work on things. My box of hardware and components has collected a fine coat of grinding dust, other people’s projects, and assorted unwanted parts. More than a few tours of the place in the mean time have been given with the parting promise that it will be done “Soon”.

Well, soon is ideally in the next two weeks. I’m picking the completion effort back up again since I want to be tooling around on it come June 3rd.  Control issues aside, the most important unfinished detail is the replacement of the melons (which was the underpinning of its internal reporting name, Melontank) with Plain Ol’ DC motors. The new drive motors are CIM motors, the same kind used in both Segfault and something like a quarter million FIRST robots. So does this mean I have to call it “CIMtank” now?

The CIM motors are much higher speed motors, so I needed a “preduction” to get the speed of the vehicle back down to the range it was in with brushless power. As detailed last time, I was going to do this using a shady little e-bike planetary gearbox and some crafty arrangement of rotating shafts.

This shaft-mounted speed reduction solution has been affectionately named “CIMulink”, after everyone’s favorite MATLAB simulation toolbox. The aluminum sprocket adapter bolts onto the (rotating) planetary carrier, and it spins on bearings which just ride directly on the motor shaft.

Like so. These are the solid part geometries turned from some 2.25″ aluminum stock. I milled a D flat onto the CIM motor shafts so they directly engage the Currie gearbox input. The output “bump” sits in the adapter’s bearing indentation, though it’s the motor shaft itself which contributes most of the alignment in the system.

I removed the sprockets from the Turnigy motors and bored them out to 7/8″ to fit the adapters. These sprockets were some kind of horrible sintered steel that machined like garbage, and would spark if I fed too hard. They also finished poorly and also smelled really bad. What, I can’t even get real steel in my power transmission components any more?!

Anyways, the 7/8″ boreout  left too little “thread” in the hub to tighten a set screw, so the adapter had a blind hole drilled at the set screw location for the screw to seat in. It functions more as a pin in this capacity.  The flange holes in the aluminum adapter were finished using my indexing fixture on the mill.

With some 10-32 low-head cap screws, the adapters were bolted to the Currie gearboxes. The gearbox didn’t have a bolt circle in it originally – the four holes through which it was riveted for structure were drilled out to a depth of 1/4″, then tapped with a 10-32 bottoming tap.

This is what the CIMulink looks like mounted to the mot…

Wait, there isn’t a mount there…

That’s because during all this time, Make-a-bot was faithfully printing out the motor mounting bracket seen in the initial CAD image. Each one of those took about 1.5 hours…. during which I probably could have just straight up machined it, but I’m both lazy and didn’t have stock of the right size to start with.

Oh, there it is.

The mount is a total of 12mm thick and is printed from white ABS plastic. It’s 90% filled, so it will be more than strong enough for the application. Four 8-32 bolts retain the Currieboxen to the mount, and the ears are through-bolted to the frame.  I couldn’t find 3 inch long bolts to connect the new (thicker overall) motor module, so I had to use 3.5″ long bolts for now. They stick out quite a ways, so I’ll either cut them down or maybe just turn them around later.

I’m also going to change the tensioner arrangement – right now, the chain slings under the white tensioner sprocket. I’m finding that I can’t expand the tensioner diameter any further without it interfering with the teeth of the treads, and the chain is still a bit loose. Moving the chain to over that standoff decreases the tension roller diameter needed, but I do lose a tooth or two of sprocket contact. With sufficient added tension, though, I think this should be fine.

With the drivetrain swap completed, LBS looks…about the same it has been for the past four months or so. Well, it’s already 5 months late, so why do I care?!

The track pods draw about 8 to 10 amps no-load per side at 24 volts on a power supply test.

At this point, I could actually just drop the control rig from Überclocker into it or something and be done. However, that’s simple, realistic, and stands a chance of working, so we can’t have that.

In the interest of eventually pursuing the dual-glove “fingerless” control using XBee radios, I’ve elected to use a 2.007 Arduino Carrier board, a wonderful robot motherboard-like device created specifically for the class this year. It even comes with an XBee socket already. But for the next week and a half, which is less time than I can foresee me designing and ordering boards and parts for the wrist controller, the interim solution for control will be just using the Arduino Carrier to interpret throttle and steering signals from a shady 2.4ghz hand-held radio.

I have, of course, prepared a custom motor control solution for it too.

This is a little logicless power amplifier board similar to the Segtroller boards I made for Segfault. The difference is that it isn’t locked-antiphase, just has two independent PWM inputs and a master disable. Gate drive voltage is derived directly from the power rails by a single 15v regulator. So basically, it’s a Small Cute Full Bridge.

Distinct from all the other random motor control modules I seem to make, though, is the fact that it has an ACS714 Hall current sensor in line with the power inputs so it can sense DC bus current. I’m going to try and make LBS current controlled so it doesn’t jerk around. Current control directly dictates the torque a motor can produce, so it would be like setting a maximum acceleration. A current sense output pin is broken out on the header row so I can feed it back into the Arduino board.

These boards are currently out for fabrication, so they should arrive by the end of next week. That’s a little too close, though, so who knows – maybe I will just pitch a robot controller in it!

A Few Words on “The Segfault”

Okay Make, I have an axe to pick and a bone to grind with you guys.

My experiences with Make Magazine and the affiliated blog have been extremely positive in the past. Everything from LOLrioKart to a certain 3D printer to even Fankart has been on the blog so far, and MITERS generally has contacts with people pretty closely associated with Make anyway, so just about everything we do ends up on there. But I have some pretty big reservations about the description of Segfault up there, in this month’s Make (volume 26). Basically the story is a few months ago I was contacted by a journalist for a quick interview about Segfault’s construction, which I obliged to. Now, I don’t blame John up there at all – I know that the guy knows his shit, and he’s in fact the person who puts alot of our stuff on the blog. So I think in this case, he was only reporting on information relayed to him. And boy was that faulty – so since the given address seems to link directly back to this site, I might as well open the valve a little, so to speak.

In a nutshell, those are all the fine little details that nobody cares about being treated as headline news. It has 9 inch scooter wheels!!! And GEARMOTORS!!! No, I’m not just bitter because the gyro and accelerometer functional description is wrong and I’m not sure how it was distilled from the description I gave it. No, what I’m really peeved about is the fact that

Segfault is analog.

That was like, the entire point, man.  Fact #1 about Segfault is always that it’s analog. Not a single line of code runs to keep the vehicle stabilized. Your segway runs on 14 lines of code, mine runs on op amps. Real op amps.  FOUR HUNDRED OP AMPS.

Okay, so more like 11. I think they’re starting to wear out and their gains need replacing soon, but OP AMPS!!!

The signal processing occurs in continuous time.

Instead of waterjetted aluminum chassis (which is nice and all), that line should read ANALOG!!!! I’m not particularly proud of the fact that it uses rudimentary and rather obsolete technology to accomplish the task, but the fact that it was one hell of a control theory learning experience, especially since the final build really occured over like 48 hours. Porting a transfer function to op amps!!!!! is about the closest you can get to just double-fisting the raw theory.

It doesn’t have an Arduino.

Or an ATMEGA chip, or a MSP, or a Cortex. Or anything for that matter. I guess the twin Class D switching amplifiers running the motors are kind of digital.

It also doesn’t work like that.

I’m not sure where the “gyroscope prevents the accelerometer from overcorrecting” bit came from, but it’s way more like the gyro and accelerometer complementing eachother and working in synchrony. In fact that’s so true that it’s even called a complementary filter. It’s a very common and simple sensor fusion algorithm, and if you actually want to know what one is, Segfault’s second most recent build post goes over why I use the two sensors this way in the Adaptive Face Forward Compensator.

Okay, that’s enough for now. Ya’ll should go build Segsticks. Maybe I should start writing for Make or something, eh?!