Speed of axis camera

[nickmagus]

Has anyone else noticed that FindTwoColors() takes a really long time? I noticed the camera servo loop was running slowly so I tested the time FindTwoColors() takes and it is about .34 seconds. Thinking it might be a problem with my code, I ran their default code and FindTwoColors() still took .34 seconds. has anyone else encountered this problem?

[Greg McKaskle]

If the example doesn't set the resolution, your camera could be set to 640x480. At that resolution, the decoding of the jpg, and the shear number of pixels to process will limit processing to something like four fps.

Greg McKaskle

[gorillamonky]

Originally Posted by Greg McKaskle

If the example doesn't set the resolution, your camera could be set to 640x480. At that resolution, the decoding of the jpg, and the shear number of pixels to process will limit processing to something like four fps.

Greg McKaskle

agreed, your resolution can be bulcox and you will still find the colors, try setting your resolution to the lowest you can find.

you also don't need to find multiple colors, finding one is fine, however, you should find the two colors as one color if at all possible so you can differentiate between teams

ie, find the setting for red on top as one color, named rog
and the setting for green on top as one color, named gor

[EHaskins]

Originally Posted by Greg McKaskle

If the example doesn't set the resolution, your camera could be set to 640x480. At that resolution, the decoding of the jpg, and the shear number of pixels to process will limit processing to something like four fps.

Greg McKaskle

By default the TwoColorDemo code sets it to 320*240 @ 15fps. You can change the FPS setting on line 100 of TwoColorDemo.cpp, and you can change the resolution at line 131 of TwoColorDemo.cpp.

The resolution choices are k640x480, k320x240, k160x120.

I also had the same issue. I haven't had time to experiment with resolution yet, but I suspect that it will help.

[nickmagus]

I have already done some experimentation with the resolution. It significantly improves the speed of the loop (about 3.3 times faster which is about right since it has 1/4 as many pixels to look through) but the autonomous still only runs at 10 hz (not nearly fast enough). With some further experimentation i found that the frcColorThreshold() appears to be the slowest link. Threading is a possible solution but it seems that that would not help because threading cant increase the processor speed of the cRio. it might not speed up the camera but it would keep it from interfering with the rest of the code.

[Greg McKaskle]

Good summary about threading. Many people fall for the -- more threads results in faster execution trap. Having the camera run at 10Hz may be reasonable, but you don't want it to slow everything else down. Give the tasks or threads a shot. It certainly helped the LV stuff to be in an independent loop.

Greg McKaskle

[Uberbots]

try setting the res to 160 by 120, and do processing at 15fps.

You can also do a bit of code modifying to only threshold one color, which would significantly increase speed.

what i would think about doing is thresholding one color, then doing the particle analysis, and then doing a linear search through all the returned particles;

if the color patch is big enough, search for the color from the original image that you would expect to be below the color patch (red on green, or green/red) using a 3 point match or more if necessary.

im pretty sure that would at least double the speed.


since thresholding seems to be the slowest operation, perhaps modifying the thresholding algorithm to optimize it for the cRIO's processor might yield some benefit (though it probably already is... and that would be sad)