RazEr: The Aftermath and Beyond

Some time last year, I said this about RazEr:

It’s been hanging on a utility hook since the last controller fire. Everything works and the batteries are still charged, so all I need is a BLDC motor controller. Since everything still technically “works”, I don’t intend to touch the scooter that much, if at all. Any work on it will be replacing the shell of the wheelmotor with something more substantial (and better engineered, and more reversably built).

Well, it’s STILL hanging on a hook – almost a whole year now.

I can’t really remember when the “last voyage” of RazEr was, except that the hub motor was already on its way out. By that time, it wouldn’t even start from standstill and made ugly grinding noises when the controller finally did start it. The bearings were trashed, and I had filled the cavity between the wheel and motor can with hot glue so things would stay together.

After the motor just totally locked up one day, I put RazEr back on the hook and pretty much forgot about it. But since then, I had been slowly revising the motor design as a background process – when nothing else is on deck, I’d open up the model files and mess around with things.

I was specifically targeting a few shortcomings of the existing motor in the redesigns.

  • The tire should be removable without taking the whole motor apart. The existing version only had two solid end plates securing everything, and if I ever wanted to change the wheel, I would actually have to disassemble the motor down to the wound stator.
  • I should not have to modify the tire itself past just cutting the center out. The fact that the side plates were attached with through-bolts meant that I had to cut bits out of the rigid plastic rim of the scooter wheel. This made the wheel very floppy and nonstructural.
  • No more protrusions outside the can! Combined with the nonstructural wheel, it meant that the through bolts were used in heavy cyclic bending – this lead to them backing out, fracturing, stripping… everything.
  • The 6802 type bearings were wimpy and very underrated for the loads that the motor had to bear.

The last problem had to be held off until a complete blank-slate redesign because I could not otherwise recycle the core, including the stator, which had been designed around 5mm wide bearings and was well-epoxied in place.

The theme of the redesigns drifted towards some form of removable rings around the perimeter of the motor which retained the wheel between them.  I bounced around between two means of “removable” – either giant threaded rings:

… or radial screws, in the same manner that I would later execute on Deathrunner:

Threaded collars offer a way to actually tighten to the wheel – retaining it by compressive friction, but I consider threading a nontrivial operation. Additionally, there would still be a need to assemble the motor’s bearing endcaps that was nonpermanent, a difficult affair unless I either wanted to thread over crossdrilled holes or make the endcaps themselves an additional threaded mount. Either way, lots of threads, and lots of chance to bum it up.

On the other hand, some radially bolted collars are simpler to make, but don’t allow setting the ‘grip’ on the wheel – if i’m a millimeter short, then the wheel wouldn’t be actually retained under torque, and so on. They also allow easier installation or removal of the endcaps, as I saw on Deathrunner.

So what’s the decision here, then?

Well, an exact 50/50 compromise. On one side, radial case screws drilled into the magnet can (which is now much thicker and structural, and features a solid integrated collar) retain a bearing endcap. This is the “service entrance” since these parts are not permanently joined.

The other side features a removable threaded collar that mates with fine threads cut into the steel can. I included some spanner wrench holes to aid in tightening and removing. The bearing cap on this side is “permanent” – it will be aluminum, but slam-fitted into the can.

This was the design I settled on. It achieves a good balance of manufacturing convenience with serviceability.  Now I needed the stator out of the now retired motor. I disassembled RazEr to have a look at the motor insides after the failure.

Nothing prepared me for the utter horror that was the motor internals.

It’s already looking bad. Bent bolts, stripped threads and heads, and clumps of torn up urethane and hot glue debris.

Where’s the tire?

Oh, yeah. I had to cut that off because the screws were too broken to be extracted from the endcap, and the whole thing was probably friction welded together by now.

I finally knock one endcap off with a large screwdriver and mallet and

AAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHH

What HAPPENED?

The entire interior surface of the motor was completely caked in some black powdery mess. It looks like something either got inside, or otherwise managed to interfere with the stator-rotor airgap, and subsequently got ground to bits.

This probably explained the inability of the motor to start from standstill because of the massive friction.

Through some investigation of the surface conformity of the magnets, I discovered these two loose and displaced magnets which bear clear scraping marks. The black powder is probably corroded magnet bits – both dust from their ceramic bulk and the nickel-copper plating. There’s probably stator steel particles involves also. Rust on the interior tells me that water got into the motor, probably from riding around all winter.

The motor casing, after separation.

I feared for the stator’s integrity, but it was electrically sound  – no burns or broken wires. The loose magnet had carved a very impressive gouge across half its thickness. The uniformity of this gouge tells me that the magnet has been dragging like this for a very long time.

Seriously – that’s a wear pattern you usually see on DC motor commutators.

The damage isn’t permanent or serious, so the stator will be reused.

Alright, so usually this is where I make about 4 build reports detaining every minor machining step in the process of making this thing. But I think we’ve heard enough about day to day machine technique, so I’ll start saving some words and just show the interesting steps.

I got up one day and decided to just blitz everything in one shop spree. I got most of the way there, too.  The components above are “protoforms” – they don’t have holes drilled and tapped yet, but the basic shape of the motor is done and the threads have even been cut into the motor can!

Making the can’s  3 1/4″-24 GYF (Girl You Fine) thread went quicker and was less disasterous than I had anticipated. Fortunately, my toy indexable cutter set came with a carbide tipped threading tool. Regardless, the finish left alot to be desired. I ended up running a needle file through the threads to clean them up – otherwise, the steel appeared more liable to tearing and smearing than.. cutting.

I suspect it’s just a matter of technique, though. That and tool quality – something mitr0nz lacks a bit.

Hurrr. A bit.

Making the threaded external collar, though, was a adventure in a first. I had to make internal threads that had to mate with an external one.

A long time ago, I anticipated eventually having to deal with this problem (or was just tool shopping) and picked up some internal threading tools, both left hand and right handed. I finally was able to whip one out and use it on the aluminum threaded collar.

Here they are, the most hideous threads known to man.

Actually, they are not that bad. Aluminum machines like a blaze with carbide, and most of the gunk in the threads is just particles mixed in cutting oil.

And the motor can screws on!

I decided to leave the inner diameter a little loose. This made the collar wobble slightly on the motor can, but I figured that while removing metal is always easier than putting it back, trying to line up the lathe’s leadscrew and threading feed with something it already made is not so easy.

A bit of shaping and parting later, there was a threaded collar.

And the collar threaded onto the can…

And everything test-fitted together.

After making sure the fits were correct, I put in the new motor magnets. They are SuperdupermagnetGeorge‘s M2515. For all your stock and custom magnet needs, see Supermagnet George. He’s supplied the mags for literally ALL the motors I have ever built, including the customs for Deathrunner!

There are very few magnet arrangements that yield an almost 100% fill with flat magnets, but somehow, during the builds of this motor, I managed to hit two already. 28 magnets complete a circle in this redesigned can with a gap the size of a few stacked sheets of paper left over!

It could have been totally closed if I had machined the can just 0.005″ smaller.

With the motor assembled, I cored out my last 125mm scooter wheel.

And here is the motor in the test fixture, ready for a whirl. I ended up being too lazy to actually put fastening features on the ring, and ended up just cranking it with a set of vise grips.

I can’t say that I’m satisfied with the machining tolerances (there’s a very small amount of wobble and the bearing fits are suboptimal), but that’s what I get for blitzing everything.

Read more “RazEr: The Aftermath and Beyond”

SEGFAULT Update 8: IT’S ALMOST THEEEERRRRRRREEEE

Hey Charles, what ever happened to Segfault?

You know, that scooter you were building? With those sensors and shit? That one with the big saw blade…. or was that your robot? Or whatever else you’re building?

It is true that Segfault was sidetracked so I could start on Cold Arbor. I suddenly felt the urge to revisit Segfault again after a lull in the parts shipment schedule for Arbor. I wanted to get at least something done by the end of IAP. It’s probably also wiser to get Segfault out of the way so I can continue work on Arbor with no other project distractions, right up until Motorama 2010.

And so I pulled Segfault out from its corner behind LOLrioKart. In the few weeks that I have neglected it, the MITERS industrial grunge fairy had already deposited a fine layer of her dusts and particles of unknown origin all over the frame. In the last Segfault episode, I finished the wheel hubs and got the vehicle supporting its own weight … to the extent that a Segway-like vehicle can without any electronics, that is. Essentially all the mechanical aspects of the vehicle were done.

Except one.

I had always just hand-waved the steering column’s mechanical detail, telling myself that I’ll take care of it when I get there. After all, how hard can it be to rig a few springs to keep the column centered?

Turns out the answer was very. The control box weighed several pounds, and it was on a lever of nearly 4 feet. So, I couldn’t find springs stiff enough at MITERS to provide a strong enough return force such that the whole handlebar assembly didn’t just become a severely underdamped harmonic oscillator. Design negligence played a part in this, because I didn’t even design in any provisions for mounting springs of any sort – just a hole in a piece of 80/20.

Hello, attention to detail.

Anyway, that was part of the reason for my ditching of Segfault. I moved onto Arbor while solutions to the centering problem slow-cooked to completion. The idea I ended up settling upon was using small gas springs, discovered while virtually rummaging the nether regions of Surplus Center.

I ordered these as a curiosity along with some sprockets and chain for Arbor. They are very basic bidirectionally damped, rod mount gas springs.

Alright, so how was I going to mount these? Because I didn’t design in any mounting provisions for actuators, I had to adapt around what existed in the Segfault frame. I decided to use the gas springs in a triangular arrangement, with the rod ends meeting at a single point on the column and mounted to two points on the longitudinal (front-to-back) rails next to the bearing blocks.

I DOTF’d these mounting “clips” for the piston body end out of aluminum bar. The width of the channel is the width of the longitudinal rails, and the depth just a little more than the thickness. These just slide onto the rails, and the downward force of preloaded gas springs keeps them in place. No further mechanical retention is needed.

Here they are installed. The column mounting point is provided by a shoulder screw and a convenient 80/20 channel nut, so I didn’t have to drill the extrusion.

A better view from the other side. I can’t just drop the gas springs in their fully extended position onto Segfault, because one side of the triangle must necessarily get longer as the column pivots about the base. So they had to be preloaded.

No way was I going to just tighten them down while holding onto them, so I enlisted the help of a bar clamp to squeeze the gas springs a half inch or so.

I needed to cut away a small piece of the top plate in order to clear the new gas springs in both directions of swing. So, feeling the lazy bug, I took a bandsaw to my Shiny Precision Waterjet Machined top plate. It *ALMOST* looks like I designed it that way to begin with!

Almost, meaning “wow, what happened here?”

On the same pass, I opened up the square hole that the column protruded from so I could quickly remove the top plate.

The Continued Tale of the Hardware Balancing Controller

Overall, SEGFAULT’s controller has three major components besides the Class D power amplifier that will drive the motors.

  • The complementary sensor frontend, which reads the angle of tilt of the vehicle
  • The PID compensator block, which attempts to hold the angle signal to zero
  • The steering controller, which creates a speed (voltage) differential from the single output of the PID controller and passes it to the two motor drivers. This differential allows the vehicle to turn.

I’ve already explored #1 pretty thoroughly in updates past. An uncomfortably high portion of this entire venture is me firing into the dark and seeing what happens. I don’t have a solid background in the EE side of things, especially not in the hardware, so the whole thing is one big learning adventure. I think I have gotten the complementary sensor rig working reliably enough to continue.

The next longshot of the project is the steering controller. To steer a Segway-type vehicle, the wheels have to rotate at different speeds. A steering controller would have to take the speed command being sent to the motors and superimpose a differential between the left and right sides.

Let’s hit all of these one step at a time. Here’s the latest wiring nest, labeled for convenience.

A. Version 4 of the Complementary Sensor

Documented in Update 5. It uses a MEMS accelerometer and rate gyroscope in unison to yield a roughly linear function of voltage and tilt angle.

B. Negative-5-voltificalator

A charge pump type circuit to create a -5 volt power supply rail for the op amps.

C. 30kHz Main PWM clock

I made a simple oscillator using a 74HC14 Schmitt Trigger inverter chip. This creates a 30,000Hz triangle wave that is centered roughly around 2.5 volts, with a peak-to-peak of roughly 1 volt. It will be the clock signal from which the motor driver signals are generated.

There’s no need to use such a large chip for exactly 1 function,  so I will probably hand this off to a 555 or something.

D. PID Input Level Shifter

The main control loops on the sensor board use a symmetric +/- 5 volt power supply with 0 volts being “straight up”. To be compatible with the rest of the logic, it needs to be turned into something between 0 and 5 volts, positive. Assuming the signal itself stays within the bounds of +/- 2.5 volts, which it should barring extraordinary circumstances (keeping in mind that the PWM triangle wave will only span 1 to 2 volts total), just adding 2.5 DC volts to the signal will take care of things.

This is done with a simple inverting summation circuit.

The arrangement is unity gain, so it’s just PID_INPUT + voltage at the pot. If the PID input is centered around 0 volts and the pot is set to 2.5, then the new center voltage is 2.5 volts.

But wait… why is that -5 volts going to the potentiometer there? I thought the point was to make the output positive?

Because this arrangement of components creates an inverting summer, if I just feed it + 2.5 volts, then the output will become -(2.5v + PID_INPUT). So the hackaround for this is to feed the circuit -2.5 volts, such that the output is -(-2.5v + PID_INPUT), which is to say, 2.5v – PID_INPUT.

This adds 1 layer of inversion to PID input which I’ll have to compensate for elsewhere. Or perhaps it will cause the system to feature the correct number of inversions again? Who knows…

E. The Differential Signal Generator

This is where the now level-shifted signal is split into left and right channels. With 1 potentiometer (eventually to be mounted to the handlebars), a small voltage is either added or subtracted to the motor command to generate two slightly different, but symmetric commands.

The potentiometer has inputs at +5 and -5 volts, making “center” 0 volts. Using either a unity gain summer or a unity gain subtractor (only slightly more complicated than swapping inputs on the op amp),  the voltage at this pot is superimposed onto the 2.5 volt centered motor command.

Thus the vehicle can spin in place assuming otherwise perfect balance (2.5 volt command), as the left and right channel motor commands would be, for example, 2.6 and 2.4 volts, or vice versa. If the pot is exactly centered… well, nothing happens. 2.5 +/- 0 is still 2.5.

This is why I like having symmetric power supplies. Zero is zero… is zero, which is zero.

F. +2 Comparators of PWM Generation

This is a fairly conventional PWM generator using the intersective method. The aforementioned triangle wave is fed into both comparators, while each individual one receives either the left side or right side signal.

So what the heck is “STP”? Besides “Standard Temperature and Pressure”, it stands for shoot-through protection. H-bridge drives need some form of this to prevent the top and bottom switches in each half from conducting at the same time, which leads to Bad Things happening. This was securely drilled and bolted into my head in 6.131.

Essentially, the STP circuit will force a delay between the top and bottom switches changing states. There are a few ways of doing this in hardware, most of them involving a bunch of inverter gates and diode-shunted low pass filters.

Huh?

Just plug this:

$ 1 5.0E-6 0.27182818284590454 46 5.0 50
I 272 288 352 288 0 0.5
w 272 176 352 176 0
r 352 176 416 176 0 1000.0
r 352 288 416 288 0 1000.0
c 416 176 416 288 0 5.0E-8 4.009206304089476
w 416 336 416 288 0
w 352 288 352 336 0
w 352 176 352 128 0
w 416 128 416 176 0
R 176 176 112 176 1 2 1000.0 2.5 2.5 0.0 0.5
w 176 176 176 288 0
I 416 176 496 176 0 0.5
I 416 288 496 288 0 0.5
p 496 176 544 176 0
p 496 288 544 288 0
g 544 176 544 224 0
g 544 288 544 336 0
d 352 128 416 128 1 0.805904783
d 352 336 416 336 1 0.805904783
w 272 176 176 176 0
w 176 288 272 288 0
o 13 1 0 38 8.183476519740355 4.8828125000000005E-155 0 -1
o 14 1 0 38 5.0 9.765625E-5 0 -1

into here. Observe the square wave pattern – never do the top and bottom square waves go HIGH (which would translate to switches turning on) at once!

In the course, I combined the triangle wave generator and STP for a single half bridge (two signals) into one 74HC14. The STP requires 5 inverters and the triangle wave only one, and the 74HC14 is a 6-inverter chip . But, this time, I will need two STP circuits, since I have two sides of the drive to deal with. Nothing special will happen – I’ll stick with what I know for now, and just use two 74HC14s.

Speaking of the two H-bridges, here they are!

A neat little design using the same IXYS half bridge driver chips that I bought for LOLrioKart’s last motor controller.

So how do I control 8 FETs with what amounts to 2 square waves? Locked-antiphase PWM is the secret. Each gate driver controls diagonally opposed FETs instead of two in the same half-bridge. To change the direction of the motor, I merely select the other gate driver. Locked Antiphase PWM is essentially doing this rapid switching of motor direction in complementary duty cycles.

If this complementary duty cycle is symmetric, i.e. 50/50, then the motor will remain still.

If it is off balance, e.g. 75/25 or 25/75, the motor will rotate with half maximum speed.

If the duty cycle is more like 99/1, then the motor will run very near maximum speed.

The final breakdown of the “digital” part of my analog controller is something like:

  • LEFT_STP and RIGHT_STP are “master duty cycle” commands, directly affected by the angle of the vehicle and my steering command input.
  • The STP circuit for LEFT_STP will create an inverted, slightly delayed version of itself. Let’s call this LEFT_STP’. Same goes for the right side.
  • LEFT_STP controls two diagonal legs of the left H-bridge, and LEFT_STP” controls the other two.
  • Hence, the diagonal legs will swap on-times with eachother, rapidly reversing the motor back and forth at 30,000hz.
  • Varying LEFT_STP and RIGHT_STP duty cycles will therefore cause the drive motors to spin.

Now that I’ve written the 1000 words, here’s a VIDEO!!!!

Some things to note about the video:

  • The controller itself was too tied up in wires to actually show on screen.
  • The two square waves are LEFT_STP and RIGHT_STP.
  • They grow and shrink in unison if I rock the controller around.
  • They grow and shrink oppositely if I turn the steering potentiometer.

I haven’t actually implemented the STP circuitry yet, or the actual PID part of the PID controller. Currently, a wire bridges the output of the sensor and the input to the level shifter. I suppose that amounts to a P of 1, I and D of 0.  So what you see on the screen is essentially 1:1 with what’s coming out of the sensors.

Left to go are prototyping the PID stage and the STP circuitry for both sides, then putting the entire mess onto some perf/vector/strip/veroboards! The Inaugural Faceplant draws ever closer!

AAAAAAHHHHHHHHHHHHHH WHAT THE FUCK IS THIS SHIT