On Board Computer

[Brian Selle]

Originally Posted by Tom Bottiglieri

Yes, for a few reasons.

First off, we didn't want to block the control code. While most control loops ran in their own threads, there were still some things that were 'close' to time dependent in the main thread. Also, doing this made it easier to debug as we could stop the robot at any point and look at what it thought about the target. This allowed us to use the vision system to align the robot for autonomous mode without any additional glue code. The cost of running it all the time vs. one shot at a time is pretty minimal, and this is just the way we chose to implement it.

Thanks for info. We are using the Java command based framework and it seemed more natural to do the single frame analysis when required but I like the idea of not blocking and keeping everything running at a steady pace. We had one connection issue on our first practice match of the season that I'm pretty sure was because the cRIO spiked at 100% CPU during an image processing step. We cleaned up the code and made it more efficient and never had that issue again but it was always in the back of my mind.