I have an intellectual dilemma, on creating algorithm for traction control module. Approximately I have:
700hz front approx 100kmph
430hz rear approx 100kmph
And twice as many pulses (interrupts) in the processor ... Let the processor run at 8MHz or 16MHz if necessary (the same as in VEMS v3)...
So, if I count the pulses per second, I would have each measuring 1 second late... This is not usable for TCM...
If I measure the time between 2 pulses, around 0.7ms, there will be an error in recalculation of the time in the speed will be greater...
What I thought was to measure the duration of 10 or 50 pulses... This would come in the time of 7ms or 35ms... Delay of 35ms for TCM electronics is not so bad, and the error would have been 10 or 50 times less then measuring only one pulse...
Or combine all those undergarments like every 0.1s, measure number of pulses, and meassure last pulse that didn't complete?
BTW, at 16MHz, 1 clock stroke is less than a micro-seconds, so I think that the processor must be fast enough to do 4 wheels and an algorithm for reducing the torque...
How does VEMS measure speed of a wheel or a speed of a engine? ???
Count the teeth using the "time between n teeth" method and use a Kalman filter to smooth the speed. A simple alpha filter with short memory would be sufficient.
N could even be 1 using this method because you will average out the timing errors.
The error when converting time into a speed could be great in my opinion... And ATmega128 doesn't have hardware divider...
Does anybody know how VEMS do it?
Quote from: mr_g on February 18, 2010, 05:41:49 PM
The error when converting time into a speed could be great in my opinion...
That's why you smooth it with a sensible filter!
Let's assume you count clock cycles between wheel teeth:
If you use software interrupts on a processor running at 8Mhz, there are 11428 full clock cycles between wheel speed teeth. It is unlikely more than a handfull of cycles will go "missing" between cycles. 500 clock cycles is only 4% at this speed, and at slower wheel speeds it is a considerably smaller percentage.
I doubt this will cause too many problems with errors.
And if you're worried then have an "association test" as part of your filter - eg limit the maximum amount the wheel speed can change between sample windows, or simply throw the sample you suspect away and "coast" the last good speed.
IMO analogue electronics could be less compicate:
http://www.national.com/ds/LM/LM2907.pdf
and then back to desired frequency (if necessary) with
http://www.national.com/mpf/LM/LM231.html#Overview
I used a LM2917 for my TVR tacho. They work pretty well but noise may be prove to be an issue in some applications.
Quote from: dnb on February 19, 2010, 02:10:24 AM
If you use software interrupts on a processor running at 8Mhz, there are 11428 full clock cycles between wheel speed teeth. It is unlikely more than a handfull of cycles will go "missing" between cycles. 500 clock cycles is only 4% at this speed, and at slower wheel speeds it is a considerably smaller percentage.
I doubt this will cause too many problems with errors.
time dividing to get the speed will take many clock cycles as ATmega doesn't have clock divider...
But thanks anyway... I would need this to calculate average consumption.. ;)
Not sure what you mean. ATmega has at least one 16bit counter. Use this (in a free-running mode) to count clock cycles between interrupts triggered by the wheel speed sensor. (All the interrupt code would need to do is a subtraction of 2 numbers, check if the counter had wrapped and add a constant if so)
Outside of the interrupt, you can work out the speed from the time period - it doesn't matter really how long this takes since it will only affect latency, not accuracy.
Are you saying you've used up all the timers?
maybe this helps?
http://shop.vems.hu/catalog/wheelspeed-cable-p-143.html?osCsid=4149b96a7ff9e4ac720c5ad6b8703242 (http://shop.vems.hu/catalog/wheelspeed-cable-p-143.html?osCsid=4149b96a7ff9e4ac720c5ad6b8703242)
Thank you. I allready have something much more complex... ;)
(http://memimage.cardomain.com/ride_images/1/2822/1741/7053370276_large.jpg)
Would anyone really want to use those connectors on their cars?
Why not? I'm using them for a five years in about 150 cars in other application without any noticeable problems...
(http://img683.imageshack.us/img683/3562/conej.jpg)
What do you have in mind?
I have seen worse in OEM applications
There is no high currents... The biggest current is 0.5A... So it's up for the task...
It is resistant to mechanical influence as long it is inside the vehicle in dry place.. :D
G_man - I use those connectors on my TVR heater controller. They work fine (and the OEM version used the same connectors)
I think Rob was refering to the PS2 connectors from lost's post. These don't belong on cars for fairly obvious reasons.
dnb, I hear you... ;)
Here is the TCM hardware... :D
(http://img514.imageshack.us/img514/3052/21072009004.jpg)
(http://img28.imageshack.us/img28/4899/20022010003h.jpg)
(http://img682.imageshack.us/img682/503/20022010o.jpg)
I have made the algoritam. Very simple without timers, without dividers. Just a simple counter... And it works perfect...
The only issue is false traction slip detection in hard short turns...
4x LM1815, ATmega128, 4x20 LCD, ULN2003D, A/D inputs, SPI, UART, and 2 expansion slots.. :D
very interesting,
Explain the operation and adjusting if you could.
Well done - told you it didn't need a divider :)
False slip readings could be compensated by a steering wheel position sensor or 3 axis accelerometer - with that you could quite easily calculate what the cross axle speed should be for a given turn. There may be a way to calculate it without this.
After my autotest today, I think I need traction control on the TVR... Are you making boards you're willing to sell? I could provide a reasonable input to algorithms if you want too.
I think I could detect turning by counting impulses from left and right rear wheel and detecting difference in their speed...
How will you tell that from one of the rear wheels starting to slip? (Not that you can do a lot about that without something to control the brakes)
My rear wheel wouldn't slip... :lol: It is FWD.. :D
lol. These people with wrong wheel drive... ;)
As soon we have an stable and tested operating version, I will sell the board to anybody who needs it... ;)
Now I need some interface to the VEMS to tell it to lover the torque for a moment of wheel loosing traction.
very interested in your developments here ;D
subscribed
For those who have joined the discussion later, I'm working on TCM (traction control module) which will act as a g-tech (measuring acceleration in meters and km/h) and the OBC (on board computer) that will measure trip times, fuel consumption average, current, etc. ..
It has the 4x20 text display, where you will get all the information, and the acceleration measurement:
*automatically (as soon as you start from standing)
*manual (if you don't want to brake to zero, but you want to measure acc for example from 100km/h to 200km/h)
And later I will develop an application in VB, for those who have carPC, that will show it graphically on the screen with graphs, history, best times, etc. ..
And of course the primary thing is to lower the torque at the start when you got too heavy foot.. :)
It meassures:
N*100m acc,
0-60km/h,
0-100km/h,
0-160km/h,
0-200km/h,
60-100km/h,
100-160km/h,
160-200km/h and
100-200km/h...
Quote from: mr_g on February 23, 2010, 02:03:25 PM
As soon we have an stable and tested operating version, I will sell the board to anybody who needs it... ;)
Now I need some interface to the VEMS to tell it to lover the torque for a moment of wheel loosing traction.
This would be perfect with drive by wire. Which VEMS will have to upgrade to eventually.
Otherwise cylinder fuel cut would probably be best for NA vehicles and boost lowering along with cylinder fuel cut if boost has been lowered as much as possible.
This sounds very promising. Can you use VR sensors or are Hall a must
VR sensors are standard ABS sensors.... So it uses VR.. ;)
This is a great project.
I am joust wondering if it could communicate with Vems by canbus.
This will give us the possibility to make a lot of things like fly by wire and so.
Also maybe you could use some of the data there are already in Vems.
Looks good
In the short term there is the nitrous retard feature. This could be used to pull out a few degrees of timing when a trigger is applied. You could also construct a simple PWM interface connected to the VEMS PS2 port to simulate a wheel speed sensor - you can then use the VEMS launch control settings to cause a limit in torque for a given input.
I know neither is ideal, but it gives you a quick way of testing your control algorithms now.
Quote from: gunni on February 24, 2010, 03:51:47 AM
This would be perfect with drive by wire. Which VEMS will have to upgrade to eventually...
Quote from: peter_jensen on February 24, 2010, 06:09:48 AM... This will give us the possibility to make a lot of things like fly by wire and so...
Who's going to be responsible for the recalls if runaway acceleration (http://abcnews.go.com/Blotter/toyota-recall-electronic-design-flaw-linked-toyota-runaway-acceleration-problems/story?id=9909319) happens. :D :D :D
Quote from: peter_jensen on February 24, 2010, 06:09:48 AM
I am joust wondering if it could communicate with Vems by canbus.
I didn't know that v3.x has a canbus?! I have ATmega128 on my VEMS 3.3 and it doesn't have canbus abilities..
Quote from: dnb on February 24, 2010, 06:56:47 AM
You could also construct a simple PWM interface connected to the VEMS PS2 port to simulate a wheel speed sensor - you can then use the VEMS launch control settings to cause a limit in torque for a given input.
I already forward the information from the rear wheel to the VEMS (PS2 port), but don't have an idea how to limit the torque...
For starters I will use Launch control / flat shifting input for this... LC input would be appliyed as long as the car doesn't reach the speed where the LC locked the rpm...
And when overtorqueing, I would use the same input to cut the fuel and ignition (for short period of time) and at the same time cut the output the wastegate 3way solenoid (lowering the boost to the WG settings) also for a short period of time...
Will start from there and see what would happen.. :)
Ignition timing retard works much quicker then boost reduction, especially due to delay from boost solenoid to wastegate-turbo-intake manifold.
Best to start with ignition retard to control torque, this is also less perceptible to people's ears if you are using it in a racing class where it may not be legal. (compared to cutting fuel/ignition events).
Interesting project, will be checking in for progress.
Quote from: lugnuts on February 24, 2010, 11:36:44 PM
Ignition timing retard works much quicker then boost reduction, especially due to delay from boost solenoid to wastegate-turbo-intake manifold.
Best to start with ignition retard to control torque, this is also less perceptible to people's ears if you are using it in a racing class where it may not be legal. (compared to cutting fuel/ignition events).
Interesting project, will be checking in for progress.
but egt more than 1100C is not rare with that control. For n/a engines is good, but for turbo not.
EGT is a non-issue.
We are talking about a few tenths of a second or at worst a few seconds.
If someone's set-up is so far off that it takes more than 1-2 seconds to regain traction, then they should have lower boost settings in the lower gears, or some kind of wet-dry boost setting.
An added benefit to ignition retard is, the turbo boost stays up and ready for the power to be re-applied.
How to apply this to the VEMS? Use nitrous input or something?
Ask the developers for an input.
The progress you have made I feel demands a update that incorporates it.
I would.. :) I would like to join the developer team also.. :)
But seems that they are untouchable.. :D
Why ?
Email marcell or post on the wiki about joining and adding input to the development
I have tried but with no luck... No response... :(
I could use Flat shifting input for TC also... It would cut the fuel and ignition at the same time...
How TCM properly measure the acceleration in (stop and you go):
100m, 200m, 300m, 400m, 500m, 600m, 700m, 800m, 900m, 1000m,
0 to 60km/h, 0 to 100km/h, 0 to 160km/h, 0 to 200km/h,
60 to 100km/h, 100 to 160km/h, 160 to 200km/h, 100 to 200km/h, and the current speed of the car, I made the integration of TCM and Climate Control application in the CarPC, to show all together (for savings COM port) ...
Soon, triptimes.. :D
(http://img24.imageshack.us/img24/7057/climatronictcm.png)