On Board Computer

[Tom Bottiglieri]

Originally Posted by btslaser

Just to make sure I understand this... on a separate low priority thread you were continuously grabbing the latest image, thresholding, filtering, calculating distance/angle/position then sleeping for a bit. Then whenever your shooter pressed the shoot button you would check to make sure a valid calculation was made within the last 100ms or so and then use the last calculated distance/angle/position to align the robot and spool up the shooter wheel?

If the image processing was only taking 100ms what was the advantage of running it continuously? Was the image quality degraded because the robot may have been still moving?

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.

[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.