![]() |
Camera Tracking Delay
Hello, My team has finally gotten camera targeting to work in c++. The only issue is there is about a 3-5 sec wait between when the function is called and when it actually begins to auto correct to the target. My code is full of "printf" commands and I was wondering if this could cause the delay by using up more resources or is 3-5 sec the best speeds we are going to get. I dont have the code on me to post sry.
|
Re: Camera Tracking Delay
Quote:
|
Re: Camera Tracking Delay
Quote:
1. Make sure your camera resolution is 320x240. If you had it 640x480, it will take a long time to process the image. At first, we thought we had it set at 320x240 because we have the line m_camera.WriteResolution(AxisCamera::kResolution_3 20x240). But for some reason, we had to go to the web interface of the camera to force it to 320x240 before the performance started to improve. 2. Make sure you filter the image correctly. For example, if your light source is red, make sure your color thresholds are towards red. If not, you may end up with lots of false positive targets that require a long time to process. In order to diagnose performance issues, it may be helpful to add timing code to check who takes a long time. For example, this is an excerpt of our image processing code based on the sample: Code:
#define SAFE_DELETE(p) if ((p) != NULL) \ |
Re: Camera Tracking Delay
Cutting the resolution to 320x240 should cut the processing time by at least 75%.
Printfs generally aren't so much a bottleneck, as the output is buffered. What'll cause a much bigger slowdown are memory allocations. Make sure you're not copying around gigantic vectors of particle reports (use a const reference/pointer) or a bunch of separate copies of the image. A FLOP (Floating Point Operation) is also pretty slow on the cRIO, which makes triginometric or exponential calculations pretty slow. So if you find yourself calling std::sin or std::pow a lot, you might see a slowdown. Most of the speedup you can get though is by decreasing the resolution and making sure your thresholds don't generate a lot of false positives though. If you want to get rid of the printfs though, one of the best things to do is to make a macro: Code:
//in "someglobalincludefile.h"DEBUG>somefile.cpp@123: Error finding XYZ Might be a small error; don't have the compiler in front of me right now :( |
| All times are GMT -5. The time now is 17:39. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi