Implementing Traction Control for an advantage in the 2009 game
 

I think I can safely say that the robot with the best ability to move around will have an advantage this year. One way to do that is to maximize traction. A slipping wheel provides no traction (at least at certain high slip values)

In looking at this graph (scroll down to see the graph) we see that on a certain surface* a certain amount of slip provides optimal traction while maintaining stability. This is the principle behind Anti-Lock Brakes and other traction control systems.

If we then conclude that traction control can be superior to excessive acceleration**, we now have a few issues to manage before we can implement that in software.

The purpose of this thread is to share knowledge and ideas on how to implement this, especially since automotive engineers probably know a lot more about this - and can help their teams more - than others, who can and should benefit from this expertise.

Anti-Lock Braking Systems (ABS) work on the principle that a wheel can only slow down at a maximum rate, and once it exceeds that rate it is "locking up". ABS is implemented without knowing the coefficient of friction or vehicle speed by finding the slope (differential) of the wheel speed. Once that slope (rate of change) exceeds a certain experimentally-derived value, the wheel is Locking Up and actions are taken to reduce the braking force upon that wheel.

Acceleration Slip Regulation (ASR) is different, and is probably more of what we need to implement in this year's game. ASR works by measuring the slip due to acceleration, comparing the actual speed of the driven wheels to the undriven wheels, reducing throttle input*** if driven wheel speed exceeds that of undriven wheel speed by some value (perhaps 20%).

The graph mentioned shows 20% to be the magic number for dry pavement and rubber tires****.

The first problem is to measure the speed of each wheel. This is moot if all wheels on a side are driven by a single motor, since they all are at the same speed, so the first requirement seems to be that each wheel needs its own motor (although an 8 wheel drive may be possible, 2 wheels off one motor). The encoders provided are OK, but may also be overkill at 300 pulses per revolution (most ABS systems have 48 or 96).

The second problem is to measure the actual vehicle speed. In a car, just use the undriven wheels, but in a robot, usually there is no undriven wheel. In this case, one can mount an undriven 'fifth' wheel for this purpose, perhaps using a caster type mounting system (if you want to detect sideways travel). One post mentioned using an optical mouse - my MS optical mouse seems pretty reliable at 1/16" off the desk surface, but it would probably get quickly dirty on a FIRST field. Trains use acceleration control for optimal traction, and they sense vehicle speed using radar (essentially a traffic radar gun - Ramsey Electronics sells a kit for $60)). I wonder which might be best here.

The next problem is motor speed control. Cars usually work at 15 to 30 Hz, due to limits of their mechanical systems. The new Jaguars can adjust their outputs a lot faster than that. The control system can keep up with it, too, but can the motors? Can a PID loop be implemented that gets a new setpoint every 1/60th of a second?

This being a somewhat deep issue, any and all comments are welcome, since we never know which tidbit will be the important one.

Don

*The curve changes a little for different surfaces, mostly flattening as mu decreases, but the principle remains. One notable difference, not relevant here, is on loose surfaces such as gravel.

**This also applies to excessive negative acceleration, also known as braking.

***Some systems also apply braking to a single slipping wheel, but in FIRST we can limit ourselves to a single response.

**** This is not stated anywhere, but I know it to be true from my experience with these systems.

.

Re: Implementing Traction Control for an advantage in the 2009 game
 

The first thing that came to mind was that the coefficients of static and dynamic friction for rubber tires on pavement seem to be more different than they are for the robot wheels on regolith. That means we don't have as much to gain as car designers do. I'm not rtying to dissuade anyone from working on this, though.

Also with a typical skid steer 4 wheel drive, the front and rear wheels on each side will be slipping the same amount in the driving direction, because they are turning at the same speed, and they are on the same surface, and the stay the same distance apart. So, there seems to be no need to worry about sensing the speed of each wheel, only the speed of each set of commonly driven wheels. This concept is used in older automotive ABS also, note you'll find only one speed sensor on the rear axle of 80s pickup trucks with primitive ABS.

Re: Implementing Traction Control for an advantage in the 2009 game
 

It is relatively simple to limit the rates of acceleation and turning in the programming as opposed to monitoring wheel speed to look for slippage.

With this approach you would need to test the robot on the surface and adjust the limits in the program.

Any traction control system will require some getting used to.

Re: Implementing Traction Control for an advantage in the 2009 game
 

You mentioned using a caster for figuring out the actual velocity of the robot; another possible way to do this is with the accelerometer. Before kick-off we designed a quick inertial positioning system using an accelerometer and gyro based off of 111's system back in '04 (I think it was '04...). Using some trivial physics you can use a loop to keep track of your actual velocity and position. Now, we haven't actually messed around with an accelerometer at any point in our history, so I don't exactly know how accurate these are, but that was our first take on traction control.

Re: Implementing Traction Control for an advantage in the 2009 game
 

You might not want to implement a PID loop depending on what you are trying to accomplish with the drive train. Using a ramp instead of a step input is ideally what we want. The problem is that it changes the system type that you need (Read: How many integrators you need) to achieve a specific amount of steady state error.. I actually have to go over the dynamics of a basic gear train (Read: How many integrators you start out with) but the worst case scenario is that you have to integrate at least once to get a system that doesn't give an steady state error that blows off to infinity and twice to get zero steady state error.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Agreed, an empirical approach would probably be effective, even if the testing surface differed from the actual surface (simply adjust one parameter).

However my goal is to show these kids an engineering approach. Someone once said that the difference between an engineer and a tinkerer is that the engineer can calculate the results beforehand.

This assumes that 6 weeks is enough, of course.

Re: Implementing Traction Control for an advantage in the 2009 game
 

What you could do is use optical encoders with optical encoder wheels on two kinds of wheels -- driven and not -- then take the data from both and make a table that you can use to program the TCS with. Drive the robot on a surface as close to regolith that you can.

Or, you could program it so each wheel has an optical encoder, each side independent, but tell the code that when the non-driven right-side wheel's speed value and the driven right-side wheel's speed value don't match, to slow down the motor until they do and keep it there, in the traction zone.

this assumes, of course, the use of extra optical encoders on non-drive wheels, which would require a drive system with possibly extraneous wheels. But if the bot's 2wd with four wheels, it'd work.

Re: Implementing Traction Control for an advantage in the 2009 game
 

CAN interface on jaguar motor controller, allows for reading the current and voltage. Wouldn't these spike when the wheel loses traction?

Re: Implementing Traction Control for an advantage in the 2009 game
 

The CAN interface is not FRC-legal for 2009.

Re: Implementing Traction Control for an advantage in the 2009 game
 

What about using analog current sensors? Would that work, and provide the same functionality as the CAN interface?

Re: Implementing Traction Control for an advantage in the 2009 game
 

Absolutely, but at this time we are planning on six driven wheels and none undriven. I mentiojned that in the intiial post: "but in a robot, usually there is no undriven wheel."
Good idea Blair - you'd need to compare the measured current AND voltage and then compare it to what was being commanded to the Jaguar (i.e., the PWM value), but this may be simpler in some cases than using wheel encoders - and probably a lot less expensive as well.

Why not just current? Because motor output is not directly proportional to only current if the robot can be acted upon by external forces - like a robot slamming into you. The current should remain the same for a given wheel speed so long as you are slipping above a certain factor, but get below that slip threshold and it gets nonlinear. Measure power (Power = current * voltage) and you can be sure all the time.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I don't know that there is any team out there quite up to the level of programming, prototyping, testing, and time management skills this might require, but I had a thought and I figured I would put it out there. In watching my favorite car show, Top Gear, I saw the track test for the Nissan GTR. The GTR uses a myriad of sensors to analyze the car's current situation in comparison to predetermined targets. If the car gets outside those boundaries the electronic system appropriately routes power and there by keeps the car constantly in control, while allowing a significant amount of freedom in terms of aggressive driving and cornering. I have no doubt a similar system would be possible for this game, but I am sure it would require a great deal of time and testing. Any thoughts.

Re: Implementing Traction Control for an advantage in the 2009 game
 

You seem to be describing what I call ESP. Certainly there are teams up to this, and we have the sensors necessary. It is a bit more ambitious that i think our team wants to bem but good suggestion, I'll bring it up. The advnatage is that you also get the robot working to give you directional controls, not just acceleration.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I didn't really make my suggestion clear in re-reading my post. I guess the most difficult part of the system I'm describing is obtaining the data to know what those predetermined targets should be. I was contemplating the idea of obtaining them with a robot using a relatively standard kit wheel of similar diameter from previous years, because the rover wheels aren't going to provide accurate driving targets, even off of the Regolith.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I’m thinking two things,
1st by the time you have drive control your robot is going to be hit by another and be out of control.
2nd Optics - Optical encoders on the wheels and optical mouse to senses floor movement. The mouse may need modifying so it will work a few inches off the floor. I will be a cool thing for the programs to work on.

I think this game is going to fun to build, play, and watch:)

Re: Implementing Traction Control for an advantage in the 2009 game
 

What I am thinking of is a simple, program-level, "pseudo-pulse"; can't think of the word off the top of my head, but it would pretend that the input is pulsing at a rapid rate, and then have a button mapped to turn this pulse on or off, just in case it needs to be off. Granted, the on-off button would only work in teleop, but it's still better than nothing and can easily be implemented by a loop with a wait of, say, 10 ms. Would this work, or would this just be interpreted as just a steady stream? I didn't look too deep into the specifics of the control system, but this is my interpretation of a traction control mechanism implemented in the software level. And yes, I am a rookie.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Would the "pseudo-pulse" be variable depending on conditions? If not, then you're effectively driving the motors slower, not actually preventing a slip.

A Traction Control System looks at the all of the wheel speeds and determines which are slipping, then slows only those wheels.

My team is definitely trying to do this [4WD, all independently driven] but we can't figure out one thing:

How do you determine if a wheel is slipping when all four wheels are powered?

Any answer would be appreciated.

Re: Implementing Traction Control for an advantage in the 2009 game
 

An accelerometer perhaps? It's not bullet proof, but I'd imagine it could work pretty well. You can figure the theoretical limit of your acceleration. If you're slipping, you aren't accelerating that fast. So slow down until a decrease in wheel rpm produces a slight decrease in acceleration.

Re: Implementing Traction Control for an advantage in the 2009 game
 

FIRST off, it's important to note that even absolutely perfect traction control (runs riiiight at the limit of static friction at all times) compared to a wheel slipping a reasonable amount (dynamic friction but not so incredibly fast that the materials do not have time to interact with eachother before the surfaces move) has very little difference in acceleration.

The coefficients of friction (preliminarily) for static is 0.06 and dynamic is 0.05. If you calculate out how long it would take for a 120lb robot to accelerate to 10ft/sec, you'll find the difference in time to be about 0.1sec. Not much difference.

But, if you were going to go ahead with it anyhow, I think integrating the accelerometer over time to get real velocity would be a good start. Then, using encoders for wheel speed and the accelerometer integration value for real speed, you have a surefire indication for weather or not you are slipping, then you're control logic/software can take over from there.

I realize other methods of detecting slip have been mentioned in this thread, but knowing the real velocity of the robot gives you another cool ability. If for example you are using a tank drive train (motor for left, right side of robot) and one of the sides of your robot gets on carpet, your control system can independently adjust the traction control action regardless of the surface the wheels are on (power would be increased to point of slippage on carpet, which would be a higher force than can be exerted on the opposite (regolith) side). Should make your routine surface type independent.

It would be very interesting to learn what the coefficients of static+dynamic friction of the moon tires are on the carpet. Does anyone know/want to figure it out?

Okay, time for bed. :o

-q

Re: Implementing Traction Control for an advantage in the 2009 game
 

Extending on what QBranch said, its kind of a bad idea to implement traction control when you have no traction in the first place.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I was thinking of just adding some inertia on the joysticks, for not to allow sudden variations on the axis, like a capacitor would do to a square signal.

I already figured out how to get the derivative of the movement of the axis, so I can measure sudden moves to correct it, but that's as far as we've got.

Re: Implementing Traction Control for an advantage in the 2009 game
 

You could use voltage and current feedback from the motors with the analog sensors currently available. Through test trends would appear when the wheel lost traction, possibly a spike in amperage. Also if the wheels are independently driven you could use encoders and compare the rotation rate of wheels being driven similarly so if left front and right front are both moving forward, but left front is slipping the rotation speed of that wheel should be faster.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I looked extensively in to optical mice last year however they do not work at high enough speeds to be feasible (even for this challenge) if you find one fast enough please inform me but the best i could get was ~5ft/s before it losses all idea of whats going on.
I realize this may be a pain (mostly for the mechanics) but the easiest way to determine wheel slippage is to compare the speed of each wheel to the speed of an driven encoder wheel next to it. Or (since the robot moves as a whole) you could get away with three encoder wheels telling you how the robot is moving and do some calculations to figure out how each wheel is moving.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Perhaps a rate limit between the joystick reading and the pwm requested, will be helpful.

Re: Implementing Traction Control for an advantage in the 2009 game
 

solve for your current acceleration, using laws of motion, then compare with the accelerometer, using the derivative of the accelerometer data you can tell what speed your going, adjust motion for collisions, it seams helpful in terms of traction control.

Re: Implementing Traction Control for an advantage in the 2009 game
 

EricS,

We tried the joystick method and it works great. It was very simple to implement and we just wanted to see if it made a difference ... it does big time (as we expected)!

I do not think this is the best way as it does not actually account for actual wheel speed. Caution: this post might get a little long.

First, a description of what we did. We forced the maximum PWM input change from the joystick from one time step to another to be a certain value (ours ranged from 1 to 10). We only had it working in the forward direction as we had a bug that made it not working in reverse (we were trying to do it fast).

When diving around on the actual surface with the actual trailer and wheels with the trailer loaded (about 40 - 45 lbs) here is what we found:

The "poor man's traction control" worked great except when you tried to turn the trailer and it took longer than the ramp up. The wheels would eventually break free and spin but backing off on the throttle would bring it back down and gain traction. I think people will be suprised when they see how much trailer weight affects turning performance. Anyway, it proved to us that traction control is a must.

In my mind there are 3 basic ways to do traction control this year:

1. Poor man's - as described above just control throttle rate.

2. Middle Income - Encoders on the driving wheels only. Control the rate of change of wheel speed (also known as acceleration) to match what the surface can handle.

3. The super rich - Do the same as number 2, but add a frame of reference like a non powered wheel or an accelerometer. In addition to controlling the change, you also make sure the wheel speed is close to the frame of reference speed.

Our team is leaning towards #2 and here is why:

1. As I proved in a different thread, the maximum acceleration we can have is equal to g*CoF, where g is the acceleration due to gravity and CoF is the coefficient of friction between the floor and the wheels.

2. Since this is a known quantity we can set the maximum wheel speed change per time step based on testing.

3. In addition, we can cap the maximum speed (if you think that is important.


If this proves to not be enough, then we will probably use an accelerometer as a reference.

Re: Implementing Traction Control for an advantage in the 2009 game
 

First off, thank you for the informative post and test results. Many would have kept this as an advantage.

Didn't your team use idle wheels last year to measure wheel speed? Did last year's experience influence your opinion so far?

Re: Implementing Traction Control for an advantage in the 2009 game
 

Methods for doing traction control:

1. Use what you know about the physics of your environment (open-loop):

1a. Limit acceleration of the wheel to the acceleration that provides the maximum tractive force. Works great in theory, but the dynamics of the robot (i.e. weight transfer from wheel to wheel when turning, irregularities in the wheel tread) make this style slightly unreliable. Still, it should be much better than nothing.

2. Sense the difference between your true robot velocity and your wheel velocity:

2a. Combine driven and non-driven wheels. Sense the speed of both. This will absolutely detect wheel slip, but you lose some downforce to the non-driven wheels.

2b. Use inertial sensors (accelerometer + gyro) to get your robot speed. The problem is that these sensors are noisy and will drift when integrated.

2c. Use a camera/mouse/ultrasonic range finder/RADAR/LIDAR to detect true robot speed. I've yet to see a reliable implementation of one of these methods on a FIRST robot, however.

3. There are other clever ways as well:

3a. Kalman filters are based on complicated mathematics, but can take different types of sensors with known uncertainty characteristics and fuse together their outputs to get a generally reliable view of the overall picture. This would be a robust way to use inertial guidance, for example.

3b. Even in a 4WD robot with 4 independently-powered wheels with encoders, you can detect (some kinds of) slip without the need for additional sensors. You know where on your robot the wheels are mounted. You can measure the speeds of all four wheels. If you examine the speeds of three wheels at a time, you can compute what the speed of the fourth you HAVE to be in order for there to be no slippage. You can do this for all 4 combinations of three wheels and deduce which wheel(s) are lying to you. If all four (or even three, and sometimes two) wheels are slipping, you're still out of luck, but if one wheel loses traction before the others, you will know.

---------

How much agility will we really gain with these methods on this floor? I don't know - but I do know that in the kingdom of the blind, the one-eyed man is king. A small edge might tip the balance of an otherwise level playing field this season.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I can't speak for 217, but one thing that scares me about non-driven wheels this year is that every pound of downforce on a non-powered wheel takes away from your maximum tractive force (and therefore acceleration). Does the loss of this force make up for the benefits of an otherwise simple way to get high-fidelity anti-slip control? I don't know.

Re: Implementing Traction Control for an advantage in the 2009 game
 

It might work better to use a laser mouse since it works on more surfaces and is more powerful

Re: Implementing Traction Control for an advantage in the 2009 game
 

If a laser mouse uses a real laser, you should search the rules for the word laser.

I was pleased to see that my idea of using an optical mouse had already been thought of, and even tried, and found to be not effective at speeds > 5f/s. Now I don't have to spend the time to try it myself.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Jared this was helpful.

How about tracking the speed of a wheel and when the speed greatly increases more than normal what is expected bring the power back.

Re: Implementing Traction Control for an advantage in the 2009 game
 

That was my thinking too - monitor the second derivative of wheel velocity. I'd expect this to be fairly noisy but usable with some filtering. I promise to report back red-faced if it's a dismal failure.

Out in the open field away from carpet, I think we'll be facing the situation where several (all) wheels will slip simultaneously, but many of the standard workarounds seem to assume single wheel slippage. (Obviously at high enough sampling frequency one wheel will be the first to go.) I see an integrated approach (pun intended) as the way to go.

And thanks to all for a very thought provoking thread.

Re: Implementing Traction Control for an advantage in the 2009 game
 

This would work, as it would limit the acceleration of the wheels. If you are measuring the speed of the wheel, then the derivative of that value (the rate of change) is the wheel acceleration. The wheel acceleration can't exceed some absolute threshold, otherwise the wheel will slip.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I think you meant first derivative of wheel velocity (or second derivative of wheel position). This is your acceleration.

Here's the rub - encoders are digital sensors, with limited resolution. The "derivative" operator is continuous. You can approximate the derivative with the "difference" (i.e. accel = speed - last_speed), but this is only ever an approximation.

Luckily, the straight difference isn't the only way to approximate the derivative. For example:

accel = -last_last_speed + 2*last_speed - speed;

This is a smoother derivative approximation, but it is now time-delayed (since it is centered around the time of last_speed). This is the tradeoff of filtering - with smoothness comes time delay.

Re: Implementing Traction Control for an advantage in the 2009 game
 

What I am planning on doing is finding what would be the best (on a linolium floor; Bill said that that would work) or at least have average results; we (programmers) were told that we would have "enough" time to mess around with the robot and see what works, and we DO know the coefficiants of friction and the weight, so we could change it based on that (we also have a few engineers that have been known to understand these kinds of things..... You know; something about a college degree...... :rolleyes:)

We have decided (or at least the programmers have) that it would be best to have a steady number, instead of sensors.... You know; ease and all that jazz..... :D

Re: Implementing Traction Control for an advantage in the 2009 game
 

LabVIEW has some really helpful filtering VIs under Signal Processing -> Filters. It may be worth while to use these to implement higher order filters easily. For example, using a band-pass filter may be an easy way to detect sudden changes in wheel speed.

Every time I think about trying to compare the past to the present I think about filters.

Re: Implementing Traction Control for an advantage in the 2009 game
 

No, I actually did meant the second derivative, or more precisely the change in the first derivative, i.e. looking for a sudden increase in acceleration as an indication of slippage.

I haven't thought through the resolution necessary to get reliable performance, but I am certain that processing power won't be the limiting factor.

And I agree with Eric's comments about Labview. I've spent too much of my working life re-implementing signal processing code to want to do it unnecessarily.

Re: Implementing Traction Control for an advantage in the 2009 game
 

My one problem with this idea is what do you bring the power back to and now what is normal speed to track against now since it has slipped. Maybe it is the speed before the wheel slipped.

Our team is first going to ramp up power as first step. I would like to see a graph of a wheel speed as it is going normal then slipping. Maybe analyzing the graph you can use that to predict slippage and bringing it back to non-slip.

Re: Implementing Traction Control for an advantage in the 2009 game
 

You're a jerk!:)

Re: Implementing Traction Control for an advantage in the 2009 game
 

To answer the earlier question, what we do on carpet is use an idler wheel on a spring connected to an encoder. this will not really take away from normal force (very, very small spring load) but we are concerned this year that we have to use the actual wheel instead of a small wheel and that the low friction will make that one slip too.

The time step (or ITP time) for the cRIO is ridiculously small so we are using the simple difference and will use the labview filtering if we have to.

I can tell you the simple joystick filtering works way better than I thought, but will need a lot of manual intervention in a pushing match.

Re: Implementing Traction Control for an advantage in the 2009 game
 

The first Q/A answer is in, and it's a good one. We do not have to use a rover wheel for an idler wheel. http://forums.usfirst.org/showthread.php?t=10917

Re: Implementing Traction Control for an advantage in the 2009 game
 

This was an answer I did not expect. Well then - this becomes the most attractive of the various slip detection strategies in my mind (since you can get away with negligible downforce). Keep in mind that the poster of this question talked about a freely rotating caster - non-rotating casters would indeed provide turning resistance (even if slight) and might not be covered.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Most would say you need an unpowered wheel (and now that a speed sensor is legal, it seems to be the simplest method), but consider the case of a 4-wheel drive vehicle that has implemented traction control. The answer given by MikeE is similar to what is used in the real world. Yes, there are some considerations regarding the effects of the motors on speed, but if we assume we know the input (i.e., PWM value to the motor) we can use that to filter out those effects from the output (wheel speed second derivative)

You can also set a maximum allowable acceleration using an accelerometer. Discount the occasional collision of course, and make it easily disabled for those cases where you have that sliver of carpet under your wheels.

However, Paul Copioli mentioned that joystick control is effective, and I tend to favor the simple solution. And we'll disable that when the trigger is pulled...

Exactly the second derivative of wheel speed - the rate of wheel acceleration.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Thanks Don for starting this discussion it has helped a lot.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Do you mean: "I think this game is going to be fun to build, frustrating to play, and funniest to watch:)"

;-)

Re: Implementing Traction Control for an advantage in the 2009 game
 

So far this is pretty much exactly what we are doing, but we have a couple other methods too, like an E-Brake that senses the direction of the angle that you are drifting at and when enabled (a joystick button) turns our wheels perpendicular to the drift angle. You wouldn't have much control during the braking but it might help some. We will post our results when available.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Although this might be overly complex, something out of the box would be to create some sort of velocimeter that bounces sound off the ground and measures the change in reflected frequency due to the sound doppler shift. Ocean current profilers work in this fashion. Of course an encoder can accomplish the same thing, in a simler fashion, but just wanted to throw the idea out there.

I like the idea brought up earlier about monitoring the motor's current to detect a drop in load due to the transition from static to kinetic friction.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Some one might have posted this, but if you use the accelerometer to measure the acceleration of the robot, and solve for what your acceleration should be if the limit of the wheels speed is approaching the speed of the robot, to achieve maximum traction you can multiply the forward force by 120%! Of course you need some serious math for this, but nearly three quarters of it will be math, so if you can solve the math you should be able to program it.

Re: Implementing Traction Control for an advantage in the 2009 game
 

http://cigr-ejournal.tamu.edu/submis...2001%20007.pdf

Ocean current profilers are called sounders, I think? Check out how the weather satellites do it if you're really interested.

Re: Implementing Traction Control for an advantage in the 2009 game
 

windell747 & purduephotog -

Very cool! That is essentially a radar gun using sound instead of RF. That got me thinking - why not use a radar gun?

Do you know of any vendors that sell an accoustic radar gun?

Re: Implementing Traction Control for an advantage in the 2009 game
 

I thought of that earlier, but I assume the GDC would take issue with me sticking a 10GHz transmitter on my robot. Then again, the rules as worded don't really address it - they only discuss wireless communication. But, I think the intent is clear - no RF transmitters or receivers on the robot other than the wireless bridge.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I know that for braking and acceleration testing at Chrysler we had an optical 5th wheel device that I believe used laser system similar to an optical mouse just with better range. I think these are pretty expensive, and the ones I found online are heavy (0.5Kg for sensor and 1Kg for single converter).

If anyone finds an optical mouse that reads the surface well without touching it, I would love to know the model!

Re: Implementing Traction Control for an advantage in the 2009 game
 

If your Coefficient of Friction of the mouse is less than the Rover Wheels would that be expectable because it does not increase your traction and you are using it for input rather then output?

-Oris-

Re: Implementing Traction Control for an advantage in the 2009 game
 

I think that we are going to ask in the Official Q&A if a small caster with no motive force, and no way of providing traction can be used to get surface speed and direction, but I am fairly certain they will give a resounding "NO".

Re: Implementing Traction Control for an advantage in the 2009 game
 

Has anyone thought about using an FIR filter on joystick inputs? It would work for acceleration from a stop in either direction (F/R), but I am stuck on how change directions or stop without considerable lag.

Thoughts?

Re: Implementing Traction Control for an advantage in the 2009 game
 

Just make the wheel of the caster a Rover Wheel.

-Oris-

Re: Implementing Traction Control for an advantage in the 2009 game
 

One of the first responses on the Q&A system indicates that this is legal.

http://forums.usfirst.org/showthread.php?t=10917

Re: Implementing Traction Control for an advantage in the 2009 game
 

First, I want to thank everyone for such a wonderful open flow of information on this topic. This is such a tremendous paradigm shift from previous years that teams could fall into a "Cold War" mentality and not share this information with others.

Now, Paul Coplioi's post on the second page made one assumption that I thought I would try to correct.

I don't think that the mass cancels out in the equation for maximum acceleration (amax=g*CoF). If you walk through it carefully, you will see that while the friction force is Cof*robot weight, the mass that you are acceleating includes the trailer weight. In that case, the maximum acceleration of the system will be limited to roughly 75% of g*CoF.

This should only affect teams who are measuring acceleration. Teams using encoders and follower wheels (thank you FIRST GDC for the rapid response to that question) should not see a problem.

Re: Implementing Traction Control for an advantage in the 2009 game
 

With the recent allowing of idler wheels this will probably not be needed but my thought was to have a pivoting motor mount with a load cell under one of the mounts, thus you could sense the torque applied to the motor shaft. you should be able to calculate, and after it is done test to find your maximum torque that can be applied before slippage occurs, then write your software to drive the motor to this condition. In this case, if you diden't use speed input (would be a good idea to do so) your joystick would become not a speed input, but a torque input, or just like the accelerator pedal in your car!

But the sensor wheel will most likely give you 95% of the benefit that you are looking for anyway, but I like to throw my ideas out there and see if anyone bites.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Tom,

The FIR filter should work just as well when changing directions. Indeed, you want to back off the throttle from the one direction before increasing in the other direction. Of course, you may want to try using the new Jaguars for this. Also, something other than constant coefficients for the FIR would be interesting...

JMHO.

Mike

Re: Implementing Traction Control for an advantage in the 2009 game
 

It would be interesting to see an analysis on real output speed vs allowed acceleration on the rover wheel/CIM setup. Physics says max acceleration should always be the same, but I tend to remember CIMs being kind of sloshy in their top end. This may break a linear filtering system and limit your max acceleration.

This is all based on the non linearity of PWM duty cycle to torque in the CIM. Anyone with knowledge on this, care to share?

On a side note: I rather like the "Middle Income" situtation Paul suggested. I just don't think input filtering is enough to be super useful.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Tom,

Check this out and you will see why I suggested the Jags... However, I have not been able to do any testing myself yet...

Regards,

Mike

Re: Implementing Traction Control for an advantage in the 2009 game
 

This is something I would like to see end once and for all in FIRST.

Re: Implementing Traction Control for an advantage in the 2009 game
 

All,

Warren is absolutely correct in that my analyssi did not include the dead weight of the trailer. The robot still has to accelerate the trailer, but you also get some tongue weight transfer. The actual equation break down is like this:

F = (Mrobot + Mtrailer) * accel

Ff = (Mrobot + Mtongue) * g * Mu

Setting both sides equal to each other and simplifying:

accel = (Mrobot + Mtongue)/ (Mrobot + Mtrailer) * g * Mu


Let's assume tongue weight is negligible (it is actually really small). The equation breaks down to:

accel = Mrobot * g * Mu / (Mrobot + Mtrailer)

Our estimation of a trailer weight of 40 lbs and a robot weight of 150 lbs (120 + bumpers + battery) puts us at 150 / 190 so the accel is:

accel = 0.79 * g * Mu

Warren's estimate was pretty darn good at 75%. If your robot mass is less, then your ratio gets smaller and you will have a lower available acceleration.

This analysis assumes all of your robot wheels are driving. If you do not have all of your wheels driving, then you will have to decrease your acceleration even more.

Re: Implementing Traction Control for an advantage in the 2009 game
 

In terms of effective application of power, wouldn't using all 4 motors and independently driving each wheel be better for an electronic traction control system? I say this because with a system like that you would more easily be able to isolate the slipping wheel and you would not have to take power away from a wheel that is not slipping, whereas in a one motor per two wheel design if you detect either wheel as slipping your traction control system would take away power from one wheel that is slipping, but possibly also a wheel that is not slipping.

My second thought:

Its been mentioned several times that in the automotive world cars use the anti lock braking system to perform traction control duties. Couldn't a bicycle disk break be used with a pneumatic cylinder driving it to exhibit the same result? Although the system would use a good deal of air, I would think the added driveability would definitely be worth it this year.

My final thought:

If the problem we face is that Traction=Normal Force * Coefficient of friction, and we have now way to increase our coefficient of friction why not increase the normal force? Last year 1741 used a very small vacuum to great effect in capturing balls. Why not apply the same idea to a robot? The area of the robot (28 x 38) is 1064 square inches if even 1/2 psi vacuum is applied to that area that is over 500 pounds of downward force. I know Bill has said that he doesn't like this idea, but he didn't like the idea of launchers last year, and look how many teams did that.

p.s. I know that last part isn't really traction control but its an idea I had that I wanted to throw out there. I guess the thought was who needs traction control if you aren't lacking traction.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Back on a speed sensor (should this kick over to a different thread?), has anyone tried using the Ultrasonics in order to get Doppler effect? I plan on testing this this weekend, but if someone has already got some results to get us headed in the right direction, it would be great.

My thought is that if you use the Ultrasonic distance measuring sensors at an angle, they should measure different distance values for different speeds (doppler effect). What I hope my tests will show is whether or not there is enough range and resolution to get a decent speed measurement.

Addition:
Found this paper describing the physics and moth and testing results from someone elses experimentation.
http://cigr-ejournal.tamu.edu/submis...2001%20007.pdf

Re: Implementing Traction Control for an advantage in the 2009 game
 

As Adam Savage, Jamie Hyneman, and countless others have said,"Close enough." Mathematically you will never be able to create a differentiators using analog or digital components. It does not actually stop you from implementing systems like PID controllers. You just have to realize that the differentiators only acts like a differentiators at certain frequencies. I wonder how Labview implements analog filters because it does have the capability to use the Laplace transform but its an analog construct.
Going much farther would require the expertise of someone with his PHD. At the undergraduate level you really only learn how to implement linear control systems.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Not quite:
Max acceleration = CoF * g (ft/s^2)
dynamic: .05 * 32.174 = 1.6087
static: .06 * 32.174 = 1.93044
thus the 0-10ft/s times are:
dynamic: 10/1.6087 = 6.2162
static: 10/1.9304 = 5.1802
difference: 1.0359

That's just a bit over a second, a fairly significant difference. Not to mention the fact that preventing slip will improve handling.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Also at the end of 5 seconds one will be about 4 feet ahead of the other. Of course this is 24 vs 20 feetwhich means you have traveled about half way across the field.

Re: Implementing Traction Control for an advantage in the 2009 game
 

what might help would be to reverse one of the cims to make them both spin clockwise ( or counterclockwise i forget which way) any way electric motors favor one direction the other direction give less accl.

just a thought

also can someone correct me if im wrong ,because its been a while for me , isn't it just the torque that makes the wheels slip; and if so couldn't you simple create a drivetrain like a 4wd with a cim on each wheel and put a high gear ratio on it.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Therefore, max weight overpowered robots have most acceleration.
I get max acceleration of about 1.5 fpss, and top speed of 10fps,
which is top wheel speed of about [overstrike]32rpm [/Overstrike] 380rpm

Here are two opposite approaches to gear design to aid traction control:
- use little to no reduction on motors so that the peak motor torque is near the friction x torque on wheel. Highcurrent on slow speed motors.
Note Low rotational momentum of gear train, and high current deltas.
Jaguar speed controllers are reported to be better at low speed control.
I don't like this approach....

- use huge reduction (5000/32?) on motors so that the fuller range of motor speeds can be applied and more torque to drive wheel at exactly right speed.
No reason for wheels to ever go > 380rpm.
Note higher rotational momentum of gear train, but lower current deltas.

Re: Implementing Traction Control for an advantage in the 2009 game
 

CIM motors have no significant directional bias.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I finally have something to say and registered, it seems my OCD for computers ' and its peripherals' performance have a use!
Anyways, about mice: I was very ecstatic after I saw the first ever precise and quantified mouse benchmark published on esreality.com http://www.esreality.com/?a=longpost&id=1265679

In short, All mouses ARE NOT created equal, even if they are optical, laser, wireless, wired, high DPI. Many generic mouses(in my opinion) have a very low what esreality terms "malfunction speed", a maximum threshold speed when the mouse begins to report very inaccurate changes in position causing the cursor to seemingly go crazy or unresponsive. Luckily there are some very good mice made years ago that are still even one of the best today.
this benchmark was done in 2006
http://www.esreality.com/?a=longpost&id=1265679&page=21
This page shows all the mice and their perfect control and malfunction speeds on a graph.The best are the mx500 and mx300 capable of performing at 4 m/s if the usb polling rate is overclocked to 1000hz from 125hz; i'm not sure if the robot controller can do that.. I also have an mx518 that may be able to perform at those speeds according to this post http://forums.logitech.com/logitech/...17117#M17 117
Maybe the mx500, mx300, mx518, a4tech x7



hmm what do you mean by getting dirty? how?

Re: Implementing Traction Control for an advantage in the 2009 game
 

Yes, absolutely.I don't think [neumatic cylinders can react fast enough. Even a slow automotive system operates at 15 Hz, far above what a pneumatic system might achieve. Not only are you limited by the valves, air needs to flow and is compressible; pressuretakes time to reach a certain level - this is different from hydraulic systems.read Bill's Blog from January 6th.
Think dust bunnies: bits of hair, thread, and other crud; the object touching the floor but not rolling will act something like a broom, and stuff on the floor will clog up the optical sensor. Maybe not enough in one round, but it should be considered.

Re: Implementing Traction Control for an advantage in the 2009 game
 

I'm not sure who said it but i know some one mentioned before about using an accelerometer to sense drift and turn the wheels perpendicular to the direction of unwanted travel... my team also had a similar idea but threw it out ( for now) due to the fact that this will only make a difference if the deflection of the floor is a [i]relatively[i] significant amount.. We started to reconsider when we found the regolith is over the carpet (or so we've heard) but are still unsure if it will have any useful effect.. if the floor doesn't deflect enough you get the same effect by just locking the wheels, or are we misunderstanding this concept?

Re: Implementing Traction Control for an advantage in the 2009 game
 

If there is a project for trying to implement a common code base for the base of this an ABS-system-like idea, my team has a couple of programmers who would be willing to help... it could really be an interesting project to implement it together in a codebase for everyone

Re: Implementing Traction Control for an advantage in the 2009 game
 

Wow, what a thread. Wish I understood what half of it meant, although I did get a chance to learn the first, second, third derivatives of wheel positon are velocity, acceleration, and jerk.

We just started working on this today. We use a potentiometer to measure the rate the wheels are turning. If we see an increase of > 20% in the rate, we reduce the power to the wheels by 20%. Power keeps reducing until the rotational rate gets back below 20%.

May not be absolutely perfect, but we will hopefully get enough of an advantage to beat the teams that don't have traction control.

Unfortunately I think this puts us in the 'tinkerer' category isn't the second first derivative of tinkerer = engineer once you add in the velocity heading towards being able to calculate the results?

Re: Implementing Traction Control for an advantage in the 2009 game
 

Tinkerer + math => engineer

Re: Implementing Traction Control for an advantage in the 2009 game
 

We're going with a reverse-ABS route for our first attempt:
-If slippage detected, reduce motor power somewhat, then gradually increase it again

Slippage will be detected by comparing the reported acceleration of our encoders with the reported acceleration from our accelerometer.

Re: Implementing Traction Control for an advantage in the 2009 game
 

For the Tinkerers out there. Please keep one thing in mind. ABS, ESP, Stability control..... All of these get tuned by very skilled evaluator/engineers. I have a friend who does this work for Bosch. Testing and tuning is not simply tinkering, it is engineering. They do however had a pretty good idea of what their algoritms need to look like and then tune them in.

IKE

Re: Implementing Traction Control for an advantage in the 2009 game
 

This is the only field where being a tinkerer will mean that your robot will end up in twenty thousand little itty bitty pieces as it thrashes it around because your tinkering resulted in a system that mathematically would blow up the world (An Texas Instruments engineers words not mine) if it were not for the fact that your robot is powered by a battery.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Our programmer challenged our 2 year driver to try and beat the traction controlled robot from one side of our field to the other.
The driver lost EVERY time!!

In conclusion, implement it if you can........:D :D

Re: Implementing Traction Control for an advantage in the 2009 game
 

A potentiometer? Not exactly an optimal sensor, look up "encoder" for a better choice
The difference between a Tinkerer and an Engineer is that the Engineer will be able to tell you the results before you start.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Our team is looking into implementing an algorithm we found for a four-independent-wheel-drive electric vehicle ETS, using four encoders and a gyroscopic yaw-rate sensor. We will be enhancing it with the accelerometer to detect sideways skid and report to the driver, if not correct it.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Right now Warren B and I are trying to get our arms around Paul's "middle income" solution. But for those of you going for the "super rich" solution, I have found a few interesting places to look:

http://scholar.lib.vt.edu/theses/ava...ed/Thesis2.pdf

and here's some observer and alpha-beta filter explanations:

http://www.mstarlabs.com/control.html


Check out "rough Data, Smooth signals" and "When One feedback isn't enough"

I expect SPAM'll compete with the "middle income" solution at the Florida regional

cool stuff
Eric

Re: Implementing Traction Control for an advantage in the 2009 game
 

Hey, cool! I will definitely have the guys look in on those.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Just a note:
We went to implement our accelerometer/encoder solution last night, and it wasn't as good as expected. This was partly because I hadn't totally thought it through and thought that simply comparing accelerations was going to be sufficient. I failed to realize the obvious fact that the encoder acceleration would not STAY above the accelerometer acceleration for long, so it is not a good way of telling when the wheelspin stopped. It was an excellent way of telling when your wheel started spinning, but since you can't easily detect when they stop spinning, the algorithm as I described it is not ideal.

We're going to have to get a bit more complicated, with either an estimated velocity from the accelerometer or a trailing wheel to get this working properly.

Re: Implementing Traction Control for an advantage in the 2009 game
 

You can try integrating the acceleration signal to get velocity, and then comparing velocities to detect slip. The problem is that a noisy accelerometer signal looks even worse once it's integrated. For this and other reasons (one being the simplicity of an apples to apples speed comparison in code), non-driven encoder wheels lead to a better solution to this problem in my opinion.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Yeah, that's exactly what I'm thinking. Even with our rolling-average filtering, the accelerometer is ridiculously noisy.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Sounds like the legendary 1978 Brabam BT46B Formula 1 car which used an enormous fan underneath to generate a vacuum and more normal force. The car won the one race it ever competed in but was declared illegal

Re: Implementing Traction Control for an advantage in the 2009 game
 

We were given a +/-3g accelerometer, and our robots can accelerate at around +/- .05g (based on the published COF). Therefore, we can only use a ridiculously small portion of the range of the ADC.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Hi, i'm a rookie programmer this year, our team has gone with LabView. I was just wondering if anyone could explain to me how to filter the joystick to limit acceleration, and/or how the how the filtering will effect the acceleration.

Thanks in advance,
Charlie

Re: Implementing Traction Control for an advantage in the 2009 game
 

I used case structures in between the joystick subVIs and the drive VI. I believe I had one case structure to determine if the joysticks were at their "relaxed" position, then one to determine whether it was in a positive or negative position (foward and backwards), and finally one to determine if the output was equal to the input. Inside the last case structure, it the output was less than the input, it increases it by a constant value some each cycle of the while loop. There may be an easier way to do this, but this setup works exactly as we need it to.

Re: Implementing Traction Control for an advantage in the 2009 game
 

Gordon Murray's Brabham was copying Jim Hall's Chapparal 2J from 1970: http://www.photoessayist.com/canam/c.../chaparral.htm. It was a Can-Am racer that used a 45hp snowmobile engine to drive two ducted fans producing 1,000 pounds of static down force. If someone can move enough air with the limited power available I don't know why this wouldn't work for a FIRST robot. In some respects FRC robots have advantages over the "sucker" racers -- a perfectly flat "road" surface and no suspensions. I don't know how to do the math (sorry, Mark) on an aerodynamics problem like this, but a pair of CIMs driving 8-12" fans mounted vertically in cylinders open on the ends might generate some significant normal force. I wouldn't think it would approach 1,000 pounds, though.

EDITED: Here's a link to a Website of a model-builder who constructs battery-powered hovercraft: http://www.model-hovercraft.com/index.html. A hovercraft is only a Lunacy robot turned upside down.

Or... how about an electric hover-lawn mower? http://www.flymo.co.uk/node3126.aspx

Re: Implementing Traction Control for an advantage in the 2009 game
 

I can't locate the reference right now, but it was either a team update or a blog entry that said that down-force suction would not be allowed as the regolith is fairly fragile and any form of suction would deform and possibly damage the playfield resulting in a potential disqualification.

Before spending much time experimenting, you might want to investigate the updates, the blog, and the Q&A system.

Lynn (D) - Team Voltage 386

Re: Implementing Traction Control for an advantage in the 2009 game
 

It's in Bill's Blog for Jan. 4th.
http://frcdirector.blogspot.com/sear...&max-results=7

Re: Implementing Traction Control for an advantage in the 2009 game
 

Actually, the accelerometer seems good to us. But, there is definitely a LOT of mechanical noise on our chassis.....which the accelerometer dutifully reports.

Re: Implementing Traction Control for an advantage in the 2009 game
 

We've moved it onto a piece of foam to try and isolate it from the chassis, but due to a me-dropping-the-laptop incident this weekend, we haven't had a chance to see if it improved.

Re: Implementing Traction Control for an advantage in the 2009 game
 

With some help from a few mentors from my old team I did the math. Based on the horsepower output of a Cim motor your could use a fan that moves roughly 1000 cubic feet per minute. Two of those on the robot so 2000 cubic feet per minute. If you use the entire bottom surface of the robot leaving a 1/8" gap with the floor that is capable of generating a negative pressure of .72 psi multiplied across the area of the robot 1064 square inches that is approximately 766 additional pounds of down force. Added to the weight of the robot that is 886 pounds total downward force. I completely understand Bill's concern, but darn if it wouldn't be awesome to see.

The fan source I was considering is Cincinnati Fan Company.