View Full Version : Team 121 Traction Control
Tom Schindler
31-01-2009, 23:06
A demonstration of the traction control software by team 121:
http://www.tomschindler.net/2009_TC.php
Good luck everyone!
Tom
=Martin=Taylor=
31-01-2009, 23:12
The difference: BIG!
What kind of feed-back are you using? Encoders on the tough boxes?
Is there some kind of "mechanical traction control" (under gearing) as well? What ratios are you running?
Woody1458
31-01-2009, 23:13
what method are you using for slip detection? I'm assuming since u were mentored by 148 it is a ground sensor vs motor encoder?
Akash Rastogi
31-01-2009, 23:17
Woot!
Ours is working well too. Great to see that you guys are performing the same as well. :)
Seat Ninja
31-01-2009, 23:18
Nice. Is that programming only, or are there some accelerometers in there?
EDIT: wow like 5 posts at the same time
nnfuller
01-02-2009, 00:06
So what kind of weight is on that robot in the video? and how does it do with pushing something?
It's week four,
Shouldn't you guys be done the whole robot by now?
It's week four,
Shouldn't you guys be done the whole robot by now?
No, not really. Well we aren't, but we will be done by this upcoming Sat.
Michael Corsetto
01-02-2009, 02:27
No, not really. Well we aren't, but we will be done by this upcoming Sat.
I believe Chris is referring to how quickly 121 had a competitive robot last season, it was on youtube and scoring in week 3. Just slightly intimidating :p
Akash Rastogi
01-02-2009, 02:29
No, not really. Well we aren't, but we will be done by this upcoming Sat.
121 is one of the beastliest teams that uses the kit frame. They are fast and efficient.
121 is one of the beastliest teams that uses the kit frame. They are fast and efficient.
I should so join a east coast team.:rolleyes:
Sean Raia
01-02-2009, 10:18
Nice. Was it hard to implement the traction control?
sybert1ger
01-02-2009, 13:01
While we are not as far ahead as we were last year, we are still making good progress.
HELLOOooo from the North East to the North East :D
Yep its me old MOE your bot looks great:yikes: , But what else would be new as you always have one of the best around. Keep up with the super job and WE will meet up some place I am sure... Good Luck to all the teams and see ya sooooon !!!!:ahh:
MOE and Team 88 TJ2 oh yeah ???? OH YEAH !!!! TJE DYE for ever....
Billfred
01-02-2009, 16:20
If this doesn't sell teams on the advantages of traction control, I don't know what does.
Thats pretty awesome. I have one question though, what kinda feed back are you using from the robot to use your traction control off of. We have some ideas and want to see how others are doing it.
gorillamonky
01-02-2009, 18:27
Can you explain what you mean by traction control? Like, what was different between traction control and non-traction control?
gorillamonky
01-02-2009, 18:28
What surface are you using? Is the the real "regolith" material that will be used in the crater?
Can you explain what you mean by traction control? Like, what was different between traction control and non-traction control?
Traction control basically senses if your wheels are spinning and if you're moving. If the wheels are just spinning and you aren't moving it slows the wheels until the robot starts to accelerate.
And yes, it appears to be regolith from what I can see
skidmarks
02-02-2009, 00:37
How did you do it? I'm asking all teams with working traction control. I see traction control threads, but as of yet I don't see one where someone says how they successfully did it.
sanddrag
02-02-2009, 03:54
I too would enjoy hearing the mechanism/electronics and logic used to achieve this result.
windell747
02-02-2009, 05:29
Great work! The traction control performs better than I thought! It also looks like you're controlling two wheels with one motor! Much simpler than four wheel drive and it still seems to do quite well! I'm dying to know if you guys used the accelerometer or an idler encoder wheel as feedback. Again, great job!
Anne Shade
02-02-2009, 08:29
That's a nice encoder / idler wheel setup you've got under there. Looks mighty familiar. I wonder where I've seen it before.....
XXShadowXX
02-02-2009, 08:40
I count 5 wheels in contact with the ground. Big difference looks good. The only good video our team has of traction control is when i got stuck in the ditch heading home from a meeting...
I too would enjoy hearing the mechanism/electronics and logic used to achieve this result.
There are generally two ways of achieving traction control.
1) wheel based; uses a 5th wheel (or 7th), high traction wheel to get the speed of the robot (this is legal, per a Q&A post by the GDC), then it compares the speed that the traction wheel is turning at (the speed of the robot), and the speed of the other wheels (that drive the robot), and it attempts to get them spinning at the close to the same speed so your CoF (friction constant) gets closer to the static friction CoF (a different friction constant, larger by definition), to better the drive the robot.
2) accelerometer based; integrates the accelerometer input to get velocity, instead of the using a spare wheel..
that is how Traction control works in FRC (or at least how my team is doing it)
Tom Schindler
02-02-2009, 08:58
What surface are you using? Is the the real "regolith" material that will be used in the crater?
Yes, this is the actual field surface.
Nice. Was it hard to implement the traction control?
The theory is simple, actually implementing it is a bit harder. The basic concept is, throttle back an appropriate amount when your ground speed is less than your wheel speed (indicates your wheels are spinning).
Ground speed can be calculated by either a follower drag wheel, or an accelerometer. We're using the follower wheel.
How did you do it? I'm asking all teams with working traction control. I see traction control threads, but as of yet I don't see one where someone says how they successfully did it.
I too would enjoy hearing the mechanism/electronics and logic used to achieve this result.
At this point the software is only reading 4 encoder inputs, 2 on each AndyMark gearbox, and 2 in the follower drag wheels. We have current sensors mounted, and in the coming days/weeks we hope to have a finer control of maintaining the delicate balance between maximum acceleration, and spinning out of control (it's a very fine line).
There are many good articles/thesis papers online that have incredibly detailed technical workings of how to successfully implement this. We obviously aren't the first to come up with this kind of system, i'm sure many teams will have similar systems. Maybe this year in Atlanta we can have a robot pushing competition after hours.
That's a nice encoder / idler wheel setup you've got under there. Looks mighty familiar. I wonder where I've seen it before.....
Why re-invent the (follower) wheel?
It's week four,
Shouldn't you guys be done the whole robot by now?
Getting there :)
Michael Corsetto
02-02-2009, 10:45
At this point the software is only reading 4 encoder inputs, 2 on each AndyMark gearbox, and 2 in the follower drag wheels. We have current sensors mounted, and in the coming days/weeks we hope to have a finer control of maintaining the delicate balance between maximum acceleration, and spinning out of control (it's a very fine line).
Does this set up make it easy to write traction control programs for turning, since you have a follower wheel for each side of your skid steer drive train? Definitely proof that traction control makes a huge difference, thanks for posting the video!
very nice how long did the code take your team?
Jared Russell
02-02-2009, 14:13
Many thanks for sharing this. It provides a benchmark comparison that will be invaluable to my team and to others.
I can't watch the video yet; work has most team sites blocked since they're not categorized as 'safe' (they're just 'none'). So I'll see it in a few hours. Now, I say this next statement because I know our programmer lead who's at the school right now may watch this video and perhaps forget that there are still many other things to be done that have a higher priority...
Make sure you guys/gals are sticking to your goals and strategies -- retrogressing just to get a third-order traction control system implemented will severely hinder your progress, and therefore your overall performance. If you have a plan and traction control wasn't included, stick to the plan (but perhaps speed it up a bit ;)). We're in this situation, but tonight we made huge progress so maybe we'll have a little bit of time left over around ship date.
skidmarks
02-02-2009, 21:19
I'm going off topic from this team, but has any other team had success with traction control without an idler wheel? If so, please share! I am interested in hearing other success stories.
AlexD744
02-02-2009, 23:45
Awesome turns.
It's week four,
Shouldn't you guys be done the whole robot by now?
Are you kidding it took like us until the end of week thrree to start building.
windell747
03-02-2009, 05:57
How do you ignore the backlash within the gearboxes?
JamesBrown
03-02-2009, 08:47
I'm going off topic from this team, but has any other team had success with traction control without an idler wheel? If so, please share! I am interested in hearing other success stories.
A similar algorithm can be used by using an accelerometer. By integrating acceleration you can get speed, this is the same information you would be getting from the idler wheel (combining rotational and linear speed can give you the difference in speed between the two sides of the bot with tank drive. comparing this to wheel speed measured by encoders (or estimated wheel speed based on pwm values) can indicate slip.
As a warning, error will compound much faster with the accelerometer method than with a follow wheel.
-James
Chadius012
03-02-2009, 18:33
Can you post the program that you are using for the traction control, please :D
The difference between the two modes is huge!!! :ahh: :ahh: :ahh:
traction control.... ahhhh;)
Can you post the program that you are using for the traction control, please :D
The difference between the two modes is huge!!! :ahh: :ahh: :ahh:
So you feel entitled to get that "huge" advantage without any work?
skidmarks
03-02-2009, 21:53
A similar algorithm can be used by using an accelerometer. By integrating acceleration you can get speed, this is the same information you would be getting from the idler wheel (combining rotational and linear speed can give you the difference in speed between the two sides of the bot with tank drive. comparing this to wheel speed measured by encoders (or estimated wheel speed based on pwm values) can indicate slip.
As far as I know, the accelerometer is way too noisy and inaccurate to result in an accurate velocity, much less get the velocity accurate enough to estimate the percentage of slip.:( If anyone has successfully done this, however, please tell! We are interested if anyone else has successfully done traction control without an idler wheel.
JamesBrown
03-02-2009, 23:03
As far as I know, the accelerometer is way too noisy and inaccurate to result in an accurate velocity, much less get the velocity accurate enough to estimate the percentage of slip.:( If anyone has successfully done this, however, please tell! We are interested if anyone else has successfully done traction control without an idler wheel.
It has been done, I am speaking from experience, not just offering a theoretical understanding. The kit accelerometer is not perfect but it will suffice. Alternatively you can purchase an more reliable one.
nathanww
03-02-2009, 23:22
One doesn't neccesarily need to know velocity to use the accelerometer for TC--after all, traction control is all about maximizing your acceleration, and an accelerometer measures acceleration. 1678 is currently using a system whereby the program checks that a large shift in acceleration on the joystick is corroborate by an actual shift, and if it's not we then start ramping down wheel speeds until we gain traction or we hit a timeout. It works pretty well on our field analouge(the gymansium floor), but not that well on carpet(something keeps in stuck in low-power mode for some reason)
gorillamonky
04-02-2009, 20:34
So you feel entitled to get that "huge" advantage without any work?
gracious professionalism?
our programming team is primarily first years
gracious professionalism?
our programming team is primarily first years
So because you think your programming team can't do it you feel like someone should hand you a finished solution? Have your programmers tried to work on traction control? I'm not a code guy (I just play with gears) but I've heard that it's not that difficult to make a pseudo successful traction control algorithm. There is even an entire thread of people discussing ways to do this sort of thing.
Perhaps your first year programmers can read the thread, take a stab at it, and then ask for additional guidance from the community. I know lots of teams would be more than happy to help poke them in the right direction.
I don't find much GP in just giving a finished solution to someone who (seemingly) can't be bothered to try to solve it on their own. However, I do think GP mandates that we do everything we can to help you solve it on your own.
Maybe that is just my interpretation.
$.02
-John
dtengineering
05-02-2009, 02:41
I would suggest the professionalism part is answered by making it work, the gracious part is answered by posting the video and some basic feedback on how the system works here.
I will suggest that there may be other ways to implement traction control... track wheel speed with an encoder and if it suddenly spikes then your wheel is probably slipping... or figure out your maximum possible theoretical accelleration and set up a PID loop to control speed to your motors in such a way that the acelleration does not exceed the theoretical maximum.
But we have yet to try either. The best way is probably with the idler wheel. You can see here that it works!
Jason
Good job 121. It probably took allot of effort to get to that result. I wouldn't give your hard work away, But a generalized description would be nice for other teams. From the posts, allot of teams are envious of their accomplishment. Our team does not have the time or resources to do what 121 and others are doing. However we do have traction control of sorts. A simple filter to limit the rate of change for the joystick inputs can do allot to help with slipping. If your using Labview most of the work is done for you. There are several VI's that a team can try. An averaging function would not be a bad place to start. Our programmer and mentor took about 3 hours to find a solution. It's a drag, drop, wire and set parameters solution. Much easier than what 121 has done, but not perfect. Any team can achieve this method. The driver is also part of the equation. A smooth precise driver will do better than a button smasher. I'll note that the kids who have driven this year seam to prefer arcade as to tank control. Seams to allow more precise control. There is plenty of time left to play with the slip control by limiting rate of change.
Rich Kressly
05-02-2009, 08:20
So because you think your programming team can't do it you feel like someone should hand you a finished solution? Have your programmers tried to work on traction control? I'm not a code guy (I just play with gears) but I've heard that it's not that difficult to make a pseudo successful traction control algorithm. There is even an entire thread of people discussing ways to do this sort of thing.
Perhaps your first year programmers can read the thread, take a stab at it, and then ask for additional guidance from the community. I know lots of teams would be more than happy to help poke them in the right direction.
I don't find much GP in just giving a finished solution to someone who (seemingly) can't be bothered to try to solve it on their own. However, I do think GP mandates that we do everything we can to help you solve it on your own.
Maybe that is just my interpretation.
$.02
-John
"Give a man a fish and he eats for a day. Teach a man to fish and he eats for a lifetime." The community is here to help everyone get better together so that next year the "rookie" is in a position to help the "new rookie" with the same kinds of difficult problems. Namaste...
We just finished our traction control last night. Despite my earlier rants about doing an open-loop TCS, it works great and beats a human driver every time. We tried integrating velocity from the kit accelerometer, but could never get it good enough to be worthwhile. Later, we are going to be trying to modify the Gyro class to use its accumulator code with the accelerometer for integration.
Our data for accelerating down a couple sheets of regolith:
TCS: 3.55 - 3.95 (usually around 3.7)
Human: 3.93 - 4.8 (usually around 4.2)
Wheel-spin: 4.2-4.6
A half-second advantage over 20 feet is pretty good, especially when you consider that when using TCS, the driver doesn't have to think. We expect that driver times to accelerate 20 feet will be FAR worse in competition because they won't be concentrating on just accelerating smoothly. Ours only works for from-stopped acceleration, though it'll be easy to modify into an ABS system and a system that accelerates from any speed. It does not help for turning.
Description of our setup:
-One PIDController with an encoder-velocity input and motor-power output. You'll need to tune it so it can quickly adjust your wheel velocity without oscillation
-When the driver presses the 'launch' button, we mark what time we started our launch
-For each cycle of teleOp when the 'launch' button is pressed, we set our wheel-velocity setpoint to timeElapsed * DESIRED_ACCEL.
-Once the code is all set, you just tune DESIRED_ACCEL until your robot is as fast as it can be. For us, that was 24.8 inches per second squared.
Rosiebotboss
05-02-2009, 08:28
"Give a man a fish and he eats for a day. Teach a man to fish and he eats for a lifetime." The community is here to help everyone get better together so that next year the "rookie" is in a position to help the "new rookie" with the same kinds of difficult problems. Namaste...
Kressly beat me to the quote, again.
We are developing our own traction control algothirms. If you PM me, I will hook you up with our code guys to steer you in the right direction...oh, is my GP showing??:o
Tom Schindler
05-02-2009, 08:55
All,
Apologies on the slow response, things have been busy in Rhode Warrior Land.
A good number have asked for a better explanation of how we accomplished this traction control, here is the basic outline of what we've done.
The setup includes an encoder in each AndyMark gearbox, as well as two follower wheel assemblies, one for each side of the robot. Through a number of tests, we normalized the follower wheel encoders using a static multiplier so the output would be as close as possible to that of the AndyMark gearbox encoder outputs.
Now we had an accurate idea of both how fast the wheels indicated we were going, and how fast the follower wheels indicated we were going.
A slip ratio can then be calculated by taking the difference between the wheel velocity and the ground velocity, and dividing that by the wheel velocity. Any value that is not zero (or NaN for when the robot isn't moving) indicates wheel slippage. The higher the slip ratio, the more the wheels are slipping.
Feed these values into a tuned PI (Proportional/Integral) loop, to obtain how much the software should "throttle back" each side for various slippages.
A question was asked about how we deal with chain slack/gearbox looseness. To be honest, it was just ignored, and put in the "we'll figure that out later" pile, turns out it seems to handle itself just fine without any modification.
As of now the software is aiming for zero slip. In the coming days we will be testing to see if allowing a little slippage increases our acceleration. For turning I’ve modified the gains such that the software allows a certain percentage slip. The driver also has an "off" button on their trigger, they've grown quite good at using it to kick the robot into a bit of a tail slide, and then keep driving. Anyone who's played the Mario Kart games remembers the "jump->power slide" technique; our drivers seem to love this.
As of right now we've probably put about 10 hours into making this v0 traction control work. I'm confident that we have a few long nights ahead fine tuning this, and making it more competitive.
I would recommend this reading, this is where most of our v0 software was derived from:
http://mizugaki.iis.u-tokyo.ac.jp/staff/hori/paperPDF/EV_Trans.pdf
marccenter
05-02-2009, 09:31
Team 121,
According to the paper (http://mizugaki.iis.u-tokyo.ac.jp/staff/hori/paperPDF/EV_Trans.pdf), you should see a significant traction force increase with very little slip. (Figure 11). This should deliver a significant advantage with trailler pulling. Similiar behavior is exhibited in locomotive applications. Have you been able to verify this? Do you think your control system will be capable of this level of fine tuning?
Tom Bottiglieri
05-02-2009, 09:51
So you feel entitled to get that "huge" advantage without any work?
That being said, I'd like to thank Tom and 121 for the details they have posted thus far. They basically gave the system away on a silver platter.
As with most projects, writing the code is the easy part. Designing the system is what's tough.
Abrakadabra
05-02-2009, 10:26
I'd like to second the thanks to Tom and the team for all the details. We look forward to meeting them in action in both Manchester and Hartford!
Does anyone have any suggestions (or a part number) for an encoder that is suitable for a simple follower wheel application? There are quite a range available, both in resolution and price. Preferably, one with a 1/4" shaft already built in?
Thanks!
Tom Bottiglieri
05-02-2009, 10:50
I'd like to second the thanks to Tom and the team for all the details. We look forward to meeting them in action in both Manchester and Hartford!
Does anyone have any suggestions (or a part number) for an encoder that is suitable for a simple follower wheel application? There are quite a range available, both in resolution and price. Preferably, one with a 1/4" shaft already built in?
Thanks!
Vex sells a decent encoder that does A/B quadrature. They fit right onto the standard Vex square shaft, and can be interfaced easily to the Vex wheels. You could have something up and running in less than one night.
For a more custom solution, teams have had luck with the Grayhill 61k series of encoders.
martin417
05-02-2009, 10:57
Does anyone have any suggestions (or a part number) for an encoder that is suitable for a simple follower wheel application? There are quite a range available, both in resolution and price. Preferably, one with a 1/4" shaft already built in?
Thanks!
We are using these (http://www.bgmicro.com/index.asp?PageAction=VIEWPROD&ProdID=12916) from BG micro. They are not really designed for this application, but they work gret, and at $4.00 each it's hard to beat!
Here (http://docs.bgmicro.com/pdf/oak-grigsby%20encoders.pdf) is the spec sheet on them.
jmarsh24
05-02-2009, 12:12
My team is attempting traction control, and a mentor brought up that when we turn we wont be getting the same values with one wheel. I may be just a little bit confused, but we are thinking we will have to do a mouse design with omni wheels to get correct values as we turn. Is this a correct understanding of how this system works?
Tom Bottiglieri
05-02-2009, 12:22
My team is attempting traction control, and a mentor brought up that when we turn we wont be getting the same values with one wheel. I may be just a little bit confused, but we are thinking we will have to do a mouse design with omni wheels to get correct values as we turn. Is this a correct understanding of how this system works?
I believe 121 is using a similar set up to 148's, which can be seen using an omni-wheel here. (http://www.chiefdelphi.com/media/photos/32440)
Our team has chosen to use an omni wheel, as well. We will have one follower assembly per side of the robot. We figured it was better to be safe than sorry and used an omni wheel.
jmarsh24
05-02-2009, 12:33
So if im right, teams are using a caster omni wheel to get the turning values along with the straight values?
jmarsh24
05-02-2009, 12:36
also is there a reason why they aren't using the encoder from the kit?
martin417
05-02-2009, 12:39
also is there a reason why they aren't using the encoder from the kit?
We are using the kit encoders to get the wheel speed, and omni wheels on each side (not caster mounted) to get the actual speed. We hope to get good results..
windell747
05-02-2009, 19:06
Wonderful work team! Thanks for sharing your psuedo algorithm! You're not giving away your code (absolutely okay), but you are reinforcing the thought scheme so that others can validate their concepts with what actually works. Now that is gracious professionalism.
Is it slipping on those turns? From the audio it sounded like when it hit the wall it was slipping quite a lot. But I can't be sure just from video & audio
robert2.0
07-02-2009, 18:43
hey the trailer weighs more and how could you stop
Tom Schindler
07-02-2009, 19:53
Is it slipping on those turns? From the audio it sounded like when it hit the wall it was slipping quite a lot. But I can't be sure just from video & audio
If you listen to the audio, the operator was directed to turn off traction control as a comparison. When it hit the wall, the traction control was disabled.
The software allows a certain amount of wheel slip when the operator is attempting to turn.
The trailer was loaded with enough weight to simulate a fully built trailer (36 lbs i believe it was).
Good Luck!
Tom
I'm curious how the traction control feed back will work when the robot is being bumped by another bot. Does the control loop stay stable. Have you tested it yet.
gorillamonky
11-02-2009, 21:25
can you post your coding, or at least post an "untuned" version our team is having trouble finding the right direction. any help would be appreciated
JamesBrown
11-02-2009, 23:36
can you post your coding, or at least post an "untuned" version our team is having trouble finding the right direction. any help would be appreciated
It is boarder line ridiculous to ask for a team to post their actual code, keep in mind this is after all still a competition.
Tom already posted a link to an academic paper with great information in it. Start by reading that and try applying it to your code. If you still have problems then try to ask specific questions either here if they relate to 121's system, or in the programming forum.
Joe_Widen
12-02-2009, 00:58
Why don't you start off by thinking about what to do before you try to code. From my understanding of everything, keep in mind I didn't read the pdf link, you want to start off by reading what your encoders are telling you vs what your encoders from your trailer wheel are telling you. Then using 121's formula they generously posted, figure out your slip. Now try and figure out how to reduce that slipping. Throw that in a loop and I think you would have a basic traction control system.
Mentor_Mike
12-02-2009, 22:08
That's really cool, but I was curious for all those with acceleration based controls. How well does it work when you do get in that occasional shoving match? Or if someone "speeds you up"?
M_M
FatBabyJezus
12-02-2009, 22:53
wait..what kind of traction control is that? wat u guys using?
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.