|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#31
|
|||||
|
|||||
|
Quote:
[All student team baby, our mentors/teacher didn't know what the robot looked like until yesterday.] |
|
#32
|
||||
|
||||
|
Sensor Inputs to Analog Port?
Quote:
|
|
#33
|
|||||
|
|||||
|
optical sensors.... on analog, hes got a point...isn't that illegal on the power distribution sheet, even if it was possible...
|
|
#34
|
|||||
|
|||||
|
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
|
|||||
|
|||||
|
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.
|
|
#36
|
|||
|
|||
|
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
|
|||||
|
|||||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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. |
|
#40
|
|||
|
|||
|
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
|
|||
|
|||
|
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. |
|
#42
|
|||
|
|||
|
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
|
||||
|
||||
|
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!
|
|
#44
|
|||
|
|||
|
Quote:
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
|
|||
|
|||
|
Quote:
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) |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
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 |