Vision Target Detections makes cRIO code slow

[idoshamir]

Hello,

We are a rookie team trying to implement the target detection of the goals.
We want to use it both on the auto part and the teleop part.

We took the code from the example and implemented it (pretty much copy-paste) to the vision VI.

We are happy with the results - but the cRIO is immediately getting to 100% cpu and the robot responds very bad on the teleop part.
We couldn't fix the problem ourselves so we made the image processing part on only when triggered - but we would like to know are we doing something wrong and can we do better?

We are using a 320x240 resolution and got to 20% compression (tested 10% and it didn't matter). FPS doesn't seem to matter much too. We also added a 100ms delay to the image processing loop - not much change.

Thanks for any advise!

[Invictus3593]

The cRio is not a very powerful processor, so running all your robot code AND all this Vision at the same time is a big tax on CPU.

I reccomend putting all your vision code in the Dashboard and just sending back whatever values you need for Auto and Teleop. Read the dashboard values in Periodic Tasks and write the values to Globals, this way it's almost the same as having your Vision in the project vi, but without all the CPU usage!

[billbo911]

It is possible to use the cRio for image processing successfully, but it takes a bit of adjusting.

1) Minimize the resolution to only what is necessary for good target detection.
320X240 seems to work well.
2) Use compression to reduce image size, but not too much as to over reduce image quality.
30%-50% has worked well
3) Choose the lowest possible frame rate that allows good robot response.
15 FPS for the camera and limiting the vision processing loop to once every 100ms has worked well and is a good starting point.

As mentioned earlier, the cRio isn't the most powerful vision processor, but it is sufficient if you are willing to make a few compromises.

If compromise isn't an option, vision processing on your DS is your quickest solution because you already have the hardware and code to set it up.

The alternatives to DS processing is an on-board co-processor like the BeagleBone, O-Droid, PCDuino and RPi.

[idoshamir]

Hello! Thank you very much - we actually thought of using the Dashboard code just a little before your replies and started working on it!

We managed quite alright but we have a few problems/questions:
a. The distance computed in the Dashboard code is different than the distance in the robot code - although the code is the same! We think it is has something to do with the Get Image / Dashboard Image VIs but we do know how to change and compare between them.
It is very strange. Can you think of why this happens?

b. We are using DS Write and DS Read to communicate between the DS and the cRIO - is this the way to do this and will work the the ports blocked during the game etc?

Thank you for your help.

[Alan Anderson]

The distance calculation assumes a specific field of view of the camera. If you connect a different model camera than the software is expecting, the numbers could be different.

Running the vision processing only when necessary is a good idea.

Smart Dashboard communication uses a TCP port that is open on the competition network.

[idoshamir]

The camera type was the problem! So easy and it works!
Thank you very much.