[CRUSH-build] Preparation for Las Vegas
Bill Bennett
bill at wizardofaz.net
Sun Mar 19 11:26:00 MST 2006
Hi Joann
Here are my thoughts about your ideas below:
1.. brake - I think a mechanical brake is more than we have time to do. If we had a wheel motion sensor, a software brake would be possible. But we don't. So I'm not sure what kind of brake we can some up with in the available time. I'm also not convinced a brake would help much. Brake or not, I doubt we can shoot with any accuracy while being pushed.
2.. Your ideas about an alarm are good. But maybe all we really need is code that (1) doesn't fire if the wheel isn't on, and (2) turns the wheel on if firing is attempted. The code could then use some delay for spin up before allowing firing. We'd have to decide how to turn it off in that case, since it would be on with the switch off. Maybe the simplest way would be that turning the switch on then off again would turn the wheel off.
3.. We can put the battery in under the shooter w/o removing the bumber, so I think this problem is solved.
4.. Good. Not so sure about random, but secret at least. The advantage of random is we don't need to create autonomous mode set choice code.
5.. good
6.. good
Bill
----- Original Message -----
From: Gary and Joann Hawes
To: build at crush1011.org
Sent: Saturday, March 18, 2006 8:10 PM
Subject: Re: [CRUSH-build] Preparation for Las Vegas
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
------------------------------------------------------------------------------
_______________________________________________
CRUSH-build mailing list
CRUSH-build at crush1011.org
http://crush1011.org/mailman/listinfo/crush-build
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wizardofaz.whsites.net/pipermail/crush-build/attachments/20060319/ff9813e1/attachment.htm
More information about the CRUSH-build
mailing list