2 days to go how is Autonomous going?
 

Other then simple programs such as moving forward or back, how many teams are done with their Autonomous code. Our bot is still in the shop and our programmer is just now getting his time with it to figure out how to program everything. How's the rest of the world going?

Ehhh, pretty good.
 

Im not on the programming team, but im pretty sure we have about half of our autonomous programs finished.

i dun with it:D :D :D

I've got a program written, but our robot still doesn't drive so I can't test it. I'll be lucky to get 15mins with the robot before we ship...

Aint it the truth!

I know what thats like.

Well, autonomous is done, theoretically. I've gotta tweak it, but we went to a scrimmage today @ chatsworth and I kinda made the gears jump off. so we gotta repair drive train b4 the tweakage. The weird thing tho, autonomous didn't work @ chatsworth at all.

Our autonomous is an adaptable line tracker. It's cool cuz it adapts motor power values based on how long you've been in a particular position and orientation. Pretty nice stuff. Just need to tweak then we're done.

930 just has some tweaking to do after Sussex Practice Competition.

hehe.. our robot has been driveable for 2 weeks:) .. and we had 3 auto proggies done and tested and then they switched to 2-wheel drive.. so now we have one (nickname: "track line and jump over the ramp".. lol) Now working on an adaptable dead-reckoning proggie now.. fun fun. Word of advice for auto programs: hardware timers make it soo much easier! Now if i could just quit running out of EEPROM space.. :D

Only 2 weeks?...

Why hardware timers? I use a software timer in mine and it works fine. 38 counts = 1 second.

Hmm.. yeah, that would work <i>if</i> your program didn't have lots of branches in it and executed at a somewhat constant speed.. but personally hardware is better cuz we can count in 1/4 seconds instead of 1/38th.. and like I said, its easier. lol, like 3 lines of code to implement it. much easier methinks compared to some of the solutions ive seen on these boards..

True I guess. My code's fairly constant in all branches. I've tested the timing with feedback LED lights and it seems constant. We have a counter that counts how long the robot's been on a particular sensor config and adjusts motor power due to that. So I don't need to be ultra precise, and 1/38 is an annoying number to work with tho.

yeah.. i got pissed off about the timing not working correctly and the weird numbers... so i got myself a 555 and stuck it on our prototype. it worked great, so we kept it.. definitely gonna have one next year too even if there's no automatic programming.. very useful

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.

What we did was while design worked hard on our design, I got 2 or 3 guys together and made last year's robot do kinda what this years bot will be doing. We then took this and found out flaws in our design, found better, more efficient and faster methods of working as well as gave us the ability to have different codes designed (such as stack tracking) that can be used if we add and setup the sensors. I have a few different little autonomous codes so we can swap codes to counteract what scouting data brings us.

One last thing, with your dead reckoning codes, be careful! I realized very well that over time those numbers WILL change. The drive system is gonna change after running a bit, as things wear in and hardware changes. Also I'd really suggest using the delta_t counter and add it in to your counter since sometimes that RC can be crazy and lose loops like mad. It keeps it so you have your times closer. That's my 2 cents though. Good luck programmers. If you guys got that autonomous running well, great job cause you deserve it.

Are code is done we got the auton code working it does perfect 90's everytime not matter about wheel slip or battery it works everytime.

could you give me an example of how delta_t would be used? I'm interested in how this could be utilized in my own counter.

15 minutes? we should be so lucky.

really easy. make sure delta_t is setup in your code like in the default code and use this for your counter...

counter = counter + 1 + delta_t

Yah, 15 minutes sounds about right. The problem being I have never programed in pbasic before and have no idea if our auto code even works!

***sigh*** what I wouldn't give for fractions and inverse trig functions..........

I've talked to several teams, and none of them got line following working with just 3 sensors. One used 5 sensors and has it working, and the rest of us are using dead reckoning.

edit: do a search on delta_t. I know I've explained it several times, and I know others have as well.

Hey, errrm there's a robot emulator out there. go to the innovation first website. It's a good way to test if your code is messed up or not. Can't really predict turning and stuff because that's all based on your robot, but it helps.

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:

HALLELUYAH!!! Praise be the the powers that be, we have an extension!! We were almost considering not telling our Mech E team so we had more time to test programing :p I say programers unite and we take control of the bots for a change. Wadda ya all think?

extension wu? Well I am the driver as well as programmer. *chuckles* GTA 3 skillz baby! Not really.. but extension? time to head over to first website

I shouldn't say not working, but not working quickly. With the code you have, you aren't going very fast. The teams I talked to all decided that speed was more important then the coolness of linefollowing.

bah our programmers have to much time with the bot and havn't given our drivers enough time to p ractice.. today our sponsors company is working and only allowed 2 team members to work on the the bot during work hourse ( like 7-3 ) so the programmers forced their way in there and have been running autonmous programs all day, I have to sit here and wait until finally at about 2:30 I can get up there and start playing around and getting better at this driving buisness

Very very true. I'm actually doing autonomous dead reckoning as we speak. Problem is I'm worred about the battery running low and that fudging up how much it turns... etc. etc. I wish I had time to install the gyro and learn how to use it. Grrrr.

Our code is coming along but was set back a few days ago when our yaw rate chip decided that it didn't want to work anymore setting us back about 3 days... but we are getting by...

we are doing some crazy stuff that should be cool if it gets done...hopefully we can get enough time in to play with it while still letting the drivers practice.

hehe.. our team is lucky... the driver is our other programmer .. although she doesn't really do much programming.. but no competition for driving times!

.. they wont let me drive cuz im way too agressive.. you should have seen the mentors faces when i was doing "quality control" (involving running the robot in high gear straight into a cement wall multiple times).. hehe:D

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.]

Sensor Inputs to Analog Port?
 

You have your optical sensors connected to the analog input of your RC?

optical sensors.... on analog, hes got a point...isn't that illegal on the power distribution sheet, even if it was possible...

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

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.

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..

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

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(':D'))

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.

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.

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.

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.

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

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...

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)