Archive for the 'SEGFAULT' Category

 

Why are there Segfault?

Dec 09, 2010 in Bots, Project Build Reports, SEGFAULT

Is a point to it?

More details on the execution to come…

Segfault’s page is here, but the technical description is not yet up to date with the current iteration. It’s mostly still true, though.

SEGFAULT Re/BOOTED Part 1: The Cyclic Tragedy of the SEGFAULT

Dec 04, 2010 in MIT, Bostoncaster, Cambridgeshire, Project Build Reports, SEGFAULT

Pop quiz: When was the last Segfault update?

Answer: It was almost a year ago in January.

As of a few weeks ago, Segfault looked like of like this:

Poor Segfault.

The abridged version of the story is that I stopped reporting on it shortly after the project ran into electrical demons and the gyro-accelerometer filter completely did not function as anticipated. Several more attempts, each getting increasingly desperate, were made during the Spring 2010 term and over the summer. But sadly enough, none were successful in getting it to balance or remain remotely stable, and Segfault has been sitting in a corner at MITERS for the past semester. However, it’s slated to make a comeback…. right freakin’ now…. and hopefully will be somewhat functional this time around.

Let’s start at the beginning.

january

After putting together the final iteration of the balance controller, I started bench testing the locked-antiphase H-bridge drivers.

Yeah. That worked well. I blew out gate driver chips in rapid succession for seeming no reason at all. The FETs were also changed out a bunch of times as they seemingly latched up and shorted. It wasn’t the deadtime/delay circuit at fault – something else was killing the drivers.

I got so desperate that I began putting the FETs themselves in removable sockets. Damn the current processing ability – I was just going to pop them in and out as they died or became questionable, in the interest of problem solving.

When one power-on seemingly killed the entire dead-time circuit, I gave up for the month of January and finished Cold Arbor for Motorama 2010.

I now know that probing the ungrounded high side drivers with a grounded oscilloscope probe was the most likely cause of the latchup and destruction.

april

In April, I signed up to exhibit at the HKN Project Expo. Pursuant to this, I decided to Just Rig Something to see if Segfault would remotely function. I yanked the two Dimension 25A controllers from Cold Arbor and set them to run on 0-5v analog input mode, which was compatible with the signal that the original H-bridges wanted. The Dimension boards didn’t allow any more than 24 volts input (originally slated to be 36v), however, so I pitched some NiCd packs that I had just standing around onto the thing.

The verdict? Yeah right.

The response was extremely poor, even with all the gains set to the highest possible. Segfault would start out balanced, but be unable to stay at that position and entered very high amplitude, low-frequency oscillations (effectively driving forward and backward). As I later found out, this isn’t just due to weak motors or weak motor drivers. Regardless, it wasn’t worth demoing…

So I just brought it as a sculpture.

may

After not looking at Segfault for several more weeks, I decided to take the Victor HV controllers out of Arbor (which by this point was a parts-bot) and try running the whole 36 volts to see if the response would be any stiffer.

Besides switching at only 100 Hz (and making a massive racket using Segfault’s hollow shell as a resonator), the Victors also demanded a digital input signal.

And so I sank yet another level.

Stop judging me.

By this pointed, I just wanted a balancing vehicle, dammit!

This board was thrown together, and some sensor-reading code freelanced, in a few hours.

An IRL screenshot of the Gory Details.  The Arduino read in the user gains and steering pot angle and processed them together with the two sensored readings. A complementary filter (a real one, as I later discovered), i.e. my entire two breadboards full of parts (which really isn’t one), is like one line of code.

It was nearing the end of term, and I wanted to just get this thing out of my sight (and mind) for a while. This version of Segfault was the closest it had ever come to working – I think I managed to stay on it for 2 or 3 whole seconds. But to get there, it must have kicked me in the shins at least 10 times. It was also very angry and would occasionally completely lose all control and accelerate wildly into something, or at least until it just fell over.

The falling over part destroyed the handlebar panel and broke several of the precision pots inside. So that was the end of Segfault for a while. Back into the corner it goes…

july

On A Midsummer Night’s Eve, when I was waiting on parts for the RazErBlades, I decided to take another crack at the thing. The Arduino controller was horribly hacked together the first time, and didn’t really incorporate the important part of the vehicle – which was the functioning Degrees gauge.

First order of business, however, was to fix the user interface panel. I found some matching 100K 10-turn potentiometers to replace the broken ones. The wiring was made cleaner by the use of a sacrificed VGA cable instead of a billion different twisted pairs.

I rebuilt the Arduino board with some actual forethought this time around so it incorporated all the pins and inputs I needed.

And here it is, the degrees gauge functional for the first time!

Too bad nothing else was. The test video pretty much says it all.

No matter how the gains were tuned, Segfault was prone to high frequency oscillations this time. It was too twitchy, or perhaps the sensors coupled too much of the motion back into the control loop.

The spark seen in the video was a portion of the battery pack heatshrink wearing through because of the vibrations, briefly contacting the metal frame at two different potentials. It was inconsequential. Unfortunately, the rapid forward-and-reverse gunning of the motors stripped out both of the precision spur gearboxes.

With the forced termination of that test, I decided to just write off Segfault and revisit it yet another day.

now

Mechatronics.

The synergistic combination of Mechanical engineering, Electronic engineering, Computer engineering, Control engineering, and Systems Design engineering[1], and also a really cool class here at MIT, designation 2.737. You should take it if you get the chance.

Basically, my assessment is that it’s everything I should have learned in my undegraduate controls courses (It’s actually a grad-level class, since MIT enjoys watching undegraduates torture themselves by taking G-level classes).

As such, I now know what a real analog complementary filter is. Referencing this paper by K. Byl (nee Lilienkamp), I’ve designed a new balance filter for Segfault, the Adaptive Face-Forward Compensator. I’ve also summoned the 21844 gate drivers and my now full-blown addiction to PCB design to create a new locked-antiphase Segtroller.

The major difference this time? I’m actually finishing SEGFAULT as a part of the grade for this class. This shit just got real™.

Here’s the sneak-peek.


The complementary filter and analog signal processing backend

The locked-antiphase H-bridge, each driving a single side

So when’s this due? Wednesday.

By that I mean a few days from now, and between now and then I also have to make sure that 2.009 doesn’t end in utter disaster.

Onwards Adaptive Face-Forward Compensator!

SEGFAULT Update 8: IT’S ALMOST THEEEERRRRRRREEEE

Jan 22, 2010 in Project Build Reports, Reference Posts, SEGFAULT

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

SEGFAULT Update 7: The Hub of the Universe

Dec 15, 2009 in Project Build Reports, SEGFAULT

You can’t have drive wheels without hubs. Before I slinked back to Atlanta for two weeks, I wanted to get Segfault at least off the ground on its own two wheels. I have yet to actually lay out the control electronics or devise a way to center the steering column.That will probably happen after I return, since I’m not taking all of MITERS with me (but I’m guaranteed to, given the opportunity, trust me.)

To make large wheel hubs, you need large chunks of metal.

Which I have plenty of. The hubs were designed on the fly and are made from a 3″ diameter round of aluminum. I quickly popped off the basic shape and external features on the MITERS Old Mercedes (so called because of its completely beat-to-shit but flawlessly reliable nature) before transferring to the mill to drill the bolt circle.

Here’s an idea of the fit. After putting in the bolt circle, I took a trip over to the Formula SAE team shop and borrowed a keyway broach. The KOOOOOOOOOOOOOOOOLmorgen motors have  a 1/2″ keyed shaft, and I figured that using the existing keyway was better than hacking my own solution, or keypepgging.

No design of mine is complete without a Giant Set Screw. So here it is, sitting directly over the keyway. I discovered that the Bridgeport spindle has enough rotational inertia in low gear to crank a 1/2″ tap through half an inch of aluminum just by coasting.

That is why I am dismayed by “miniature” machine tools.

The wheels bolt on and…

AAAAAAAAAAHHHHHHHHHH

IT’S BALANCING ITSELF!

No, just kidding.

Here’s a view of the drive wheels, as featured in an earlier episode of Charles’ Amusing Non-Academic Distracting Adventures (CANADA). There is no additional support past the motor shafts, so here’s hoping those KOOOLmorgen motors have really stiff bearings.

Alright, so this thing isn’t really any good without handlebars to hold onto. At this point, I pulled out a diversionary project that I embarked on a few weeks ago to explore new means of lazily putting together pieces of metal.

The handlebars, just some pieces of 7/8″ diameter bike frame tubing, are attached. Hey, what’s that holding them on there – are those fillet welds?! Did MITERS finally get a TIG welder?

Has Charles finally broken down and welded something together, knowing that some times, sturctural integrity is more important than the ability to be easily disassembled?!

No, and yes. I remembered the existence of low temperature aluminum brazing solutions and decided to give it a run. The most promiment label in this field seems to be Durafix. Basically, the alloy rod is a high aluminum-content zinc material that melts at around 750°F and flows over bare aluminum metal. You’d heat the metals to be joined to greater than 750 degrees, higher seemingly better, then rub the rod over the joint to break the oxide layer. Using a stainless steel wire brush and abrading the joint results in better flow because the oxide layer disintegrates under mechanical pressure. The process is flux-free.

I have a hard time coming to terms with the no-flux part, but have also been having trouble finding high temperature (700+F) aluminum soldering flux. The vast majority seems to be designed for lead-tin soldering of aluminum which occurs at lower temperature. Whatever. The dude in the demo video could do it, so I can do it, right?

I saw that McMaster listed a similar “zinc-aluminum solder” in their catalog. I’m a stickler for instant gratification, and McMaster is about as close to instant as I’ll get this stuff. It came in a tube, in the form of bunch of 1/8″ diameter rods.

Leap of faith! Using my newfound joining abilities to put together random pieces of scrap aluminum, I discovered that…

  • You really need to get the parts HOLY FUCK HOT. After sufficient heat is applied, the stuff just sort of flows itself across the joint without much assistance. The problem is the HFH requires a massive heat source, and much time (like sitting there holding the torch for a minute or two), and so far, my torching ability is only limited to small or thin parts. The 1/8″ thick pieces took forever.
  • It seems too viscous to “wick” into tight joints, at least without the help of flux. It’s great for fillet and butt joints, but I don’t see it filling the entire inside surface of, say, a lap joint.
  • No, it’s not welding. There’s no mixing of the alloy with the parent aluminum, unless you melt the aluminum. Then you’re doing it wrong.
  • No, using a soldering iron doesn’t work, not even if your soldering iron is 15″ long, has a copper tip an inch in diameter, and has a 300 watt heating element. Clearly it just needs overvolting.

With that established, here’s the joint on the control box!

Eww. This is probably the most obnoxious overuse of the stuff on the planet. It looks like more of it got on irrelevant surfaces than in the actual joint. I think I dumped at least a third of a rod onto this thing.

What made it worse was that I didn’t have a good set of wire brushes. I totally wrecked two cheap plastic ones because… well, once the stainless wire gets hot, they just sort of melt off.  To do this right, I’d need a good set of wood or metal handled brushes.

As I hinted at before, the tab-and-slot construction of the control box itself is *very* amenable to this type of unwelding.

That looks MUCH better.

I did a few things differently on this joint. I thoroughly sanded and brushed down both surfaces so there is minimum surface oxide present. I held the torch to the pieces for about two minutes, and made sure the whole joint was evenly heated by moving the torch around. This was tested just be pushing the rod against the joint to see where it melted the easiest. Then I added the alloy kind of like how you’d add filler metal to a TIG joint (slightly hard to describe past “poke-swirl-move-repeat”) .

The process was repeated for the inside joints. I made sure that there was metal holding onto metal on both sides of the control box (i.e. it’s two fillets, not just a butt joint).

That worked substantially better, and it was without in-process brushing. Still a bit globbier than I’d like it, but that’s something which gets better with practice.

Completed control box!

I’m very satisfied. Time will tell how my crazy unwelding job holds up.

Alright, it’s glamor shot time!

Yes, this picture is totally posed. How’d you know?

And one more, showing the SHIIIIIIIIIIIINY aluminum top plate.

SEGFAULT Update 6: The Impending WHEE-SPLAT Gets Closer

Dec 05, 2009 in Project Build Reports, SEGFAULT

With the balancing circuit prototype demonstrating consistent and non-glitchy angle indication, I’m picking up the slack on the mechanicals. Work continues with the frame being fully assembled, motors mounted, and the tilting handlebar essentially finished! I’m now just missing the handlebar tubes themselves and some big chunks of aluminum to carve the wheel hubs out of.

Things are on track for the Maiden Faceplant some time in early January. Meanwhile…

When you make fancy waterjet-cut puzzle frames, you shouldn’t forget, like me, to lay out the fastener holes that will put them together.

In this case, I accidentally the front and rear structural screw holes. So it was back to the old center punch and caliscribing, followed by some quick drill press work. Manual fabrication… can you imagine that?

While I had the temporarily-fastened frame taken back apart to drill the new baseplate holes, I decided to fill the empty motor cages with motors. The KOOOOOOLmorgen motors are sandwiched between the two rails, mounted on both ends for maximum load carrying ability. I need high stiffness in the motor mounts because of the single-supported axles.

Rinse and repeat for both motors. After adding the requisite hardware, I should not have to fiddle with the bottom structure ever again. At least, until something breaks.

In this image, the “pillow blocks” for the tilting handlebar are already mounted in place. Said handlebar assembly will pivot at this location a few degrees to either side, and the rotation will be read by a potentiometer and translated into a differential motor speed to let the vehicle turn.

The pivot pin is a 1/2″ steel rod with a milled flat to position the handlebar and an axial center hole to couple to the feedback pot.

By pure chance, I managed to select a piece of 1/2″ alloy or tool steel. What a total bitch to machine – I had to break out the carbide to mash through it- but the shaft took on an almost polished appearance after a run through with 1000 grit sandpaper. I guess that’s why they grind tools instead of mill them?

The complement to the above is a single 40″ stick of 80/20 structural extrusion, the 1″ flavor. Conveniently enough, the extrusion has a center hole that is the correct diameter to be tapped 1/4″-20. This meant I had a set screw attachment solution practically ready to go.

To interface this with the pivot pin, I just crammed a 1/2″ cutter through the extrusion from one side to the other.

A view inside. Visible are the pivot pin (kinda…), its +2 Set Screw Holes of Potentiometer Retaining, the 80/20 handle stick, and some spacers. A big cap screw is cranked down the center hole to lock the pieces together.

Another view of the assembly. I need to come up with a way to spring load the stick such that it tends to center itself. I actually couldn’t scrounge either 1) two matching springs or 2) stiff enough springs or 3) springs of a workable physical dimension, so a hardware store run will be made in the near future.

Without the centering, I’d have a hell of a time actually trying to operate the thing.

On the other end of the handle stick is the control box. It’s retained by a single cap screw, threaded into the 80/20 center hole. This isn’t particularly structural, but… it doesn’t need to be. Right?

The control box will never have to support the full vehicle weight, or any number over, right?

Right? :(

Oh, the 4 perimeter holes don’t serve a mechanical purpose – they are only there to pass wires through. They are at the same distance from the center as the cavities in the 80/20 X profile, to encourage clean wiring.

Speaking of the control box… I finally got my SHINY ALUMINUM KNOBS from my most recent favorite Sketchy-ass Ebay Electronics Dealer (SEED). I purchased a grand total of 20. They’ll be useful for future knobbery, but Segfault only needs 3. The other Big Knob was scrounged. Besides the knobs, the same order brought in a handful of multiturn trim potentiometers and a stack of single-sided protoboard.

So the user interface is now complete, with exception of the power switch. Can you find the power switch? I can’t either right now, because it doesn’t exist, but the ultimate goal is to hide it in the most obscure location possible, characteristic of older electronics equipment (designed by engineers rather than product designers, I imagine). For instance, all the MITERS oscilloscopes have their power switches integrated as a small selectable section of the scale illumination & beam intensity knob, hidden amongst the other knobs.

Here I am trying to think of some dastardly way to make the zero adjustment screw on the degree-o-meter the main power switch.

Okay, enough is enough – here’s where SEGFAULT stands (LOL PUN) as of today.

Missing: things which herd electrons, wheels, and handlebars. And cool glowy lights.

I’ll be making the wheel hubs soon, hopefully out of one of my “stock” hugeluminum billets. The handlebars are easy – they can be just about any steel or aluminum tube. I should at least be able to stand on this thing and practice static balancing soon. Then it’s back to the electronics!

Here’s a “global perspective” picture  showing the proportions of SEGFAULT in relation to other things in MITERS. It’s a good 4 feet tall without wheels.  The handlebar position will be higher than real Segways, if nothing else but to lessen the sensation of standing on a pogo stick.

MORE TO COME!