IRL Flinch

What was I working on?

Oh, right, it's summer, the most productive build season by far. No more excuses: Quals are done, I didn't fail out of MIT, and it's time to get back on track with the current list of open and pending projects:

1. Flinch, a miniature Mecanum-drive robot, the subject of this post.
2. Adapting the 3ph v3.1 controller for sensorless field-oriented control. Mostly a software project.
3. A new brushless controller with a lot more power and several new tricks I've been meaning to try. The first iteration is almost ready for circuit boards. Look for a post on this shortly. Hint: It's called DirectDrive.
4. The newest vehicle from the Edgerton Center Summer Engineering Workshop (of DIY Segway, Cap Kart, and BWD Scooter fame). This one is very cool. Hint: We're back to four wheels.

But first, Flinch. Here's a reminder of where this one is going:

Like Twitch, Flinch is an omni-directional, or "holonomic", robot. It doesn't have Twitch's fancy linkage steering, though. Instead it uses Mecanum wheels to accomplish 4I3O omni-directional control. I suspect it will take a good amount of software help to make the tiny Mecanum wheels effective at the kinds of speeds I hope to achieve with Flinch (~10fps), but for now I'm focusing on getting the mechanics and temporary electrical system in place.

The first order of business was to produce the motor mounts. I made all four at once from a piece of 1" wide aluminum stock, cutting them down to size later:

Under normal circumstances, 16 blind-tapped 4-40 mounting holes would be an annoyance, but compared to Quals, it was a relative pleasure.

Next, I made an insta-chassis with top, bottom, and side plates:

The top and bottom plates are laser-cut UHMW from Big Blue Saw. (I guess in this case it's more like Big Infrared Saw since it was probably cut with a CO2 laser...) I've never worked with UHMW before, but it seems to be a nice, cheap alternative for robots that don't quite justify an aluminum plate chassis. To make up for the bendiness of the plastic top and bottom, I ditched the standoffs in the original CAD model for solid 1/4" side plates.

I did put the standoffs to good use, though: From the side plates, a standoff sticks into a bearing I added to the outside of each Mecanum wheel, acting as a dead axle. It provides a bit of extra support to the wheel, even though the structural loop around the chassis is not as stiff as it would be with aluminum top and bottom plates. After dropping it a few times (on purpose), I found that the bearings would just pop out, so I added some washers to hold them in place:

I'm missing some M3 screws required to mount the motors, which is preventing final assembly for now, but here's what it looks like all together:

There's something wrong with this picture. If you can spot it, you win a cookie.

After I get the motors mounted, I may borrow the electronics package from mini4WDbot to do some initial testing. I don't expect very good open-loop performance, especially at high speeds, but you never know. I might be pleasantly surprised by the handling. And even if not, it's a good way to make sure all the motors work and the wheels do roughly what Mecanum wheels are supposed to do.

Mini-Segstick, My Mid-Quals Crisis Robot

MechE Quals, Round 2.

I just finished up the subject tests for Round 2, Do or Die Edition. One thing I hate about Quals (besides the peer pressure to consume yourself in study for six months and the shell-shocked look on everyone's faces after they come out of the oral exams) is the artificial mysteriousness around it all. Which, by the way, is propagated by both the faculty and the prior test takers. So even though I failed the first time and my outcome this time is faaaar from certain, I have been in observer mode this entire time and I'll continue to post my (obviously opinionated/experiential) impression of exactly how it all works.

Here's the summary of where I stand after Day 2:

Machine Design: Definite pass. Once again, the least amount of studying for the most result. Gears, linkages, mechanisms, motors, transmission ratio, power budget. Where have I seen these things before? It's the subject with which I have the most hands-on experience, and no doubt that makes a big difference. If you want to learn something...do it.

Manufacturing: Definite fail. Okay, so I don't know anything about heat transfer into a mold. That was one part out of nine, and I failed because of it. That alone doesn't bother me as much as the nature of this test. Normally, the written and the oral are separate problems. Here, the oral exam was literally a critique of your weakest answers on the written exam. And by critique I mean drill down on the same numerical analysis that I clearly do not understand, for fifteen minutes, and leave five minutes for the other eight parts that I actually was able to do. If the point is to make me feel like an idiot, well, mission accomplished.

Controls: Oh, Controls. How can I sum up my experience with the MechE Controls Qual? Both times I've taken the written Controls exam now, I've gotten totally lost in the algebra required to model the system. If you can't get past that in one hour, there is absolutely no hope of getting to show your knowledge of control of the system. Then there's the Controls oral exam. Whereas the other oral exams have two, three, or maybe four professors sitting in on them, Controls for some reason seems to need six or seven. This time around, even though there were only three of us taking the test, we got seven profs again. And make no mistake, they will attempt to tear you apart at your weakest point.

I learned a couple of very important lessons from the Controls oral last time that served me well this time:

1. Do not waste time on the algebra. On the orals, they tend to give you the answer to the system modeling part. Just use it and do the rest of the problem, then go back to the math if you have time. Last time I spent 20 minutes working out the math during the reading period only to be told within the first 2 minutes of the exam that "we don't have time to do algebra." Okay, fine. This time I explained how to do the math, but that's it.
2. Use your notes. This was probably the most important lesson I learned. Last time I walked in, put my notes down, and proceeded to try to re-do everything on the board, while be bombarded with questions. This time, notes in hand, I at least managed to show them what I had already worked through.

So the second time around I was able to at least hold my ground in the Controls orals. But I don't know if it will be enough to make up for the algebra train-wreck that was the written exam...

Actually...none of that really bothers me though. No, what really bothers me is that they put a motherfucking self-balancing robot on the written exam.

I have this thing about self-balancing things. Mainly, nobody really "gets" how these things work, and how to implement a controller for things like these things. And I can't tell you how many times I've explained why it's harder to make a self-balancing robot thing than a full-sized self-balancing...thing. 

If you're going to stand on it, all the controller has to do is try to keep the platform horizontal. It doesn't have to worry about wheel speed or position control, since you do that. The robot has to do it all. And it's got a faster time constant, because it's smaller. And while we're at it, let's throw in full mass and inertia on both the stick and the wheel as well so we get a nice coupled matrix that I can spend 60 minutes trying to untie. Had I managed to do so, the answer to Part 1 of 5, would have looked  something like this:

If you have absolutely nothing better to do, here's the full derivation, including the defintions of the H's. So let's just say I had been drilling algebraic manipulation since kindergarten and I could get to that point in less than 60 minutes. It turns out to have the typical inverted pendulum form with a set of real poles, one of which is in the right half-plane. Stabilizing it is straightforward with a PD controller.

Then the problem went on to talk about damping at the wheel/stick interface, which according to MATLAB adds a zero at the origin and a pole in the left half-plane. (Am I supposed to just know that, or what?) The zero at the origin is problematic because it "traps" the unstable pole in the right half-plane. So you can use PID control to cancel that zero and drag everything back over into the left half-plane. I feel like this was the interesting part of the problem, and I never got to it because I had to first untie the mass matrix into a transfer function. Working through the solution took me about eight hours, spread over two days. So if this is designed to be a one hour test, I never even had a chance.

But you know what else I can do in eight hours?

Build it.

I figured, since I already have the nice compact sensor/controller/motor drive combo-board from Segstick, I should strap it to a robot. Yes, those are mecanum wheels. No, they don't serve a purpose. It's just the quickest motor and wheel set I had available. They're really for Flinch. I've seen enough of self-balancing things to know that, if you do it right, they can tolerate almost any disturbance you can find, including oddly-shaped wheels.

Even if MechE decides I am not good enough at mass matrices and root loci to merit a Quals Pass, I refuse to accept the implication that I can't build a working self-balancing robot in my sleep. I have been messing around with the balancing framework for almost four years now. For example, one thing entirely not captured by the controls problem is the fact that you don't actually get a measurement of angle. You get, at best, noisy accelerometer data and drift-y gyro data. Dealing with this has somehow become an odd specialty of mine.

Then there is the thing I always rant about, which is that controlling a self-balancing robot thing is inherently harder than controlling a ridable balancing thing. While the balance controller can be a simple PD loop that keeps the platform horizontal, you have no way of controlling the speed of the robot. Inertial sensors are inertial, i.e. they don't know the difference between standing still and moving at 10fps straight at a wall. The human rider can close a loop with his or her mind that keeps the platform stationary, or moving at a constant speed, but a robot needs help. This extra feedback can come in the form of a radio control, wheel speed sensors, or in the case of Mini-Segstick, a hack speed estimator that just low-pass filters the motor command.

By the way, don't try to do laundry during Quals week.

Mini-Segstick uses a strange control strategy that I don't think you can find on a root locus. I thought of it a long time ago for making an RC balancing robot, but I've never actually implemented it until now. It runs the normal balance controller all the time, trying to stay vertical, but if it senses that it's been moving forward for too long, it will make the gains "softer" for leaning backwards than for leaning forwards. That is, it will resist less to disturbances that cause it to lean backwards and slow down. And vice versa if it's been going backwards for too long. It definitely behaves differently than the normal 2nd-order balancing thing does. You can see it make movements that are seemingly preventative...moving in the "wrong" direction now to prevent a big problem later. It's...fascinating. Maybe after Quals is done altogether I'll build a permanent one and really tweak the controls.

So while I wait for the results of Round 2, I'm content with the fact that even if I can't finish a Controls problem in a reasonable amount of time, I can still build a real control system. At least I haven't gotten (much) stupider since I became a grad student. I look forward greatly to being useful again after Thursday.

eBay Hack Charger #7,523

I really should start a project page for random power supplies that I put together with junk from eBay...

A few weeks ago, I re-purposed an Xbox 360 power supply for my battery charger, and commented on how nice it would be to have a flat OEM power supply brick like this one from TDK Lambda instead. Well, I didn't find that on eBay, but I may have found the next best thing. Vicor is another manufacturer of shiny OEM power converter bricks, and I happened to come across a lot of these:

Turns out Azure Dynamics, a local EV technology company, has an eBay store, presumably for stuff they don't need anymore. I'll be sure to check back regularly. The VI-251-09 brick takes 100-300Vdc and puts out 12V at 200W. I also managed to find a matching Vicor input rectifier module, though presumably any bridge rectifier could work. Combined, the rectifier and DC/DC converter are functionally equivalent to the XBox 360 power supply, but a lot smaller. Some assembly is required, though:

The input is 120Vac and the output is trimmed up to 13.2Vdc. In between, I added a two-pack of 200V, 330μF capacitors. This buffers the rectified AC at the input to the DC/DC converter. The disk-looking capacitors between the terminals and the baseplate are recommended in the datasheet for EMI protection, i.e. they are probably not necessary.

And as usual, I found a random heat sink in MITERS that was already the perfect size for fitting the input rectifier and DC/DC converter brick. I added the fans after experimentally determining that they were needed to hit the full 200W output. Through some sort of luck, the 8-32's I happened to have lying around self-tap into the heat sink fins. Since I'm not an HVfrosh, I thought it wise to insulate all the high voltage pins and ground the heat sink in the final configuration.

I also randomly found a box/carrying case that everything fits in perfectly. There's even a little square left for the balancing lead breakout board. I really should stop measuring things and just look around until I find things that are exactly the right size. It works well.

Meet Flinch

Every year during and immediately after 2.007, I have a bit of robot nostalgia. Last year, this resulted in Twitch, Jr., a switched-mode omnidirectional robot named after Team 1565's '08 FIRST bot. Since then Twitch has had a professional HD camera mounted to it, driven a microphone stand around at the 2.007 final contest, been on something like three Japanese TV shows, and recently been to the Cambridge Mini Maker Faire. It's by far the most fun robot to drive, ever. And I've driven a lot of robots.

But now I think it's time for Twitch to have a friend:

d'awwwww

Flinch is a smaller robot, 9"x8"x2.125" and probably less than 3lbs. While Twitch uses a fairly rare linkage drive, Flinch will feature the somewhat more common Mecanum wheel solution for omnidirectional motion. Mecanum wheels have been around for a while, but were popularized by FIRST and AndyMark over the past seven years or so. You can see what exactly they do on Team 97's '08 FIRST bot. (2008 was a great year for drivetrains.)

The wheels give it the ability to defy typical 4WD robot kinematics by controllably moving sideways. Two axes of translation and one of rotation are simultaneously available, making it a true holonomic drive. (Twitch, in its most extreme configurations, only has two degrees of freedom.) What makes this possible are angled rollers on the Mecanum wheels:

Flinch will use four of these 2.125"-diameter Mecanum wheels from FingerTech. They each have six rollers angled at 45º from the drive axis. Effectively, a robot with four of these wheels, independently driven, can create force vectors at 45º angles from each wheel's contact point. By summing these vectors, the translation and rotation of the robot is determined. Or, if you know the (x,y,θ) you want, you can run them through a 4x3 matrix to recover the wheel commands. (I guess the extra degree of freedom is the burnout axis.)

Straightforward kinematics will only get you so far, though. The real difference between a mediocre Mecanum drive and a good Mecanum drive is closed-loop control. The addition of a gyro to control the rotational degree of freedom made a big difference in Twitch's driveability, and I suspect at least that much will also be required for Flinch. I left a standard mounting pattern for electronics so that I can start with an Arduino Nano Carrier (shut up) and upgrade later to a full custom solution with integrated inertial sensors, motor control, and maybe even a magnetometer for Earth-oriented control. More on that in a later post.

For now, I've mostly been focusing on the mechanical elements. For one, an obsessively detailed CAD model of the wheel. I don't think I've ever been so disoriented by reference geometry before.

And then there are the rollers. I know there is a parametric equation governing the profile of the rollers, and there seems to be some discussion as to whether it is parabolic or elliptical. I took the easy way out:

It is what it is.

Next, motors. Unfortunately, Banebots has entirely stopped making small gearboxes, apparently. Every single one is out of stock. They've also folded up the 36mm RS-380 line that Twitch utilized so well. So basically, they only sell P60 and P80's now? And even those take 10-15 business days to ship? Fuck you, BaneBots. (I'll probably still buy your shit since it's cheaper than any alternative.)

Also, I refuse to use FingerTech's 16mm gearmotor (the one for which this wheel was designed). It just looks so dinky. The FK-050 motor and the flimsy-looking shaft are not my style. Aren't there any companies still making good robot drive solutions!? Oh yes...Pololu Robotics, where I got the motor controllers for both Twitch and Segstick. They have their own line of gearmotors now, too. And they actually don't look dinky.

Metal.

Flinch will use the 9.7:1 HP model, probably running 7.4-11.1V like Twitch. This would give it a no-load speed of around 10fps, even accounting for the √2 from the Mecanum wheels, and significantly more than its own weight in available traction force. Of course, this all depends on having two things: (1) a fast and powerful ESC, which I suspect will have to be custom, and (2) very good closed-loop control to keep it stable at high speeds. If I can meet those two criteria, I think Flinch will be amazingly quick.

Flinch will also be a little more durable than Twitch. By necessity, Twitch has outboard wheels, but this puts them in a vulnerable location. They also have wimpy plastic spokes that tend to crack when Twitch hits a wall, or when other robots attack Twitch for no reason. Since the Mecnaum set is a rather large investment, Flinch will instead have enclosed wheels, and they will be doubly-supported:

The addition of a tiny 1/4"-ID, 1/2"-OD bearing is easy, since the wheel bore is already just under 1/2". And the outboard axle is the same 1" standoff used to space out the two chassis plates. Simple. Nevermind that the chassis itself, with wheel wells cut out, is probably not rigid enough to make the structural loop meaningful. At least the wheel will look like it's supported on both sides. It's probably slightly better than nothing.

The chassis plates will be waterjet-cut, so the only real fabrication required are the motor mounts and outboard axle mounts. So basically, I could have a laser-cut prototype done some time this week...

...because clearly Designing and Manufacturing a robot with interesting System Dynamics and Controls is the best way to study for quals.