Archive for the 'SEGFAULT' Category


A Few Words on “The Segfault”

Apr 19, 2011 in Project Build Reports, SEGFAULT

Okay Make, I have an axe to pick and a bone to grind with you guys.

My experiences with Make Magazine and the affiliated blog have been extremely positive in the past. Everything from LOLrioKart to a certain 3D printer to even Fankart has been on the blog so far, and MITERS generally has contacts with people pretty closely associated with Make anyway, so just about everything we do ends up on there. But I have some pretty big reservations about the description of Segfault up there, in this month’s Make (volume 26). Basically the story is a few months ago I was contacted by a journalist for a quick interview about Segfault’s construction, which I obliged to. Now, I don’t blame John up there at all – I know that the guy knows his shit, and he’s in fact the person who puts alot of our stuff on the blog. So I think in this case, he was only reporting on information relayed to him. And boy was that faulty – so since the given address seems to link directly back to this site, I might as well open the valve a little, so to speak.

In a nutshell, those are all the fine little details that nobody cares about being treated as headline news. It has 9 inch scooter wheels!!! And GEARMOTORS!!! No, I’m not just bitter because the gyro and accelerometer functional description is wrong and I’m not sure how it was distilled from the description I gave it. No, what I’m really peeved about is the fact that

Segfault is analog.

That was like, the entire point, man.  Fact #1 about Segfault is always that it’s analog. Not a single line of code runs to keep the vehicle stabilized. Your segway runs on 14 lines of code, mine runs on op amps. Real op amps.  FOUR HUNDRED OP AMPS.

Okay, so more like 11. I think they’re starting to wear out and their gains need replacing soon, but OP AMPS!!!

The signal processing occurs in continuous time.

Instead of waterjetted aluminum chassis (which is nice and all), that line should read ANALOG!!!! I’m not particularly proud of the fact that it uses rudimentary and rather obsolete technology to accomplish the task, but the fact that it was one hell of a control theory learning experience, especially since the final build really occured over like 48 hours. Porting a transfer function to op amps!!!!! is about the closest you can get to just double-fisting the raw theory.

It doesn’t have an Arduino.

Or an ATMEGA chip, or a MSP, or a Cortex. Or anything for that matter. I guess the twin Class D switching amplifiers running the motors are kind of digital.

It also doesn’t work like that.

I’m not sure where the “gyroscope prevents the accelerometer from overcorrecting” bit came from, but it’s way more like the gyro and accelerometer complementing eachother and working in synchrony. In fact that’s so true that it’s even called a complementary filter. It’s a very common and simple sensor fusion algorithm, and if you actually want to know what one is, Segfault’s second most recent build post goes over why I use the two sensors this way in the Adaptive Face Forward Compensator.

Okay, that’s enough for now. Ya’ll should go build Segsticks. Maybe I should start writing for Make or something, eh?!

And now, for something completely different.

Jan 06, 2011 in Project Build Reports, SEGFAULT, Stuff

So, who’s going to be the first to do it on a real Segway?

Make-a-Segbearshark: Random Updates

Jan 04, 2011 in Done!, In Progress, Land-Bear-Shark, Make-a-Bot, Project Build Reports, SEGFAULT

With the holiday and end-of-year business shutdowns finally ending, the steady trickle of parts shipments for Landmelonsharkpigbeartankboard is flowing once again. I’ve finally gotten my trippy PCBs in for Make-a-Bot too, but haven’t gotten the chance to make the heat spreading plate and test it yet. Otherwise, I got Segfault running once again, now with its own enormously overkill battery.

Overall not much to say, so let’s just start with the grocery list.


LBS is still a pile of parts that has been steadily increasing in size. The materials needed to start the entire project off are the aluminum plates, which have yet to arrive. Otherwise, I have essentially everything – motors, motor-side sprockets, chains and links, the four shock bodies, a whole mess of stainless steel hardware, most other drive components, and this cute little contactor.

Here’s what the whole mess looks like right now…

Still on the way for whatever reason are three 24″ x 24″ x 1/4″ aluminum slabs. Other frame materials are used in small enough quantities to just be scrounged.

The design has been filled out with the requisite t-nuts needed to hold the panels together.

Some minor touches are missing, including places to mount the rider-sensing switches. The contactor and other major electrical components are also homeless at the moment. I also need to make the “second deck” of electronics which will handle tasks other than motor control. I did collect a model of the Giant Red Key Switch, and it hangs out in the back.

If I’m lucky, the metal will arrive tomorrow and the frame can be cut out by the weekend. That’s really the only hard part.

(Okay, minus the electronics…)


At last, the trippy PCB heaters!


I made one change from the version I keep linking to – there’s a center hole in the board so I can wedge a thermistor between it and the aluminum heat spreader. You know, so I can actually find out the temperature of the working surface. Otherwise, the trace resistance checks out (the squiggles on the bottom side in the design were put there in case they did not…) I’ll need to cut a single square of aluminum for the heat spreader. The aluminum will then be thermal-epoxied (not bolted or sandwiched) to the top of the board.

I got two boards, but will only prepare one of them for now.


Poor Segfault.

No, I haven’t completely trashed it yet again. It’s been working, but always became weak after 30 minutes or so because all I had in it were two of Überclocker’s packs. It would usually just fall over after an hour. So after the term ended, I swore I would make a new battery just for it such that I can reliably bring it out for demos. Naturally, with the ennui of the break, I felt unmotivated to do anything. Additionally, during an unfortunate scooter-organizing incident, the cable leading to the control knobs was sheared off, so it was just one more impediment and grunt-work repair job I had to tackle before it could even work again.

So maybe I did completely trash it. Either way, I guess it counts as New Year’s resolution to repair Segfault? I’m not sure.

Here’s where it starts.

Ah, another brick of A123 26650 lithium nanophosphate cells; here, being prepared and tinned.

Segfault’s completely empty right side was just begging for a brutally large battery. I measured everything out and found that I could easily fit a 5 x 7 cell array. Since Segfault already demonstrated operation on 7S (about 23 volts), I’d have to make a pack that had 5 cells in parallel. This is more or less a 146% \m/etalpaKkK. With 5 2.2 amp-hour cells in parallel, the total watthours count of this pack comes out to be around 250. It ought to be enough to keep Segfault running for two hours or more.

The enormous \m/etalbraid makes a return on this pack. Grounding braid is now my staple “battery bar”, as shown by the \m/etalpaxXx themselves and RazEr rEVolution’s pack (and the Clockerpacks, and the monstrosity I made for Cold Arbor). Segfault will never draw enough current to overload these busbars, but hey – maybe one day this thing will be repurposed. Have to plan ahead, you know.

Soldering is discouraged on cells like this because of the risk of melting the polymer separator close to the terminal, which results in bad. If you’re very fast and have a soldering iron with a large tip (high thermal mass, effective thermal bath), it’s definitely possible. I stuck to my 3-second rule here – once the joint starts melting, I count 3 seconds to smash it down and add more solder. Once that time is up, I immediately move on to another cell, and don’t return to that one until I’ve visited the rest of the pack.

It’s probably not very legit, but I haven’t overheated a cell yet…

After the whole pack got busbraided, it was time to add the wires. There’s three heavy-gauge wire pairs coming out of the pack this time. The two off to the right interface with the existing double battery connector in Segfault. There’s no reason to have a double connector in the thing, but it’s the way I originally made it to accept the robot batteries.

The single cable to the left is only used for charging. But I guess it could be a third discharge port if needed.

I ordered JST-XH connectors in several different sizes from Digi-key, so I was actually able to make a legitimate balancing harness.

Now the fun part begins: Packaging the whole thing.


So there’s no soda bottle big enough in this world (please prove me wrong) to swallow up 5 cell wide rows. The \m/etalpaxXx required a 3-liter soda bottle, and they were only 4-parallel groups. And while I could have planned ahead and ordered wide heatshrink tubing, that just doesn’t work with how I like to build these things – i.e. right now.

I did, however, buy a six inch wide roll of Kapton (Crapton, since it was from a Chinese ebay seller, and doubtlessly not real DuPont polyimide film) for Make-A-Bot’s future build surface. So I decided to just give it a try with finishing the packs up. With some cut up sheets of adhesive-backed foam rubber fitted on the cells for shock isolation, I wrapped the Giant Crapton around the whole pack several times in two separate loops. I think it came out great. The tape doesn’t really stretch, so it doesn’t look as “heat-shrinky”, and I wouldn’t say it’s waterproof. But it got the job done.

After a brief interlude to reconnect six little wires, Segfault is now once again attempting to kill innocent riders.

Segfault Re/BOOTED Part 3: How Seggfault is Formed

Dec 10, 2010 in Project Build Reports, SEGFAULT

The first part of this Segfault update, and the second, are linked herein respectively. Whoa… can I actually get back to building things now? The last state that Segfault was left in mechanically consisted of two stripped drive motors and a few banged up bits of sheet metal (well, and the loss of two “frame standoffs” on the right side).  Before I could use it again, I would have to replace those drive motors with something else.

The answer was found hiding in a closet at the MIT Edgerton Center. These are 27:1 Banebots P80 gearmotors, similar to ones formerly provided with FIRST kits of parts. The new P80s are pretty legitimate in terms of construction and materials used, and I rather like them. Only problem is, they don’t share the same mounting pattern as the KOOOOLmorgen pancake gearmotors. That was solved rather quickly with a waterjet-cut adapter plate made from frame scrap.

The hole that passed the Kollmorgen motors didn’t fit around the square diagonal of the Banebots. I got out the killing-head and opened up the circle another quarter inch or so. (That’s actually a boring head, but with that giant slab of tool steel mounted in there, it can only kill things and ruin livelihoods.)

A few selective spacers later and the motors once again drop into place in the subframe. Since the wheel hubs and shaft diameters match, I didn’t have to process the motors any further. And thus Segfault was pitched back together.

back to course VI

Two weeks ago (or thereabouts), I sent out the locked-antiphase/class-D motor driver H bridges to Advanced We’re So Awesome We Send You Free Food Circuits on the quick-and-dirty turnaround option.

They really are quite cute. I did these up all through-hole this time around because of component availability (no guarantees on finding all the SMT values and packages I needed in the rush schedule). I had a few IR21844 DIP chips left over, and they found homes on these boards.

Of course, every rush-sleep-deprivation-designed short-turnaround board is bound to have some kind of boneheaded mistake in it. In my case, it was accidentally switching the high side source (/half bridge midpoint) and the high side gate drive supply connections and not noticing until I wondered why my 15v gate drive supply was directly accessible through said phase midpoint. A few chops with a knife and then some Little Blue(and yellow, and purple) Wire followup fixed that.

I began putting together the new filter board alongside the motor drivers. This time, instead of using my custom 555 negative-5-voltificalator, I purchased some cool 24-to-15 volt DC/DC converter modules that gave isolated +/- 15 volt rails. Unfortunately, I found out the hard way that the LMC6484 quad op amps couldn’t handle a whole 30 volts across the power supply pins, so I ended up having to down-regulate both sides to +/- 5 volts. There is also a 3.3v LDO regulator just to feed the sensors.

Motor drivers temporarily hooked up for testing. Consensus: Yeah, I guess they work. Actually, it wasn’t quite that easy. Because of my isolated power supply on the front end, the gate drive chips couldn’t get a common ground between the input and output sides. I had to jump the “VSS” and “COM” pins on the 21844 to make them actually turn on. But wait… what on earth are those wires on the op amps?

I had to wing-jump +/- 5 volts to the LMC6484 on the motor drivers. This chip serves as the 21kHz triangle wave oscillator for the PWM outputs. Unfortunately, moving the supply rails way closer and changing the “divider” value together reduced the frequency to a paltry 6.2kHz. That’s the constant ear-piercing noise in the video.

Concurrent to the electronics assembly process was the repair of the control panel. Previously, this had been wired up to give voltages out at each of the potentiometers. Since the new controller needed the resistance of the pots to control the PI & K gains, I had to perform some air-wiring on the 10 pin cable.

After bench-testing the motor drivers, it was time to start hooking up the Serious Power wiring. I just reused most of what was already in Segfault for this one. The controllers themselves have already been super-professionally mounted using chunks of velcro.

The 100th build report of Segfault is a picture of me taking everything back out after checking for wire length and bench-testing the controller with all the gain knobs hooked up, on live power.  A small test motor was used initially since the power supplies could only push about 5 amps max, and the Banebots motors don’t get up in the morning for anything less than like 40. You can really see the difference between the AFFC and the old controller. Overall, the layout is much cleaner. Granted I did move alot of the H-bridge control circuitry onto their own PCBs…

With temporary Clockerpaxxx dropped into place. I’ll be making a more permanent 7 or 8S pack array for Segfault later. For now, the two robot packs run it just fine for about half an hourt of net run time.

And we’re ready to roll. We’ve already seen what happened after this. By the end of the day of demoing and test riding, I had taken out 2.1 out of the nominal 2.3 amp-hours in each battery. These things were toast – it was hitting the 18 volt cutoff of the DC/DC converter, so near the end of the day, Segfault would occasionally just fall over dead.

A1234 cells being amazing as always, they charged right back up to take in 2.1 amp hours…. at a rate of 9 amps


end of segfault

Well, not truly the end. But now that the project is demonstrably working, I’m ready to move on. I’ll be making the bigger battery pack and possibly making the control mounting more robust, but otherwise, I’m going to consider Segfault a (finally) finished tale after a year of head-scratching.

Segfault Re/BOOTED Part 2: The Adaptive Face-Forward Compensator

Dec 09, 2010 in Project Build Reports, Reference Posts, SEGFAULT

Alright, so this is the post that will drill into some details of execution surrounding the analog balancing filter on Segfault. By the way, the first test video is now linked here: either [Youtube] or  [MIT TechTV]. I don’t get paid by  either for references, so take your pick. I generally don’t like being pedantically academic (or perhaps even mildly), so there won’t be (many?) proofs, derivations, calculations, or simulations. Most of the description is intended to be conceptual – if you really wanted to learn the math behind something, I’m sure there are plenty of resources around the Intertubes that can help you out.

Two Sensors One Filter

The idea of the balance filter is to combine the reading from both an accelerometer (with its sensitive axis horizontal and aligned perpendicular to the wheel axis, and a rate gyroscope with its sensitive axis of rotation parallel to the wheel axis. The reason that this is done is because the two sensors respond optimally to two different kinds of input.

The accelerometer acts as a long-term stable reference, since gravity ultimately points downwards. However, because its sensitive axis is also in line with the direction of vehicle movement, any vehicle acceleration will tend to contaminate the reading, as illustrated by my awesome artistic diagram below:

In this diagram, I’ve roughly equated the rest output voltage of the accelerometer as the blue pendulum. During linear acceleration, the reading is distorted (purple arrow) and becomes inaccurate. Used alone, this sensor would report an “angle” even if the vehicle were completely upright. That’s just the best case – any vibrations, bumps, motor discontinuities like backlash; pretty much any vehicle movement at all outside of steady state velocity (accel = 0) will couple into the reading.

So accelerometers are useful if you’re not moving. You can build a Segway-esque vehicle with just an accelerometer, but it stands a chance of becoming unstable if it accelerates too quickly. Or at all.

On the other hand, the gyroscope will handily tell you how fast you’re rotating, but for very low velocities and zero rotational velocities (standing still), they will tend to report a small nonzero reading. This is DC error (zero frequency, since it’s zero movement-related), contrasted with the accelerometer’s “AC” error (induced by some nonzero input that may be periodic).

Therefore, you can also build a Segway-esque vehicle with only a gyro, but it’ll never stay still.

Combining Readings

There are already plenty of established “sensor fusion” algorithms that can take any number of inertial sensors and produce a reading that is the weighed sum of some combination of them. Some of those algorithms, like the Kalman filter (which this balance filter is not), can dynamically change those weights so the system has a sensor it comes to “trust” the most for any given situation.

The classic case for two sensors like the above, and one that is easy to implement in the digital world as about 2 lines of code, is the following:

  • Low pass filter the accelerometer input, and then
  • Sum it with the high-pass filtered time-integral of the gyroscope input. After all, integrating velocity gives position – angular or otherwise.

If I may cite Mr. DIY Segway himself, it’s “easier explained in code“:

angle = (0.98)*(angle + gyro * dt) + (0.02)*(x_acc);

Assume the above line of code runs every dt seconds – typically 0.01 or 0.02 seconds or something, for a 100hz (or 50hz, etc. loop). Then that line says “Combine the integrated gyro reading with the accelerometer reading, but let the gyro dominate the majority of the result”. In this case, the gyro should be used for 98% of the update each timestep. What this accomplishes is that it makes sure the accelerometer reading is sufficiently tuned out for anything that is not standing still. For anything but the act of standing still, the gyro is more trustworthy.

The astute will also notice that “high pass” means “blocking DC error” – this is required so the integration doesn’t rise to infinity as it continuously sums a very tiny but still nontrivial error.

That works pretty well for most cases in software.

But I’m not using software.

My problems with the first (few) Segfault filters came from trying port that line of code into hardware. You think porting between operating systems and programming languages is hard some times; try porting it to op amps.

Essentially, what ultimately doomed those filter designs to failure (despite some of the outputs looking good) is that ideal differentiation and integration is impossible to achieve in real life, and especially near “DC” i.e. zero frequency, which is the dominant regime in which a Segway-like vehicle operates. Op amps coupled to capacitative loads can start oscillating and becoming unstable, which was clearly exhibited by the previous designs.

What did I do to fix that? Well I tacked on more low-pass filter stages to “lower the peak to peak ripple”. Which only really caused more phase lag and made everything worse.

What is this? Like seriously… what did this do? I don’t even remember. It was all so painful. That isn’t even counting the actual op amps used in the PI(D) loop itself, nor the op amps used in splitting the drive signals into left and right.

Another Approach

Early on this term, I was introduced to another implementation of the complementary filter which was mind bogglingly simple compared to the ball of parasitic oscillation I made before. It appeared as part of a paper on teaching undergraduate dynamics and controls. The author K. Byl (nee Lilienkamp) described the analysis and design of several “plants” that demonstrated control theory, one of which was a “hardware” inverted pendulum robot. If you’re interested in reading the whole thing (it’s like a REALLY REALLY EPIC build report), it’s on MIT’s Internet publications cubby.

I’ll just knock some of the interesting parts out and put them here. First off, from p. 298, figure 6.15:

What can be observed is:

  • It’s just two low-pass filter architectures.
  • By algebraic manipulation, the top and bottom transfer functions sum to 1. That is the “complementary” part.
  • The inputs differ only by one time derivative (a single zero at the origin if we are considering s-domain) and have the same magnitude (e.g. 1 V / radian of tilt and 1 V/ radian / s of angular rotation rate)
  • The derivative path has a gain equivalent to the time constant of the filters

From a visual/graphical perspective, it’s helpful to refer to some Bode plots of the system.

The input variable θ does not have any time derivatives innately associated with it. Therefore, in the frequency domain, its transfer function is just itself. Its magnitude is a constant value across all frequencies, a flat horizontal line.When multiplied in the s-domain with the transfer function of a first order low-pass filter (the blue line), there is therefore no change, and the output has the same slope and break frequency.

The single-zero-at-zero (H(s) = s) is, on a Bode plot, a straight line from the lower left towards the upper right.

When this is multiplied with the first order low pass filter transfer function, it effectively “rotates” the whole plot about the break frequency.

Moving towards increasing frequency in the first plot, a positive slope times a flat line is a positive slope. And a positive slope times a negative slope is a flat line. This is the green line in the first plot. Summing the result is the flat line marked in red, once again showing frequency independence.

However, mathematical manipulation of the transfer function s / (tau *s + 1) with the low pass filter transfer function  1 / (tau*s + 1) will come up short of 1. To compensate for this, the derivative path must have a gain (constant numerator factor) of tau. The block diagram is complete.

What this told me is that as long as my accelerometer and gyro gave me the same magnitude of output, I could just low pass filter them with gain and then sum them together.

No AC coupling or extra integrators required.

my turn

Knowing this, I immediately turned my attention back to whipping up a workable, breadboardable circuit for Segfault. I’ve shown this kind of picture before, two build reports ago, but this is the latest version as-implemented in Segfault. It might be better to have the image open in another window, since it’s enormous for legibility.

For the netlabel challenged, it reads like a standard English book. Left to right, then to the next “line”.

Several important design notes emerge from the circuit:

  • Ignore all the power supply junk. That was for my reference when breadboarding the circuit.
  • I manually found the “volts per tilt” of the accelerometer board to be about 30mV per radian, using our slick MITERS adjustable angle block. The datasheet claims a sensitivity of about 150mV per g of acceleration… which is not correlated to the tilt sensitivity as far as I can tell.
  • The accelerometer therefore has a significant “pre-gain” factor applied to it during the offset subtraction process.
  • The gyro’s complementary filter has a gain equal to the designed time constant of 3.14 rad/s (0.5 Hz).
  • The PI stage’s integrator does not need the limiting Zener diodes. The reason, which I will explain in the next post, is that it turned out the LMC6484 op amps could not handle the +/- 15v logic rails. The intention was to make sure the integrator never hit the +/-15 volt rails, but with the rails on the actual board being +/-5, I’m satisfied letting it peg itself.
  • The “user inputs” are the knobs on Segfault’s upper control panel.
  • The output zeners are necessary since the maximum and minimum voltages had to stay within the roughly +/- 4.8 volt swing of the PWM oscillator (to be shown below). Otherwise, it would hit 100% duty cycle on at least one half of the H-bridge, resulting in bootstrap failure and a faceplant.
  • Oh, one more thing:

Sparkfun, why the TITS did you guys put a HIGH PASS FILTER on the LPY503AL breakout board? For very low frequencies, that’s an accelerometer, not a gyro. Is that why Segfault has never worked before? Seriously, why is that on there? Because the datasheet said “optional”? Sup dawg, I put an accelerometer on your accelerometer so you can do what exactly?! Dear Robot Jesus, how many people have you screwed over with that move?

Update: The new LPY5xxAL breakout board does away with the high pass filter! Yay!

Anyway, I removed the Rs and Cs associated with that high pass filter, and it’s been absolutely golden ever since. By the way, I have a few LPY503AL boards – they’re not bad, just… there’s this extra zero in the transfer function.

The locked antiphase H-bridge motor drivers remained… kind of the same. I’ll explain in the implementation and testing post later, but I had to Little Blue Wire a few parts of the circuit due to my own derpiness.


Wow, how did this turn into a technical paper?

Anyway, that’s about all the theory I care to go over. Segfault is currently running with a 0.5Hz complementary filter and a PI compensator that is primarily integral response dominated (high I, comparatively low P).

Next post: how is seggfault formed