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.