[CRUSH-build] Preparation for Las Vegas

[Gary and Joann Hawes]

We are allowed to TALK about software all we want, right?  I had several things I wanted to throw out to the build team even though some of it would probably be better addressed to the code team.  But we can accept or reject these ideas and prioritize the accepted ones so we know what to work on.  

Three of these ideas require some hardware changes so I'll throw those out first.

1.  I already mentioned the idea of brakes.  Korbin was the only one who seemed to like the idea.  I just wanted to point one that we now have the switch previously used for dumping to accomodate this if we decide to use it.  

2.  We talked about locking out the trigger if the shooter wheel isn't spinning.  I think we need more than that.  During one of the matches in Phoenix, Jason and I could clearly see that the wheel wasn't spinning, but Korbin thought he was scoring because our alliance partners just happened to shoot at the same time.  Also, the drivers might just think it was jammed balls.  I propose an alarm be sounded if the trigger is pulled and the shooter wheel is not up to speed.  This would require modifying our box with an alarm, a loud one to overcome the noise in there.  It might be worthwhile to put a motion sensor of some type on the shooter wheel.  If that is do-able.  That would be very helpful in autonomous mode also.

3.  I propose we lose the solid rear bumper.  Replace it with two bumpers that don't impede changing the battery.  If we must have a third one in front of the battery,  make it as quick to remove as possible.  We can't afford low batteries and we spend too much time in queue lines to effectively charge between matches.  We need to be able to change out the battery quickly.  Then the other one can be charging while we are in the queue.  

The rest of these have to do with the autonomous mode.  

4.  My big idea for autonomous mode is to actually create three of them.  A close, centered shot; a farther out centered shot; and an off-center shot.  Then we randomly pick one each match to run. We wouldn't even know what we were going to run, how could they.  It would make us MUCH harder to defend against as the matches got more strategic.  The first two would just be variants of each other.  Using different blob sizes would result in different distances.  The third one would be a bit trickier.  We would have to use camera angles the whole way in.  

5.  Assuming we get this working on FWIPER (above idea) , we will probably need to be able to re-calibrate to the blob sizes we are getting in Las Vegas.  To acommodate this, we could use the two aiming lights on the box for a different purpose during autonomous.  For example, blink both lights if we are searching; turn both lights off if we are tracking with a blob size < 5; right light on for blob size => 5 and < 10; left light on for blob size => 10 and < 15; and both lights on for blob size =>15.  We could also use them for finer calibration if needed or for monitoring other parameters in subsequent matches.

6.   I feel that the only reason autonomous didn't work in Phoenix, once Chris got it turning the right direction (which was also the problem in Auto Move and Shoot),  was the uneven drive caused by one motor being unplugged.  If we go back to Auto Move and Shoot, we could improve the code to overcome that sort of thing.  If we watched our Pan Error, we would see it start to rise alot just before we lost track.  We could turn accordingly to compensate for the uneven driving.  

I guess that is it.  I feel that the amount of code I'm suggesting is very do-able within our Fix-It Windows.  We just need that camera tray Bill ordered.  What do you all think?


Joann



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wizardofaz.whsites.net/pipermail/crush-build/attachments/20060318/60a6855f/attachment.htm