#       
 #       
 # ###   
 ##   #  
 #    #  
 #    #  
 #    #  
         

         
         
 ##  ##  
 ##  ##  
 ##  ##  
 ##  ##  
  #####  
         

   _____ 
  / ____|
 | (___  
  \___ \ 
  ____) |
 |_____/ 
         
         

__   __
\ \ / /
 \ V / 
 /   \ 
/ /^\ \
\/   \/
       
       

         
         
  #####  
 ##      
  ####   
     ##  
 #####   
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''TractionControlArm is a module under development''' It is based on the ARM processor to handle traction control functions. It is intended to provide acceleration, deceleration, lateral g-force and (most importantly) traction data to the main board. Can we get some update on current state ? We thought about '''merging with VemsFrontier/ArmEfi, but dropped''': 4 LM1815 is just too many, why not add an ARM than and with CAN we have this board anyway. ---- '''Divider or no divider needed?''' - before input CAP pin. VR signal with 20-60teeth per wheel? or more ? 1986-1992 RX7 w/ ABS has 91 teeth per wheel on the front, unknown on the back, but probably the same 90m/s at 1.5m circumference is 60 rot/s = 3600 Hz. 4 of these is .... I think 10kHz is not too bad for ARM: irq handler will be slim. Unless we find 360 tooth monsters (as we do with crank), divider shouldn't be needed. ---- Dave Blundell says: "At this point, the only outputs planned for the board are to drive ABS modulation solenoids so that this board could function as a complete ABS system in addition to traction system if it was desired." Proposed method of action: *CAN signalling to main board - "traction count" and possibly "wheel / wheels slipping" for AWD systems. If accels are added, the g's should be added to this. *Direct modulation of ABS solenoids (optional) Proposed actions when receiving traction event: (actions taken by board receiving CAN data. TractionControlArm should output a percentage of slip correct, the mainboard does the rest.) *Boost limit/boost cut *Retard of spark *Direct throttle-down in drive-by-wire *Negate individual fuel pulses, per racelogic ---- === Suggestions === Corner weight the car. At the cg center in the horizontal plane, mount a box. In this box will be... (assuming cg center is x = 0inches, y = 0 inches) * 3 .5-1g vertical accels @ +3,0; -3,-3; -3,+3 * 2 4g lateral accels @ +3,0; -3,0 * 1 5-10g longitudal accel @ 0,0. This will give us x,y,z accels and x,y,z rolls and roll rates!!!!! Literally it will give us everything. The vertical, lateral, and longitudal accels mentioned are all single axis accels, just mounted in a different direction. Benifits are supper long. Some things that come to mind are both road course playout w/ 3d car playback, drag race playback, and poor man engine tuning. ''' Benifits: ''' - ''Decided to add them'' * 3D g-force, roll, pitch, yaw. Including rates. * Horsepower (need corner weights) * Speed and distance in a vector * No need for suspension slop calibration since you have 4 3d accels. * Many of the above functions can get you 0-100-0 speeds, 1/4 ets, skid pads, etc. * Traction control by looking at twitching in any direction by any accel... this will be tricky and doubt it will be of much benifit... maybe more if someone wrote a stability management like SAAB. [http://www.race-technology.com/WebPage/Products/Accelerometer/PerformanceMeterIntro.html I own one of these devices.] I would love to have this integrated into VEMS because I can then compare against a/f and timing to improve my runs. Alot of it is going to require post processing. It is priceless information. The unit that I have requires all kinds of lat/long roll stuff because its a 2d single accel. Then to make things even more powerful is to have the 4 wheel pwm inputs to detect slip. This can be used to determine if you are slipping wheels or you need to tune at that rpm/speed. One of the things I didnt think about, which this document brought up was "Direct modulation of ABS solenoids." ''' How is this for cost? ''' ---- Proposed hardware: *[http://www.semiconductors.philips.com/acrobat/datasheets/LPC2119_2129-02.pdf Phillips LPC2119] ARM MCU *4x [http://www.national.com/ds.cgi/LM/LM1815.pdf LM1815] - one for each VR wheel sensor *2x Analog ADXL213 2-axis tilt sensors, perpendicular mounting for tilt and acceleration measurement in 3D (new chip) Proposed algorithms for detecting traction issues: (in rough working order of importance) #VR sensor - wheelspeed differences in excess of threshold (relatively easy on 2 wheel drive, not so easy on 4wd) #Without VR sensor: compare accelleration versus delta RPM. If delta RPM is > acceleration by a threshold, then wheels are spinning (marcell's note: I don't think this would work. usable RPMdot is a black art in itself, the actual gear would need to be known, and the g-based acceleration is also disturbed by roadbumps). (dave's note: fair enough, but its a software approach and wouldn't cost anything but codespace and time to implement) Proposed VR sensor -> ARM interface: *raw VR sensor signal processed by LM1815 into square wave *4 square wave signal fed into ARM on CAP1.0, CAP1.1, CAP1.2, CAP1.3 (pins 35, 37, 47, 53) *input capture used to measure frequency of square wave Proposed types of traction problems: *FWD: Front left/ front right wheels spinning unequal speeds *RWD: Rear left / read right wheels spinning unequal speeds *AWD: Any wheel spinning unequal speeds *Axle diff: Front/ Rear axle (wheels) spinning unequal speeds (useful when having difflock on a axle?) Differing wheelspeeds that are acceptable: *Cornering (should be able to tell by G-forces?) *VR sensors not sending exact same frequency (calibration phase - neutral G?) Proposed calibration algorithm: *Wait until minimum frequency reached on all 4 VR sensors *Wait until zero / close to zero G conditions are acheived *Assume that all wheels are spinning same speed *Measure slowest VR sensor *Generate factor to multiply slowest sensor by in order to get speed of other 3 sensors *Store factor data for later use in traction calculations Question of which 2 axis tilt sensor to use (todo: datasheet links): *Analog ADXL311: +/-2g Scale. Analog linear output Accuracy +-17% $4.25 q1000 (cheap) *Analog ADXL202E: +/-2g Scale. PWM output Accuracy +-16% $8.50 q1000 (dropped) *Analog ADXL213: +/-1.2g Scale. PWM output Accuracy +-10% $9.70 q1000 (relatively precise and cheap) *Analog ADXL203: +/-1.7g Scale. Analog linear output Accuracy +/-6% $12.00 q1000 (most expensive, but precise) *Others? * PWM requires input capture or interrupt. With interrupt we can store the time snapshot in the interrupt handler, precision is perfect. * Analog linear output requires ADC input. I don't really mind if PWM or AIN is used. I estimate that ADXL213 precision would be appr. the same as ADXL203 in practice. Note that these beasts are more precise at 25C. Do we want a board temperature here too (hint: yes) -Marcell So it looks like the ADXL213 will be the tilt sensor of choice for the simple reason that it is cheaper. -Dave Anyone have any recomendations for *cheap* temperature sensors for use onboard? Yes, an NTC with a pullup resistor. If you are short of ADC inputs (ARM's 4 might be enough), we should add MCP3208. Since this board would often be used as a standalone logger (logging acceleration and a few other parameters) a few extra lowpass-filtered input is a must. Further input welcome *Need option for sensor output without traction control through the CAN Bus... great for data logging. MembersPage/PatrickB suggested these inputs: * Brake (D) '''I'd rather see an analog input -Jörgen''' Brake pressure sensor on front brake circuit? Agreed...However, I was thinking digital at a minimum, as high pressure sensors seem to be expensive. -Patrick. * Steering (A) * Susp Travel (A) * 4 * Driveshaft RPM(D) * I would like a gyro to be able to determine jaw rate. -Jörgen All available as resistive or voltage output sensors. * GPS based sensing. RaceLogic uses this technique. -GergelyLezsak * G-sensors with higher scale. Possible to fire airbags/pyro seatbelts based on these. (Would be tricky to test however..) -GergelyLezsak ---- == Research == A link to a ACC Essay called Calculating Logitudinal Wheel Slip and Tire Parameters Using GPS Velocity. This is good stuff for implimenting with Traction control. The standard speed sensor will give us the needed wheel velocity, while the accelerometers will give us absolute velocity (accels will supliment the gps data) \\ http://www-cdr.stanford.edu/dynamic/WheelSlip/SlmillerGerdesACC.pdf A link to a three axis gyro G sensor circuit: http://autopilot.sourceforge.net/download.html and http://www.rotomotion.com/prd_IMP.html for circuits (Using Tokin CG-16D angular rate gyros and ADXL202-EB accelerometers to an Mega163) -Johan Some Tech: http://www.sensorsmag.com/articles/0203/14/main.shtml http://www.dprg.org/projects/2003-01a/ ADXRS300 Gyro (BGA): http://www.analog.com/UploadedFiles/Data_Sheets/732884779ADXRS300_b.pdf ENC-03M gyro 35$? (4pin SMD): http://www.murata.com/ninfo/nr0283e.html See also: TractionControl/Algorithms
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.