Implementing Traction Control for an advantage in the 2009 game

[DonRotolo]

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 (http://www.hunter.com/PUB/undercar/901701/index.htm)(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 (http://www.ramseyelectronics.com/cgi-bin/commerce.exe?preadd=action&key=SG7)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.

.

[MrForbes]

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.

[sbrumund]

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.

[TheOtherGuy]

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.

[Adam Y.]

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?
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.

[DonRotolo]

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.
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.

[Otaku]

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.

[King Duke]

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

[d235j]

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

The CAN interface is not FRC-legal for 2009.

[Blair Frank]

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

[DonRotolo]

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 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."
What about using analog current sensors? Would that work, and provide the same functionality as the CAN interface?
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.

[cgredalertcc]

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.

[DonRotolo]

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.

[cgredalertcc]

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.

[DadDean]

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:)

[DSST\neal.ian]

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.

[lemon1324]

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.

[Ian Curtis]

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.

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.

[Qbranch]

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

[Uberbots]

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

[Daniel_H]

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.

[cgredalertcc]

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.

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.

[nickmagus]

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 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.
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.
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.

[EricS-Team180]

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.

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

[XXShadowXX]

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.

[Paul Copioli]

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.

[IKE]

EricS,

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.

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?

[Jared Russell]

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.

[Jared Russell]

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?

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.

[vansivallab]

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

[jgraber]

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

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.

[Doug Leppard]

Methods for doing traction control:



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.

[MikeE]

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.

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.

[Jared Russell]

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.

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.

[Jared Russell]

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.

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.

[DSST\neal.ian]

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

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

[EricVanWyk]

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.

[MikeE]

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.

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.

[Doug Leppard]

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.

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.

[Booksy]

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.

You're a jerk (http://en.wikipedia.org/wiki/Jerk_(physics))!:)

[Paul Copioli]

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.

[Joe Ross]

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 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

[Jared Russell]

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

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.

[DonRotolo]

How do you determine if a wheel is slipping when all four wheels are powered?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...

How about tracking the speed of a wheel and when the speed greatly increases more than normal what is expected bring the power back.Exactly the second derivative of wheel speed - the rate of wheel acceleration.

[Doug Leppard]

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

[keehun]

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

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

;-)

[DavidGitz]

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.

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.

[windell747]

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.

[XXShadowXX]

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.

[purduephotog]

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 similar 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.

http://cigr-ejournal.tamu.edu/submissions/volume3/PM%2001%20007.pdf

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

[EricVanWyk]

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 (http://www.amazon.com/Mattel-J2358-Hot-Wheels-Radar/dp/B000EHLB0M)?

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

[Dave Flowerday]

That got me thinking - why not use a radar gun (http://www.amazon.com/Mattel-J2358-Hot-Wheels-Radar/dp/B000EHLB0M)?
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.

[IKE]

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!

[Clinton Bolinger]

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-

[IKE]

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.



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".

[Tom Bottiglieri]

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?

[Clinton Bolinger]

Just make the wheel of the caster a Rover Wheel.

-Oris-

[Madison]

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".

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

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

[Warren Boudreau]

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.

[Justin Stiltner]

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.

[Mike Betts]

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?

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

[Tom Bottiglieri]

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
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.

[Mike Betts]

...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?...

Tom,

Check this (http://forums.usfirst.org/showthread.php?t=10182) out and you will see why I suggested the Jags... However, I have not been able to do any testing myself yet...

Regards,

Mike

[Jared Russell]

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.


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

[Paul Copioli]

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.

[cgredalertcc]

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.

[IKE]

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/submissions/volume3/PM%2001%20007.pdf

[Adam Y.]

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.
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.
This may break a linear filtering system and limit your max acceleration.
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.

[Lesman]

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.
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.

[IKE]

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.

[Dominicano0519]

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.

[jgraber]

All,
Warren is absolutely correct in that my analysis did not include the dead weight of the trailer. The robot still has to accelerate the trailer, ...

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.



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 32rpm 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.

[Alan Anderson]

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.

CIM motors have no significant directional bias.

[eatbuckshot]

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/board/message?board.id=general_mice&message.id=17117#M17117
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.

...
Maybe the mx500, mx300, mx518, a4tech x7


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.


... 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. ...
hmm what do you mean by getting dirty? how?

[DonRotolo]

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?Yes, absolutely.Couldn't a bicycle disk break be used with a pneumatic cylinder driving it to exhibit the same result? 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.Last year 1741 used a very small vacuum to great effect in capturing balls. Why not apply the same idea to a robot? read Bill's Blog (http://frcdirector.blogspot.com/)from January 6th.
hmm what do you mean by getting dirty? how?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.

[krupinski]

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?

[RandomStyuff]

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

[rsisk]

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?

[MikeE]

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?

Tinkerer + math => engineer

[Bongle]

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.

[IKE]

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

[Adam Y.]

Tinkerer + math => engineer
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.

[waialua359]

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

[DonRotolo]

We use a potentiometer to measure the rate the wheels are turning. A potentiometer? Not exactly an optimal sensor, look up "encoder" for a better choice
first derivative of tinkerer = engineer once you add in the velocity heading towards...
Tinkerer + math => engineer
The difference between a Tinkerer and an Engineer is that the Engineer will be able to tell you the results before you start.

[agmlego]

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.

[EricS-Team180]

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.

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/available/etd-05182004-215925/unrestricted/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

[agmlego]

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

[Bongle]

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.

[Jared Russell]

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.

[Bongle]

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.

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

[Rickertsen2]

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.

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

[Joe Ross]

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

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.

[Charlie_A]

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

[Lord Byron]

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
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.

[Rick TYler]

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

Gordon Murray's Brabham was copying Jim Hall's Chapparal 2J from 1970: http://www.photoessayist.com/canam/chaparral/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

[ldeffenb]

If someone can move enough air with the limited power available I don't know why this wouldn't work for a FIRST robot.

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

[rwood359]

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
It's in Bill's Blog for Jan. 4th.
http://frcdirector.blogspot.com/search?updated-max=2009-01-13T08%3A50%3A00-08%3A00&max-results=7

[DonRotolo]

Even with our rolling-average filtering, the accelerometer is ridiculously noisy.
Actually, the accelerometer seems good to us. But, there is definitely a LOT of mechanical noise on our chassis.....which the accelerometer dutifully reports.

[Bongle]

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

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.

[cgredalertcc]

Gordon Murray's Brabham was copying Jim Hall's Chapparal 2J from 1970: http://www.photoessayist.com/canam/chaparral/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

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.

[agmlego]

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

LabVIEW has a "Range and Check" (or something similar) block which allows you to cap a value to a range and/or check if it is in that range--may be useful to your purpose.

[Charlie_A]

LabVIEW has a "Range and Check" (or something similar) block which allows you to cap a value to a range and/or check if it is in that range--may be useful to your purpose.

Thanks, thats what we ended up doing.

----------------
Now playing: The Police vs. Rick James - Put On The Super Freak [Leebuzz] (http://www.foxytunes.com/artist/the+police+vs.+rick+james/track/put+on+the+super+freak+%5bleebuzz%5d)
via FoxyTunes (http://www.foxytunes.com/signatunes/)

[jgraber]

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.

A mechanical lowpass filter should theoretically help:
tightly couple the accelerometer to something massive (like the battery) and loosely couple that mass to the frame (mount in spongy foam).

[Rick TYler]

The difference between a Tinkerer and an Engineer is that the Engineer will be able to tell you the results before you start.

Until something goes all nonlinear on you -- then the Tinkerer with the duct tape gets you home.

I recommend "To Engineer is Human: The Role of Failure in Successful Design" by Henry Petroski for some good cases where engineers learn from the unintended consequences of engineering inadequately foretelling the future.

(And I know you know this, Don. I just love the idea of Red Green backing up engineers with his handyman's secret weapon.)

(Although My Father the Retired Aerospace Engineer swears he never built anything that didn't have "Missile Tape" on-board somewhere.)

[Mike Betts]

...I recommend "To Engineer is Human: The Role of Failure in Successful Design" by Henry Petroski for some good cases where engineers learn from the unintended consequences of engineering inadequately foretelling the future...

Rick,

I also have this book on my shelf. An excellent read...

Regards,

Mike

[FRC4ME]

I'm going to chime in here and say something that's been on my mind. Perhaps it has already been mentioned.

The coefficient of static friction of the rover wheels is 0.06.
The coefficient of kinetic friction is 0.05.

So, if we spend our six week build season implementing traction control, is it really worth it for an extra 120lb * 0.01 = 12lb of frictional force?

Or am I oversimplifying the physics...

[Paul Copioli]

One thing you must consider is that the dynamic coefficient of friction is actually related to speed. If you spin your wheels fast enough, your dynamic CoF will go down. If you are constantly spinning you will be pushed around by those that are not spinning their wheels.

[lemon1324]

The other thing to consider is that many people here on CD have been getting static/kinetic ratios much higher than the FIRST-published values.

Even given .06 against .05, it is a difference of 17-20% tractive force(depending on your reference value)

[jreuter]

If all we were worried about was linear accelleration, I've also wondered whether a 20% improvement is worth the complexity you add. However, there was a compelling post by one team who measured a 50% increase in turning time when slipping vs. when not slipping wheels.

[KilroyLaxer]

Ok, so first off i'd like to say I'm diggin' this thread. I <3 this thread.

Now down to business. So, my team thought up traction control once we found out the game. We thought about having pulsing wheels that are activated off of the controller and having the z-axis control how long the time is between pulses. And we have that working, BUT unfortunately that was based upon the assuption (or lie) that we had free spinning wheels on the bot,and of course with my luck, we do not. Now, we thought instead of using an accelerometer and graphing its outputs to determine the greatest amount of acceleration before slippage (usually occuring at the beginning, also known as breakaway friction.) and using it as a point to reach complete controlability for one half of the pulsing and the other being to run both wheels at a very low input. And of course, with my luck, when we do graph said acceleration, it has impossibly tough-to-tell results. So, i have a couple questions. 1. Does anyone know how to make a working graph that would average out the noise we have and give us a good base reading? 2. Is there any other way of working this only using the accelerometer?

[Gdeaver]

Our team has impemented filtering of the joystick inputs. While not as good as sensor feed back type traction control, the improvements are quite obvious. It's also less complex. For those who are using sensor feed back remeber that the control loop is going to be disturbed heavily by impacts.

[JesseK]

Are there any teams who are doing driver-based traction control?

- edit - (like this)
Our team has impemented filtering of the joystick inputs. While not as good as sensor feed back type traction control, the improvements are quite obvious. It's also less complex. For those who are using sensor feed back remeber that the control loop is going to be disturbed heavily by impacts.

I.e. rather than a direct 1-to-1 magnitudal relationship from the joystick to the motor outputs, there is more of a geometric or exponential scalar applied? That way, the motors really only apply the full torque when the joystick is out on the perimeter, whereas halfway the software only sends, say 20% torque. Drivers could learn how and when to slow things down vs. the software doing wonky acceleration/decceleration 'detection' algorithms that are hard for the drivers to get used to.

Maybe it's dependent upon what the drivers are comfortable with, but I would think that I could 'feel' the way the robot handles alot faster and better than software could, and with alot less hassle. I mean, true slip detection is very hard to add in to a control algorithm if you don't have all independently-controllable wheels, or at least have electronically-controlled differentials in between them...and proper weight distribution plays a huge role too... Maybe that could be a new 'control' feature -- a force-feedback system that the driver wears to physically simulate the g-forces on the robot.

Hmm, maybe it's just me and my racing experiences talking here, and the fact that I'm a control nut when it comes to my car.

[KilroyLaxer]

Are there any teams who are doing driver-based traction control?

- edit - (like this)


I.e. rather than a direct 1-to-1 magnitudal relationship from the joystick to the motor outputs, there is more of a geometric or exponential scalar applied? That way, the motors really only apply the full torque when the joystick is out on the perimeter, whereas halfway the software only sends, say 20% torque. Drivers could learn how and when to slow things down vs. the software doing wonky acceleration/decceleration 'detection' algorithms that are hard for the drivers to get used to.

Maybe it's dependent upon what the drivers are comfortable with, but I would think that I could 'feel' the way the robot handles alot faster and better than software could, and with alot less hassle. I mean, true slip detection is very hard to add in to a control algorithm if you don't have all independently-controllable wheels, or at least have electronically-controlled differentials in between them...and proper weight distribution plays a huge role too...

Hmm, maybe it's just me and my racing experiences talking here, and the fact that I'm a control nut when it comes to my car.


Lol yeah, for the efforts of being lazy, that was my first suggestion, but everyone else decided we wanted "intuitive" controls, or in the words of one of the team members " We want this robot to be able to be driven by a ferret." So, yea, more work for me.

[MrForbes]

Has anyone tried simply detecting a sudden increase in drive wheel speed and modulating motor control based on that? I'm dying to see if it'll work for simple straight acceleration....haven't conned the electronics/programming team into getting the encoders wired up and trying to write some code yet...

[thefro526]

I think this was mentioned above but I'm not sure. On my team we discussed having a progressive acceleration function where it would limit the acceleration of the bot. We were thinking that if the driver went from zero value to a full throttle the code would progressively accelerate the wheels up to the desired speed. We think it'll work but if not we may pursue something else.

[dani190]

Has anyone tried simply detecting a sudden increase in drive wheel speed and modulating motor control based on that? I'm dying to see if it'll work for simple straight acceleration....haven't conned the electronics/programming team into getting the encoders wired up and trying to write some code yet...


I will try it when i get into the shop today. Il try and post back when i can and give u guys an update on weather or not that works...

[Phazonmutant]

Just read over the thread, here's some thoughts from a 2nd-year team member: (warning, long)

1) For the teams that don't have mentors experienced or trained in engineering, it's difficult to understand how signal processing and sensors play together. For example, I've never even heard of things like high-pass or low-pass filtering - I thought accelerometers returned pretty decent values. Therefore, it seems like what we're going to go for is the simple solution that's been mentioned - limiting the rate of change of the joystick.

Regarding that, if you dig into the Jaguar.cpp class, the SetSpeed method (I believe) has an exponential curve implemented by default. It shouldn't be too hard to modify this to have a variable curve.
Specifically:
The Atack3 joystick has a "throttle" knob below the joystick. In the default code, this switches between Arcade and Tank, but I'm pretty sure custom code won't do this (haven't actually checked though). If that's the case, it should be simple to have the knob set a curve power that you pass into the SetSpeed method.

That may be a little unclear, so just to explain - the SetSpeed method essentially performs this function on the passed speed:
f(x) = x^p,
where x is the (passed) speed and p is the passed power, f(x) is the speed going to the motor.
By default, p=2. The knob could set this to be anywhere from 1 to say 5. The slope of this curve will be increasing for p>1. As p increases, the slope increases faster; that is to say, the second derivative of f(x) is more positive.

If I understand the formula correctly, though, you'll need to add a coefficient for each p that fits the curve to the 0-255 range that the jaguars can accept. However, the SetSpeed method is called for both autonomous drive and teleop (which raises the question of why there isn't the coefficient...). So, given that the joystick ranges from 0-100 on a given axis, you'll have to adjust the passed speed in the Drive method. I haven't quite worked this out, but I think the basic concept is sound.

Theoretically, the benefits to this approach are (a) a simple-to-understand and code change that can (b) produce a much more fine-tuned traction control system that doesn't involve complicated sensors.
Also, this would be simple enough to code for turning, too.

2) Our team considered having the wheels mounted on two axles that pivoted opposite of each other (ex. front turns clockwise while the back turns counterclockwise to turn the robot right), but after calculating the turn radius (especially with the trailer), it wasn't deemed worth it. Has anyone actually built something like this?

3) Just to clear up some confusion regarding the "minor" gains from traction control: Other people have pointed out that just looking at the difference in dynamic and static friction is oversimplistic, but that's not even the main reason to use traction control. Wheels deliver negligible power when they're slipping, so the main goal of a traction control system is to limit slippage. This has the benefit of improving handling.

4) If the accelerometers are noisy, wouldn't differentiating their output to get jerk result in even more noisy data? Also, question for those who don't have a problem with noisy accelerometers - do you buy custom ones?

5) Would calibrating the motors result in increased performance? How would one go about that?

[Doug Leppard]

Has anyone tried simply detecting a sudden increase in drive wheel speed and modulating motor control based on that? I'm dying to see if it'll work for simple straight acceleration....haven't conned the electronics/programming team into getting the encoders wired up and trying to write some code yet...

This is what we have done. that was the reason for our three wheel bot proto type that I posted.

We allow up to 20% slipage of the drive wheel, if it goes above that the computer backs off the power.

Now the driver never has to worry about pushing power too far, the computer controls that both in accelerating and de-accelerating. I saw the test bed this weekend, pretty cool.

We haven't put it in the four wheel bot yet, but I suspect it will help our turns also.

I think the bots are drivable without traction control, but it makes a big difference and takes the load off the driver.

[rwood359]

Now the driver never has to worry about pushing power too far, the computer controls that both in accelerating and de-accelerating.
I haven't figured it out yet, but I'm having more trouble controlling deceleration than acceleration.

[Jared Russell]

Just read over the thread, here's some thoughts from a 2nd-year team member: (warning, long)

1) For the teams that don't have mentors experienced or trained in engineering, it's difficult to understand how signal processing and sensors play together. For example, I've never even heard of things like high-pass or low-pass filtering - I thought accelerometers returned pretty decent values. Therefore, it seems like what we're going to go for is the simple solution that's been mentioned - limiting the rate of change of the joystick.

Regarding that, if you dig into the Jaguar.cpp class, the SetSpeed method (I believe) has an exponential curve implemented by default. It shouldn't be too hard to modify this to have a variable curve.
Specifically:
The Atack3 joystick has a "throttle" knob below the joystick. In the default code, this switches between Arcade and Tank, but I'm pretty sure custom code won't do this (haven't actually checked though). If that's the case, it should be simple to have the knob set a curve power that you pass into the SetSpeed method.

That may be a little unclear, so just to explain - the SetSpeed method essentially performs this function on the passed speed:
f(x) = x^p,
where x is the (passed) speed and p is the passed power, f(x) is the speed going to the motor.
By default, p=2. The knob could set this to be anywhere from 1 to say 5. The slope of this curve will be increasing for p>1. As p increases, the slope increases faster; that is to say, the second derivative of f(x) is more positive.

If I understand the formula correctly, though, you'll need to add a coefficient for each p that fits the curve to the 0-255 range that the jaguars can accept. However, the SetSpeed method is called for both autonomous drive and teleop (which raises the question of why there isn't the coefficient...). So, given that the joystick ranges from 0-100 on a given axis, you'll have to adjust the passed speed in the Drive method. I haven't quite worked this out, but I think the basic concept is sound.

Theoretically, the benefits to this approach are (a) a simple-to-understand and code change that can (b) produce a much more fine-tuned traction control system that doesn't involve complicated sensors.
Also, this would be simple enough to code for turning, too.

2) Our team considered having the wheels mounted on two axles that pivoted opposite of each other (ex. front turns clockwise while the back turns counterclockwise to turn the robot right), but after calculating the turn radius (especially with the trailer), it wasn't deemed worth it. Has anyone actually built something like this?

3) Just to clear up some confusion regarding the "minor" gains from traction control: Other people have pointed out that just looking at the difference in dynamic and static friction is oversimplistic, but that's not even the main reason to use traction control. Wheels deliver negligible power when they're slipping, so the main goal of a traction control system is to limit slippage. This has the benefit of improving handling.

4) If the accelerometers are noisy, wouldn't differentiating their output to get jerk result in even more noisy data? Also, question for those who don't have a problem with noisy accelerometers - do you buy custom ones?

5) Would calibrating the motors result in increased performance? How would one go about that?

1) I don't think that this system as I understand it would actually implement any "traction control", per se. Rather, it would result in a different mapping of joystick position to motor speed (which may or may not be helpful). But throwing the stick forward will still result in slip.

2) Yep, this pic was posted not long ago: http://www.chiefdelphi.com/media/photos/32590

3) This is true. Traction control will affect your overall acceleration ability, but handling is usually the bigger benefit.

4) Yes, differentiating a noisy signal will give you garbage. Differentiation is essentially a high-pass filter, and "noise" tends to be high in frequency.

5) Calibrating the speed controllers will help your motors to behave more linearly. This will help ensure that any assumptions you made about their dynamics are closer to reality. That said, all of the speed controllers should come calibrated.

[Gdeaver]

A simple moving average filter of the joystick inputs works well. For those who are coding in C this isn't to bad an algorithm to code. There are a couple forms of moving averages to play with. The number of averaged samples and the sampling rate can allow tunning. For those using Labveiw it's real easy. Just drag, drop and wire. Play with the constants to get the feel you want. This is just controlling the rate of change. In Labview there about 5 filters that could be used however only 2 yield good results. The great thing about Labview is you can graphically watch the behavior. Our filter is working well and allows even the kids who are button smashers to drive. One thing is that it doesn't do as much good for is stopping. We always slide a little. I would suggest that all teams make an effort to apply some form of traction control. With out it it's going to be hard to play the game.

[Dominicano0519]

CIM motors have no significant directional bias.

yes they do
correct me if im wrong but if you put a cim rotating clockwise on one side and vive versa the clockwise side will go faster therefore creating a right-handed turn

[Mike Betts]

yes they do
correct me if im wrong but if you put a cim rotating clockwise on one side and vive versa the clockwise side will go faster therefore creating a right-handed turn

Actually, Alan is correct. The directional bias on a CIM, although not zero, is so negligible that it is almost unmeasurable.

What is far more common, historically, is that one side of your robot will have more friction than the other. However, this year we have added Jaguars into the mix. The neutral PWM for a Victor and a Jaguar are not the same and the software must match the hardware or you will see significant discrepancies.

Regards,

Mike

[bronxbomber92]

For people who are doing simple traction control by filtering the joysticks, are you all basically recording the last joystick value, and then comparing it to the current one, and if the difference is too large you'll cap it out at a certain maximum?

[weinbergmath]

That's exactly what we're doing - I previously posted a VI that uses shift registers to compare the old motor output values to the new reading on the joystick - located at http://www.chiefdelphi.com/forums/showthread.php?t=73009

I think it's the simplest way to do it - thus far, it has worked quite well.

good luck,

Evan

[prometheoid]

It seems almost criminal not to mention that it's possible to take values from the drop in electrical potential from one side of the motor fuse to the other. After applying a physical or code implemented low pass filter, the value returned is actually just a flat DC voltage that increases proportionally to the current drawn by the motor. A bit tricky to implement, but as far as being "poor man's traction control," at about $2 per motor or less it'd be a shame not to try.

[Alan Anderson]

It seems almost criminal not to mention that it's possible to take values from the drop in electrical potential from one side of the motor fuse to the other.

It's a great idea, but it violates the electrical rules. Custom circuitry must be powered through a circuit breaker. It can't connect to the battery side of a breaker. You'd need your own sensing element -- say, a foot-long length of wire.

[prometheoid]

Is it considered powered? Or is it basically like a potentiometer?

Argh.
<R46>
A. Each speed controller branch circuit must be protected by one and only one 20-amp, 30-
amp, or 40-amp circuit breaker on the Power Distribution Board. No other electrical load
can be connected to the breaker supplying this circuit.

<R44> Custom circuits shall NOT directly alter the power pathways between the battery, Power
Distribution Board, speed controllers, relays, motors, or other elements of the robot control
system (including the power pathways to other sensors or circuits). Custom high impedance
voltage monitoring or low impedance current monitoring circuitry connected to the ROBOT’S
electrical system is acceptable, because the effect on the ROBOT outputs should be
inconsequential.

<R66> Inputs to custom circuits can be connected only to the following sources:
A. Power Distribution Board protected 12Vdc outputs


The only real information I've found is in the "suggestions" PDF, and it just says to use good engineering judgment. Since the Analog breakout can handle direct motor current to measure battery level, engineering judgment tells me that it has sufficient internal impedance to handle this job without worry. The voltage I measure is maxing out around 60 mV, and since current isn't an issue..... :confused:

I think this has become a Q&A question.... ha. Then Again, maybe I'm overthinking this and it's just illegal, like you said.

[eugenebrooks]

On the current measurement front, just order yourself a pair of 620-1106-ND current sensors from Digikey and hook them up. This goes in line with the power leads to the motor and has three pins that you can hook your pwm cable to for the analog input. You can pot it in epoxy after soldering the wiring to it. You might want to filter the output of the sensor as it will follow the chopped current to the motor nicely.

Eugene

[FRC4ME]

I'm wondering why everyone seems to be focused on measuring current. As far as I know, the equation we need (which calculates the amount of torque you are applying to the wheel, which cannot exceed the force of friction pushing back or you will slip) involves only voltage and angular velocity, not current.

http://www.gizmology.net/motors.htm

Could someone who is using current sensing in their traction control clue me in on how you are doing that?

[Ian Curtis]

I'm wondering why everyone seems to be focused on measuring current. As far as I know, the equation we need (which calculates the amount of torque you are applying to the wheel, which cannot exceed the force of friction pushing back or you will slip) involves only voltage and angular velocity, not current.

http://www.gizmology.net/motors.htm

Could someone who is using current sensing in their traction control clue me in on how you are doing that?

Current is a function of wheel velocity. When the wheel begins to slip, the motor will spin faster and draw less current. As long the as change in current draw was sharp enough, I'd imagine it could potentially be simpler than measuring your velocity relative to the floor.

[Doug Leppard]

Current is a function of wheel velocity. When the wheel begins to slip, the motor will spin faster and draw less current. As long the as change in current draw was sharp enough, I'd imagine it could potentially be simpler than measuring your velocity relative to the floor.

I think it would be so diificult to measure this acurately using current draw, but again maybe it is possible.

We have ATC using an encoder wheel on the floor. We found you can have 50% slippage and still have good traction. found 20% is best slippage for maxiumu speed and traction.

So maybe with that much variation using current it is possible.

[Jared Russell]

We have ATC using an encoder wheel on the floor. We found you can have 50% slippage and still have good traction. found 20% is best slippage for maxiumu speed and traction.

I also discovered this. It was sort of disappointing. I applied postgraduate-level dynamics and control theory to create a mathematically nearly-optimal traction control system, then found that just low-pass filtering the inputs and outputs of my velocity control PID loop gave almost identical functional performance.

If anyone ever needs to kill a fly with a flamethrower - you know where to find me!

[Doug Leppard]

I also discovered this. It was sort of disappointing. I applied postgraduate-level dynamics and control theory to create a mathematically nearly-optimal traction control system, then found that just low-pass filtering the inputs and outputs of my velocity control PID loop gave almost identical functional performance.

If anyone ever needs to kill a fly with a flamethrower - you know where to find me!

The current tracking is an interesting concept and maybe it will work when you are accelerating.

But what about decelerating? Slowing down in a controlled manner is just as important as speeding up. I am not sure how you apply current tracking to control slowing up. Possibly with some well defined current flow you could.

Like someone already asked, I would like to hear from someone that has already done it.

[Daniel_LaFleur]

Current is a function of wheel velocity. When the wheel begins to slip, the motor will spin faster and draw less current. As long the as change in current draw was sharp enough, I'd imagine it could potentially be simpler than measuring your velocity relative to the floor.

Almost correct.

Current is a function of wheel torque, not wheel velocity.

[eugenebrooks]

Almost correct.

Current is a function of wheel torque, not wheel velocity.

Daniel is wise, you should pay attention to him.

Eugene

[prometheoid]

Doug-- Because of the weird resonances between the pwm outs and the motor kick-back, the amperage ranges wildly as you accelerate and decelerate, making it tricky to determine slip. You could potentially compare the values to a baseline, and if it's higher or lower adjust the pwm output.(baseline determined in conjunction with accelerometer...?)

[Doug Leppard]

Doug-- Because of the weird resonances between the pwm outs and the motor kick-back, the amperage ranges wildly as you accelerate and decelerate, making it tricky to determine slip. You could potentially compare the values to a baseline, and if it's higher or lower adjust the pwm output.(baseline determined in conjunction with accelerometer...?)

That is why I think it would be difficult at best. We use an undriven wheel with an encoder to test agaisnt the speed of the driven wheel.

I would like to hear about someone who had used tracking current and how it worked or didn't work.

[marccenter]

I think it would be so diificult to measure this acurately using current draw, but again maybe it is possible.

We have ATC using an encoder wheel on the floor. We found you can have 50% slippage and still have good traction. found 20% is best slippage for maxiumum speed and traction.

So maybe with that much variation using current it is possible.

So, you guys appear to have validated the following file attachments obtained from some of my colleagues who are presently enrolled in an Hybrid-Electric vehicle class at UofM-Dearborn.

[Jared Russell]

So, you guys appear to have validated the following file attachments obtained from some of my colleagues who are presently enrolled in an Hybrid-Electric vehicle class at UofM-Dearborn.

I love it when science works right!

[Doug Leppard]

So, you guys appear to have validated the following file attachments obtained from some of my colleagues who are presently enrolled in an Hybrid-Electric vehicle class at UofM-Dearborn.

What is surprises me is that the difference between asphalt, wet asphalt and regolith is about the same for the slippage factor and traction. You would think it would be a greater difference between surfaces.

[eugenebrooks]

If you could accurately measure average motor current, and therefore motor torque, given the typical longitudinal traction curve shown in the plot posted earlier, just what would you be inspired to do?

Eugene

[prometheoid]

Correct me if I'm wrong, but I believe that this works:
I'd make a table of a few test values, finding the current draw at various pwm outputs with no slip, and then have my program look for a result that was more than twenty percent less current draw than the values in the table. Since speed and current are inversely proportional this should mean that the motor is spinning more than 20% faster than normal loaded speeds-- hence spinning out. I'd then have it decrease the wheel speed(move the pwm output towards neutral), and then check the wheel for slip again, adjusting as necessary until 20% slip was achieved. Sort of a recursive algorithm.
Basically, since the current draw means nothing by itself, test values must be taken. They probably even vary from motor to motor.
And as for decelerating.... I think that has to be a joystick filter thing. Not much you can do with currents alone.


By the way Eugene, thanks for the current sensor tip. I'm still checking the legality of my method, but it looks like the output from those ICs will even work with the program we have(just new test values). :]

[eugenebrooks]

Don't you just want to maximize torque and let the wheel slip
take care of itself? Imagine your self somewhere on the x axis
of the first curve and adjust the motor PWM drive (which will
adjust the slip) in the direction of increasing average current.
Where do you end up?

In the case that you want a specific torque that is less than
the maximum there are two spots on the curve and you might
prefer the one on the left.

Why is the situation any different when braking, as long
as the current is going through the current sensor?

Don't forget to install a suitable RC filter on the output of the
current sensor. For Jaguars with their very high chop rate
it might not matter. For the Victors that chop at 120 hz it will
matter...

Eugene

Correct me if I'm wrong, but I believe that this works:
I'd make a table of a few test values, finding the current draw at various pwm outputs with no slip, and then have my program look for a result that was more than twenty percent less current draw than the values in the table. Since speed and current are inversely proportional this should mean that the motor is spinning more than 20% faster than normal loaded speeds-- hence spinning out. I'd then have it decrease the wheel speed(move the pwm output towards neutral), and then check the wheel for slip again, adjusting as necessary until 20% slip was achieved. Sort of a recursive algorithm.
Basically, since the current draw means nothing by itself, test values must be taken. They probably even vary from motor to motor.
And as for decelerating.... I think that has to be a joystick filter thing. Not much you can do with currents alone.


By the way Eugene, thanks for the current sensor tip. I'm still checking the legality of my method, but it looks like the output from those ICs will even work with the program we have(just new test values). :]