Gatorbotics Brain

1/16/09

2009-01-16T20:47:00.000-08:00

So...I can't figure out how to post on the main blog so I am blogging here. Hi! This is Sallie(not to be confused with Allie). So today has been filled with more prototyping! After dinner we decided to begin to prototype some of our new ideas. We are afraid the windmill is going to get stuck or not work. Instead, we are thinking of using conveyor belts made out of surgical tubing. Annie, Shreya (did I spell that right), divya, and I started to prototype a conveyor belt. While grooving to some jack johnson music, we determined that rather than have circular pully/sticks/track/the thing that the belt goes on, a multi-faceted surface tended to grip the belt better. Basically, we took some 80/20 and put this scratchy sandpaper tape for extra friction and used surgical tubing for the belt. We also tried to saw/file the sides down to make sides; it didn't turn out to grippy enough. Finally, we got a prototype that kinda worked. Next, we ran a lap around the circle and came back to make a prototype out of the ball-put-er-out-er. We decided that we might need to make our base of our robot a little shorter in order to allow the put-er-out-er to sucessfully get the ball in the trailer. Oh! we got the trailer today! It is a work of art. We hopefully are getting 3 more orbit balls from north carolina! So other things that happened today: toby was being amazing and de-bugging or talking with the computers as others onlooked, others were designing or measuring or planning for the robot. Ida tried to take pictures for the website. Allie was using solid works. And we all were shooting our orbit ball into our new trailer. Fun Friday!

Wheels

2008-01-24T16:29:00.000-08:00

On wednesday David Anne and I put together the mecanum wheels with the bearings from last year's wheels inside. We measured the width of the bearings and the width of the spacers that were inside of the mecanum wheels and the bearings were 3mm short. To temporarily take care of the change in width we layered tape onto the plastic around the bearings. Since the bearings have two sides of plastic parts that could come loose, we decided to use three of the holes to hold the sides together with screws and bolts. The other three holes were used to hold the complete wheels together. We then noticed that the sprocket must be spaced apart from the wheel so that the chain won't hit the wheels.

first week

2008-01-13T19:59:00.001-08:00

reposting from build blog - this is not productive. can we *please* just combine and tag them?

39 days left!

i've been rather remiss in the blogging for the past couple days.

basically, there's a new design in the works. multiple, actually. i know emily/annie were definitely getting some action with the pvc pipe today. an overpass HAS been constructed. i'm not entirely sure whether it's precise proportions but it looks amaaaaazing. another idea is the three-prong one we've been working with for awhile.

also, are we really going to have an arm? we've all agreed that drive train and strong chassis is definitely the priority. but do we attempt an actuating arm as well?
and for that drive train... mecanum wheels will hopefully be ordered asap, mourad's been given the order. jimmy mentioned that you don't need to program them to slide? you can just use the same old drive code like for anything else? with skid steer? we'll obviously have to check that out.

there are a lot of ideas out there, and while we're beginning to experiment and start doing more serious prototyping, all the leads definitely want a small, focused design meeting with mentors. that's what saturday was planned to be, but it ended up being more general, which is okay. except that as such a young team, we definitely want your opinions and input as well as advice on how to proceed once we finally have a (temporarily) set design we want to aim for.

once again, are we "going fat"? decisions really need to start getting made, but i know we dont want to make those decisions without consulting the mentors as a group rather than individually, where we get conflicting opinions.

oh i just had a random thought: i think that maybe we should just combine the two blog and maybe tag the posts "programming" or "build"? because at least for now, i'm just posting the same thing in two places. and hopefully people are reading both. thoughts? comments?

all the newbies who were around on saturday HAVE been shoptrained (and got to make blocks. grrrr. ) jessa ran a programming 101 workshop, which was definitely useful. so now hopefully sallie, neli, and divya (somewhat) get programming. yay! that's wayyyy farther than programming was last year. i think at the end of the first week, we'd just received "C for dummies" and thought it was a godsend. :)

a temporary electronics board (complete with a battery mount, attached and all!) has been put on the prototype kit chassis. there are also wheels on there. now if only there can be motors. that will happen soon, i believe.

i'm sure there are more things that have happened. actually, i knowww there are more things that have happened. blanking out.

oh! does anyone remember where i put the lugs for the battey leads?! i distinctly remember being like "let's not forget where i'm putting these!" but we've completely forgotten. we need to find those.

thank you (Again!) to doug for providing us with retail therapy. thank you for all the mentors for your commitment and energy and enthusiasm and time. we appreciate it so much.

i'll post random thoughts as they come to me. this is all i have for now.

monday + tuesday

2008-01-08T22:11:00.000-08:00

sorry for no post yesterday, and today will have to be quick

summary version:

we have a basic arm idea. trying to finalize motors/potentiometers and how to mount, etc.
drive train: 6 wheels? or 4? definitely steering the front two. any input on how cars works would be greatly appreciated.

there has been some math-doing. :) but i assume there is more to come.

thank you thank you to karlin and tiffany for coming

and i believe there are cart designs in the works

a question: are we ACTUALLY going to use sketchup/solidworks? i think we should... if we know how.
boms and weight lists should be made.

that's all...

we've kicked off!

2008-01-06T15:02:00.000-08:00

hello!

the 2008 season has begun! build and programming are working together on the design process, so i've posted this to both blogs.

caroline, me, allie, and nandini headed down at the crack of dawn (literally...) saturday to recieve the challenge from sj state. this year's challenge, first overdrive, is different from any other challenge. effectively, it's a racetrack with oversized inflatable balls. these are the game pieces. it's really hard to describe - search for first overdrive 08 on youtube and you should find something. i think this should link to it: http://youtube.com/watch?v=GKBIEqY2Ak4

we had a great turnout for brainstorming session at school saturday. many mentors came, and thank you for that. we broke into groups and came up with many rough ideas.

then, today, with a smaller turnout (allie, caroline, anndini, annie c, sallie, crystal, mari, neli, me...) we presented our design ideas and began to PROTOTYPE! the two main arm concepts at this point are the shoulder-elbow-wrist extendable design, as recommended by jimmy and a forklift. very rough prototyping with 80/20 ensued. allie and i also put together the kit chassis as a prototype.

things to think about:
what is going to grip that thing? the ball is huge, and fairly slippery.
what is our overall strategy? i know we're hoping to go over rather than under the overpass, but are we going to place it on top at the end?
what's our priority?
hybrid?
sensors?
we've been discussing many different concepts for a drive train. obviously, scotty's will not work. we can't almost tip over every time we turn...

possibilities:
-mecanum wheels. like jester drive (is it possible to buy them? how difficult is the programming?)
-omni wheels (again. expensive. no experience with them)
-omni wheel/traction wheel combo. we saw a lot of this in atlanta
-power steering two smaller front wheel
-combination of casters and driven wheels
-anything i've forgotten

this is something we'll have to continue to think about.

oh, there's a schedule of deadlines on the project room whiteboard. that will come soon. we deffffinitely need to be testing far earlier this year, and spend less time on prototyping. i know we're hoping to have parents help out to build an overpass, and we want to make good use of that.

uh, also, can we get that leak in the closet taken care of? ...it makes me nervous.

a HUGE THANK YOU to doug for generally being an amazing source of information as well as providing the books and tools necessary. those hex screwdrivers will make everything so much easier. :D
also thanks to karlin for coming in to help us talk through concepts, and marsha abbott for chaperoning and yummy dips for the pita, as well as the costco run.

get ready for season! i'm excited. hopefully you are too. :)

ship day!

2007-02-20T01:13:00.000-08:00

it's officially ship day... ack!

today we tested and debugged... we still need to do a LOT of testing, especially autonomous. we now have 3 autonomous codes. one literally does nothing, to make sure we don't sabotage our own alliance, one is from the right position, and one's from the left. sophia helped us make a dongle that you plug into the dig i/os.

ramp code has been modified to release when both side buttons and the trigger are pressed to insure less accidental release. there is a wingtimer to make sure flipper only goes halfway.

the limit switch works. now we might add another one to stop at the second spider arm.

driving. we can't really drive straight. and we don't know why. it sort of goes in circles. and speaking of circles, erm, the robot... jumps? when you spin too quickly.

paly came over and used our rack and we realized that if we are aligned with robots that have really low clearance, they might just fold up our ramps, not drive up them...

wiring is sort of ugly, but low priority.

we learned by experience the importance of the kill switch being easily accessible. it now is.

there's a very long list of stuff to be done tomorrow before crating.

that's all i remember. vacuum idea has been abandoned due to weight resistrictions.

sunday and non-programming news

2007-02-18T21:57:00.000-08:00

alright so the p/e team has been doing a lot of non-programming things. mostly experimenting with the vacuum idea.

we know that if we attach a wide nozzle to the end of the shop vac that used to be in the project room it works really well to pick up the tubes and place them on the rack. now we just have to modify it to use the motors we are given by FIRST. doug and steve helped us to modify the fan and parts of the shop vac that we took to pieces and replace the motor with our own.

if this design works it will be incredibly awesome and really easy to operate from far far away. just suck up, lift arm, reverse motor.

tomorrow we will write vacuum code.

doug left some edge deflect (?) stuff in a notebook with julia. neither julia nor i have any idea what it's talking about but it has something to do with limit switches. jessa knows what they are.

we are meeting at 10 tomorrow.

stores do not sell vacuum attachments separately.

we are hooking up this vacuum thing at the end of the arm (if it works. we need to test it to see, and if it does, GREAT! if it doesn't, we always have the old arm to fall back on)

after erin and mary left, we tested the ramp code with the actual ramps, and it works! julia/jimmy/build/everyone is concerned that the driver might accidently hit those buttons during competition and that would screw stuff up badly. if it's simple and foolproof, we might want to add a timer or a switch or something to the code so that you CAN'T release the ramps before you want to. we can talk about that tomorrow.

to do:

mount limit switches
TEST CODE
-autonomous
-arm
-everything
write vacuum code
clean up wiring
hook up arm and ramps

we need to remember to bring the right terminal box to ideo.

that's all i remember about now.

proggggggress. fri.

2007-02-16T19:09:00.000-08:00

WE HAVE AUTONOMOUS. THAT'S RIGHT.

OHHHHHTONOMOUS

and it works. yeah. it's basically go forward. turn. we need to make the turn bigger. then it's fwd back fwd back. eric came and helped us make a really really easy loop. it's one line of code. YAY.

we might want to shorten the wires on the electronics board.

mary re-soldered the limit switches. we made pretty diagrams. they're in GENERAL.

yeah.

i'm exhausted.

we are all crazy.

karlin ate.

mary's a juicy ninja.

caroline has a wet nose

metamorphisis

that's about it. so far.

AUTONOMOUS. YEAH.

thurs

2007-02-15T22:51:00.000-08:00

karlin and erin and sherri and alecia and caroline were here today.

we talked about limit switches... there will be some sort of block on the gear for the arm, and the limit switch and some metal (caroline and i bent metal and drilled holes) on the tower frame. the block might just be made out of an eraser, we haven't really decided yet.

AUTONOMOUS CODE HAS BEEN STARTED. yes. timers and good stuff like that. no interrupts necessary! we think! now we have to code the if timer is between x and y do lgoweiutpreoiuw. aka the real code. basically forward. turn. forward. back. fwd. back. repeat the fwd. back.

the robot has wings. it's pretty awesome. it still needs a name. we want to fly. soon.

build is going to make some sort of adjustable crossbar for the back of the tower.

our electronics cover has been cut and mounted with velcro. it's great.

someone really needs to solder the good limit switch back together. both of the them (where's the other one?!) need to get mounted and make it work.

WE REALLY NEED TO GET DONE WITH EVERYTHING TOMORROW. REALLY.

we didn't forcefeed karlin today. progress has been made. =)

that's about all i can remember. general is our notebook from now on.

the backed up code is on emily.

you need to hook up the oi if you want printf values. don't forget.

yeah.

gnite.

wednesday

2007-02-14T22:33:00.000-08:00

caroline and jessa (and sherri) modified arm code so that there are two speeds

erin and mary did some wire management

caroline and sherri went to ideo, and mounted the electronics board. there was other random bulid stuff to help with so that build could then help us w/ crossbraces for limit switches.

we were planning on attaching to the limit switches to crossbraces on the tower... however, with the new arm design that programmers have yet to see, the arm will probably not be touching the tower in the front. we had the idea before to attach protuding bit from the gear and then limit switches, but were afraid of having two switches hitting each other and ugliness. jimmy suggests just having different radii which might work. the other limit switch could be attached from the tower, but build/jimmy thinks that we need flappy bits of metal so we don't get crunch. because that would be ugly.

current idea:

*limit switch for the front on the gear itself
*for the back on the tower

however, because we only have a prototype + it was 10 we decided to deal with it tomorrow. also we wanted to make sure it wouldn't screw anything else up.

there is a list of stuff in the GENERAL notebook for programming. that's our notebook now.

electronics covers need to be dealt with. they have been designed and are made out of the board material.

ribs go in the wrong direction for the board... but it's not worth changing (says everyone besides rockman)

yeah. sorry if i forgot anything - just look in GENERAL. the dogeared page.

chrissy now has the best picture ever of caroline. =)

Schedule for this week

2007-02-14T15:02:00.000-08:00

Tues:

rewire (somewhat done)
hack mount board (done)
(joystick board)
wings
arm working (the motor spun, but no arm to test with)
fix limit switch code (done)
wire (done... the robot drove)
fix deadband (done)
order potientiometer

Wed:

get real arm working
mount limit switch
arm sensor (potentiometer/GTS)
real mount board

Thurs:

wings - fly!

Fri:

autonomous - defense

Sat/Sun/Mon/Tues:

TEST!
PRACTICE!

tuesday + DRIVING ROBOT!

2007-02-13T19:41:00.000-08:00

hello!

so. the robot ships a week from today. that's the scary/AHHH FREAK OUT NOW news. however, the robot drives. the way we want it to. there were some issues, we flipped some cables, some wires. it's all good now; things were just wired badly.

one issue we haven't looked into yet is the fact that when you stop the joystick/bring it back to center, there is a lag in one of the motors, causing it to turn in that direction. apparently, this is a known issue in the master code (?) for this year, so hopefully there is a simple solution.

jessa explained interrupts to us and tomorrow we are going to dive into the details.

we have a schedule that we have all (aka those of us who were there when we agreed: sherri, mary, erin) agreed to stick to for the remainder of this week, regardless of whether judy/karlin/jessa can be with us. we completed everything that we physically could from today's list. we couldn't debug wing/arm code since we don't HAVE wings/arm connected.

there was some wiring, soldering, clampsmushing, ziptying and other lovely things while we had the robot. the electronics cover goes on top of the board, so zip ties need to go UNDER it.

the robot needs a name. badly.

and the dolly has sharp edges... don't ram into it.

we need to have EVERYTHING done by friday so sat/sun/mon/tues is TESTESTESTESTEST. PRACTICEPRACTICEPRACTICE.

we also need to/already did change the deadbands for making driving more intuitive and less really-big-deadband-and-then-it-jumps-crazy.

yay! IT MOVES. IT'S ALIVE. IT NEEDS A NAME.

this week's schedule

2007-02-11T21:54:00.000-08:00

from judy's email:

Tuesday 3:30-7 PM- Judy 5-7, Jessa 3:30-7

Wednesday 3-7 PM- Jessa 3-5, Judy 5-7

Thursday 3:30-7 PM- Karlin 3:30-7, Jessa 3:30-5 or 5-7

Friday 3-7 PM- Judy 3-7, Karlin 5-7

(Saturday) <-- might meet depending on how things go

Sunday 11-3 PM- JJ&K 11-3

from me:

*i will be around school tomorrow (monday) after school anyway, so if there's anything (ie wiring) that needs to be done, i can do it.

*also: judy showed erin how to back up on the USB stick and why that's important. so basically, every night before we leave we should save that day's code in it's own folder. that way, if we do anything drastically bad, we have some code to fall back on.

*if we could get the new tape in the label maker that would be great... currently we are using blue tape and a sharpie, which works too.

sunday

2007-02-11T21:27:00.000-08:00

so on friday we got the new board material to lighten up the robot... it's pretty much just air with some plastic partitions, but we have been assured that it is strong. so we had to move everything from one board to the other and drilling and washers and such stuff. but finally we had an assembled board and then today we checked that everything worked. that one speed controller is still finicky, but should be okay. we can switch it out if necessary.

we went to ideo and tested the arm code and started to lengthen the transmission leads because they are too short and realized (again) that one of the radios is finicky but then i think we changed the cable and it was okay. the arm code works and erin and caroline were changing the code so that you could move the arm again if it hits the switch.

we did some other stuff too but that's about all i remember. build was punching some serious holes into that metal and it was pretty cool to watch. we are cutting our wire length as much as possible because every little bit of wire is a little bit of weight we cut back on! =)

wed + thurs

2007-02-08T20:02:00.000-08:00

quick recap of wednesday: we stayed till 9, got the board all wired up and functional and lovely. tues night judy and karlin went to the los altos team and got us a 40 amp circuit breaker which is gold and shiny. we did drilling and wire cutting and clamp smushing and all sorts of lovely things. the board was functioning... we attached motors to make sure all of our wiring was functional and stuff downloaded and it was good.

thurs: instead of squashing the tether cable in there, we figured out how to attach the radios, so now we are sending signals more like we will in the actual competition. we (aka sherri) learned about debouncing limit switches and got thoroughly confused. but anyhow, we knew what we had to do and mary soldered and put together the circuit for our other limit switch. erin didn't freak out too much when we saw the board, but wants it to be prettier. build is going to put a potientometer on the arm so that the yet-t0-be-decided driver has distinct analog values and it just makes coding so much easier. yeah.

we talked about SUPER-SCARY autonomous. two major types - defense and offense. our defense strategy is pretty much just to go at an angle, turn, forward, back, forward back, until 15 sec is up. unfortunately we are going to have to use a timer. offense: go straight/angled for x seconds, hang keeper. (We hope!)

and that's my condensed, what-i-can-remember-in-my-stressed-out-state version of the week.

2/6/07

2007-02-06T18:35:00.000-08:00

Today Erin was sick, so we weren't really sure what to do. Karlin came and we make marks for screws and drilled holes that actually fit what we were trying to attach to the board. All the speed controllers, the RC, one of the breaker panels, and the main switch were all attached to the board. Los Altos' team is willing to give us their old 40 amp circuit breaker.

* We need 12 gauge black wire.

*We have too much energy. (*alecia commenting on the group*) We also cut the 12 gauge red wires that will be connected to the speed controllers and the circuit breaker.

So yes. We did wiring and drilling and assembling, and that's just about it. We actually drilled the holes in the right spots which was very good. =)

And that's just about it. Hopefully tomorrow will be more productive, remember, we meet at 5!

-Sherri

Schedule + Deadlines!

2007-02-04T21:22:00.000-08:00

From Caroline's email:

-Tuesday: 3:15-7 (some people are going to Los Altos to talk about the 40 amp circuit breaker panel. Erin will send details)
-Wednesday: 5-8 (wiring and mounting done)
-Thursday: 3:15-7
-Friday: 3-7ish (driving by today)
-Sunday: 12-4 (arm running)

Sunday

2007-02-04T16:24:00.000-08:00

Hello all

Today we started assembling electronics. We had more mentors than programmers, which is always nice. Jessa and Eric came first. We looked at the board and speed controllers and talked about methods of attaching them. I won't bore you with the details, but Jessa went to Ace and got us some screws and nylon washers. Drilling holes and other such nice stuff that made us feel like we were on build. We found the large box of screws we had been looking for. Caroline wrote/modified/added code for another limit switch, while Erin and Sherri assembled electronics. Or rather, Erin drilled holes and Sherri attempted to strip wire. She's learning. Slowly. ;)

We talked about autonomous. We possibly might use a GTS, we're not sure. Autonomous is very scary. No camera though. Camera is wayyy too hard with 2 weeks left. We went down to the cafeteria and looked at the Rack and took the arm and talked strategy. We didn't really come up with one, but it is going to be really hard to program this thing to do it in autonomous. And the driver (Does anyone know who is driving??) better be very very good to move the joystick jusssttt enough to drop the tube.

Also, sensors. What are we using? No camera. Maybe GTS, otherwise, how on EARTH do we get autonomous working? Potientometer, for the arm? So driver knows how far to move etc etc?

While looking through some stuff online, Jessa found a diagram of "suggested circuits" or something like that. Those funny looking plastic things? We may be required to use them. Do we know what they do/why we would need them? No. We looked online and couldn't find anything. We're really hoping Emily/SOMEBODY knows... These are odd looking black and red plastic things with some metal in them. Jessa, Judy, and Karlin all have no idea what they are. If I remember right, FIRST called them terminal blocks, I think. ????

And finally, Eric took the broken speed controllers home to see if anything can be done to the many we managed to short/break.

Oh, right. In order to get rid of dead weight, we might cut the end of our polycarb electronics board off, because the only thing on that end of it was the main switch, which can be easily moved. However, with our scary weird plastic puzzle pieces... Who knows?

That's all I can remember.

Board + more functional code!

2007-02-01T20:26:00.000-08:00

Hey

Quick summary of today: We got the switch for the arm code working. It turned out we were using the wrong variable because it originally set the value to ALWAYS be 1. So nothing happened/it always happened (I can't remember). We changed the variable, code works, yayness. Then Mary and drew an outline/diagram of the electronics board with to-size drawings and labels and it's hella cool. If slightly messy. We know where all the precious gold 2007 stuff is. And that, in a (very) short form, was our evening! It was a shortened meeting because Judy and Karlin came at 5:30.

More Functional Code! 1/31/07

2007-01-31T20:41:00.000-08:00

Hey

So we can make the robot (which is currently on blocks) move! Or rather, the wheels start spinning like they are supposed to be spinning. We hooked up the transmissions to the speed controllers and they didn't die. It's pretty cool. The deadband works too, after some problems yesterday because we were squaring the values to make parabolas. This made negative values turn positive and it wasn't very good. But now we are cubing it! =) And values stay the right sign. At first, because transmissions were facing different directions, right and left went different directions. Jessa showed us simple way (254 - ?) to fix that and it was very pretty. We looked through the code FIRST gave us, but actually really truly understood it this time. We also talked about sensors and what we need... It sounds like the arm needs two sensors to make sure it doesn't hit things, keep going and die. So we are writing "if switch is closed, die" code. In order to check voltage/etc on the touch switch, we used the oscilloscope and saw the pretty curves and that the voltage was 5V. We drew diagrams and the woooonderful if/then statements on the board with Judy and started to code for the arm/chassis switch.

To be continued...

WE WROTE FUNCTIONAL CODE!

2007-01-28T16:43:00.000-08:00

Hey so today (Sunday) we got a TON of stuff done. We had as many mentors (Jessa, Judy, Karlin, Trae, Eric) as programmers (Erin, Sherri, Mary, Alecia, Caroline). We took the electronics board off Rosie, and harvested all of her speed controllers, labeling them 06. After that, our mentors gave us a very useful introduction to C programming. The silly stuff we couldn't figure out was explained, and it all finally made sense. There were lots of "OH! That's what wasn't working!" moments, and it was all very good.

We then had a group brainstorming session on how to make the robot work, number of joysticks, etc. We finally decided on one joystick for driving, and another controlling the arm and the ramp. Preliminary arm ideas included forward as going down, backward as coming up. The joystick would control the direction/speed of the robot but the direction joystick is moving would not matter. It's the joystick position controlling the speed, if that makes sense. A combination of buttons would spin the motor controlling the ramp, because we do not want the wings unfolding by accident!

After that, we broke into groups to actually write code. Working code. It was pretty impressive. Anyhow, Caroline and Alecia were working on arm code, Mary doing the wings/ramp code, and Erin and I worked on the driving code. Following our lovely mentors' instructions, it was much much much simpler than in the past and we/I actually understood it. First, we drew pretty graphs and talked about how it would work, coded that and *gasp* it worked. I know that arm/wing people also had success. We also started talking about deadband stuff and doing preliminary coding for that. And then I had to leave.

But it was a great day, and we ACTUALLY WROTE CODE. I think this is really exciting.

And the food was really good, too. Thanks, Mukherjees! ;)

-Sherri

Hooray!!! We made (more) things work!!! :D

2007-01-21T17:20:00.000-08:00

Hello! This is my first ever ever ever blog.
:) me happy.
okie dokie.

Soooooooooo TODAY (1/21/07) we actually did something useful...without Erin. *gasp* (Don't worry, Erin, we still love you.)

Trae came for the entire time today, and Eric got to come for like 20 minutes or something.

Mentors = great help. :)

We focused on setting up 2 other laptops with the correct versions of MPLAB IDE, the C18 Compiler, and IFI Loader. So now, anyone can phutz around with code, compile it, and download it onto the board on Francey, Annie, and Emily. And the desktop computer. :) (We've increased efficiency. :D) Eric also helped set the COM ports on Annie and Emily. So, just to remind you guys, Francey, Annie, and Emily are all COM 2, and the desktop computer is COM 3. (Don't worry, we also made labels, so you don't have to memorize that.) On Francey, Annie, and Emily, there should be a copy of the original default code, and another copy for phutzing around with, so in case we royally screw up, there's a backup code to save us. :)

We were also trying to figure out how to light up the LEDs, because both were turning a kind of orangey-yellow and they were getting very hot. (In other words...NOT GOOD.) We finally figured out that the LEDs we programmed to light up were the ones on the O/I (or was it the RC...? I forget) But the point is that the LEDs DID light up; we were just looking at the wrong LEDs. (Hopefully that made sense. But if it didn't, I can show you.) However, we don't really know what to do with the other two LEDs (the red one and the green one connected to DIG_OUT_08 and 09). We're not exactly sure how to actually connect them to the board. So right now, they're just sitting on the board doing nothing. But no worries...we'll fix them soon! :)

The backup battery also ran out...but we found the charger, so it'll be ok. :)

Trae also fixed (somewhat) the camera! So now it doesn't go into erratic spasms anymore. Which is a good thing.

Also, thanks to Mary's dad for getting some cool sandwiches for us... :] (even if Mary didn't especially like hers...) and also for making copies of code for each of us.

We also wrote down (on the whiteboard) all the stuff on the board and where it's connected to...just for reference and so we actually know what we're doing.

So we got a lot done today, thanks to Trae and Eric and Mary's dad!

Now that we've got everything set up...I suppose we can all start phutzing around...some more...and we should also study the default code and last year's code so we know what we're doing before we blow something up or ruin something (just kidding)...!

(By the way, Erin...it says on the whiteboard in the project room that you have to get the code running by Tuesday...)

WE MADE SOMETHING WORK! (and our plans for next week)

2007-01-15T07:41:00.000-08:00

Alright, so I am sorry that this is my first post, but it will be a really good one. So, yesterday, (Sunday the 14) the programming and electronics team (along with Eric and Doug) figured out how to compile our code, download it, and worked on using the potentiometer and switch. For the entire week until Sunday, the P/E team worked on familiarizing ourselves with the language by writing mini codes. We also attempted to solve some of our problems... So, this week we are going to try to get all of the sensors working. Once they are "working" we are going to try to write some code that takes inputs from the sensors and uses it to change other things (such as motor speed or the led's).

Get Excited for 2007!

2006-12-23T08:30:00.000-08:00

Hello Team!

Thank you so much for signing up for Castilleja's Robotics Team: FIRST
Team 1700!
This will be our third season as a team, and we expect to rock! This email will outline the major dates for the 2007 season, what to expect and how to get involved. Please look it over, mark your calendars, and get psyched!

FIRST (For Inspiration and Recognition of Science and Technology), was founded in 1992 by Dean Kamen, "To create a world where science and technology are celebrated... where young people dream of becoming science and technology heroes". In 2006, its flagship program, the FIRST Robotics Competition, reached more than 28,000 high school students on
1,133 teams in 33 regional competitions. FIRST's multinational competition teams professionals and young people to solve an engineering design problem in an intense and competitive way. Its goal is to motivate young people to pursue education and career opportunities in science, technology, engineering, and math, while building self-confidence, knowledge, and life skills. Check out the website:
http://www.usfirst.org/community/frc/

Sat Jan 6, 2007 KICK OFF DAY! Meet at Castilleja, in the Choral Room, at 12 noon. Team leaders will be returning from San Jose State with the Challenge Announcement, Game Rules, and the Kit of Parts. Be ready to brainstorm, inventory all the cool gadgets and gizmos, and start working on the challenge. Plan on working with the team until 5pm. ALL PARENTS
are urged to stay at 12 noon for a special parent meeting to discuss team supervision, meals and logistics. Be there or be square - Lunch will be served!
As a reminder, the kick off day is the SATURDAY BEFORE school starts. Although we would love if everyone could come, we also realize that some of you might be away of vacation. Please let us know ASAP if you are unable to attend.

Sun Jan 7, 11 am to 5pm - continue brainstorming/ possibly prototype the robot.

Mon - Fri, Jan 8 - 14 (Global Week) We will meet daily after school 4 - 7 pm to work on the Challenge.

The team will work daily in the evenings after school, and weekends, to prototype and build the robot, develop the programming that controls it, create the team web site, and our team animation entry. Find the project that interests you most, work hard and HAVE FUN! We ask that Parents help provide supervision and meals.

Feb 20, 2007 Robot Shipping Deadline - Fed Ex will pick up our Robot by 5pm. Please note that the Ship Date is during Ski Week. This is usually the most intense time for build and programming, so we ask that everyone be here for it.

Feb 22, 2007 Website Design Deadline - our Website is up for Award consideration.

March 1 - 3, 2007 Pacific Northwest Regional FIRST competition in Portland, Oregon.
About a dozen team members will go. This is where we won the KPCB Entrepreneurship award in 2006.

March 15 - 17, 2007 Silicon Valley Regional FIRST competition at San Jose State Event Center.
All team members participate in this exciting tournament. This is where we won another KPCB Entrepreneurship award, and
the Engineering Inspiration Award in 2006.

April 12 -14, 2007 FIRST National Championships in Atlanta, Georgia.
About a dozen team members will go. This is where we won the Daimler Chrysler Team Spirit Award in 2006. Keep in mind that the Nationals are during the second weekend of spring Spring Break (meaning that we will leave the wednesday of break).

We'd love for the whole team to go to the out-of-town competitions, but unfortunately that is not financially or organizationally feasible. Team members will qualify to attend the out-of-state tournaments by hard work and dedication to meeting the goals of the team and through their "gracious professionalism."

Thank You and GET EXCITED!

PLEASE send me an e-mail saying that you have read this, and let me know if you are able to make it to kickoff, a simple yes or no in the subject line will suffice :)
THANK YOU!!!

Team Lead
-Chrissy Crone
(Cell: 650-339-2028)

Technical Lead
-Julia Lee
(Cell: 408-482-5196)

Non-Technical Lead
-Hannah Sachs
(Cell: 650-248-8687)

What's happening folks?

2006-04-10T21:23:00.000-07:00

We need to pack all the stuff we need (including the tether cable this time...) into the large box that build has so kindly provided. Also, we need to do the possible revisions to autonomous. When are people (*cough Erin*) free to meet?

so. i will not add to the odd list of comments already

2006-03-19T20:40:00.000-08:00

some ideas to fix autonomous
-have robot shoot straight from the box, either point it at goal, or line it up exactly in the corner (not diagonally) then turn turret as needed and shoot.

-instead of going forward then turning turret, just drive forward pointing towards goal and do not turn turret. (similar to team 192s method).

I think both these methods would make lining the robot up easier. (just look the the wheels and see if you can see the goal) or line it up straigt in the corner (although we may have to loosen wires to allow it to turn enough).

or what i don't want to do. but if people are up to it (but hopefully not because it would suck)

apparently camera doesn't work because of wrong firmware and there was a firmware update posted on the website during the last week of build. so we could try it. but once again it would be a lot of work and hard to do without the robot.

there most likely will be a scaled practice field at nationals; however, there are quite a few teams so we may not get much time (but i think that it would only take a few minutes to figure out what speed and how much the robot needs to turn, so we can write code with variables.

(As pointed out by Shirin)

2006-03-19T14:10:00.000-08:00

As we now have another competition to compete in, we need to fix our autonomous code. Any ideas on exactly what we want to do? (Add pauses? Ditch the twitch?)When do people want to meet?

Erin is the master (of code)

2006-02-27T22:03:00.000-08:00

We went over ALL OF THE ROBOT CODE TONIGHT, and Erin got *so* much of it (including the interrupt stuff). Congradulations, Erin!

2006-02-26T10:41:00.000-08:00

We (most notably Shirin) figured out the glitch in our autonomous code! We had initialized the potentiometer value outside of the while (autonomous) loop. Silly us, but at least we are fairly confident that it will shoot now!

Monday Night

2006-02-14T08:35:00.000-08:00

We mounted the sensor to a prototyped version of the gating mechanism. We also finished up the code for it. Now all that is left is testing and more testing. (And getting build to mount the sensors we have programmed for.)

Interrupts Galore

2006-02-11T18:20:00.000-08:00

With many thanks to Doug and Eric, we finished writing the GTS code and are almost done with the code for the gating system. We had to dig into writing actual bits, but it has worked successfully :) Still to do on the above items:

-Figure out the mounting of the GTS. It needs to be REALLY close to the gears, but hopefully we can do it. 'Twould be a shame to do all that coding and then not be able to mount it properly.
-Find out how many teeth/revolution and the circumference of the wheel. Easily done, just one more thing on the list.
-Deal with turning using the GTS. This could be an issue...

-Finish writing the motor code for the gating system
-Decide on speed for gate motor that will be efficient yet not kill our touch sensor.
-Figure out mounting of gating system and of touch sensor to motor. This should be another task for build.

Followed by:
LOTS of testing and debugging! (and modifying controls to driver preferences)

Today

2006-02-10T12:02:00.000-08:00

I think the best plan for today is to work on the gating system. Let's recruit someone from build to help us mock something up and then see if we can get it opening and closing on the command of a joystick button.

Tomorrow, Doug will be back and he will help us on the GTS. We have hooked it up to the correct cables and figured out that if we mount it facing the main plane of the gear it will send out a signal. Saturday holds the wonder of interupt code...

naming

2006-02-09T16:28:00.001-08:00

the turret has officially been named
(*drumroll please*)

CHESTER

woot!

next up,
robot name
..and gear tooth sensors.... gack!

A Driving Robot!!!

2006-02-02T16:08:00.000-08:00

The robot now drives under joystick control! We debugged the algorythm we wrote last night and now we have more control at low speeds and a deadband that can be easily adjusted to the driver's preference.

2006-02-01T20:50:00.000-08:00

So, today was I think the most productive day we have had yet.

What we did:
Calibrated the speed controllers for the wheels to the joysticks and then hooked the speed controllers up to the transmission and ran it with default code. The right wheels then ran backward, but Sophia promptly fixed that problem.

Then we set out at writing a code which would make the driving less sensitive, so adding a sort of deadband.

umm, it is quite hard to explain how we did this online.

we kind of added our own function called DrivingDeadband as an inbetween step between taking in the pwm values form the joy stick and then converting them into pwm values for the wheels.

So the function basically takes the joystick values and makes them higher or lower based on a function we made up.

okay, i'm going to give up trying to explain it, because i can't draw the function.

however, it did build successfully, however it didn't work quite as expected (but it did work somewhat). it is probably something wrong with our algebra. we will work more on it tomorrow, but it seems promising.

STUFF TO DO TOMORROW

-mount the speed controllers so that they are not shorted (our plan, use nylon washers or nuts)

-fix deadband code

- debug/write turret code.

So stuff is finally moving along at a better pace.

Speed Controllers WORKING!

2006-02-01T08:41:00.000-08:00

All of them! Thank heavens for George and Sanjay and a combined six degrees in electrical engineering to solve this silly problem.

http://www.ifirobotics.com/docs/ifi-v884-users-manual-1-26-05.pdf

Sanjay, Shirin's father, found a little note in the data sheet that the speed controllers need to be calibrated. Also, one of the cables was questionable.

Things are better. Now we can sort of move forward with the project.

Em

Starting to see the light?

2006-01-31T00:07:00.000-08:00

Y'all, good job today. Shirin, Chris and I worked on getting the turret to move a little less violently and prevent constant smackdown of the limit switches. With a very low value of pwm02 = 123 for CCW motion and a higher value of pwm02 = 142, we worked out the bias from the van door motor. Sort of . . .

For tomorrow: There's a zip file on the IDEO FTP site named 2006_EM_013006.zip. Download it if you're interested in seeing where we are.

So here's the deal. Rather than wading through the 'bells and whistles' version of the vision camera code, I've made an attempt to take the default code that we're familiar with and integrate it with the streamlined camera code. What does that mean?

1. You need to put in the default calibrated values into camera.h. You have those values now right?

2. I essentially took the 2006_EM_011506.mcp project and added the following files from the frc_camera_s.zip: camera.c, camera.h, terminal.c, terminal.h, serial_ports.c, serial_ports.h, and finally tracking.c and tracking.h which I actually don't use but are necessary for terminal.c to run.

3. You realize that you can learn and do a lot by just looking at TERMINAL.C. Please open it up and look at what it does. It's the function that prints the current state of a slew of camera values to the screeen every few seconds.

Okay, so what do you see printed to the screen?

- pan angle
- tilt angle
- pan error
- tilt error
- blob size
- confidence

What do all these things mean? Check page 34 and 35 of the CMUCam2 Workbook, and since all of you programming fans have read the ENTIRE manual already, this will be a good refresher .

So think about your basic strategy here. You just want to continue with your turret panning until all the following conditions are met (for example):

- your pan error is below a certain allowable value
- your tilt error is below a certain allowable value
- your blob size is above a certain desired value
- your confidence is above a certain desired value

Pan pan pan, search search search, and when all the above conditions are met. STOP EVERYTHING. STOP ALL YOUR MOTORS and shoot the darn ball!!

I hope 'nested if statement' is at the tip of your tongue!!! Is it?? Is it??!

The code I've included compiles, but since we don't yet have any hardware to plug it into, I do not vouch for its ability to actually do anything productive and I am not guilty if it results in personal harm or property damage.

Most interesting to look at user_routines_fast.c to start with.

Good luck,

Em

Monday Madness!

2006-01-29T22:41:00.000-08:00

Yo dudettes! I suspect that Doug and myself won't get to Castilleja until 6:30 pm or so but here are a few things to get started with:

1. Check out the code in the 'EMILY' folder on the desktop computer. It's the basic autonomous driving code that we wrote for the 2005 robot controller, rebuilt for the 2006 robot controller. That's what we've got downloaded to the robot controller right now so you can jump it in and out of autonomous and see what it does.

A few things to notice:

* Open up 'driving.c'. You'll find a few extra functions in it that are named 'TurretCW', 'TurretCCW' and 'TurretStop'. Do those make sense?

* Open up 'user_routines_fast.c' and under the User_Autonomous function, you'll find that I've added some test code for the turret motor. We haven't actually hooked up the turret motor (van door motor) underneath the camera platform yet so we should try.

BIG CAUTION BIG BIG BIG CAUTION: PLEASE *REMOVE* the LIMIT SWITCHES FROM THE PLATFORM before you try to run ANY CODE on the turret platform. If in doubt, call me. The van door motor has some SERIOUS torque and if the code is wrong (i.e. I'm not sure of the directions completely yet), it can result in the van door motor totally running the limit switches over, smushing them.

So, just pull the limit switches out of the holes in the platform for now, but don't unplug them from the robot controller. You can still used them.

* Hook up the speed controller (Victor 884) for the van door motor. You'll need some leads for power (black for ground, red for power - ask Julia who's been doing a fantastic job on the electronics board). You'll also need a PWM cable from the RC. Finally, you'll need to also make sure that the fan on top of the speed controller (Victor 884) gets power. Look at the other speed controllers for reference.

PLEASE DON'T BLOW THE SPEED CONTROLLERS UP. ALWAYS MAKE SURE THE FANS ARE ON. EACH VICTOR 884 COSTS $115.00. That means the electronics alone on our robot is worth well over $1000.00.

Yeah?? Okay, Doug and I will be there soon.

2. Debug the speed controllers on the electronics board. I suspect that might need more of Doug's help, but no worries.

Good luck and see you tomorrow!

Emily

name the robot competition

2006-01-28T16:06:00.000-08:00

just kidding
no competition
but we would love all input for possible robot names
no name is too ridiculous at this point
so get creative
get loving (for the yet-unnamed robot)
and get naming

go!

Making sure we have atleast a functional basic robot

2006-01-27T00:48:00.000-08:00

Dearest Electronics Team,

Here are some important next steps:

1. VISION SYSTEM: PLEASE SAVE AND PRINT OUT ALL YOUR CALIBRATED VALUES. This is WORTH GOLD right now and all we have. Shirin or Sophia, I implore you to print out the values for RGB and error values etc. that allow your camera to work. Please do whatever you need - i.e. nail it to the ceiling if you have to. I don't want you to lose these values in the many versions of saved code you have on the desktop (ack, do we need to learn and use CVS in the future).

2. DEFAULT CODE: Let's make sure that we have atleast a moving robot. That would suck if we spent ALL our time trying ot get the camera code to work and didn't have a running robot (and if you look closely at the code, you'll see that in user_routines.c, that all the code that allows your robot to work has been commented out, which means you can't currently run the camera at the same time as your regular default code; gross). Let's make sure the deafult code compiles and that we can actually run our chassis on it - electronics board and chassis nearing completion, unfortunately a lot later than we had hoped :( :(

3. HELP FINISH UP THE ELECTRONICS SETUP: Bud is building a layout board for you. Jen now knows how to solder and Chrissy knows how to crimp lugs onto different sizes of wire. We should get this whole gig set up real soon and have all the wires connected except to the output actuators and sensors. I'm relying on you to get this done!! Jen also knows how to use heat shrink so let's try to use that rather than lots of electrical tape all over the place!! Oh right, you know what, Erin knows how to too because she did that in 8th grade tech challenge!!

We'll come back to the vision system when we have atleast a basic robot that works during the non-autonomous periods of the game. At this point, I *AM* concerned that if we focus all our time on vision tracking duirng the autonomous mode, we'll end up with a robot that sits there THE ENTIRE GAME. Should we not aim to atleast have a robot running during the non-autonomous part of the game??

That's just my opinion for all it's worth.

Thanks for listening to and surviving yet another Emily blogpost.

Update

2006-01-26T23:01:00.000-08:00

So, programming met today. Aditi decided to join and help out. It was helpful. Worked on getting the camera working again. Everytime we try something else goes wrong. Perhaps it is because the pwm power cable is quite loose. Maybe we can fix that with superglue or something.

so, we tried editing code to make it respond to switches. That way we can set limits to how much the turret will turn. Aditi and I tried a few things, some worked some didn't. Em suggested we might start writing our own turret code. So I started that. It didn't quite compile and I didn't have time to figure out what was wrong because it was like 8:30. So once we figure out what is wrong, then we can make it more complicated/detailed and incorporate camera code into it. perhaps writing our own search code might be better, as it would not rely on the servo position values, just the inputs on the switches would determine the limits. might be extremely complicated though (i.e. how would step size translate (perhaps we could use a timer, and run the pwm at a certain value for a certain amount of time).

Perhaps we should try and write out a detailed flow chart thing. and then it might be easier to translate into code, and we can make sure we cover all bases.

Okay, the code I was working with is a new copy of the bells and whistles code. I changed the image values to be the ones we configured for the target and I added a file called turret.c . The project is saved in a folder called turret in the FRC2006 folder.

I may not be able to make it Friday (Dentist appointment eeek). I might stop by though.

-Shirin

hello? missing!

2006-01-26T17:26:00.000-08:00

So today we are missing one-third of our subteam, i.e. Erin, due to a fractured ankle. OWCH! Ay, pobrecita!

We wish her a happy, speedy recovery.
Erin, we are thinking of you and miss your chatter and happiness.

Come back soon!

things to do next meeting....

2006-01-25T19:33:00.000-08:00

* somehow mount the camera onto the van-door motor...
* ...see if tracking still works (if not, change code as necessary)

...and things to do later in the near-ish future
* program camera to move back-and-forth as part of the search algorithm (so robot can drive back-and-forth to find target, as the camera commands it to)
* make driving less sensitive
* program manual control of 'shooter'
* calculate what to do in passsive autonomous (where, how to move)

(Shirin is dancing with the camera as I type... very interesting... haha)

So apparently, today = happiness!

camera improvements

2006-01-25T19:25:00.000-08:00

Remember how the camera was having problems with the search algorithm?
...Turns out we had commented something out that we shouldn't have,
and today we re-put it in, and VOILA! it worked! It steps, like Emily said it should!
And now, it tracks remarkably well, HOWEVER,
the servo is kinda of broken as Someman Who Need Not Be Named (cough) dropped the camera, and that certain servo comes apart at inconvenient times... however we realize we will not be using that certain servo because we will be using motors instead.

Whatever. It works!
This is a moment of which Shirin is very very proud, and insisted I record for all eternity. YAY!

2006-01-24T22:18:00.000-08:00

Today we managed to get the camera working. We discovered that if you don't flip the camera switch, but just turn the power off, you don't have to re-load settings. Also, we got a motor to run instead of a servo. Our next goal is to make some sort of sketchy rig to mount the camera to the motor and see if we can get it to succesfully track with that. We plan to use switches (binary touch sensors) at either end of the span to tell the turret when to turn around.

what was done friday

2006-01-21T17:06:00.000-08:00

I know its kind of late to post this.

But, the camera code is saved in a folder in the FRC 2006 folder its called bellsandwhistlescamera or something of the sort (not one of the ones that says clean or cameracodeedited)

what Erin and I did Friday after Sophia left
-looked through tracking.c and tool out all the parts with tilt (including the parts in the search algorithm)

and discovered that in order to make it work for the turret motor we should only have to change default values in tracking.h (i.e. step size and max and min pwm values)

however, we couldn't check if it worked because the servos were causing problems again.

One Meeeeellion Dollars! Muahahahaha.

2006-01-19T23:22:00.000-08:00

Nice work Sophia and Shirin. Camera is no simple task (it's the little dude to the right of the picture for you visitors to the site).

Next up . . . a suggestion. Dig into tracking.h I believe to figure out what you can do to just take out the changing of the tilt angle and just have it scan back and forth by panning. I haven't looked in deep but it looks like it's probably a nested FOR statement somewhere that makes it scan on one tilt angle, change tilt, scan on another tilt angle, change tilt etc.

See you tomorrow for a little bit!

m-uhahahahah

Mwahahahaha I am posting everywhere

2006-01-19T22:34:00.000-08:00

SO...Today and yesterday have been eventful days for programming (well eventful compared to other days)

First, we were having trouble getting lab view to recognize the difference between the green and white lights. However, after much trial and error we found a solution.

However, then we were having problems with the servos. Except that was just because the power was low, so we fixed that and the servos worked.

Then we made some changes to the camera code and hooked it up, and got it to track the light kind of. There were some minor technical difficulties (the camera is mounted upside down) However, tomorrow we will fix that quickely, and start working on modifying the code to work with rotating the turret instead of using servos.

Now things should be able to move at a slightly faster pace.

Potentiometer Fun!!!

2006-01-17T16:44:00.000-08:00

We successfully hooked up a potentiometer (with help from the manual that Emily gave us) and coded so that we could see the value on the screen in a printf statement. Then, we used the value to control wheel speed and made the robot move forward or backward at various speeds based on how we turned the potentiometer.
Analog sensors will actually work! YAY!!!!!!!!!!!!!!!!!!!!
Teehee
-Sophia

Extra Extra! Read all about it! The GTS.

2006-01-16T22:55:00.000-08:00

Not the celica GTS, but the gear tooth sensor. (Haha, I guess that's only funny to my bf since he owns the most clunker or clunker toyota celicas).

GREEAT sensor for tracking our yaw if we built a turret. Think tank like. Remember this post about the tank and turret?

Click here for '2006 Sensor Basic Operation' for more information about the GTS: Document on Sensors

Click here for the GTS data sheet (if you scroll to page 12, you'll realize that the GTS is about the size of a piece of snot and is mounted to the sensor strip already for you):
Allegro Microsystems Gear-Tooth Sensor

Remember that the US FIRST website is your oracle! You can pretty much find everything you ever want to know about any of these parts on that website, if you look hard enough!!

Good luck!

Emily

Monday's Happenings

2006-01-16T17:46:00.000-08:00

The first thing we did today was to compile the 2006 default code so that we could run it on the 2005 RC. Thanks to Emily for her copius instructions! We also looked through interupts.c and the autonomous code that was already in user_routines_fast.c so we (Shirin and Sophia) fully understand the lovely timer mechinism. We did a little poking around to look at sensors that we could potentially use for distance. It appears that they gave you hook-ups for a gear-tooth sensor (gts) but not the actual sensor. We looked at the sensor that sees if light can get through (the name eludes me at the moment), but were a tad perplexed and had trouble finding any detailed documentation. Also, we bought a potentiometer (two, actually) so that we could play around with analog sensors. Neither Shirin nor I had brought our programming booklet, so our attempt to hook it up / program it properly was not successful. It did, however, change the value from what we initialized it as. It just would not continually returned 255. We hope to have it up and running tomorrow with help from our handy guide created by Emily.

2006 RC vs. 2005 RC

2006-01-15T17:41:00.000-08:00

As I blogged previously, the 2006 RC is not the same as the 2005 RC. The 2006 RC contains the PIC 18F8722 and the 2005 RC contains the PIC 18F8520.

No matter. I am pretty sure you can still compile 2006 default code for the 2005 RC and test it.

Here's what you would need to do - To compile this project to work with your 2005 FRC (18F8520) system do the following:

1. Select the correct device from the MPLAB IDE. Configure->Select Device->PIC18F8520

2. Replace the library file with the appropriate one. Remove the FRC_Library.lib file and replace it with FRC_Library_8520.lib OR Remove the FRC_alltimers.lib file and replace it with FRC_alltimers_8520.lib

3. Remove the 18f8722.lkr file and replace it with the 18f8520.lkr file

4. Rebuild your project and download the HEX file to your controller.

I pulled these instructions from the 2006 Default Code 'Other Files'. Under your project workspace (see the picture I posted below), the last line is a file called 'Using_Last_Years_FRC.txt. Open that and you'll find the same instructions.

Emily's Sample Code: long due explanation

2006-01-15T17:36:00.000-08:00

I apologize that I haven’t had the chance to explain to all of you together what I did with the code in December to make it drive in a simple pattern in autonomous. I walked Sophia through the code that you should find in your email now; it’s a zipped file called ‘EM_011506_2006AUTO.zip’. First things first – copy this file onto the computer NOT ON THE DESKTOP, but in the C:\FRC2006.

When you open up the .mcp project file, you should see something like this on the left of your screen that shows you all the .h and .c files in your project. Try to compile it (CTRL+F10) – it should succeed.

Sorry it’s taken me so long. I had to take the autonomous code that I wrote for the 2005 RC and re-integrate it into the 2006 default code and that took me a little bit of time. If you’re not already aware of it, the 2005 RC uses the PIC18F8520 microprocessor and the 2006 RC uses the PIC18F8722. That’s why things aren’t going to be as straight forward as I hoped.

Here’s the gist of what’s going on with the autonomous / timer etc.

1. Open up interrupts.c. Look at how there are two functions that look awfully familiar: InterruptVectorLow and InterruptHandlerLow. Yes, I swiped and deleted them from user_routines_fast.c and put them in interrupts.c to keep all the interrupts stuff in one place.

2. I set up a GLOBAL second timer in interrupt.c according to the instructions in this white paper: http://www.ifirobotics.com/white-papers.shtml. This GLOBAL TIMER starts counting in seconds the MOMENT you start the robot. This is the BIG CLOCK I always look at when I’m trying to write code for time intervals within the existence of the robot being powered on.

3. Open up user_routines_fast.c and look at the function ‘User_Autonomous_Code’. That’s where I have a clock within a clock. Remember that in the background I have this GLOBAL CLOCK running in interrupts.c. So now, for autonomous, I have a mini clock that starts when I trick the robot into autonomous mode (with the plug that goes onto the operator interface). I mark when I jump into autonomous with a variable called ‘clockstart’. Do you see it? Then whenever I check the global clock, I store that value into ‘clock’. So now I can figure out how long I’ve been in autonomous mode for – with the variable deltaclock = clock – clockstart.

Does that make sense?

Here’s an example of how things could pan out:

I turn my robot on and the global clock starts running.

5 seconds into it, I trick the robot into autonomous. At this point: Clockstart = 5.

I check my clock every time I go into the loop, updating the variable ‘clock’ as necessary. Two seconds later, my variable clock = 7. Thus, at this point in time, deltaclock = clock – clockstart = 7 – 5 = 2 seconds, which is how long I’ve been in autonomous mode. Now I can do things like tell the robot to move forward for 2 seconds in autonomous mode and then move backwards for 2 seconds after that.

Hope this is good food for thought!

- Emily

Monday

2006-01-14T22:14:00.000-08:00

On Monday, programming is going to meet from 10-12 in the project room. Shirin and I (Sophia) are definitely coming; Christina, I really hope you can join us!

Saturday turns sunny

2006-01-14T17:38:00.000-08:00

Hello. We brought in some heavy duty equiment today - Doug B (Tesla Motors) and welcome newcomer Eric Mac (Mindtribe). Doug continues to bring wonderful presents to support the hardware / software effort, aside from people like Eric Mac. Now we have a box full of tools just for the electronics team: crimpers, cutters, wire strippers, digital multimeters and such. Also, Doug pretty much bought one of every power strip product so there should be no excuses that you can't find an outlet to plug into now! Thanks to J Rock as well for loaning us the oscilloscope!

Eric and Doug made some serious headway on the camera - getting LabView 8.0 setup on the desktop computer. If we open up Labview, connect the camera to the computer, we can do a frame grab, pick a target, download that information to the camera, and then have it pick up that target. No working servos yet, but the camera can pick up and follow a target in its stationery field of view. Fantastic.

The oscilloscope also started giving us some well needed information about the PWM outputs coming out of the RC. Eeesh. We're only getting about a change of 25% in the PWM signal vs. the 3-100% duty cycle that the speed controller is supposed to be able to take. We thought it was the joysticks (nope) and now we think it might be the fact that GeneratePWMs only gets updated every 26.2 ms. We'd like to dig into the GeneratePWM function and see what it's all about since it's not giving us the expected output.

Em spent some time with Sophia explaining the timed autonomous code that was written in December. I will post this code on my FTP site for you guys to access and download and play with. Now Sophia understands what my autonomous code is doing, she should be able to explain to you what is happening. Again, ALL the computers (3 laptops, 1 desktop) should now have the newest version of MPLAB, C18 compiler, and the FRC2006 code, that successfully compiles!

Things to do next:

1. Programming team: Hook up an analog input i.e. potentiometer and try to read out the values (hint, using the printf to the terminal that we've always used). If you are going to Fry's also pick up the connector that goes with the 7.2 battery so we can set up the 2006 RC. Finally, can you hook up the 12V battery with the quick connects??

2. Em will post the autonomous code in a few days (probably by Monday night).

3. Look at and get the camera code running.

4. Set up the 2006 RC with some minimal inputs. Can we quickly mock up a surface to mount everything to for now? Velcro will do for now.

Cool. Thanks much!

- Emily

MPLAB, Default Code Setup!

2006-01-14T09:18:00.000-08:00

Dearest programming team,

So here's the deal - does anyone remember way back when two months ago when I warned you that your 'location name' of your project file can't be more than 64 characters long? That was definitely the first culprit!! You really need to stick your project code here in the C:\ drive (or local drive) and NOT ON THE DESKTOP (that's where the location name becomes like a biggilion miles long).

So here's what we have now:

1. All four computers (including the desktop) are loaded with MPLAB, C18 compiler, and the IFI Loader for 2006 (yes, the 2005 IFI loader will not work).

2. All four computers have a copy of the 2006 default code in C:\FRC2006. I've successfully built and compiled the code on all four computers. DO NOT MESS WITH THIS COPY OF THE CODE. NO COPYING FILES OUT OF IT!! There's a 'shortcut icon' on the desktop to that location so you don't have to wade through 'My computer --> C:\ --> FRC2006' to get to it every single time.

3. Doug was working hard last night to install LabView 8 on the Desktop Computer. We're hoping to get the camera hooked up today and start looking at calibrating it for 'bench testing'. Getting it up and running might take a little while longer!

We're doing okay guys!

- Emily

Friday: What you can do when Em is fixing computers

2006-01-12T22:45:00.000-08:00

Yo. I'm sorry we couldn't solve the compiler problem today. Shirin and I discovered that the PIC processor in this years RC might be different from last year's (remember they said they added a s*load of memory?). Very scary. That is a serious problem I think. We'll see what we can do.

Okay, so here's what you can do while you're waiting. Please use your time wisely.

Look at the 2006 FIRST guidelines, tips & good practices. Yes, I printed out two copies of the booklet for you if you can't find it here.

I would like someone to put together an excel file that puts all the stall torque values IN THE SAME units so we can compare all the motors at face value. Also, I want the speed at no load converted from RPM to RPS (rotations per second) to degrees per second (Sophia, that's theta dot to you). Why????

We need to try to shoot the ball out from the spinning wheels at a certain speed. What is that speed? Can someone tell me the speed at which the spinning wheel (of radius r) connects to the ball? The fact that you have to find theta_dot is a really really good clue.

I can tell you that I've done all of this already, but of course, I can't just give it to you now just like that huh?

There's a lot of motor and sensor characterization we can do while we try to get the compiler up and running again. Please make use of your time.

Signing out since I need to write a personal statement tonight,

Em

Last post: No big-ass servos

2006-01-09T23:59:00.000-08:00

To Sophia, who asked about using a big-ass servo essentially rotating the ENTIRE shooting system with the camera . . . No.

Remember that we can ONLY use the motors that are provided in our kits, and we don't have a big-ass servo included in the KoP. The only servos we have are the mosquito sized Hi-Tec ones that you so hate.

However, I can tell you that in this case, we can drive a turret like platform with a DC motor but use the gear tooth sensor, a very large potentiometer, some sort of homemade rheostat (do you know what that is?), or some other means to sense our rotational position, in combination with a simple switch to provide it with a physical starting position that it can initialize to.

Capiche? Let's ask Doug.

- Emily

Strategy, Autonomous and Coding

2006-01-09T23:40:00.000-08:00

I just wanted to make sure that this all gets documented somewhere. The flowcharts that Ed walked you through were awesome . . .

Remember that autonomous doesn’t mean that it’s ALL autonomous. Remember that you’re not just DUMPING your robot onto an unexplored uncharted terrain like Mars or something. Your FIELD has specific dimensions, and your INITIAL position can only be one of three choices. You as a HUMAN BEING will know a lot about your robot that you can tell it in advance with simple digital I/O switches and not have to build sensor systems for (i.e. you’ll know how many balls you have in your robot at the start, so why bother having it sense that information when you can input it directly as a binary value?). Hence the hard coded switches that will drive your if/then/else statements.

Also, you know a lot of about your enviroment and the game pieces. What does that mean? If you can get your robot into a certain, let’s say 4’ X 4’ area on the field by just plan feedforward (i.e. no sensor information), then you can use your auto-targeting system to do the FINE CALIBRATION work for aiming. On a fully charged 12V battery (a voltage supply that is hopefully regulated – I’m checking), you should be able to tell your robot to drive forward for 3 seconds, turn left, and drive forward for another 3 seconds for example to get to your ‘target area’. We’ll have to experiment with the turning.

Remember, your human drivers can do the COARSE POSITIONING, so use your complex sensors (i.e. vision) ONLY FOR FINE CALIBRATION. Figure out what the bounds of COARSE POSITIONING are BEFORE you start trying to get your feedback system to do EVERYTHING for you. The truth is, trained humans are far better than feedback systems (see Wired Article on a well practiced high school team that beat an MIT student team that had a bad-ass system but little practice): http://www.wired.com/wired/archive/13.04/robot.html

Use your surroundings to guide you as much as possible in SIMPLE WAYS. My graduate school research work was all about sensors and feedback systems that were computationally simple and cheap, and THUS much more robust right off the bat. You can do a LOT with touch sensors for example. Sophia had a GREAT suggestion about getting the robot to drive up to the RAMP and sense it with simple touch sensor and then aiming from there. That’s a GREAT idea.

Please analyze your PLAYING FIELD: Please don’t tell me you don’t know anything, because you do, with a little bit of work.

1. How high up is the center of the hoop?

2. What angle is the hoop set up at?

3. If you are 10’ away in front of the hoop and you can shoot the ball out at 10 ft/s, what is the angle range that you can shoot at and still get the ball in, provided that you haven’t reached the peak of your trajectory.

4. Answer question 3 if you are 9’ feet away.

An excel spread sheet would be a GREAT idea (since we don’t know what our initial velocity will be). Or as Shirin pointed out, you can probably even write code to do this. (Oh man, you are totally making me want to bust out Matlab . . .)

This is a great analysis problem ;) See you tomorrow! Yah, I might just skip the talk at Stanford on ‘Engineering Education’ since this is way too much fun.

- Emily

Strategy Discussion (on Build Blog)

2006-01-09T23:15:00.000-08:00

Shirin, Erin and Christina, for notes from today's discussion related to strategy, please go to the build blog or click on this link:

http://gatorbotics-build.blogspot.com/2006/01/ems-monday-night-build-strategy.html

- Emily

CMU Camera Workbook Link

2006-01-09T22:13:00.000-08:00

Please read this during the weekend. I am going to aim to look at it by January 16.
http://www2.usfirst.org/2006comp/other/2006_CMUCam2_Workbook.pdf

If we are going to try to build an auto-targeting shooter, we really need to familiarize ourselves with this camera . . . like now.

- Emily

Holy Smokes!

2006-01-07T23:19:00.000-08:00

Someone's been working on a lot of good code already: http://www.kevin.org/frc/
You know the demo code I put together for you guys a while back on autonomous stuff and interrupts? Looks like they'll probably put something together in the next few days on this too!

Also check out this site for a basic description of this year's software: http://www.usfirst.org/robotics/2006/2006frcsoftwareoverview.htm

Check out the links on the side!

2006-01-07T22:30:00.000-08:00

A few important things:

There's a blog specific to you here at http://gatorbotics-code.blogspot.com.

There's a blog for the mechanical and structural build at http://gatorbotics-build.blogspot.com.

And there's my friends of gatorbotics blog here: http://gatorbotics-friends.blogspot.com.

As well, I've posted some generic links to places like US FIRST and your own website for the time being. Let me know if there's anything else I can link to for you.

Welcome 11010100100

2006-01-07T22:27:00.000-08:00

Hello Gatorbotics electronics and programming. We definitely picked up momentum at the end of last quarter. Let's keep it up!