Tuesday, May 31, 2011

DirectDrive v1.0

"Hey Shane, why don't you build a larger controller that does more current?"
-Everyone.

Because...I...don't.....ok, whatever.


Rather than mess around with a new 3ph revision, I'm just going to start a brand new controller series, to try out some of the crazy stuff I've been wanting to try that's too risky to test on controllers I actually need. 3ph v3.1 works nicely at 40V and 40A. It's finally free of noise issues and has been running on Pneu Scooter for almost half a year now. But in the interest of satisfying some more demanding brushless motor applications, I'm shooting for 50V (DC) and 200A (peak phase current). So I'm going back to v1.0 and I will call this series DirectDrive...




...because it uses a crapload of DirectFETs. DirectFETs are one of the big things I've been meaning to try out on a motor controller. They're an International Rectifier proprietary package that eliminates plastic and bond wires in favor of...just...metal. It's about as minimalist a package for a power MOSFET as you can imagine, and in addition to low resistance due to increased die area, they can also get rid of heat more easily thanks to exposed metal cans that can be directly attached to a heat sink. 

They're also less than 0.7mm tall.
The particular part being used on this controller is the IRF7759L2TRPbF, a 75V FET with a typical on-resistance of 1.8mΩ. There are four in parallel for each leg of the three-phase bridge. The layout is one I've been thinking about for a long time that uses the DirectFET package (can) as a sort-of bus bar to augment the current-carrying capability of the traces and to jump the three phase outputs across the negative bus to the outer edge of the board:


It even looks like a three-phase bridge. The phases are arranged in three columns and the phase output is the giant strip of through-hole pads at the bottom edge of the board. All the high side FETs are connected together at the can (drain). There are traces that link them and the bus capacitors on the top of the board, but for the most part current will go straight through the cans themselves. Likewise, the phase outputs jump over the negative DC rail by way of the low-side FET cans. Conductive FET packages are like having an extra PCB layer to play with. Of course, the can resistance (measured to be about 0.15mΩ) will add to the total heat dissipation.

Here's what it looks like on the bottom.
One of the risks of using the DirectFETs that's prevented me including them on a controller so far is the fact that they are impossible to solder with an iron. The gate and source terminals are on the underside of the FET. IR has a 33-page app note entirely about how to reflow the DirectFET packages. I don't have regular access to a reflow oven, but this video convinced me that it would be possible to do with just a hot air station. I tried it out on one of Matthew's test boards, without the stencil, and it seemed to work okay. The measured resistance after soldering was about 2mΩ. How the array of 24 will behave, especially in terms of overall straightness and flatness post-soldering, will be an interesting experiment.


The reason flatness came to mind as a potential problem is because of the massive heat sinking requirement of this board. Even if it were 99% efficient, a 50V/200A controller would have to shed 100W somehow. The DirectFETs provide plenty of area for extracting heat, but we're still talking about the sort of cooling requirements you'd have in a beastly processor. So, what isn't pictured above is the sizable heat sink and fan that will be required to actually run at 200A for any extended period of time. For a quick burst, though, the 1/4" slab of aluminum will provide some thermal mass buffering. Between the sink and the FETs will be a 0.5mm silicone thermal interface material, to fill the gaps and isolate the sink from the electrically conductive cans.

This will also be, oddly enough, the first controller I've ever designed with on-board temperature measurement. I wanted to use a linear temperature sensing IC instead of having to calibrate thermistor curves, but they don't make one that would fit in the gap between the board and the heat sink...

...oh wait yes they do. The TMP20 sensor from Texas Instruments is a mere 0.5mm tall, making it actually shorter than the DirectFETs. On the board, it takes up less than 2mm x 2mm, which means it's basically invisible and probably very difficult to solder.

The thing next to it is a 0603 thermistor...
Because it basically doesn't even exist, I could put it in a tiny gap at the intersection of the high side and low side FETs on one of the phases. It will be in contact with the heat sink, and has a local ground plane to conduct heat into it. But it's so small that it probably instantly assumes the temperature of whatever it's touching anyway. It's also right next to the logic side of the board, allowing easy access for 3.3V, signal ground, and the analog output. Just in case it folds itself up into nothingness or explodes due to dV/dt induced nastiness, I put a 0603 thermistor footprint right next to it.

The power layout of this board was probably one of the most fun layouts I've done, ever. I had it basically finished a few weeks ago, after I converged on a very nice interleaved bus capacitor arrangement:


You might have to use your 3D imagination skills a little here. It jumps between layers a lot. The vias will need to be filled with solder to carry the full current, but I think that's standard practice for high power-density controllers. There are five 18mm surface-mount electrolytic capacitors on board for a total of 3300μF at 63V. The capacitance is high enough, but the ESR may cause problems running at 200A. External capacitance is not out of the question. Additionally, there are software games you can play to minimize the ripple on the bus capacitors in a three-phase inverter.

I have no idea how it will perform, but I also really like the way the gate drive escapes from the power section up to the top of the board. Crossing over traces under the capacitors frightens me a little bit, but it cleans the layout up nicely and I think gate signals are low-enough impedance to blast through any EMI issues. I think... 

Speaking of EMI, although the 3ph controllers since v3.0 have made good use of the IRS21844 half-bridge integrated gate drivers, I've decided to retreat to the comfort and safety of the optocoupled gate drive that I used in 3ph 2.1 and, the ultimate FET killer, Cap Kart. The idea is fairly straightforward:


Each MOSFET is driven by a gate drive optocoupler, formerly the HCPL-3120. The output of the gate driver is a push-pull driver that runs on 15V, either directly from a 15V supply (low side) or a bootstrap capacitor (high side). The input is just an LED. If the LED is on, output is driven high, if off, the output is driven low. The LEDs are connected in anti-parallel. A simple inverter and low-pass filter circuit ensures that a) both LEDs can't be on at the same time and b) there is a suitable delay between turn-off of one LED and turn-on of the other. This is passive shoot-through protection. Importantly, the logic side is entirely isolated from the noisy power side by virtue of the optical interface.

Switching four parallel IRF7759L2TRPbF FETs is a tall order for the 2.5A HCPL-3120, though. The total gate charge per FET is 200nC and the "switch charge" is 73nC. Even if the gate driver were operating at 2.0A for the entire switching period, it would take 4*200nC/2A=400ns to fully turn on or off the FETs. It's similar in switching effort to Cap Kart's half-bridge, but unlike Cap Kart it's being designed to run at 15.6kHz and has three phases.

This is not a happy gate drive.
Avago Technologies to the rescue. It's been a couple years since I browsed the gate drive optocoupler selection, and in that time a new, 5A version has come out. The ACNW3190 is more-or-less pin compatible with the HCPL-3120, and should be able to switch the four parallel FETs in a more reasonable amount of time. This will be the first time I'm trying them out, though.

There's one more "new" trick I am trying out, probably the most risky one of all. You may have noticed the odd, broken traces on the A and C phase:


And the islanded SOIC8 chip on the top layer. This is, in fact, an attempt at through-the-board Hall effect current sensing. The chip is a LEM FHS 40-P current sensor. Actually, it's more like a magnetometer, measuring field strength to the right, looking down on the chip. The traces passing under the chip produce a magnetic field according to the right-hand rule. 


I've use Hall effect current sensors before, but never a remote-sensing one like this. It is a little worrying because they can easily pick up stray magnetic fields. I've taken a few steps to minimize this: I used the A and C phases to keep them as far away from each other as possible. Also, all the power wires leave the board perpendicular to the current-carrying traces designed to be sensed. This way, they do not contribute to the measured field. Presumably, any static errors can be calibrated out, but there's also the potential for external fields from things with magnets in them, like perhaps motors. Of course, this would be a problem with regular Hall effect current sensors as well. Only one way to find out how they perform.

Oh yeah, I forgot to mention the purpose of the broken traces. The FHS 40-P is designed for, at most, 100A sense current through the board, with a single large trace running directly under the center of the chip. At the definite expense of resolution and the possible risk of lower noise immunity, I'm trying to sense an even larger current by moving the current-carrying wires farther away from the center of the chip. The broken traces can be selectively jumpered to "program"  the gain of the current sensor to my liking.

To improve the noise immunity of the current sensor signal Because I am too lazy to route the traces, the current sensors are actually connected to the logic side of the board via external three-wire cables, almost as if they were separate modules altogether. As an added bonus, if they don't work out, I could possibly use external current sensors anyway. Though in reality I would probably consider that a big enough failure to merit a v2.0 design revision. The two phase currents, as well as the Hall effect encoder and throttle signals, come in to the logic board via two rows of headers:


There's also an auxiliary current sense input which could be used for sensing DC current, as well as a spare analog channel. Differential voltage sensing is also available, though it comes in through a separate input near the bottom of the logic section. The logic board and power supply are the same as on 3ph 3.1, including the DCR021205 isolated regulator that saved the day last time. It will run my field-oriented control code for the STM32F103, so there shouldn't be any software surprises.

The entire controller is just about 4"x3"x1", or one standard EAGLE brick. (3ph 3.1 is an EAGLE half-brick.) The power to area ratio is quite high, which means that cooling will be a big challenge if it is to actually run at 200A. But even having a nice 100A continuous controller around will be handy, I think.

Board have been ordered. Actually, since it's v1.0, I only ordered one board. For some reason, my v1.0 motor controllers never seem to work. (And I know v1.0 of everything is usually not a complete success, but I'm talking about spectacular failures here.) So I'm not going to get my hopes up right away. But it's nice to finally be working on motor controllers again.

Saturday, May 28, 2011

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 SegwayCap 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.

Tuesday, May 24, 2011

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.

Sunday, May 15, 2011

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.

Wednesday, May 11, 2011

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.