OCCRA
Go to Post I betcha the FIRST officials in the know come in here from time to time and either gasp and think of how to make next year's clue harder or fall off their chair laughing. - Sparks333 [more]
Home
Go Back   Chief Delphi > FIRST > General Forum
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 02-22-2009, 11:03 AM
willferral willferral is offline
Registered User
FRC #0885
 
Join Date: Feb 2009
Location: vermont
Posts: 2
willferral is an unknown quantity at this point
Driving and "Traction controls"

I need some suggestions. Here is our problem: We designed our robot with a simple four-wheel drive system, skid-steering. We tested the original robot with a relatively slow gear system, and could go about 6ft/sec. We tested our robot early on without any "traction controls." It was easy to drive, and very maneuverable.
http://www.youtube.com/watch?v=asyMu...eature=related Then we changed two things. One, we geared up to 9 ft/sec. Two, we added traction control. Now the robot is very hard to drive. To me the driver, it feels like there is a "delay" in the system. Our programmer had good intentions by putting a traction control system in, but it make the robot intolerable to drive. How did your teams solve the control conundrum? Any suggestions for us? Thanks!
Reply With Quote
  #2   Spotlight this post!  
Unread 02-22-2009, 11:09 AM
Bongle's Avatar
Bongle Bongle is offline
Registered User
FRC #2702 (REBotics)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2002
Location: Waterloo
Posts: 1,016
Bongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond repute
Send a message via MSN to Bongle
Re: Driving and "Traction controls"

Quote:
Originally Posted by willferral View Post
I need some suggestions. Here is our problem: We designed our robot with a simple four-wheel drive system, skid-steering. We tested the original robot with a relatively slow gear system, and could go about 6ft/sec. We tested our robot early on without any "traction controls." It was easy to drive, and very maneuverable.
http://www.youtube.com/watch?v=asyMu...eature=related Then we changed two things. One, we geared up to 9 ft/sec. Two, we added traction control. Now the robot is very hard to drive. To me the driver, it feels like there is a "delay" in the system. Our programmer had good intentions by putting a traction control system in, but it make the robot intolerable to drive. How did your teams solve the control conundrum? Any suggestions for us? Thanks!
You've got a bunch of options:
1) Make a better traction control system. There are many options that allow for quick control. One of the ones posted (by 121 I believe) had encoders mounted on free-spinning wheels, one on each side. The driven wheels would then be set to have velocities either slightly higher or slightly lower (depending on what you wanted to do) than the free-spinning wheels.
2) Have it only enable when a button is pressed, or don't use it at all. This allows the driver to drive in 'raw' mode most of the time, then use traction control when quick acceleration is needed. As a programmer I never like this solution because it means my hard work will go unused most of the time, but from a practical standpoint: if the robot performs better without it, then don't use it. I have seen many matches go wasted because a robot just wants to use its ineffective mechanism or programming when it could have been better spent doing less glamorous tasks. If it comes down to it, face reality and say "hey, this doesn't work. We can work on it in the off-season to make it work, but for now we'd be better off pushing balls"
3) Take your current system and tweak, tweak tweak.

Last edited by Bongle : 02-22-2009 at 11:16 AM.
Reply With Quote
  #3   Spotlight this post!  
Unread 02-22-2009, 02:45 PM
nathanww nathanww is offline
Hacker
FRC #1678 (Citrus Circuits)
Team Role: Programmer
 
Join Date: Dec 2008
Rookie Year: 2007
Location: Davis, CA
Posts: 224
nathanww is just really nicenathanww is just really nicenathanww is just really nicenathanww is just really nice
Re: Driving and "Traction controls"

Quote:
To me the driver, it feels like there is a "delay" in the system.
Not to go too much into technical discussion, but the delay you're noticing is likely due to the physics of the playing field. Essentially, high responsiveness=large,sudden changes in motor speed=slipping=decreased responsiveness. The job of the traction control system is to keep manuevering within the envelope where it is not slipping. If tuned correctly, this will mean that overall maneuverability and acceleration is increased, but if it is overzealous the reverse might be true.


Quote:
There are many options that allow for quick control. One of the ones posted (by 121 I believe) had encoders mounted on free-spinning wheels, one on each side.
Actually, a purely closed-loop traction control can be quite slow because you have to wait for enough data to come in. Otherwise, you might be dealing with a situation where, say, a motor encoder has registered 1 tick and a follower has registered 0. If you don't wait for enough data, this will indicate that you're operating at 0% efficiency. The technique that we're using to correct this problem is a "hybrid" approach--a basic ramping system limits acceleration to somewhat reasonable values while we wait for an average from an accelerometer.


Quote:
Have it only enable when a button is pressed, or don't use it at all. This allows the driver to drive in 'raw' mode most of the time, then use traction control when quick acceleration is needed.
I would be extremely cautious about doing this, because
  1. Functionality of the robot != responsiveness to commands. The cRio is capable of making tactical descisions in the time it takes a human driver to blink. With something that requires as much prescision as traction control, the robot needs to be able to override the human operator, not vice-versa
  2. Similar to this, making an effective descision to disable a TC system requires understanding at a low level of what is going wrong with the system. If you think that you can do that with the robot 50ft away from you, on a competition floor, while driving, in about 10 seconds, that's great, but otherwise it's likely that mucking about with the robot's programmatic internals on the field will do more harm than good(our original plan was to have a system to essentially fix common problems that might come up with the robot from our OI, but we scrapped this after we discovered that our drivers thought process was something like "robot acting odd->mash buttons"
__________________
Get yer robot source code here!
Reply With Quote
  #4   Spotlight this post!  
Unread 02-22-2009, 03:00 PM
AmoryG AmoryG is offline
Registered User
FRC #2423 (KwarQs)
Team Role: Alumni
 
Join Date: Mar 2008
Rookie Year: 2008
Location: Watertown, MA
Posts: 201
AmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud of
Re: Driving and "Traction controls"

Quote:
Originally Posted by willferral View Post
I need some suggestions. Here is our problem: We designed our robot with a simple four-wheel drive system, skid-steering. We tested the original robot with a relatively slow gear system, and could go about 6ft/sec. We tested our robot early on without any "traction controls." It was easy to drive, and very maneuverable.
http://www.youtube.com/watch?v=asyMu...eature=related Then we changed two things. One, we geared up to 9 ft/sec. Two, we added traction control. Now the robot is very hard to drive. To me the driver, it feels like there is a "delay" in the system. Our programmer had good intentions by putting a traction control system in, but it make the robot intolerable to drive. How did your teams solve the control conundrum? Any suggestions for us? Thanks!
Well, first could you tell us how you're doing traction control?
__________________
KwarQs 2423

2008 Boston Regional Rookie Allstars

http://whsrobot.blogspot.com/
Reply With Quote
  #5   Spotlight this post!  
Unread 02-22-2009, 03:01 PM
Lil' Lavery Lil' Lavery is offline
#8 Alliance For Life
AKA: Sean Lavery
FRC #1712 (DAWGMA)
Team Role: Mentor
 
Join Date: Nov 2003
Rookie Year: 2003
Location: Philadelphia, PA
Posts: 5,288
Lil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond reputeLil' Lavery has a reputation beyond repute
Send a message via AIM to Lil' Lavery
Re: Driving and "Traction controls"

Quote:
Originally Posted by nathanww View Post
I would be extremely cautious about doing this, because
  1. Functionality of the robot != responsiveness to commands. The cRio is capable of making tactical descisions in the time it takes a human driver to blink. With something that requires as much prescision as traction control, the robot needs to be able to override the human operator, not vice-versa
  2. Similar to this, making an effective descision to disable a TC system requires understanding at a low level of what is going wrong with the system. If you think that you can do that with the robot 50ft away from you, on a competition floor, while driving, in about 10 seconds, that's great, but otherwise it's likely that mucking about with the robot's programmatic internals on the field will do more harm than good(our original plan was to have a system to essentially fix common problems that might come up with the robot from our OI, but we scrapped this after we discovered that our drivers thought process was something like "robot acting odd->mash buttons"
That's only true if the robot is A) programmed correctly, and B) the programming is actually advantageous to your strategy.
Beyond that, it may just be a difference in design philosophy, but I always want my driver to have the ability to override my robot. There's no way to predict every potential situation on the field, and as such, there's now way to program every potential reaction into your robot. Sometimes a human (preferably very well trained) is needed to react in the proper way.
Reply With Quote
  #6   Spotlight this post!  
Unread 02-22-2009, 03:38 PM
Bongle's Avatar
Bongle Bongle is offline
Registered User
FRC #2702 (REBotics)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2002
Location: Waterloo
Posts: 1,016
Bongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond reputeBongle has a reputation beyond repute
Send a message via MSN to Bongle
Re: Driving and "Traction controls"

Quote:
Originally Posted by nathanww View Post
I would be extremely cautious about doing this, because
  1. Similar to this, making an effective descision to disable a TC system requires understanding at a low level of what is going wrong with the system. If you think that you can do that with the robot 50ft away from you, on a competition floor, while driving, in about 10 seconds, that's great, but otherwise it's likely that mucking about with the robot's programmatic internals on the field will do more harm than good(our original plan was to have a system to essentially fix common problems that might come up with the robot from our OI, but we scrapped this after we discovered that our drivers thought process was something like "robot acting odd->mash buttons"
Making an effective decision is easy: "the robot isn't doing what I tell it to in a timely fashion, switching to manual override". They don't need to understand WHAT is going wrong, simply that something is.

I'd be extremely cautious about NOT having a manual override, because by not having a manual override, you're essentially saying: "my control software is perfect and can deal with all situations". I've had many situations where the robot or the program got into a state either through malfunction, damage, or human error (driver, mechanical, or programmatic) that the control software was not able to deal with. At that point, you want the ability to directly drive individual motors and solenoids. You may be less effective than the cRio in an ideal situation, but if the code on the cRio has a bug or a sensor is malfunctioning, being worse than ideal is better than not moving at all.

Quote:
With something that requires as much prescision as traction control, the robot needs to be able to override the human operator, not vice-versa
Sure, which is why you'd have the traction control button pressed when you want it, and not pressed when you don't. Or you'd have it on all the time and allow the driver to press a button if they need to execute a maneuver that it wouldn't permit. Full-time traction control and stability systems do actually remove the ability to do certain maneuvers, and there are times when it is legitimate to want them off.

The main point I was trying to make was this: if you're not capable of making a useful full-time traction control system, then be honest with yourself, and make a simpler one that works in a subset of situations. We spent two weeks trying to get a full-time closed-loop system working, and failed. So we moved to a much simpler system that works in nearly all of the situations the more complicated one worked in. It is less buggy, less susceptible to sensor failure, and easier to debug and maintain. Of course a fully-tested, well-implemented full-time system would be preferable to what we have, but a buggy full-time system that we forced the driver to use at all times would be far worse than no traction control at all.
------------------------------------
Back on topic:
Another potential source of delay is simply too much strain on the cRio. Several times during our development we wrote code that simply did too much in a single cycle, resulting in 0.5-1.0 second delays. Doing large printfs or running camera code every loop are examples of things that can put a large delay in the robot. If you're using windriver, use the GetFPGATime function to get an idea of how long each loop is taking. It should take very small (< 0.01 sec) amounts of time per loop. Note that GetFPGATime returns microseconds.

Last edited by Bongle : 02-22-2009 at 03:49 PM.
Reply With Quote
  #7   Spotlight this post!  
Unread 02-22-2009, 05:17 PM
ZakuAce's Avatar
ZakuAce ZakuAce is offline
Registered User
AKA: Garrett
FRC #2077 (Laser Robotics (Alumni))
Team Role: College Student
 
Join Date: Jan 2008
Rookie Year: 2007
Location: Delafield,Wisconsin
Posts: 198
ZakuAce is a glorious beacon of lightZakuAce is a glorious beacon of lightZakuAce is a glorious beacon of lightZakuAce is a glorious beacon of lightZakuAce is a glorious beacon of light
Re: Driving and "Traction controls"

This is interesting. We never did have enough time for anyone but the programmers to test our traction control on the real robot, and we ran out of money to build a second one. I know our programmers made it so we can't accelerate/decelerate faster than 1.9ft/sec, so it will be sluggish but won't slip. I'm pretty sure they do NOT want a manual override, but I don't think any of them are going to be the competition driver. Ah, dilemmas!

Last edited by ZakuAce : 02-22-2009 at 05:21 PM.
Reply With Quote
  #8   Spotlight this post!  
Unread 02-22-2009, 07:16 PM
AmoryG AmoryG is offline
Registered User
FRC #2423 (KwarQs)
Team Role: Alumni
 
Join Date: Mar 2008
Rookie Year: 2008
Location: Watertown, MA
Posts: 201
AmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud ofAmoryG has much to be proud of
Re: Driving and "Traction controls"

When your robot turns, does it slow one side of the wheels down or speed one side of the wheel up? So in a tank drive you have say 4 wheels two on each side:

Code:
|                |

|                |
To turn right you either need the left side of the wheels turning faster than the right:

Code:
f 
a
s
t

|                |

|                |
Or turning the wheels on the right side slower than the wheels on the left:

Code:
                  s
                  l
                  o
                  w

|                |

|                |
I think usually in traction control, if the robot's wheels are spinning faster than the robot is moving, the speed on wheels will be limited. If when turning you increasing the speed of one side of the wheels your traction control might be reducing their speed making the turn of your robot appear delayed.
__________________
KwarQs 2423

2008 Boston Regional Rookie Allstars

http://whsrobot.blogspot.com/

Last edited by AmoryG : 02-22-2009 at 07:22 PM.
Reply With Quote
  #9   Spotlight this post!  
Unread 02-23-2009, 03:47 PM
ay2b's Avatar
ay2b ay2b is offline
Registered User
AKA: Andy
FRC #2928
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 1994
Location: Seattle, WA
Posts: 200
ay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant future
Re: Driving and "Traction controls"

Quote:
Originally Posted by nathanww View Post
we discovered that our drivers thought process was something like "robot acting odd->mash buttons"
It's amazing how many drivers think that way! Fortunately, with enough practice most drivers can be trained out of that. The trick, of course, is to be able to find a way for them to get that practice before the actual competition.
__________________

2011 - SD Quarterfinalists (980), LA Quarterfinalists (980)
2010 - LA (2404) Finalists (980), AZ Motorola Quality (980)
2009 - LA Semifinalists (980); Las Vegas Quarterfinalists (980); SD (2404); IRI #1 Seed, Finalist (980)
2008 - SD Quarterfinalists (980), LA Champions (980), LA Rookie Inspiration Award (2404); CalGames Finalists
2007 - So.Cal Finalists (980), SD Quarterfinalists (980); CalGames Finalists
2006 - So.Cal Regional Champion (4), Toronto Judge's Award Day 1 (4)
2005 - SVR Champions, Delphi "Driving Tomorrow's Technology" (980); AZ Xerox Creativity (980); So.Cal Finalists, RadioShack Innovation in Control (980); Championship Archimedes Division Semifinalists; IRI Finalists (980)
2004 - So.Cal Regional Champions, Leadership in Controls (980); AZ GM Industrial Design (980); Championship Galileo Division #2 Seed; IRI Champions
2003 - PNW Semi-finalists (488)
2002 - PNW Finalists (488)
2000 - X-bot / 488 - Mentor / Founder
1994 - Sunny Delight - Driver - champion
Reply With Quote
  #10   Spotlight this post!  
Unread 02-24-2009, 03:08 PM
willferral willferral is offline
Registered User
FRC #0885
 
Join Date: Feb 2009
Location: vermont
Posts: 2
willferral is an unknown quantity at this point
Re: Driving and "Traction controls"

The discussion has been very enlightening on the subject of programing. I don't want to discourage further program suggestions because our programmer is considering what you all have to say, but what do you all think about the idea of speed as it relates to what I am still calling "delay." If our traction control program sets a locked rate at which our robot can accelerate, then gearing it down (theoretically) won't matter. So in all of your minds, is it worth it to have the high speed capabilities? I already know that without traction control and lower gear ratios, the robot drives great. What speeds are your robots running at, and how well would you say it drives?
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Team 1293 "D5 Robotics" First Night of Driving! R.Brown Robot Showcase 1 02-08-2008 06:47 AM
Congratulations is spelled with a "T" and not a "D"!! Elgin Clock Thanks and/or Congrats 55 03-09-2007 01:24 PM
New NEMO White Papers! "Creating a Killer Packet" and "25 Ways to Sponsor" Jessica Boucher Team Organization 0 08-10-2005 10:55 AM
Conflict between "Initialize_Tracker()" and "pwm13 & pwm15"? Kevin? gnormhurst Programming 3 02-22-2004 02:55 AM
how tall is the ramp when in "up" and "balanced" position??? archiver 2001 1 06-24-2002 12:54 AM


All times are GMT -5. The time now is 02:26 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi