Go Down

Topic: Traction Control Project (Read 897 times) previous topic - next topic

ssande

Mar 27, 2012, 07:33 pm Last Edit: Mar 27, 2012, 09:43 pm by ssande Reason: 1
A quick introduction.  I just switched from the Basic Stamp to the Arduino, so I am just starting the learning curve.  I am creating a traction control program for a slow moving (up to 14mph) hydraulically driven vehicle.  The hydraulic motors are driven in a parallel configuration which allows some differential action when turning allow tight radius turns.  However if you lose traction on one tire it allows one tire to spin freely while the other tire remains stopped.  

To deal with this I am installing a flow control valve (electrically controlled by a solenoid) which will meter the hydraulic oil to each motor in equal portions when activated.  This valve forces both tires to turn at the same speed.  I will be using the traction control to monitor each wheel speed and compare the speed ratio of the two tires.  If the ratio exceeds a user selected value *and* the speed is within a predetermined safe range it will engage the flow control valve.

I have most of the logic and control scheme documented and am looking for some feedback on how I am planning to allow the user to select between different predefined slip ratios (i.e. 30% 35%, 40%, 45%, 50%, 55%).  I am going to use a rotary switch with 6 positions and use increasing resistor values on each pin of the switch.  Using the analog input I will be able to decode the various switch positions using approriate logic with a +/- tolerance for each expected resistance.

I believe the desired place to read the switch and set up the corresponding value is within the setup loop.  This way it is read once at initialization and does not read the switch position during each execution of the program.  This approach would require me to add a reset button so that after any change in the switch position it can be updated while running setup.  Once the traction control unit is setup and dialed in the switch would probably remain at the same setting and only changed if traction conditions change (mud, etc).  Does this sound like a reasonable approach?

Scott

PS. Here is a picture of the vehicle  :D Yes, it is a motorized bar that seats 8.


Coding Badly

Quote
This approach would require me to add a reset button so that after any change in the switch position it can be updated while running setup.


By exposing a reset button it raises the possibility of the button being accidentally pressed while the vehicle is in motion.

I like the general idea: make a selection, push a button to "lock in".  I would add a three things to the idea: selection can only be changed when the vehicle is dead still, reset is behind a cover / only used if the application stops responding, and an indicator that is lit when the selection does not match the strategy.  Changing the selection would go like this...

1. Vehicle is brought to a stop.
2. User changes the selection.
3. Indicator lights for all selections except the current one.
4. User presses the button.
5. Application records new selection and turns off the indicator.

ssande

Thanks for your response!

If the reset button were to be pressed while moving the worst that would happen is that it may not engage automatically.  I have a hard wired switch on the dash for the traction control that has "Off", "On", and "Automatic" in the event something flakes out.  "On" forces the valve unit, "Automatic" uses the Arduino controller.  A friend made a suggestion that coincides along with what you posted.  When both wheels are stopped have the program perform a subroutine that reads the switch position.  This way it does not interfere with the traction control processing when you are moving.  I am using all the digital I/O pins except 1 and 2 and two of the six analog pins (Arduino UNO).  To get a better idea here is a marked up picture of the proposed control box faceplate.

Scott




kf2qd

Why does it matter if the switch is read every time through the loop? It won't take mcuch processing time and it allows the setting to be changed at will without having to do anything else. And it is always functional.

ssande

I'm not sure it does make a difference - which is why I posted it for discussion in the Project Guidance forum.  Theoretically it may make a difference, but in real world application it may not matter.  Any idea how long it might take to do two analog reads?  I am coming from a Basic Stamp 1 where  you were very careful on how wrote your code.  I spent more time working around limitations than getting anything accomplished.

Scott

Coding Badly

Any idea how long it might take to do two analog reads?


From the datasheet: 13 - 260?s Conversion Time.

I think the ADC clock is set to run at 125KHz so the typical conversion will be 13 / 125000 = 104?s.

Go Up