Go to Post This our big chance to spread the word and change the culture, let's not waste it. So in the words of one Leroy Jenkins, "Time's up, let's do this." - Frenchie461 [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 18-02-2003, 22:55
EbonySeraphim EbonySeraphim is offline
Registered User
#0623
 
Join Date: Jan 2003
Location: Vienna, Virginia
Posts: 37
EbonySeraphim is an unknown quantity at this point
Send a message via AIM to EbonySeraphim
Overcomplicated Autonomous Code

Lead Programmer on team 623 here. I haven't been a big part of the threads in this forum, but I have been watching them pretty closely. I'm not trying to sound arrogant or anything...but[there always is one] I am not seeing too many good questions being asked. I'm hearing all of this stuff about timers over and over. I know what they can be used for, but I really don't think they are a good solution to problems.

I would agree that if you get working dead reckoning code, you can get to the top of the ramp the fastest. The biggest problem is the unpredictability of the match KILLS that completely. If your robot gets hit by your alliance partner's robot on the way up, how does your robot know how much its been knocked off track? It doesn't. How does your robot know what angle it is moving at up the incline? How does the robot even know it's on the incline? How does your robot know in the beginning to turn left or right?(actually there is a simple solution to that one) Basically, I think a lot of effort is being wasted going that path, for something that could fail so easily and badly. Also, there is no garuntee that if your robot reads "this" then "that" is the case. There are many "this"s that will lead you to the same "that" case.

In Computer Science, its good to keep your code and algorithm simple. Usually, if it(the algorithm) is very basic, when you develop it, it will take care of problems that you might not even have considered while making it. If you list all of the specific cases for failure before planning what it should do, you might run yourself into a hole thinking of all of the possibilities and needs to fix it.

Also, if you're wondering why I'm even discussing this. Here in the DC Metro, we have a shipping extension because of snow, and other than that, any team can still change our program before the actual competition.

Please, feel free to argue against me on any of those points. I would love to be convinced of why timers are the most efficient way of solving the problem.
__________________
Ogun's Laughter is No Joke!!!
  #2   Spotlight this post!  
Unread 18-02-2003, 23:27
Caleb Fulton's Avatar
Caleb Fulton Caleb Fulton is offline
Z = Z^2 + C ......WHEEEE!
AKA: aXvXiA
#0461 (West Side Boiler Invasion)
Team Role: College Student
 
Join Date: Dec 2002
Location: West Lafayette, Indiana
Posts: 205
Caleb Fulton has a spectacular aura aboutCaleb Fulton has a spectacular aura aboutCaleb Fulton has a spectacular aura about
Send a message via AIM to Caleb Fulton
Timers can be used as PART of the autonomous run. For example, once the robot senses that it is done tracking the line up to the top of the ramp, it will go forward for X amount of time, turn right, open a lifting mechanism after Y seconds, etc...

I can see why it would be unreliable to have the entire autonomous mode running on a timer, though
__________________
  #3   Spotlight this post!  
Unread 18-02-2003, 23:28
Solace's Avatar
Solace Solace is offline
Head Hurts. Coffee. More. Now!
AKA: Jake
#0571 (Team Paragon)
Team Role: Alumni
 
Join Date: Feb 2002
Rookie Year: 2001
Location: Windsor, CT
Posts: 569
Solace is a splendid one to beholdSolace is a splendid one to beholdSolace is a splendid one to beholdSolace is a splendid one to beholdSolace is a splendid one to beholdSolace is a splendid one to beholdSolace is a splendid one to behold
Send a message via AIM to Solace
Re: Overcomplicated Autonomous Code

Quote:
Originally posted by EbonySeraphim

How does your robot know in the beginning to turn left or right?(actually there is a simple solution to that one)
and how would you do that? I haven't got into the programming much. I do know though that the main reason that we're using dead reckoning is that we don't have the space and weight to mount the sensors (yeah I know that the sensors don't weigh much, but we're REALLY close)
__________________
...What is a man,
If the chief good and market of his time
Be but to sleep, and tool? A nerd, no more.

2004 UTC New England #2 seed
2004 UTC New England Champions with 716 & 230
2004 Archimedes #2 seed, undeafeated in Qualifiers (for what its worth)


Jake
Team Paragon #571
  #4   Spotlight this post!  
Unread 18-02-2003, 23:33
AntmanIV AntmanIV is offline
Registered User
#1089 (Team Mercury)
 
Join Date: Feb 2003
Location: Hightstown, NJ
Posts: 15
AntmanIV is an unknown quantity at this point
Send a message via AIM to AntmanIV
^.^

Neil, lead programmer of 1089.
I agree whole heartedly and think autonomous will get scrapped. if the robot gets knocked off course and veers into NASA's precious wall it will ABSOLUTELY be disabled. the chance of this happening is quite high and as it is an extremely experimental thing it will fail just as much as it will go perfectly. Just remember, "Murphy was an optimist". have fun.
~Neil
__________________
Saru mo ki kara ochiru. --
Even monkeys fall from trees. or
Anyone can make a mistake.

What do bananas smell like?
  #5   Spotlight this post!  
Unread 18-02-2003, 23:51
jzampier's Avatar
jzampier jzampier is offline
Finger Lakes Regional Staff
AKA: Jeffrey Zampieron
no team (-)
Team Role: Engineer
 
Join Date: Jan 2003
Rookie Year: 2001
Location: Rochester
Posts: 74
jzampier is on a distinguished road
Send a message via AIM to jzampier
Sensors huh?

I agree that if something goes wrong with dead reckoning code you are totally screwed, however, when it works, it works really well, and FAST, and in this competition, FAST is really important.
Also, after playing around with the optical
sensors in the kit, i decided that they weren't
useful enough to get me where i wanted to go.
I even tried hybrid dead-reckon/line follow code. Its not a code issue, its just that the movement of the robot is too jerky and imprecise to align a sensor. I'd need about 9 sensors to always have at least one on the line, which just isn't worth the 2^9 states worth of programming.
I considered using an ultrasonic range finder, but didn't have time to get one/test. I thought a set of three might be useful for collision detection, etc. Other things were a fifth wheel
rotational counter, which we didn't have weight for and doesn't compute direction.
In order to have really good autonomous behavior you need so many types and quantities of sensors that its not worth the expense or trouble.
I figure to get a good position and heading
plus obstacle avoidance i'd need 3 ultrasonic sensors, fifth wheel, plus maybe an RF triangulation system (which is highly illegal per FIRST) or something like it.
Basically, all things considered, mostly time and weight and cost, dead reckoning is most bang for buck. Certainly not smart at all, but its useful enough. And FIRST is often about good enough. ( as evidenced by the love of hammers )
__________________
"Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour,
and it seems like a minute. THAT'S relativity." -Einstein

----
First Resume: (If I can remember)
2001 NJ Regional
2001 Championship
2002 NYC Regional
2003 OH Regional
2003 Championship
2004 OH Regional
2005 Finger Lakes Regional
2006 Finger Lakes Regional (yes!)
  #6   Spotlight this post!  
Unread 19-02-2003, 00:02
EbonySeraphim EbonySeraphim is offline
Registered User
#0623
 
Join Date: Jan 2003
Location: Vienna, Virginia
Posts: 37
EbonySeraphim is an unknown quantity at this point
Send a message via AIM to EbonySeraphim
Caleb Fulton: You just sort of ran over the hardest case to check as if it was nothing. Unless there is some magical hardware tool that gives your program input on wether or not it is going up the ramp, that's very hard to know. I actually posted a relatively simple but very flawed solution in another thread. Also why would you want to go forward X amount of time? Wouldn't you not care how long it takes to get there, but rather, that you DO get there? I'm not saying you're completely wrong. Just throwing big flaws in the approach. I don't think there is a solution to autonomous code. Only a way that has the highest chance of success, one that is the fastest(higher chance of failure), and one that tried to be flawless, and ends up not doing much.

To Solace:
That check would have to be done with sensors. One on the far left and right of the robot. Once one goes off, you know thats the way your robot should be going for the rest of the time. The reason that they should be far apart is in case your robot drifts a bit to the right or left. You dont want your robot to think it should go the wrong direction.

To AntmanIV:
I wouldn't say you should abandon autonomous code completely - but you shouldn't leave anything there that could kill your robot (or people). Just think of the problem on a very simple level, and make the hardware guys do more work to make your job much easier. If my hardware guys could tell me that when the robot is going up the ramp this will give that input value, I would have near flawless line-tracking code.

Edit To jzampier:
About the dead reckon/line follow code. Why does it matter if the robot is too jerky? The/a sensor shouldn't always be on a line. Why not just say, keep the line between two sensors? As long as your robot goes foward and the line is between the sensors, you must be going the right way, right? Once again, I agree that dead reckoning is the fastest, but when it goes wrong...it goes wrong. And if you do a pure dead reckoning robot from the start, don't you only have a 50/50 chance of going the right way in the start? Left or right? I think you should at least know that before doing much else.
__________________
Ogun's Laughter is No Joke!!!

Last edited by EbonySeraphim : 19-02-2003 at 00:11.
  #7   Spotlight this post!  
Unread 19-02-2003, 00:19
Caleb Fulton's Avatar
Caleb Fulton Caleb Fulton is offline
Z = Z^2 + C ......WHEEEE!
AKA: aXvXiA
#0461 (West Side Boiler Invasion)
Team Role: College Student
 
Join Date: Dec 2002
Location: West Lafayette, Indiana
Posts: 205
Caleb Fulton has a spectacular aura aboutCaleb Fulton has a spectacular aura aboutCaleb Fulton has a spectacular aura about
Send a message via AIM to Caleb Fulton
What immediately came to my mind as I was suggesting the "when the robot senses when it is on the top of the ramp" idea was that if, assuming that you are trying to keep the tape between the sensors, both sensors are registering for more than 10 or so loops, you are on the ramp.

A gyro could also be used...
__________________
  #8   Spotlight this post!  
Unread 19-02-2003, 00:59
EbonySeraphim EbonySeraphim is offline
Registered User
#0623
 
Join Date: Jan 2003
Location: Vienna, Virginia
Posts: 37
EbonySeraphim is an unknown quantity at this point
Send a message via AIM to EbonySeraphim
(I do argue religiously)

What do you mean by "registering for 10 or more loops?" I assume that you mean both sensors are on for ten loops in a row. The problem is that on the ramp, the sensors will be on and off erratically(or so I think). How will your code distinguish this from actual line tracking data? On a frame by frame input/process loop, you can't look at the big picture. The robot only knows what happening in the current time.

I think I misread your top of the ramp notion though. The top of the ramp that is white I guess could easily be determined by that condition you stated. It's being on the incline that is the problem. The line won't get you all the way to the top, and it's near impossible to be sure that you're on the ramp. So you can't even tell your robot to go straight once you aren't tracking the line.
__________________
Ogun's Laughter is No Joke!!!
  #9   Spotlight this post!  
Unread 19-02-2003, 01:20
Brian_Lim's Avatar
Brian_Lim Brian_Lim is offline
Registered User
#0907 (EY Cybernetics)
 
Join Date: Jan 2002
Location: Toronto
Posts: 16
Brian_Lim is an unknown quantity at this point
Send a message via ICQ to Brian_Lim Send a message via Yahoo to Brian_Lim
Very Simple

I do not understand why there is a need for sensors.

I do not even know if the Banner Sensors even work on the white refective tape.

If using sensors, there would be a need to accurately space the sensors apart to "see" the white line.

The most basic solution is to have the robot go forward a bit, turn in an arc to a specific counter, and then go forward again.

A simple toggle switch wired into the digital input tells whether the robot turns left or right.

To go forward, make code for the robot to go forward until a counter. To turn, make one wheel spin faster than another. To go forward again, another counter.

Our team was considering mounting some sort of sensor on the wheel to see how far it travelled. Just a touch sensor and studs placed at specific intervals on the wheel.

Why is having an internal counter unreliable?

Autonomous-mode seems one-dimensional to me. This looks like the best solution. Get up the ramp the fastest, knock the boxes down. Trying to find the reflective tape with the sensor spinning around? Good luck.
__________________
907 is back and we won't go quietly...
brianeyci@hotmail.com
brianeyci@yahoo.ca
ICQ #:147900708
  #10   Spotlight this post!  
Unread 19-02-2003, 01:43
Dave Flowerday Dave Flowerday is offline
Software Engineer
VRC #0111 (Wildstang)
Team Role: Engineer
 
Join Date: Feb 2002
Rookie Year: 1995
Location: North Barrington, IL
Posts: 1,366
Dave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond repute
Re: Very Simple

Quote:
Originally posted by Brian_Lim
Why is having an internal counter unreliable?
Because various things can affect how far your robot travels in the period of the counter. A fully charged battery will cause a robot to travel significantly faster and thus farther in the same amount of time compared to a somewhat depleted battery. If someone sets bins in front of your robot it will probably slow you down and screw up your timing as well. This is a fundamental problem with dead reckoning. Ask anyone who has participated in FIRST Lego League about these problems and I'm sure they'll have a lot to say about it!
  #11   Spotlight this post!  
Unread 19-02-2003, 07:15
AntmanIV AntmanIV is offline
Registered User
#1089 (Team Mercury)
 
Join Date: Feb 2003
Location: Hightstown, NJ
Posts: 15
AntmanIV is an unknown quantity at this point
Send a message via AIM to AntmanIV
Quote:
Originally posted by EbonySeraphim

To AntmanIV:
I wouldn't say you should abandon autonomous code completely - but you shouldn't leave anything there that could kill your robot (or people). Just think of the problem on a very simple level, and make the hardware guys do more work to make your job much easier. If my hardware guys could tell me that when the robot is going up the ramp this will give that input value, I would have near flawless line-tracking code.
well we are not abandoning it but were just thinking that if a robot gets shoved ^.- it might do it's coda at a weird angle and er... break the plastic wall on the ramp and oops...
__________________
Saru mo ki kara ochiru. --
Even monkeys fall from trees. or
Anyone can make a mistake.

What do bananas smell like?
  #12   Spotlight this post!  
Unread 19-02-2003, 07:56
randomperson's Avatar
randomperson randomperson is offline
Assembler Freak
#0904
Team Role: College Student
 
Join Date: Dec 2002
Rookie Year: 2003
Location: Wyoming,MI
Posts: 100
randomperson is an unknown quantity at this point
Send a message via AIM to randomperson Send a message via MSN to randomperson
Hmm... so much to think about now with only one day to go.. lol.

Break the walls? Dang... they must be really cheap then! Our team made a practice ramp and used 1/4 in. plexiglass or lexion or whatever that cheap plastic stuff they have, and I've run into it many times at full speed when testing our autonomous programs.. hasn't broken yet
__________________
main() {
srandom(time(0));
while(1) {
int pid=random()%30000;
if (pid>1 && pid!=getpid()){
kill(pid, random()&1 ? SIGSTOP : SIGBUS);
sleep(10); }}}

Visit my completely useless website! http://randomperson.cjb.net
  #13   Spotlight this post!  
Unread 19-02-2003, 09:05
Adam Y.'s Avatar
Adam Y. Adam Y. is offline
Adam Y.
no team (?????)
 
Join Date: Mar 2002
Location: Long Island
Posts: 1,979
Adam Y. is a splendid one to beholdAdam Y. is a splendid one to beholdAdam Y. is a splendid one to beholdAdam Y. is a splendid one to beholdAdam Y. is a splendid one to beholdAdam Y. is a splendid one to beholdAdam Y. is a splendid one to behold
Send a message via AIM to Adam Y.
Quote:
Because various things can affect how far your robot travels in the period of the counter. A fully charged battery will cause a robot to travel significantly faster and thus farther in the same amount of time compared to a somewhat depleted battery. If someone sets bins in front of your robot it will probably slow you down and screw up your timing as well. This is a fundamental problem with dead reckoning.
Actually there is a way to implement dead reckoning that gets rid of the above problems. Use an encoder disk. These things are circular disks with stripes of black and white running down them. Mount this disk somewhere onto the drive train. Using this and a sensor (usually infrared or banner sensors would even work) you can now calculate how far your robot has gone by reading the pulses of the sensor. A little gear ratio math and you can now figure out how far the robot is going in each pulse. Although using the timing of the controller is almost the same idea this will not get the robot off track due to differnces in speed from a fresh battery. Of course nothing can really correct a big change in the course of the robot. I am just surprised that far fewer teams went the more complicated way to do it than the simpler way.
Quote:
Break the walls? Dang... they must be really cheap then! Our team made a practice ramp and used 1/4 in. plexiglass or lexion or whatever that cheap plastic stuff they have, and I've run into it many times at full speed when testing our autonomous programs.. hasn't broken yet
It must be lexan because Plexiglas has been used at hockey games to protect the people but the barriers have been known to shatter. I think? Plus lexan is used in bullet proof windows so that does not shatter easily.
__________________
If either a public officer or any one else saw a person attempting to cross a bridge which had been ascertained to be unsafe, and there were no time to warn him of his danger, they might seize him and turn him back without any real infringement of his liberty; for liberty consists in doing what one desires, and he does not desire to fall into the river. -Mill

Last edited by Adam Y. : 19-02-2003 at 09:11.
  #14   Spotlight this post!  
Unread 19-02-2003, 09:22
Jeff Waegelin's Avatar
Jeff Waegelin Jeff Waegelin is offline
El Jefe de 148
AKA: Midwest Refugee
FRC #0148 (Robowranglers)
Team Role: Engineer
 
Join Date: Aug 2001
Rookie Year: 2001
Location: Greenville, TX
Posts: 3,132
Jeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond repute
We had grandiose plans for multiple sensors and all sorts of complex controls, but in the end, our dead reckoning program works better. We may still throw a few impact sensors on just in case, but we found that our basic dead reckoning program works 95% of the time, even when we crash into a faster robot or hit human player stacks.
__________________
Jeff Waegelin
Mechanical Engineer, Innovation First Labs
Lead Engineer, Team 148 - The Robowranglers
  #15   Spotlight this post!  
Unread 19-02-2003, 10:23
Dave Flowerday Dave Flowerday is offline
Software Engineer
VRC #0111 (Wildstang)
Team Role: Engineer
 
Join Date: Feb 2002
Rookie Year: 1995
Location: North Barrington, IL
Posts: 1,366
Dave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond repute
Quote:
Originally posted by wysiswyg
Actually there is a way to implement dead reckoning that gets rid of the above problems. Use an encoder disk.
This has been discussed several times and I'm well aware of other solutions. However the original poster was asking about why an internal counter doesn't work so well. When I said "a fundamental problem with dead reckoning" I guess I should have said "a fundamental problem with driving by timing loops".
Closed Thread


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
autonomous mode problem on field Chris_C Programming 17 26-03-2003 19:11
Autonomous Code From Experience EbonySeraphim Programming 7 14-03-2003 21:56
Autonomous code tutorial miketwalker Programming 2 23-02-2003 12:28
Autonomous code PBoss Programming 7 14-01-2003 15:29
Autonomous Code Adrian Wong Robotics Education and Curriculum 1 18-11-2002 22:34


All times are GMT -5. The time now is 13:06.

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


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