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!
