Monday, September 24, 2018

TinyCross: Electron Herding Unit

My ultralight electric crosskart kit has arrived:

By "kit" I mean the water jet-cut plates and the 80/20 extrusion. There's still some custom machining to do, but most of the kart is designed as plate-and-standoff structure, so it does feel a lot like a kit build. I want to start putting it together, but also realize I am way behind on the electrical side and should get some PCBs on order before I really dive in to the build.

Since it's 4WD with independent motors, I want two dual controllers, front and rear. One of my first three-phase controllers was a dual layout, using IXYS GWM100-01X1 three-phase bridge modules. These modules have excellent cooling, thanks to their huge isolated heat sink interface that can be mounted directly to the chassis (with thermal paste). And while the GWM100-01X1 is undersized for this project, the newer MTI200WX75GD looks spectacular. So let's begin.

3ph v2.2: MTI200WX75GD High-Power Upgra...crap.

They're not available. Despite being in stock for a while, they seem to have disappeared. I mean if you want, you can still get one, but the big distributors have stopped stocking them and the little distributors are pains in the ass. Some day they will return, and I'll be ready for that day, but until then I need some other way of herding electrons.

Can I Just Stuff Some FETs Somewhere?

Sometimes having an extra constraint, even if silly, is good for making progress on things. It makes optimization easier by removing degrees of freedom. So in this case my silly constraint is that any alternative MOSFET configuration must fit entirely within the footprint of the MTI, so they could be swapped without changing the board design. 

I played with some DirectFET and Power SO8 layout ideas before settling on just one monstrous FDMT80080DC per leg. They're similar in many ways to the MTI, with comparable resistance, gate charge, and current ratings. They also have top-side cooling that, although smaller in surface area and not isolated, could sink heat to the chassis fairly well. Using just one per leg yields a tight and tidy layout that fits within the 12mm span of the eight MTI pads allotted to each phase. I've also left solderable tracks for adding extra conductors if needed.

Extending this constraint further, I decided the 12mm strips should fit an entire phase: FETs, gate drive, local capacitance, current sense, and output.

Copy-paste six total for a dual controller. A header in the middle eats current/voltage sensor signals and spits back gate drive inputs. The gate drive is the same one I use on everything: anti-parallel optos with dead-time RC. It's low part-count, easy to bootstrap the high side, tri-stateable, and guarantees dead-time in hardware. And as far as the microcontroller knows, it's just driving some LEDs. What more could you ask for?

Cross Karts, Not Current

For current sense, the ACS781 offers an impressively tiny 100A (150A peak) surface-mount Hall effect current sensor. The current sensing range can be extended by diverting some of the current around the sensor. I've had issues with nearby large currents coupling into small Hall effect sensors before, so in this case I've taken extra care to keep non-sense currents flowing perpendicular to the sensitive axis of the ACS781:

The sensors are aligned so that their sensitive axis is along the board X axis (left to right). Except for the sense leg, all nearby current is routed along the board Y axis (top to bottom). This is especially important for the sense and bypass current flowing immediately adjacent to the next sensor over, since cross-coupling is harder to deal with than a slight change in sensitivity on a single phase. Similarly, phase wires exiting vertically (Z axis) should not produce much field in the sensitive direction. Hopefully.

The Rest of the Panel

I've done separate logic/power boards for a while, but this is my first controller designed as a multi-board panel. In this case I wanted the power board, logic board, and two motor sensor boards all in one. OSH Park has a four-layer prototyping service by the square inch (no panelizing penalty), and some of the most beautiful-looking boards I've ever gotten have come from them. They do quantity three for everything, which is perfect since it gives me two controllers and a spare.

The logic board sits on the gate drive / sensor interface, with a single STM32 running the show. It turned out a lot denser than I thought. While it's more common to do a full schematic first and then layout and route, I tend to make nicer boards if I route as I go, doing a few nets at a time and planning the placement and pinout with the routing in mind. And sometimes you just get lucky and find an open path on the layer you need.

It's All So Clean Until You Add Wires

Since the dual controllers are on the kart centerline and the motors are in the corners, I need to run about 700mm of motor phase and sensor signal wires together to each corner, and I know how that story usually ends. I'll use shielded cable for the signal wires and try to keep them separated as much as possible, but I have a new trick to try for making the Hall sensor signals more robust. For starters, they will run through a buffer on the sensor side, to decrease the impedance. (Normally, they are just open-drain with pull-up resistors.) The real trick is on the logic board side, though, where they will be sent through this:

The signals are fed into a three-channel optocoupler, which means noise would have to be able to inject mA-level current into the signal to change its state. But the input side of the optocoupler also references only the phase signals, not a local or even remote ground. Common-mode noise, even on the order of Volts, can't change the state. It's a sort-of three-phase differential signal.

The Big Picture

It's been interesting to revist the idea of a dual controller. I'm honestly not sure how my first one worked at all, although I think the robustness of the IXYS bricks and opto gate drive helped me out a lot there. This one feels a lot more routine, and I'll consider it a success if it just works without any fuss, like Twitch X's drive. Speaking of Twitch X, there's a really neat consequence of independent front-wheel drive that might make for some interesting software parallels down the road...

Back to the build for now.

Saturday, August 25, 2018

TinyCross: An Ultralight Electric Crosskart

It's time for a new go-kart!

I'm going for something a little bigger and more capable than tinyKart, but with the same ultralight genetics. This time, the inspiration is from something I didn't even know existed until recently, called a crosskart. The best way to understand the appeal of a crosskart is just to watch this video:

Now, there's no way an ultralight electric version will be as exciting as that, but if I can get to an end result that's about 33% crosskart, 33% downhill racer, and 33% electric scooter, I'll be more than satisfied. So, here's the concept:

TinyCross chassis and single corner module.
The design follows the water jet-cut plate and 80/20 construction that's been my go-to for rapid and adjustable construction. There are still a few machined parts, mostly turned shafts, but a large portion of the chassis can just be "printed" on a couple sheets of aluminum.

The 0.25in aluminum plate components to be cut.
Long-time readers may recognize that I've switched over to new CAD software. The days of free SolidWorks are over, so I'm using Fusion 360 now. Rather than arguing with people about the best ECAD/MCAD software, I tend to just try the different packages until I understand their fundamental strengths and weaknesses. I've got maybe 100 hours in Fusion 360 now and the biggest difference to SolidWorks I've noticed is the assembly constraint framework: SolidWorks "mates" are refined, purposeful, and user-friendly. The "Width Mate", for example, is sublime. Fusion 360 "joints" are raw and don't inherently guide you to the good practice of constraining your CAD the same way as your real assembly. But, they have a general flexibility that I find very powerful and time-saving.

As I've done more and more projects, I spend way more time in the CAD than actually building. This design has been almost a year in the works before I felt confident enough to order plates. I'm still not sure it'll turn into exactly what I want, but here are some of the details that I have been working on:

Drive Module x4

Drive block with motor and brakes.
The powertrain is entirely contained in a ~4kg block that is repeated in each of the four corners. It uses the same motors as tinyKart, Alien Power System 6374-170 outrunners, but with different gearing for the larger 12.5in scooter wheels. With four of them, I expect around 8-10kW peak output. I've carried over the offset bearing  belt tensioner that worked so well on tinyKart. The brakes are the same as well, but I managed to fit the caliper in the middle of the belt loop to keep everything in-line.

Suspension and Steering

Front suspension and steering geometry.
Suspension separates a crosskart from a go-kart in my mind. I wanted something that can handle speed bumps, potholes, gravel, dirt, snow, and other surfaces that would (and did) tear tinyKart apart. Now, I don't have any experience designing vehicle suspension, so I took a reasonable first guess on the geometry but left room for tweaking later. The shocks are mountain bike air shocks, which are both very light and easily adjustable. The total suspension travel is about 5in.

Because the suspension takes up so much space, I wound up moving the steering linkage to the very front of the kart to make more legroom. This turned out to be a major headache since the Ackermann geometry is backwards. I was able to get back to a reasonable geometry by using a slightly more complex linkage. Minimizing bump steer from suspension travel was also an interesting new challenge for me.


Box chassis to add a little stiffness.
tinyKart's chassis was truly flat-packable, but as a result it twisted a lot. This actually worked in its favor somewhat, keeping all four wheels on the ground in lieu of suspension. But here, I was willing to go vertical and make a bit more of a box structure to keep the chassis stiff. Note that there are many stiffening spacers between the thinner bottom plates that I've left out of the model to keep the assembly smaller.

I still want to be able to separate the chassis into front an rear sections for transport with as few fasteners as possible. Removing the two side rails and then sliding the rear chassis out of the front chassis plate sandwich seems reasonable.


I've settled on motors and batteries (12S/20Ah LiPo), but haven't started any of the controller work yet. I'd like to do an update version of the 3ph "Duo" v2.1 controller, one in front and one in back, but based on the newer IXYS MTI200WX75GD-SMD, which is a pretty awesome little part. I need to run the math though, since the original design was never meant for these power levels.

I'm also planning a simple board for the steering wheel, to host a display, trigger throttle, and some knobs or switches for quick setup. Not sure how far I will dive into independent torque control, but I do plan to link everything together with CAN to leave that possibility open.

Power/Weight Budget

I'm shooting for about 34kg / 75lb for the kart without batteries. With the full 12S/20Ah it will be about 40kg / 88lbs. This is about 50% heavier than tinyKart, but still light enough to manipulate up onto a table to work on, or into a vehicle for transport. Plus, most of the weight of a go-kart is the rider, so with double the power it should have plenty of acceleration to spare.

Parts should be coming in this week so next post will have some real pictures!

Sunday, August 6, 2017

KSP: Laythe Colony, Part 1

A while back, I read a book called Seveneves, by Neal Stephenson, and found it to be immensely entertaining. The premise is that, for unknown reasons, the moon explodes and humanity has two years to get off the surface of the planet before the pieces crash into it. What I particularly enjoyed is that it's set in the near future, so we only have the tools we have now to work with. One of those tools is the International Space Station, which becomes the hub of a permanent space habitat. With no budget constraints and no point in risk aversion, a convincing amount of hacking manages to throw lots of hardware into space in a short period of time. And it falls on a few people to figure out what to do with all of it, since no viable long-term mission plan is proposed by ground leadership, who have other concerns. (Just go read it!)

You know who else has no budget constraint and no concept of risk aversion? The Kerbals! I decided a fun challenge would be to see how many Kerbals I can get off-planet in two (Kerbin) years, with the ultimate goal being to land them on Laythe and set up a colony. Laythe's atmosphere, while not directly breathable by Kerbals, has enough oxygen for jet combustion. And there is plenty of water.

Like, seriously a lot of water.
It's been a while since my Kerbals first carried out a mission to Laythe and back. Making a precision landing on Laythe's sparse, sand dune-covered islands was a challenge, especially with a top-heavy vertical lander. In order to establish a colony, Kerbals and equipment will have to meet at a single location on the surface of Laythe, so a better approach is needed. For the passengers, this means riding down on one of these:

This space plane uses four CR-7 R.A.P.I.E.R engines, hybrid engines that switch from air-breathing to closed-cycle at altitude. So, it takes off like a jet, builds up as much speed and altitude as it can, then switches to rocket propulsion to reach orbit. KSP's aero model was entirely redone for v1.0 and onward, making atmospheric flight both more realistic and more difficult. But this plane can still ferry six Kerbals into Low Kerbin Orbit (LKO) with a bit of fuel to spare.

It's also surprisingly sporty.
The Kerbals can't ride space planes all the way to Laythe, though. Well, they can if you build one like this. But I can barely get my six-passenger one into orbit so I'll need a more suitable living space for the passengers on the long cruise to Laythe. This led me to build my first true space station in LKO:

Finally a place to park all my space planes...
I wanted it to be modular and symmetric so it would be easier to add a propulsion stage for the long journey. This meant docking two space planes, and after some thought I decided they should be back-to-back to minimize the inertia on the long axis. (Any guesses as to why I would want to do that?) The planes are docked with two ports each for precise alignment and more rigidity.

The T-shaped station is actually launched into orbit in two pieces. The docking module attaches to the space planes, while the crossbar of the T is the main passenger module, where the Kerbals will ride out the long trip. The passenger module will become the hub of a much larger ship once propulsion is added on opposite the docking module.

Getting pieces this large into orbit is the work of a new two-stage heavy lifter.

No, the first stage is not recoverable.
The first stage is powered by five RE-M3 Mainsail engines, and includes all eight side-mounted fuel tanks and the bottom central fuel tank. The second stage is just a single tank and Mainsail. Together, they can hurl about 50t into orbit. Except for the space planes, every piece of hardware that goes to Laythe will start out mounted to the top of one of these ascent stages.

And there are many more pieces of hardware required to make the trip. The main strategy will be to send a crapload of unmanned stuff (rovers, habitats, and utility vehicles) to Laythe during the first launch window (~184d in) and then follow up with a fleet of passenger ships, based on the station above, during the second launch window (~1yr, 225d in). But, since KSP has added an element of realism in that unmanned craft need communications to be remote controlled, a network of relay satellites is also needed. All of this also needs efficient propulsion for the long leg of the trip.

More to come...

Sunday, July 23, 2017

Link Update (Again) and Bonus Link Trig!

Once again, all my documentation permalinks got broken when Google Drive stopped supporting static URL hosting. But, I've transferred everything over to AWS now and gone through updating links accordingly on all the static project pages and a few select posts, especially this one. Hopefully these permalinks last a bit longer! Here's the full directory: I may transfer more stuff over to there as I go, including maybe using it for hosting new static project pages. Still learning my way around AWS.

Speaking of links, here's an odd bit of trigonometry to solve last post's linkage mystery:

For Twitch X, I mentioned that rather than solving the trig for the geometry of the linkage that connects the two sets of diagonal wheels together (the sin/cos link, as I called it), I came up with a weird exponential parametric equation for the two angles:
x = [sin(θ1)]^K = 1 - [cos(θ2)]^K
The value x ranges from 0 to 1 as θ1 and θ2 both sweep from 0º to 90º, albeit on different trajectories. It makes an excellent feedback variable for the controller, since it can be derived from a simple weighted average of the two linkage angle sensors (after trig and exponent). And conveniently, x = 0.5 is where the wheel sets are perpendicular, for omni mode. For the link lengths used on Twitch X (L1 = 1.00in, L3 = 7.50in), I experimentally derived K = joke. But I wasn't ever convinced this was an exact solution, and as it turns out it isn't.

A few pages of trig later, this is the actual parametric solution:
L3*[cos(θ2) + sin(θ1) - 1] = L1*sin(θ1 + θ2)
This one's a lot less convenient from a control standpoint: since θ1 and θ2 are on both sides of the equation it's not obvious what to do with the wheels based on measurements of the linkage angles, at least not without further math. But this is the geometrically accurate solution.

What's amazing is how close the other parametric equation is. As it turns out, the max error is just over 1º and the value K = 1.23456789 is actually a pretty good one in terms of the average error over the full range from 0 to 90º:

None of this matters as far as Twitch X control software is concerned - the exponential approximation with θ1 and θ2 separated is still far better for the application. But solving the mystery of the sin/cos link was really interesting.

Thursday, June 16, 2016

Twitch X - Servoless Linkage Drive

I've got a new bot.

I'm not ready to call it 100% finished yet, but, most importantly, it drives!

It can pull off the trickiest bit of linkage drive maneuvering, Translation While axis-swITCHing, which proves it is possible to control all four degrees of freedom at the same time with just the four motors. That's a much better ratio of actuators to degrees of freedom than Twitch, Jr, which relied on two giant servos to steer the linkages. To steal a term from another Twitch, it's a "holonom-ish" drivetrain: able to fully control all three of its planar degrees of freedom, sort-of, in some cases, with an extra degree of freedom just for fun (and for generating more pushing power in a particular direction when desired). In reality, it doesn't have a practical advantage over some other drivetrains, but I've driven lots of different types of robots and this is by far the most fun.

I've Missed Going Home with Aluminum Chips in My Hair

The build was relatively quick and easy.

It helps when most of your parts are topologically similar waterjet-cut plates.
There were a few minor issues...can you spot the one in this picture? (Not the small linkages. Those are just from Twitch, Jr. for comparison.)
 The main actual fabrication required was making a few turned parts on my tinyLathe.

Poor tinyLathe.
These were the posts and keyed hubs for the wheels. The posts hold the thrust and radial bearings on which the drive units swivel. They're straight from tinyKart's steering system, so they should be very overkill for this robot.

Other than that, there was a just a lot of finish-drilling and countersinking. Oh, and some sketchy sheet metal bending that came out surprisingly well (using 5052 aluminum instead of 6061, for better forming properties).

The dimensional accuracy of the build wasn't quite as good as I was hoping, mostly due to lazy machining on my part. The top and bottom plate don't quite drop on with a satisfying zero-force slip fit, but with the bearings it really doesn't matter much. The main mechanical problem I ran into was not leaving any clearance for the rounded-off linkage ends to the inside surface of the motor mounting blocks. This led to a bit of binding that I thought was due to frame alignment issues but in fact was easily solved with a belt sander.

By virtue of careful design and forethought complete luck, I actually mitigated one of the biggest deficiencies of Twitch X over Twitch, Jr., the relative difficulty of changing out wheels. As it turns out, because of the way wheel closeouts are shaped, it's just barely possible to put on and take off a wheel without removing the top and bottom plates. This is a huge win because the top and bottom plates have the most hardware, the trickiest alignment, and are attached to the two linkage position-sensing potentiometers (so, taking them off would usually require re-calibration).

You might also notice the magnetic hubs. More on these in a later post, I think.

It's also possible to access most of the linkage shoulder screws from the wheel wells by rotating the linkages to different positions, so if one comes loose it doesn't necessarily require taking the whole robot apart to fix it. The center of the robot is also relatively accessible (for adjusting a linkage pot or soldering a motor lead, for example) thanks to the lack of giant servos in the middle and the fact that the battery and controller are outside of the central section.

It's so...empty.
The Mystery of the Sin/Cos Link

Where the two servos would be are just two potentiometers, one attached to each diagonal linkage. In Twitch, Jr., the diagonal linkages are independent, but in order for servoless linkage drive to work, they need to be tied together (to reduce the total number of degrees of freedom to four). I was a bit naive in naming the link that ties them together the sin/cos link, thinking that it just caused one to sweep out asin(x) while the other swept out acos(1-x), or something like that. The actual trajectory is not that simple.

If you can figure out the function f, you will win a cookie.

In what might be a first for this blog, I actually don't have an analytical solution for it. I'm sure one exists, but I think it would be a messy bit of trig. Through some random guesswork and not wanting to rename the linkage, I found that the following parameterization is very nearly perfect:
x = [sin(θ1)]^K = 1 - [cos(θ2)]^K
The exponent K is determined by the geometry of the linkage and can be found by fitting to CAD-solved angles. For Twitch X, it's somewhere around 1.23456789. (I'm not joking.) You can have an extra cookie if you can explain this parameterization and how the exponent can be derived from the geometry. I actually haven't worked this out. (For the purpose of verification, L1 = 1.00in and L3 = 7.50in on Twitch X.)

The parameter x is actually extremely convenient for controlling the linkage degree of freedom. It's easy to measure θ1 and θ2 using the pots, but it would be awkward to control one or the other. As the linkage sweeps through its range of motion, the sensitivity of the two angles to wheel rotation changes. Near the ends of travel, one angle is barely changing. By converting both angles to x and taking a weighted average based on the sensitivity, which is itself a function of x, a much better control variable is made available, one that ranges from 0.0 to 1.0 as the linkage degree of freedom sweeps from full forward to full sideways.

One other really nice thing about the parameter x is that at 0.5, the wheels are perpendicular. This is true for any exponent K. This gives a simple target for the linkage controller to get into the traditional diamond-layout omnidirectional drive configuration. Because of the weird geometry, the wheels are not at 45º angles to the chassis in this mode the way they were on Twitch, Jr. But, they are perpendicular to each other, which is the necessary condition for properly-constrained driving with four omniwheels. The driving coordinate system is actually rotated about 10º from the chassis at this point.

At x = 0.5, any exponent will give a linkage angle sum of 90º...very convenient.

I was mistaken in my last post when I said that it was possible to write a continuous mixer for all the in-between states that aren't linkage angle sums of {0º, 90º, 180º}, corresponding to the {forward, omni, sideways} driving. As it turns out these are all over-constrained and don't have a roll-without-slipping solution for wheel rotational velocity. (And I'm not talking about sideways slipping, I mean true tangential slipping.) So, I used a three-state mixer similar to Twitch, Jr. to handle the three driving modes. The pot-derived x parameter determines which state it's in. 

Twitch Drive

The quad H-bridge board I designed for Twitch came in and went together pretty easily.

I don't know yet if it's worthy of being it's own separate thing, but I really do like the layout and the modularity of the design. Besides the four H-bridges, there's some power conversion, an STM32F3 microcontroller, an MPU-6050 IMU, and headers for an XBee. The optocoupled gate drive works the same way it always does: without any drama.

Mmmmm, free deadtime.
The main issues I had were with relatively low-quality boards causing some soldering mishaps requiring blue wire micro-surgery. I've already ordered some spares from my absolute favorite board place, OSHPark, so if this one eventually dies I have some really nice ones to replace it. The board doesn't quite fit the way I wanted it to in the front wedge. It was supposed to mount vertically, but the capacitors and wiring take up too much space. I spent several hours trying to figure out how to modify the chassis to fit it either vertically or horizontally before I realized that I don't have to do either...

Yes, I felt stupid.
Since I'm only using the vertical gyro anyway, it doesn't matter which way the board is oriented. The extra trig just goes into the rotation controller's gain scaling anyway. Also, this mounting allows me to put some padding around the board to protect against impacts and vibration a bit more. The batteries will still go in the opposite wedge, and all the wiring runs in a tidy channel down the middle of the bottom plate.

Control and Controllers

As I mentioned, Twitch X has four degrees of freedom, all of which can be controlled independently by the four actuators. The "mixer" handles assigning wheel velocities based on the outputs of four degree of freedom controllers. In general, all four wheels are involved in each degree of freedom:

Driving forward and turning are the obvious ones and are the same as any other 4WD "tank steer" or "skid steer" robot. Driving sideways requires that the linkage be moved to the sideways position and then it's the same as driving forward (although two of the wheels have reversed their "forward" direction). Omnidirectional drive in the x = 0.5 "diamond" state also has a well-known mixer. The last degree of freedom is moving the linkage itself. This is accomplished by driving pairs of wheels against each other. (Which pairs depends on which way you want the linkage to move.)

Might help picture it...

Forward and sideways translation are easy enough to control manually, so the mixer just forwards commands for these directly to the correct wheels, depending on the linkage position. The other two degrees of freedom are much better handled by a closed-loop controller. For rotation, the vertical gyro is used in a feedback loop to control an exact rate of rotation, commanded by the driver. This helps keep the bot straight even if the wheels slip a little, and is crucial to this type of drivetrain. Likewise, the linkage degree of freedom is feedback-controlled off of the x parameter, as measured by the two potentiometers.

Everyone asks what the operator interface is like - I use a Playstation 4 controller with the following layout:

I don't know why I chose this layout originally, but I've been training on it since Twitch, Jr. and have the maneuvers all in muscle memory. The coolest tricks are ones involving all four degrees of freedom at the same time, like Translation While axis swITCHing, where the bot travels in a straight line but rotates and changes linkage orientations on the fly.

There are still some improvements to be made - I haven't gotten around to finishing the magnetic wheel hubs yet or really tying down all the loose parts and getting it ready to take abuse. But I also enjoy driving robots even more so than I do building them, so I couldn't resist doing some test drives of the new servoless system as soon as it was functional.

Friday, April 29, 2016

Twitch X - Did I used to be a MechE?

A combination of FRC season and BattleBots Season 2 got me thinking about how Saturday morning robot blitz building was a staple of my life back in the day, so I'm getting back into robots for a bit. I actually had a major "Battle-ready" redesign of Twitch, Jr. in the works a while ago, but couldn't really fit it into any sort of combat robotics framework and decided it wouldn't really be competitive without making major design sacrifices. That, and I got distracted by many other EE and software projects. Now, though, I've decided to try to remember how to MechE and go ahead and build it exactly the way I want.

There are actually at least three linkage drive robots named Twitch already. The OG version, which was my inspiration, was a 2008 FRC robot by Team 1561. There's also this one that I recently found. I can't find the documentation for it but it looks like it could be a mechanical relative of Twitch, Jr., with more modern electronics. And then there's this clever one (not named Twitch) that uses linkages and gears to achieve a similar wheel trajectory. Other than that I haven't seen any linkage drive robots; it remains a rare and uniquely entertaining drivetrain configuration. I've decided the world needs one more, so I present:

Twitch X

When I first drew up a new version of Twitch, I had in mind creating a wedge+lifter battlebot out of it. I made some rough geometry concepts for an Infiniwedge, which would be a wedge from every angle even if flipped over.

Get it?
This was a cool concept but of questionable competitiveness and legality in any particular league, and ultimately just too big to be practical. The footprint compared to the wheel placement just doesn't make sense. Also, even though it can vector traction into any pushing direction, omniwheels just aren't robust or sticky enough for a sumo match. And in any other type of competition the whole thing would just get exploded anyway. Linkage drive works fine with Colson wheels, if you ditch the 45º-angle omnidirectional state, but I think that would be too much of a compromise on what makes it a neat drivetrain.

I still like the idea of making a ruggedized, closed-wheel version of a linkage drive, though. That addresses the major failure point of Twitch, Jr., which is that if you hit something at high speed (which you will do), the exposed plastic omnis just break. When I break things, I have a habit of overdoing the next version a bit. With that in mind, here's a look at the new drive block:

First off, it uses the newer 4" Vex Pro omniwheels, which look to be much more durable than the previous version, made with fiber-reinforced plastic. These are designed for 130lb FRC bots, so I think they'll handle a ~20lb bot just fine. They're also completely enclosed by the chassis this time. To help increase impact tolerance, I'm attaching the wheels to the motor shaft via a magnetically-coupled hub.

1/2" disk magnets go in the pockets on the wheel and the hub cap. When attached, the hub cap soft-couples the wheel to the hub via the magnets (and friction). I'll probably stuff the inside of the wheel with something soft too so it floats, radially. The magnets should slip at around 20lbs of force, providing rotational and translational shock absorption but still allowing the wheels to break traction with torque to spare.

The gearbox is a Banebots P60 16:1 planetary, similar in size to what's on Twitch, Jr. But, Twitch X uses RS550 motors instead of 370s. Top speed should be around 20fps and it should be able to break traction at around 10A per motor. (So, plenty of overhead for pushing, if ever actually needed.)

The entire drive block rides on a radial and a thrust bearing set similar to what tinyKart uses for its steering. This means the whole bot sandwich can be properly preloaded without binding the linkage. In other words, I'm pretty sure I'll be able to bot-surf on it.

The linkages themselves have also been sized up, cut out of 1/4" plate and using 3/16" steel shoulder screws as pins (versus 1/8" plate linkages with 1/8" brass shoulder screw pins on Twitch, Jr.). You may wonder what massive metal-gear quarter-scale airplane servos are needed to swing these linkages. The answer is...none.

No Servos

While it's still a theory until proven in operation, I figured out some time ago that Twitch really doesn't need separate actuators to steer the linkages, which is great because the RC servos were the second most frequently broken part on Twitch, Jr. It's down to degrees of freedom and actuation. Twitch, being a holonomic drive in some configurations, generally has two translational and one rotational degree of freedom. But it has four independent actuators. There should be, then, one "extra" control mode that can steer the linkages if they're all tied together into one remaining degree of freedom.

As it turns out, this was how Twitch, Jr.'s linkages were originally designed. There is an extra linkage (or two kinematically redundant ones) that I call the sin/cos linkage, that ties the two diagonal wheel sets together. They don't rotate by the same angle - one follows a cosine, the other a sine, but they both go from 0º to 90º. I always considered this linkage optional, since with two servos to steer the diagonal wheel sets anyway, it didn't really do anything. But, in servo-less linkage drive, at least one of the sin/cos links is necessary.

The position of the last degree of freedom will be measured by one or two potentiometers mounted where the servos would have gone. This will go to a feedback-controlled output that gets mixed in with the other three degrees of control. All four control outputs can contribute to each motor's commanded speed through this mixer. It should also more smoothly handle all positions between forward and sideways driving, versus Twitch, Jr.'s discrete states.

Twitch Drive

Since there's only the four motors to control, I could probably have just gone with off-the-shelf H-bridge controllers like I did with Twitch, Jr.. But PCBs are cheap and Cap Kart taught me how to make indestructible H-bridges, so I just did that. I haven't updated the circuit in any way...I just find different ways to redraw the schematic.

It's the same H-bridge design that's running my Tesla coil, just with the normal-sized HCPL-3120s instead of the supersized ACNW-3190s, and normal FETs (IPB014N06 for this build). The optos are wired in reverse parallel with an RC filter, which sets the LED forward current and the deadtime. It's possible, with a logic inverter, to present each phase to the microcontroller as a single tri-state optical input, high for high, low for low, high-Z for off, with hardware-based deadtime. It really doesn't get any simpler...

I jammed the H-bridge module into the corner of board and copy-pasted it three more times.

Each H-bridge gets a pair of low-side shunt current sense through a differential op-amp as well. The FET thermal path isn't very good, but with good current control they should have no trouble driving RS550s on a robot this size with minimal heat sinking. In the middle is an STM32F3 (with its abundance of independent ADCs and Timers), an XBee, and an IMU for feedback control of the rotational degree of freedom (pretty much a necessity for linkage drive).

Parts are incoming just in time for a weekend robot build, I hope!

Wednesday, January 20, 2016

GS3 / Surfacecam GPU-Accelerated Preview

I've been further evolving the FlyCapture-based capture software for my Grasshopper3 camera system. This step involved merging in some work I had done to create a GPU-accelerated RAW file viewer. The viewer opens RAW files of the type saved out by the capture software and processes them through debayer, color correction, and convolution (sharpen/blur) pixel shaders. It was my first GPU-accelerated coding experience and I gained an appreciation for just how fast the GPU could do image processing tasks that take many milliseconds if done in software.

Some of the early modifications I made to the FlyCapture demo program were to reduce the frequency of the GDI-based UI thread, limit the size of the preview image, and force the preview to use only the easiest debayer algorithm (nearest-neighbor). This cut down the CPU utilization enough that the capture thread could buffer to RAM at full frame rate without getting bogged down by the UI thread. This was especially important on the Microsoft Surface Pro 2, my actual capture device, which has fewer cores to work with.

Adding the GPU debayer and color correction into the capture software lets me undo a lot of those restrictions. The GPU can run a nice debayer algorithm (this is the one I like a lot), do full color correction and sharpening, and render the preview to an arbitrarily large viewport. The CPU is no longer needed to do software debayer or GDI bitmap drawing. Its only responsibility is shuttling raw data to the GPU in the form of a texture. More on that later. This is the new, optimized architecture:

Camera capture and saving to the RAM buffer is unaffected. RAM buffer writing to disk is also unaffected. (Images are still written in RAW format, straight from the RAM buffer. GPU processing is for preview only.) I did simplify things a lot by eliminating all other modes of operation and making the RAM buffer truly circular, with one thread for filling it and one for emptying it. It's nice when you can delete 75% of your code and have the remaining bits still work just as well.

The UI thread has the new DirectX-based GPU interface. Its primary job now is to shuttle raw image data from the camera to the GPU. The mechanism for doing this is via a bound texture - a piece of memory representing a 2D image that both the CPU and the GPU have access to (not at the same time). This would normally be projected onto a 3D object but in this case it just gets rendered to a full-screen rectangle. The fastest way to get the data into a texture is to marshal it in with raw pointers, something C# allows you to do only within the context of the "unsafe" keyword...I wonder if they're trying to tell you something.

The textures usually directly represent a bitmap. So, most of the texture formats allow for three-color pixel formats such as R32G32B32A32 (32 bits of floating point each for Red, Green, Blue, and Alpha). Since the data from the camera represents raw Bayer-masked pixels, I have had to abuse the pixel formats a little. For 8-bit data, it's not too bad. I am using R8_UNorm format, which just takes an unsigned 8-bit value and normalizes it to the range 0.0f to 1.0f. 

12-bit is significantly more complicated, since there are no 12- or 24-bit pixel formats into which one or two pixels can be stuffed cleanly. Instead, I'm using R32G32B32_UInt and Texture.Load() instead of Texture.Sample(). This allows direct bitwise unpacking of the 96-bit pixel data, which actually contains eight adjacent 12-bit pixels. And I do mean bitwise...the data goes through two layers of rearrangement on its way into the texture, each with its own quirks and endianness, so there's no clean way to sort it out without bitwise operations.

This might be something like what's actually going on.
In order to accommodate both 8-bit and 12-bit data, I added an unpacking step that is just another pixel shader that converts the raw data into a common 16-bit single-color format before it goes into the debayer, color correction, and convolution shader passes just like in the RAW file viewer. The shader file is linked below for anyone who's interested.

The end result of all this is I get a cheaply-rendered high-quality preview in the capture program, up to full screen, which looks great on the Surface 2:

Once the image is in the GPU, there's almost no end to the amount of fast processing that can be done with it. Shown in the video above is a feature I developed for the RAW viewer, saturation detection. Any pixel that is clipped in red, green, or blue value because of overexposure or over-correction gets its saturated color(s) inverted. In real time, this is useful for setting up the exposure. Edge detection for focus assist can also be done fairly easily with the convolution shader. The thread timing diagnostics show just how fast the UI thread is now. Adding a bit more to the shaders will be no problem, I think.

For now, here is the shader file that does 8-bit and 12-bit unpacking (12-bit is only valid for this camera...other cameras may have different bit-ordering!), as well as the debayer, color correction, and convolution shaders.

Shaders: debayercolor_preview.fx