Quote:
Originally Posted by SuperNerd256
Or if your team used vision to track the targets on top of the goals for targeted shots in 2010, it would be a lot easier to have your robot use its sensors to align itself, and use the distance away from the target to change the kicking power to ensure that every time you press the fire button, you get a for sure shot in the goal.
|
We looked at vision in 2009, 2010, and 2011. All three times, we looked far enough to decide we didn't like it:
-In 2009, we had so many issues with CPU load of using the camera that we just gave up because we had other problems to solve. By the end of the season, our Hotbot design didn't even have a turret or camera, and the problem became irrelevant.
-In 2010, we were still having lag issues, and it was hard to get a fast enough PID loop as the sensor was so slow. We supplemented it with a gyro, but eventually gave up because the driver was so much faster at alignment. And our operator got good enough (With a linearization algorithm for the kicker power) to set the kick distance correctly.
-In 2011, we gave up on the Axis cam almost immediately, once again due to lag, but attempted some tracking with the CMUcam from the 2005 KOP (the same one in the 2006 and 2007 KOP's). We got it at a decent framerate (I think we got something like 15 fps),
but it was still slower than a driver so we saved the weight and complexity of making it work and just practiced more.
That said, we do all kinds of automation on the elevator system, handling state-transition and control loops to offload driver work. That kind of automation is great, as it can do something a driver can already do faster, but fixing something that is impossible to drive or doing vision tasks because they show you how in the default code isn't usually a good thing.