How did you manage that? not check your measurements and angles twice? or are the gremlins messing with you like they do with me.. they take the wrenches out of my back pocket and put them under the seat of the racing mower.....
Frederic's Backbone Kart
- Thread starter frederic
- Start date
- Status
frederic
The Junk Man
Out of habit (long story) I leveled off the floor, which was fine when the backbone was actually level. Since there was about a week between cutting the rear suspension mounts and welding them on, the rear bottle jack had time to slowly become shorter, thus unleveling the chassis.
The last chassis I built was a mid-engined sports car chassis and I did all of that work on a leveled chassis table, so taking measurements from the table surface became habit.
that's okay, I can grind 'em off and reweld them. Just a pain.
The last chassis I built was a mid-engined sports car chassis and I did all of that work on a leveled chassis table, so taking measurements from the table surface became habit.
that's okay, I can grind 'em off and reweld them. Just a pain.
brendonv
New member
Any updates? Dieing to see this thing go.
frederic
The Junk Man
No updates that would be amusing. I've been engrossed in other things though over the past several weeks I've been picking up more gym equipment at the curbs to use as raw material. A friend of mine gave me a short garbage can full of 1" thin-wall square tubing which will be useful to build out the floor areas, seat mounts, that sorta thing assuming I have enough. Most of them are 2-3' long which is useful.
I did finish testing my homebrew motor controller on a small series-wound 12V motor and I'm happy with the results in RPM control, braking, and so on. I worked out most to all of the controller kinks and now it's time to pick out some big IGBT's to run the motor that's actually on the chassis (24v, 2-3HP, I forget).
Also figured out why teh Audi differential was "frozen". One of the bearings on the input shaft is full of rust and crude. While the rest of the diff was clean and oil-soaked this particular bearing must have ran dry for a long time because it's falling apart and wedged itself to make things "frozen". I got another bearing and haven't had the time to shove that in there yet either. I'm going to yank out all four bearings and grease them with a heavy, high speed moly grease often used on large trucks and not bother running oil of any kind in the differential. Since the kart will never weigh what an Audi A4 would weigh nor have the horsepower, I'm not expecting any kind of problem whatsoever if I pack them well before assembly.
Most of this past week has been spent installing 5 new servers in my basement. See, nothing too exciting.
I did finish testing my homebrew motor controller on a small series-wound 12V motor and I'm happy with the results in RPM control, braking, and so on. I worked out most to all of the controller kinks and now it's time to pick out some big IGBT's to run the motor that's actually on the chassis (24v, 2-3HP, I forget).
Also figured out why teh Audi differential was "frozen". One of the bearings on the input shaft is full of rust and crude. While the rest of the diff was clean and oil-soaked this particular bearing must have ran dry for a long time because it's falling apart and wedged itself to make things "frozen". I got another bearing and haven't had the time to shove that in there yet either. I'm going to yank out all four bearings and grease them with a heavy, high speed moly grease often used on large trucks and not bother running oil of any kind in the differential. Since the kart will never weigh what an Audi A4 would weigh nor have the horsepower, I'm not expecting any kind of problem whatsoever if I pack them well before assembly.
Most of this past week has been spent installing 5 new servers in my basement. See, nothing too exciting.
Randyf1965
New member
- Messages
- 2
- Reaction score
- 0
Spec on the controller? Schematic?
What do you use the server for? hosting?
What do you use the server for? hosting?
frederic
The Junk Man
Some of the servers I have host customer applications, not limited to but including websites. Other servers host applications that I "rent seats" to certain types of customers, whereas they pay per user per month. This is the first time in years I've actually had space in the rack. Previously both racks were full floor to ceiling and I had a pile of "development" servers and networks stacked next to it on a milk crate.
The controller will be able to provide 600A to the motor from the batteries, configured more or less as an H-Bridge. It's slightly different than most of the H-Bridge schematics you'll find in that the motor is not fully in between the four IGBT transistors, as the case of the particular motor I acquired is always ground (or battery negative).
The IGBT's instead reverse how the shunt coil is wired thus reversing the direction of the motor. Fairly straight forward. The 600A rating is based on the four IGBT's I have on my workbench.
I am at the present working out current sensing, temperature sensing, and emergency shut-down and/or pulse-width limiting for either condition, and those "features" are not in the digital version of the schematic. I have them scribbled out on graph paper and breadboarded on the workbench.
Control of the below circuit (plus the sensing features I mentioned above) will be controlled by a Microchip 18F4550. I selected this chip for several reasons:
- Available in a DIP package, allowing me to use a socket in case it bursts into flames and needs to be replaced.
- Built-in USB interface capability.
- Re-writable flash memory for programs, 24K in size.
- 2048K of SRAM for variable storage.
- Thirteen 10-bit A/D converters.
- Thirty-five bits of digital I/O.
- Easy to program PWM capability.
From the "overview" schematic below you will see four inputs - IN A through IN D. This follows a truth table:
ABCD
1001 - clockwise.
0110 - counter-clockwise.
0011 - braking.
All other combinations are invalid and should not be programmed.
One of the problems with IGBT's is they switch slower than MOSFET transistors, and there can be situations where opposite IGBT pairs can be closed simultaniously, allowing battery voltage to pass directly through the entire H-Bridge to ground - a short circuit. This is why power transistors of many kinds get so darn hot - this very brief instant where there's a direct short.
Since I am going to control this by software, in the PIC, I came up with a brain-dead simple way of eliminating this problem.
To move the motor forward, I issue a binary command of 1001 and repeatedly pulse that value at the correct pulse-width to achieve a certain speed.
When I want to brake, I would issue a binary command of 0011 but only after issuing a binary command of 0000 which shuts off all the IGBTs in the bridge. Whatever the transition time of the IGBT's are, that's the length of time I have to latch the 0000 command. In the case of the IGBT's I have, that's 325ns. To be safe, I would issue the binary 0000 command for 500ns instead of 325ns (safety margin).
Since the PIC has multiple A/D controllers, I have one attached to a variable resistor (potentiometer) for the throttle pedal position, and another one for the brake pedal position.
By having both pedals monitored by a variable resistance, I not only can have proportional speed but I can also have proportional motor braking as well, and will code some software logic to determine priority.
The first step is to read both pedals (10 bit, value 0-1024) and to remove jitter I'd shift both values left 2 bits, giving me an 8-bit representation of the two pedal positions (0-255).
0 = no action (1% pulsewidth)
255 = maximum action (99% pulsewidth)
Then, I would prioritize them.
if $brake > 0 then apply $brakePWM;
else apply $acceleratorPWM;
This would ensure if my son hits both the brake and the gas at the same time, the controller pays more attention to the brake pedal position.
There is some scaling of the values necessary, as a 1% pulsewidth does nothing, and in fact with this motor as much as 13% pulsewidth doesn't make it move from a standstill. If it's already moving it will adjust it's speed to that percentage of max so the controller has to take this into consideration. This also applies to braking, though at a different scale than acceleration.
So if my son is sitting in the car, not moving, and pushes the pedal half-way, for a 50% pulsewidth, for a brief instant the controller will apply 99% pulsewidth and as the car stats to move, it will quickly but smoothly adjust the pulsewidth from 99% down to 50% - the position of the pedal - before the motor reaches 50% of it's speed.
Things like this are much easier to "code" than to do with digital logic or analog circuits. The PIC having a USB port built in makes changing these kinds of settings that much easier - plug in laptop, netbook, or whatever.
Very nice - keeping it simple! Do you have an estimate for the costs of the parts of your controller? . What language is it programmed in - assembly, C, forth, ?... Any good tutorials out there?
Looks like a good winter project to play with - Thanks for sharing all these details.
Karl
Looks like a good winter project to play with - Thanks for sharing all these details.
Karl
frederic
The Junk Man
Keep in mind the above schematic is only the power section. There are some digital circuitry between that and the PIC, which I haven't put into Visio yet.
Programming the PIC can be done in many ways, C, Basic, Assembly and which you choose depends on your comfort level. I went with a C compiler (for PIC) because I only had one programming course back in my college days and it was a C class. I figured I might remember something, or at least hoped to. A lot of my code originated from stuff I've found through google, then modified to suit my needs. Here is one site that may help you get started, and I assure you there's no shortage of such sites on the internet if you google for them: http://tutor.al-williams.com/pic-intro.html
As far as costs, well, I am an avid eBayer so I carefully hunted for auctions without a reserve price and with few, if any, bids. I have a large programmer that has PIC, eprom, eeprom and other capabilities already and all it needed was a software update to handle this particular PIC (18F4550). The pic itself was a "free sample" under my business name, and the IGBT's were purchased as a set of six for about $100. They're Toshiba units and capable of 1200V @ 600A. Brand new they'd be a couple of hundred dollars each.
And yes, winter project indeed. I'm still monkeying with the toy version which is capable of a few amps, working out the ability to determine current draw, temperature, rpms and other important parameters.
There are a lot of ways to control a series-wound motor, and my approach is simple in some ways but obviously far more complicated than a relay and a footswitch. I chose to design build a true controller for several reasons:
1. I plan to scale this even larger for a true EV full-size vehicle so this ride-on toy for my son is not only a toy for him but also a learning tool for me.
2. I'll learn/re-learn analog electronics as well as digital electronics.
3. I'll learn PIC programming, as PIC chips seem to be able to solve many problems aside from motor controller issues.
4. It's fun!
Rolling my own also allows me to do (or try to anyway) exactly what I want rather than spending $2-400 for something already made that will do most of what I want better than I could make, but not have certain features I desire - like proportional braking and other such things.
The 18F4550 PIC is a powerful chip, and if you want to get into PIC programming you can start with a much simpler chip that has less I/O and is common enough where you can purchase experimenter boards with LED's, pushbuttons and a variety of other things to play with cheaply until you get the hang of it. I started with a 16F84 (I think) which I played with for a while before I ventured into a more powerful PIC. I got the 16F84 to blink LED's, vary brightness of a 12V car headlight, even play a monophonic "guitar solo" which I fend the output through a cheesy pre-amp and into a guitar amp, cranking the distortion all the way up. Varying the PWM makes for different tonalities and varying the frequency of the PWM changes the pitch. Add some silly coding and you have pitch bend, finger vibrato, and the like. I did stuff like this to learn how the built-in timers work as well as "off the web" PWM code.
Programming the PIC can be done in many ways, C, Basic, Assembly and which you choose depends on your comfort level. I went with a C compiler (for PIC) because I only had one programming course back in my college days and it was a C class. I figured I might remember something, or at least hoped to. A lot of my code originated from stuff I've found through google, then modified to suit my needs. Here is one site that may help you get started, and I assure you there's no shortage of such sites on the internet if you google for them: http://tutor.al-williams.com/pic-intro.html
As far as costs, well, I am an avid eBayer so I carefully hunted for auctions without a reserve price and with few, if any, bids. I have a large programmer that has PIC, eprom, eeprom and other capabilities already and all it needed was a software update to handle this particular PIC (18F4550). The pic itself was a "free sample" under my business name, and the IGBT's were purchased as a set of six for about $100. They're Toshiba units and capable of 1200V @ 600A. Brand new they'd be a couple of hundred dollars each.
And yes, winter project indeed. I'm still monkeying with the toy version which is capable of a few amps, working out the ability to determine current draw, temperature, rpms and other important parameters.
There are a lot of ways to control a series-wound motor, and my approach is simple in some ways but obviously far more complicated than a relay and a footswitch. I chose to design build a true controller for several reasons:
1. I plan to scale this even larger for a true EV full-size vehicle so this ride-on toy for my son is not only a toy for him but also a learning tool for me.
2. I'll learn/re-learn analog electronics as well as digital electronics.
3. I'll learn PIC programming, as PIC chips seem to be able to solve many problems aside from motor controller issues.
4. It's fun!
Rolling my own also allows me to do (or try to anyway) exactly what I want rather than spending $2-400 for something already made that will do most of what I want better than I could make, but not have certain features I desire - like proportional braking and other such things.
The 18F4550 PIC is a powerful chip, and if you want to get into PIC programming you can start with a much simpler chip that has less I/O and is common enough where you can purchase experimenter boards with LED's, pushbuttons and a variety of other things to play with cheaply until you get the hang of it. I started with a 16F84 (I think) which I played with for a while before I ventured into a more powerful PIC. I got the 16F84 to blink LED's, vary brightness of a 12V car headlight, even play a monophonic "guitar solo" which I fend the output through a cheesy pre-amp and into a guitar amp, cranking the distortion all the way up. Varying the PWM makes for different tonalities and varying the frequency of the PWM changes the pitch. Add some silly coding and you have pitch bend, finger vibrato, and the like. I did stuff like this to learn how the built-in timers work as well as "off the web" PWM code.
Excellent advice. Ebay here I come. I think I'll start with some simple power circuits with low amperage [cheap] IGBT's and old hardware (batteries, DC motors...) I have sitting around.
Are you using a dedicated PWM chip driven from your PIC or generating your own PW directly to the IGBT's?
Are you planning on any sort of feedback loop from RPM? Basically, commanding RPM/speed from your throttle position as opposed to open loop.
This is an interesting subject and I agree with your assessment regarding building a controller versus spending hundreds of dollars for a standard controller. To me, this falls into the category of "there must be a better way".
Karl
Are you using a dedicated PWM chip driven from your PIC or generating your own PW directly to the IGBT's?
Are you planning on any sort of feedback loop from RPM? Basically, commanding RPM/speed from your throttle position as opposed to open loop.
This is an interesting subject and I agree with your assessment regarding building a controller versus spending hundreds of dollars for a standard controller. To me, this falls into the category of "there must be a better way".
Karl
frederic
The Junk Man
When you're sizing your IGBT's make sure you "supersize" well above the motor's rating to ensure the IGBT's don't explode when exposed to the much higher inrush current of the motor. The 2HP series-wound motor I have draws about 550 amps to start, and from there draws anywhere from 57A to 375A depending on the speed and load. This is at 12V, the official voltage rating of the motor. This is why I went with 600A IGBT's - that rating exceeds the current drawn (550A) from the motor if I clamp it's shaft so it can't rotate.
The PWM is done in the PIC itself because this gives me control over two things - the pulse width of course, but also the frequency of the pulses. Series wound motors are generally driven best by pulse frequencies in the 4000-20,000 hz range. The lower the frequency the more efficient the motor will be, however it will be sluggish to change speeds and often times it will "hum". The higher the frequency, the more precisely you can control the motor but the cost is efficiency and in turn, battery life. After some experimentation I chose an 8,000 hz pulse frequency and will vary that between 1-99% to control speed. Because I'm controlling this with a PIC, I can make adjustments later on if those values do not work well with the motor attached to the ride-on toy. I'm expecting a difference in results between having the motor on the toy versus clamped in a vice with a brake rotor as a flywheel. Software control makes these changes easier.
Speed sensing is very easy to acheive using junkyard parts. Almost all cars found in junkyards these days have ABS sensors in at least the front spindles, and these are nothing more than a coil wrapped around a tubular magnet with one of the poles sticking out. As the teeth on the outer CV joint pass the sensor, it generates a low-voltage pulse, one per tooth. You can arrive at speed by counting pulses for a given timeframe or by measuring the time to count a constant number pulses. Either way, there's your motor speed.
I found that the Hyundai ABS sensors that I have are quite sensitive, and if I point them at the big sprocket that's attached to the nose of the vertically mounted Audi differential the teeth are big enough to pulse the sensor accurately. So I don't have to fangle up an ABS wheel with wider teeth which I was expecting to have to do. Time savor and I can mount the ABS sensor between the sprockets, pointing at the big one. I didn't get squat by pointing it at the small sprocket on the motor shaft, probably because the teeth are too close to the steel shaft, or maybe stray magnetic fields from the motor?
I'm not expecting to build a better mousetrap here, but the idea of a DIY approach appeals to me for the reasons I mentioned above - primarily the learning experience to which I can apply that knowledge gained to a much larger hybrid project.
The PWM is done in the PIC itself because this gives me control over two things - the pulse width of course, but also the frequency of the pulses. Series wound motors are generally driven best by pulse frequencies in the 4000-20,000 hz range. The lower the frequency the more efficient the motor will be, however it will be sluggish to change speeds and often times it will "hum". The higher the frequency, the more precisely you can control the motor but the cost is efficiency and in turn, battery life. After some experimentation I chose an 8,000 hz pulse frequency and will vary that between 1-99% to control speed. Because I'm controlling this with a PIC, I can make adjustments later on if those values do not work well with the motor attached to the ride-on toy. I'm expecting a difference in results between having the motor on the toy versus clamped in a vice with a brake rotor as a flywheel. Software control makes these changes easier.
Speed sensing is very easy to acheive using junkyard parts. Almost all cars found in junkyards these days have ABS sensors in at least the front spindles, and these are nothing more than a coil wrapped around a tubular magnet with one of the poles sticking out. As the teeth on the outer CV joint pass the sensor, it generates a low-voltage pulse, one per tooth. You can arrive at speed by counting pulses for a given timeframe or by measuring the time to count a constant number pulses. Either way, there's your motor speed.
I found that the Hyundai ABS sensors that I have are quite sensitive, and if I point them at the big sprocket that's attached to the nose of the vertically mounted Audi differential the teeth are big enough to pulse the sensor accurately. So I don't have to fangle up an ABS wheel with wider teeth which I was expecting to have to do. Time savor and I can mount the ABS sensor between the sprockets, pointing at the big one. I didn't get squat by pointing it at the small sprocket on the motor shaft, probably because the teeth are too close to the steel shaft, or maybe stray magnetic fields from the motor?
I'm not expecting to build a better mousetrap here, but the idea of a DIY approach appeals to me for the reasons I mentioned above - primarily the learning experience to which I can apply that knowledge gained to a much larger hybrid project.
frederic
The Junk Man
Not mechanical/welding work, no. Due to the holidays, work, and various other things I've only gotten 20 minutes here, 20 minutes there, where setting up the welder and hauling the kart outside wouldn't leave any time to actually do much.
frederic
The Junk Man
heh-heh, this isn't exactly well engineered either and just uses bigger parts. One of the problems with custom made one-off parts is repair/replacing them when they break. And they will. Everything does.
The problem I've had is the lack of time lately... when I started this project a lot of the work was done in the wee hours of the night and lately I've been "toast" around 10pm, barely able to keep my eyes open.
The problem I've had is the lack of time lately... when I started this project a lot of the work was done in the wee hours of the night and lately I've been "toast" around 10pm, barely able to keep my eyes open.
frederic
The Junk Man
Yeah, it gets dark way to quick. At the pace I was going I'd have the chassis done by now and would be working on the body, electrical and sourcing the remaining parts over the winter.
But I can weld in the winter months with my 500W worklight, I've done outside work like that before. Just not as frequently as the warmer months.
Nothing is worse than changing the clutch on an F350 crewcab, without a jack, while it's snowing, on Christmas morning.
But I can weld in the winter months with my 500W worklight, I've done outside work like that before. Just not as frequently as the warmer months.
Nothing is worse than changing the clutch on an F350 crewcab, without a jack, while it's snowing, on Christmas morning.
Rotore
Teh SPIK
i know what thats like.
Smurph
Code Poet
Fredric, if you have any extra servers, let me know!
I need an additional machine for some of my apps to run on. Some of the apps I'm developing need to run for weeks at a time and my Piece of crap a7n8x board just doesn't like that anymore.
Excellent job on the kart so far.
I need an additional machine for some of my apps to run on. Some of the apps I'm developing need to run for weeks at a time and my Piece of crap a7n8x board just doesn't like that anymore.
Excellent job on the kart so far.
- Status