Implementing Traction Control for an advantage in the 2009 game

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

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

Originally Posted by King Duke

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]

Originally Posted by 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

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

Originally Posted by Blair Frank

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]

Originally Posted by 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.

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.

[cgredalertcc]

Originally Posted by 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.

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.

[DSST\neal.ian]

Originally Posted by 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.

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

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