Go to Post Well I have to admit, most of the people on our team are geeks. I think that it's a title of honor considering it might as well be "boss" or "head supervisor" or something along those lines. - Cyberguy34000 [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
  #31   Spotlight this post!  
Unread 18-02-2003, 01:21
rwaliany's Avatar
rwaliany rwaliany is offline
R
None #0691 (HartBurn)
Team Role: Programmer
 
Join Date: Jan 2003
Rookie Year: 2000
Location: http://www.hartrobot.com
Posts: 137
rwaliany will become famous soon enough
Quote:
Originally posted by TOHSlancer
ehh, wut was weird was at the scrimmage autonomous didn't activate for us at all. I wanted to test it out, never got a chance, our drive train jumped a gear. Grrrrr. Oh well, we won the scrimmage like 88-32 so we did well without autonomous.

what scares me is at the kickoff the robots never went autonomous. I mean these are engineers we're talking about.
hehe, our robot was the only robot which worked in the scrimage correctly in autonomous, except for the robot which spinned in circles and went back a few feet... it seemed right, it's just that everyone was programmign it wrong when i looked at some of the other teams code...

[All student team baby, our mentors/teacher didn't know what the robot looked like until yesterday.]
__________________
R
  #32   Spotlight this post!  
Unread 18-02-2003, 13:00
Bruce C.'s Avatar
Bruce C. Bruce C. is offline
Registered User
#0647 (The Cyber Wolf Corps)
Team Role: Engineer
 
Join Date: Feb 2002
Rookie Year: 2002
Location: Killeen, Texas
Posts: 65
Bruce C. will become famous soon enough
Sensor Inputs to Analog Port?

Quote:
Originally posted by TOHSlancer

Oh really? Nobody got their working on 3 sensors? Ours works decently. I just did some testing on carpeting last night.
We just had to space the sensors right, and coding wise I did some stuff that works pretty well. 5 sensors would've been nice to work with tho. Man. Right now I just gotta tweak code so that it doesn't just turn right when it hits the top of the ramp.


example:

Code:
do_autonomous_stuff:


' sensor1 sensor2 sensor3
course3 = 0
if (sensor1>127) then too_left
if (sensor3>127) then too_right
'straight on line
drive_L =145
drive_R = 145
course2 = 3
course = 1
goto perfect

======  snip  =========
You have your optical sensors connected to the analog input of your RC?
  #33   Spotlight this post!  
Unread 18-02-2003, 14:27
rwaliany's Avatar
rwaliany rwaliany is offline
R
None #0691 (HartBurn)
Team Role: Programmer
 
Join Date: Jan 2003
Rookie Year: 2000
Location: http://www.hartrobot.com
Posts: 137
rwaliany will become famous soon enough
optical sensors.... on analog, hes got a point...isn't that illegal on the power distribution sheet, even if it was possible...
__________________
R
  #34   Spotlight this post!  
Unread 18-02-2003, 14:39
jacob_dilles's Avatar
jacob_dilles jacob_dilles is offline
Registered User
AKA: theshadow
FRC #0620 (WarBots)
Team Role: Mentor
 
Join Date: Jan 2003
Rookie Year: 2003
Location: Vienna, VA
Posts: 245
jacob_dilles will become famous soon enough
Send a message via AIM to jacob_dilles
it is most possable, however, you couldent draw power from the +5v on the db25 connector. thats for 100k OHM pots only. as long as you stay away from that power source, i see no reason why you couldent do it... -jacob
  #35   Spotlight this post!  
Unread 18-02-2003, 15:06
rwaliany's Avatar
rwaliany rwaliany is offline
R
None #0691 (HartBurn)
Team Role: Programmer
 
Join Date: Jan 2003
Rookie Year: 2000
Location: http://www.hartrobot.com
Posts: 137
rwaliany will become famous soon enough
but then, wouldn't you need a speed controller for each light sensor... wouldn't that just be a waste of money, $345 for three light sensors.
__________________
R
  #36   Spotlight this post!  
Unread 18-02-2003, 15:14
TOHSlancer TOHSlancer is offline
Registered User
no team
 
Join Date: Jan 2003
Location: Thousand OAks
Posts: 12
TOHSlancer is an unknown quantity at this point
Yes

Yea, we hooked it up to analog through this weird breadboard hookup with resistors and crud so it's only 5 volts coming through.

So wut do you mean by programming wrong? I have the right tags etc. etc.

Yes I saw that one bot that was spining around like crazy. We gotta get rid of that commentor tho..
  #37   Spotlight this post!  
Unread 18-02-2003, 15:54
jacob_dilles's Avatar
jacob_dilles jacob_dilles is offline
Registered User
AKA: theshadow
FRC #0620 (WarBots)
Team Role: Mentor
 
Join Date: Jan 2003
Rookie Year: 2003
Location: Vienna, VA
Posts: 245
jacob_dilles will become famous soon enough
Send a message via AIM to jacob_dilles
what i believe you mean by "resistors and crud" to get "it to come in at 5v" is a home made pull-up bank. for all you out there who don't know what this is, i am just clarifying. for all you who do, excuse the "little words".

heres how i think they did it:

the digital switches on the optical sensors are either float or ground, so to connect it into and input that is expecting 0-100k ohms, what you have to do is simulate that. so, you take a 100k ohm resistor and connect it to 5v+ on one side and the NO (black) lead AND the analog input pin on the other. then you just attach the 12v+ lead (brown) to 12v+, and the gnd lead (blue) to ground (preferably on the RC power, but the gnd on the DB 25 works too).

then when the sensor is off, (assuming you are connected the NO lead into the input pin) voltage flows from 5v+ through the 100K resistor and then because the switch is floating (or not connected to anything) into the analog input pin on the DB 25 connector. because the voltage goes into the pin, the RC reads 254, or 5v.

however when the sensor is on, voltage flows from the 5v+ thorough the 100k resistor and because the switch is closed to ground, the voltage goes into ground. the analog input pin reads 0, or 0v, because it is easer for the voltage to flow directly to ground then through the microprocessor's's A/D and then to ground.

the point of this whole explanation is to demonstrate that this is entirely possible, and even in some aspects simpler to implement in code then reading digital inputs. however, the same effect can be accomplished with out the added hardware by the following (theoretical for clarity) code:

DIGITAL_IN * 254 = DIGITAL_IN

this saves you $5, a trip to radio shack, and 4 minutes of soldering.

-Jacob
  #38   Spotlight this post!  
Unread 18-02-2003, 21:46
Gabriel Gabriel is offline
Registered User
#1409 (Fightin' Llamas)
 
Join Date: Jan 2003
Location: Great Barrington MA
Posts: 150
Gabriel is just really niceGabriel is just really niceGabriel is just really niceGabriel is just really nice
Send a message via AIM to Gabriel
We started off with dead reckoning and now we're using two rotation counters (just a wheel with magnets and a read switch) and it works really well. It still needs a little calibration and we're usually a few inches off target so we won't necesarilly hit the middle perfectly but I think we'll always hit something no matter how low our battery is. (So long as the brakes are up at the start of the match javascript:smilie(''))

Here's a (hopefully obvious) tip: Be prepared to have your opponent place boxes in front of you before auto mode.

What I'm really worried about at this point is what will happen if four robots all decide to run for the center during autonomous mode. We went to the UTC scrimmage at Suffield and saw robots interfering with their alliance partners during autonomous mode (one even managed to end up right in front of his ally's starting position). We also saw that autonomous teams, even if they didn't make it to the stacks had an advantage over teams that just sat there. Unfortunately the only really viable strategy seems to be knocking over stacks and fighting over boxes and I'm beginning to think this game might end up a little more aggressive than FIRST anticipated.
  #39   Spotlight this post!  
Unread 18-02-2003, 23:41
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
Analog Sensors? Maybe I'm too stupid follow the previous explanation. Why would you want/need to do such a thing again?

I would guess that an analog value could give you a sort of "input inegrity" like not so reflective, definitely on, or pretty much completely off. The problem is, even if you could tell how definitive you are on the line, the programmer has to decide that this or that value and up will be considered "on the line" meaning, in the end, it's a 1 or 0 anyways. Why not read it in as that? It saves memory too.

As far as what our team is doing. We are doing a line tracking system. Very simple. Two sensors, one on the left, and one on the right. If one trips, it adjusts to the other, and so on so forth. As long as the line is between, it would work. Where it fails is if we don't have it turn sharply enough and the line is outside of both sensors. Thats a little bit of testing but not much. Another issue that came to my attention today is what happens when the robot is going up the ramp. It seems as if the wire mesh sends erratic input to the sensors. If this the case, then an "up ramp" case would have to determined, and the input from the optical sensors would be ignored. Unfortunately using only the senors, I don't think that it's possible to determine that you are going up the ramp unless you keep track of all input from previous loops. In doing so it takes a lot of memory and processing time to determine that the input being obtained is invalid.

Sticking to my keep-it-simple philosophy. I wouldn't try to figure out such a thing in that manner and probably just use 4 sensors (lined up on the same axis) and determine if something impossible happens such as the far left AND right sensors were on at the same time. When an "impossible" case occurs, I would assume the robot is on the ramp and go straight for the rest of the autonomous period.
__________________
Ogun's Laughter is No Joke!!!
  #40   Spotlight this post!  
Unread 19-02-2003, 03:31
Lindy Lindy is offline
Registered User
#0968 (RAWC)
 
Join Date: Nov 2002
Location: West Covina, CA
Posts: 15
Lindy is an unknown quantity at this point
Send a message via AIM to Lindy
Done as of last Saturday. Actually, that was a revision -- the core autonomous program was completed a bit before (I have 1,780 bytes of storage per bank now!). This is a strange case where the autonomous code was actually finished before the final main robot code (!).

What does it do? Just as simple and unsophisticated as you can get (besides not moving at all): Dead reckoning, because we were simply too lazy to put in real detection of external stimuli (I think). Actually, I call it "copy-cat" dead reckoning because the code actually doesn't know how to move the bot at all; it contains no movement instructions. Rather, it records its movements when the robot is actually driven (after the user activates the robot's programming mode) and stores it into EEPROM. When it goes into full autonomous mode, it'll replay back the instructions it recorded.

We can store four autonomous movement paths in this manner and they could all be inversed, so that it will be able to play the instructions back if it's on the other side of the field from where it was programmed at (in theory). I intended the whole system to be easy to use so that you can change the behavior of the robot without having to touch a computer or a line of PBASIC.

It worked quite well so far. However, I can just foresee the huge list of possible pitfalls this thing could ensure. Joy. At Chatsworth, we actually loaded a movement path for the robot about five minutes before our first match outside in a wide hallway- not a good thing as far as bug-testing goes. And, there's always pure human error: In our last match, someone oriented the robot backwards in its starting position... the robot's dumbfire autonomous mode didn't help it at all.

Last edited by Lindy : 19-02-2003 at 03:35.
  #41   Spotlight this post!  
Unread 19-02-2003, 17:24
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
Wow...playing back something you guys did before...now that's something new I haven't heard before. Aside from storage issues, that is a relatively simple way of doing things and has a high chance of success as long as the human moved the bot under the EXACT same conditions as a real match. Most importantly, the surface that you drive on has the be the same.

It also suffers from the same pitfalls as dead reckoning. When it gets hit. I'm sure it can't correct itself.
__________________
Ogun's Laughter is No Joke!!!
  #42   Spotlight this post!  
Unread 19-02-2003, 21:44
dave_l dave_l is offline
Registered User
#1038
 
Join Date: Feb 2003
Location: Lakota East HS
Posts: 10
dave_l is an unknown quantity at this point
Just teach it...

Interesting... Same approach we used.

Write 6 bytes of data to eeprom every other clock tick during training runs, play it back during autonomous mode. Using 5 of the banks for auto progs (plus one for init, one for main, and one utility).

Programmable on site, so we can adjust to conditions (we don't have the right carpeting) or partner strategy. Biggest difficulty is not driving it so hard during training that you get tread slips.

The utility allows us to see/massage the data after the fact, though we haven't actually done anything along those lines yet.

The addressing looks a little strange, but there is a method to my madness.

Dave

Serin COMA\COMB, INBAUD,
[oi_swA,oi_swB,rc_swA,PB_mode,sensor2,
p2_y,p1_y,p4_y,p3_y,delta_t]

if rc_sw4 = 0 or auton_mode = 1 then
if (time>>1)*6 < $6F0 then
Read (time>>1)*6, p1_y, p2_y, p3_y, p4_y, oi_swA, oi_swB
time = time +1 +delta_t
endif
else 'learn mode
if (time>>1)*6 < $6F0 then
write (time>>1)*6, p1_y, p2_y, p3_y, p4_y, oi_swA, oi_swB
time = time +1 +delta_t
endif
endif

if auto = 2 then
run 2 'dumper utilty
else
run 1 'process the data
endif
  #43   Spotlight this post!  
Unread 20-02-2003, 20:23
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
Ok.. correct me if I'm wrong (which of course I probably am, so have at it.. ), but isn't it true that the program can only access the EEPROM in the current program slot? Or am I wrong and if so could you explain why I'm wrong.. lol. Thanks!
__________________
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
  #44   Spotlight this post!  
Unread 20-02-2003, 20:46
Lindy Lindy is offline
Registered User
#0968 (RAWC)
 
Join Date: Nov 2002
Location: West Covina, CA
Posts: 15
Lindy is an unknown quantity at this point
Send a message via AIM to Lindy
Quote:
Originally posted by randomperson
Ok.. correct me if I'm wrong (which of course I probably am, so have at it.. ), but isn't it true that the program can only access the EEPROM in the current program slot? Or am I wrong and if so could you explain why I'm wrong.. lol. Thanks!
Yes, that's true, for the BS2SX and lower anyway. That fact was a bit of a headache, actually. In the original version of our code, there was only 895 bytes free in the autonomous mode bank after the program was written. It was enough for our uses, but it was chewing up memory faster than I liked.

I ended up doing some stupidly pigheaded scheme where the remaining banks on the Stamp had a small routine which wrote and fetched instructions and passed it to the autonomous bank via the scratchpad (which can be accessed by all banks). In hindsight, it's all very unnecessary, but there are now 1,750 bytes for the four storage banks, totaling about 6.8 K worth of available space for autonomous instructions. We will never use them.

(I am now reminded of a thread on this board regarding "overcomplicated autonomous code." Um... whoops.)

Oh, and the Basic Stamp BS2P has the STORE statement, which allows READ and WRITE to perform on a specific bank. Would have made things so much more easier...
  #45   Spotlight this post!  
Unread 21-02-2003, 20:09
dave_l dave_l is offline
Registered User
#1038
 
Join Date: Feb 2003
Location: Lakota East HS
Posts: 10
dave_l is an unknown quantity at this point
Quote:
Ok.. correct me if I'm wrong (which of course I probably am, so have at it.. ), but isn't it true that the program can only access the EEPROM in the current program slot?
You are correct. But if you declare the same variables in the same order in each program, then their values are available when you swap slots. So what I read in from eeprom in one slot gets processed by the program in the other slot. Simplified structure:

slot 0
declare variables
do init stuff
loop waiting for start
if auton=1 or learn=1 then
run auto 'variable with auton prog no.
else
run 1
endif

slot 1
declare (same) variables
begin: if auton=0 and learn=0 then serin ...
process input
serout ...
if auton=1 or learn=1 then run auto
goto begin

slot 3 thru 7 (auton progs)
declare (same) variable
serin ...
if learn=0 or auton=1 then
read ...
else
write ...
endif
run 1

(and I've still got 8 bytes of ram available)
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
A better autonomous method.. randomperson Programming 4 24-02-2004 18:02
crazy idea for autonomous Mike Ciance Programming 16 24-04-2003 21:50
autonomous location manodrum Programming 4 02-04-2003 08:05
autonomous mode problem on field Chris_C Programming 17 26-03-2003 19:11
Autonomous Kill Switch UCGL_Guy Programming 8 15-01-2003 17:39


All times are GMT -5. The time now is 03:58.

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