On Board Computer

[Brian Selle]

Originally Posted by Tom Bottiglieri

Yup. We grabbed one frame, processed it in about 100ms, then fed the result into a control loop using the gyro. We were even able to pull out our lateral position on the field to shoot off center if we were on the side of the key, allowing us to have an accurate alliance bridge autonomous mode. We did this spending 0 dollars and 0 hours on an external computer.

That's exactly what we did except we fed turret position. The cRIO CPU would spike to around 80-90% for a moment during the image processing but since nothing else was happening during the shot sequence it was never an issue. Never saw the need for continuous image processing or offloading to an external CPU...

[Tom Bottiglieri]

Originally Posted by btslaser

That's exactly what we did except we fed turret position. The cRIO CPU would spike to around 80-90% for a moment during the image processing but since nothing else was happening during the shot sequence it was never an issue. Never saw the need for continuous image processing or offloading to an external CPU...

I'l like to elaborate on my last post a bit. We did run the vision code continuously, but the control loops only relied on one valid frame and the vision processing ran in a separate task with lower priority than the main robot code/communications task. The vision task slept enough to not cause particularly high CPU usage. When we were looking for a frame, we would use the last processed frame (if we got a good result within the last, say, 100ms) or wait for a fresh result to appear.

[Brian Selle]

Originally Posted by Tom Bottiglieri

I'l like to elaborate on my last post a bit. We did run the vision code continuously, but the control loops only relied on one valid frame and the vision processing ran in a separate task with lower priority than the main robot code/communications task. The vision task slept enough to not cause particularly high CPU usage. When we were looking for a frame, we would use the last processed frame (if we got a good result within the last, say, 100ms) or wait for a fresh result to appear.

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?

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

[Tom Line]

Originally Posted by Tom Bottiglieri

I'l like to elaborate on my last post a bit. We did run the vision code continuously, but the control loops only relied on one valid frame and the vision processing ran in a separate task with lower priority than the main robot code/communications task. The vision task slept enough to not cause particularly high CPU usage. When we were looking for a frame, we would use the last processed frame (if we got a good result within the last, say, 100ms) or wait for a fresh result to appear.

We did a bit of the opposite. Our vision acquisition and processing didn't run unless the 'fire' trigger was pulled. Then, once it gathered the first valid image and had a target, it saved those values to reference against our turrent pot and shut down the vision code.

We'd see a temporary spike to 90% during the one frame acquisition and processing, but usually our code hovered around 70-75% cpu.