Go to Post Nothing worse than an intolerant field :D - JB987 [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 08-03-2003, 22:42
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
Autonomous Code From Experience

I just got back from the VCU regionals today and I must say - WOW!!!! We(Oakton High School) are technically not a rookie team, but being that seniors are usually the only one's working on the bot, we have new people pretty much ever year, and this year, not a single person worked on last year's robot.

I would first like to give a half apology/recant. I was arguing before in the "Overcomplicated Autonomous Code" thread that dead reckoning would be too unreliable to run with. During our matches at the VCU regionals, the only realy robot contenders during the autonomous period were dead reckoning. Those that curved and went up the ramp had the highest success rate. Also those robots that had wide areas to knock down boxes worked extremely well(for obvious reason).

I will explain what happened to our autonomous code as we progressed to hopefully help some other teams get it right sooner than us. In the beginning, we had line tracking code running, supposedly with two down looking sensors, you could try to keep the line between the sensors and have the robot make to the top of the ramp and go fowards. That was very flawed for several reasons. First, the big thing we overlooked was sensor placement. Our robot fowards had kept switching before this regional and the sensors were considerably behind the drive wheels and our center of rotation and when we did hit a line, there was no way to turn and keep the line between sensors. Also, the line never seemed to trigger anything for a few runs. But after changing our automous code a few times, we scapped line tracking and had it go fowards until ANY sensor was hit, and then it would stop. After we saw that work we decided to get our human player in good position right after autonomous mode to start. So we decided, after we hit that single sensor, lets turn in a predefined arc (dead-reckoning based) and get generally up the ramp. That worked sensationally well, but now it came down to going forwards after a certain amount of time to go through the ramp. Of course that would require timing.

I will still say that existing counting code that is supposed to use seconds in the match is too complicated and possibly unreliable. We added a simple counter in terms of program cycles to time our robot. Since we don't have a dashboard program we used switches to run our autonomous mode and stop it at a certain point to see if we were over a certain number of cycles. Using a binary search type method we centered in on about 200 cycles(that was moving relatively slow compared to any other working autonomous code and it only our code speed) Using that number we had the robot go fowards after the arc.

If you want to use such a counter you have to consider two things - if you want to go over 254 you need to use your own logic and do something like:

counter = counter + 1
if counter = 254
counter1 = 0
counter2 = counter2 + 1
endif

I don't want to explain too much but this would basically allow you go count up to 2^16. Also the timing only matters for the time up until autonomous mode starts turningstarts. Basically, if you are counting every loop in your program anyways, you need to reset it, the first time autonomous starts, and the first time a sensor is triggered or else you will have already reached your count while your team is placing your robot on the field(already on). Keep in mind that your program is running as long as the robot is on, and is therefore looping.

I'd like to end saying that our team competed very well. We had a first match and placed 27th(out of 61), then our next match we score 155 and moved up to about 17th. After our next few wins, we moved up to 3/4th after 1 day of competition. At the beginning of the next day we were moved up to first and maintained it for a good amount of time, but after the normal rounds were over we were in 4th. We got that far with practically no autonomous mode because our robot could drive and we knew what had to be done in order to win. What I'm implying is that a lot of teams don't have autonomous code and even those with it WONT knock down all of the boxes. The game is still largely decided upon what happens under human player control. I'll stop here because I've gone too far under the general game and that should go under another forum.

If you have any questions about other team's successful autonomous code/what worked and failed with ours feel free to ask.
__________________
Ogun's Laughter is No Joke!!!
  #2   Spotlight this post!  
Unread 09-03-2003, 20:41
Lloyd Burns Lloyd Burns is offline
Registered User
FRC #1246 (Agincourt Robotics)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1997
Location: Toronto
Posts: 292
Lloyd Burns is an unknown quantity at this point
Congratulations on your standing, and on your programming (all done at the match ?). and thanks for explaining it so well. It looks like line following is a slow business.
  #3   Spotlight this post!  
Unread 09-03-2003, 21:25
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
we still have two weeks before our first -- ypsi -- and im still confident in our auto line tracking skillz.. mainly cuz they're so sloppy :-) but, our line tracking was a dead reckoning of sorts, and we had a gyro to figure out when we hit the ramp :-).. so we're cool with that idea. And then, after our robot shipped, i noticed the idea about storing a path in EEPROM here on the forums and implemented it.. and that really works quite well with our prototype! so nothing for me to worry about right now...

Oh yeah.. one thing i keep telling people.. hardware timers make it easier!
__________________
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

Last edited by randomperson : 09-03-2003 at 21:32.
  #4   Spotlight this post!  
Unread 10-03-2003, 00:36
Eric G Eric G is offline
Registered User
#0343 (Metal In Motion)
 
Join Date: Mar 2003
Location: Seneca, SC
Posts: 15
Eric G is an unknown quantity at this point
I definitely feel that external timers would be a step up from loop counting. We are loop counters and we got our code working fairly well (for our treads and the carpets in our test arena). Then I noticed that we did not have code to turn on the air compressor in our auto-code. Our other programmer copied it in from his human player code and then EVERYTHING messed up. The new lines of code were executed every loop and altered the timing.

My second reason for feeling this way is because the arena surfaces and the traction/tension of our track drive system are all variables that are not measured in code. I think one of the greatest equalizers would be a tool that would measure the rotations of wheels or gears in the drive train. Knowing how far you have traveled in wheel rotations is a far cry better than knowing how long you have been heating a wire!

Oakton, congratulations on your success in coding it out!

Eric
  #5   Spotlight this post!  
Unread 11-03-2003, 13:51
yruhere yruhere is offline
Registered User
None #0769
 
Join Date: Mar 2003
Rookie Year: 2002
Location: _
Posts: 7
yruhere is an unknown quantity at this point
Well, from a team that did very poorly in autonomous code, let me share a few tips with you guys to help you out.

1. Keep it simple:
We originally went for the curved approach, in an attempt to follow the line (without sensors..) and we had a lot of problems getting the timing right. I reccomend going for a square turn if you don't have a lot of time to test.

2. Get it working early:
As far as excuses go, the problems for our team (769) were not all the fault of the programmers, but rather the mentors who did not see evidence of the autonomous code helping us in the practice matches (and therefore did not let us run it for 2 matches..which is understandable). We did not have any testing prior to the competition so we were winging it, but I hope you guys have better luck than we did. Showing other teams that you have a useful autonomous code will also be big factor in the choice of alliance partners for the finals, so I stress that you have it working for the whole competition.
  #6   Spotlight this post!  
Unread 12-03-2003, 10:32
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
Auton

After helping a few folks at Cleveland fixup their auton code, here are the problems i noticed:

1. Program Flow issues, meaning people not
seperating auton from human mode.
This included not understanding how program slots work and the need to initialize things
properly.

2. Testing Issues, meaning people didn't have time to checkout the timing of the path the robot
would take on a real field... we had this issue a little bit also, especially after swapping drill motors. (stupid brushes fell out)

3. Multiple programmer messes...
On our team: I wrote the Auton Code, someone else wrote the human code.
It was all Heavily commented so either of
us could understand what each section did of
any block. I also broke it down into 5 program
slots to keep it all neat.

Just my $0.03
__________________
"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!)
  #7   Spotlight this post!  
Unread 14-03-2003, 20:51
David Bing David Bing is offline
Registered User
no team
 
Join Date: Jan 2003
Location: None
Posts: 8
David Bing is an unknown quantity at this point
One idea that we had but that we never pursued was putting a piece of reflective tape on the inside of one of the wheels, and then mounting a sensor nearby. That seemed to be the easiest way to count rotations.
  #8   Spotlight this post!  
Unread 14-03-2003, 21:56
Alex1072 Alex1072 is offline
Registered User
AKA: Alex
#1072 (Harker Robotics Team)
Team Role: Leadership
 
Join Date: Jan 2003
Rookie Year: 2003
Location: San Jose
Posts: 110
Alex1072 is an unknown quantity at this point
Send a message via AIM to Alex1072 Send a message via Yahoo to Alex1072
Re: Autonomous Code From Experience

Quote:
Originally posted by EbonySeraphim


If you want to use such a counter you have to consider two things - if you want to go over 254 you need to use your own logic and do something like:

counter = counter + 1
if counter = 254
counter1 = 0
counter2 = counter2 + 1
endif

I don't want to explain too much but this would basically allow you go count up to 2^16...
PBasic supports word size variables which would let you hold 2^16 without adding extra code. Our code worked something like this:


Time VAR word

...

Time = Time + 1


Hope this helps.
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 tutorial miketwalker Programming 2 23-02-2003 12:28
Overcomplicated Autonomous Code EbonySeraphim Programming 33 20-02-2003 21:53
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:05.

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