forums.naturalpoint.com

Hello All,

I am currently tracking a single object at 100fps. This seems simple enough, however accuracy is very important. I notice there were frames dropped. Any help getting to the bottom of this is greatly appreciated.

Below is the segment of code where the problem occurs (if there is a problem)

void CameraEvents::HandleFrameAvailable(INPCamera * pCamera)
{

camera->GetFrame(0, &NewFrame); //get the most recent frame
NewFrame->get_TimeStamp(&TimeStamp);




if(grayScale==true)
{ camera->DrawFrame(NewFrame, (long)tempHandle); } //tempHandle


NewFrame->get_Count(&lCount);

for (int i = 0; i spObject;



NewFrame->Item(i, &spObject);


long lRank;

spObject->get_Rank(&lRank);
if (lRank == 1)
{
if(grayScale==false)
{






//*************************crosshair***************************************
//*************************************************************************

//convert the x, y, area coordinate to string easy to handle
spObject->get_X(&varX);


//---------------------------------
spObject->get_Y(&varY);

//----------------------------------
spObject->get_Area(&varArea);

//------------------------------------




}
}

spObject.Release();

}



//if camera is stopped
NewFrame->Free();
NewFrame=NULL;
frame->Free();
frame=NULL;




}


Thank You!

Looking at your code I don't see anything specific that sticks out that would cause any frames to be dropped.

One thing to be aware of though is the frame queue operates as a FIFO so the first thing you'll want to do is make sure multiple frames aren't accumulating there and potentially getting dropped if there is no space left. This is especially true if your application is taking time off from servicing the queue to do things like display a frame.

To ensure that you're keeping the queue of new data empty, call GetFrame() and process each frame until GetFrame() returns NULL. Then you'll know you've caught up.

We're trying to move everyone to our new Camera SDK, that is a complete rewrite & replacement of the original OptiTrack SDK. I would recommend you take a look at it because it removes COM completely in favor of a simple interface. There are sample applications as well. You're guaranteed to not drop frames with our new SDK.

Should OptiAl be using a loop with logic similar to below?
While
camera->GetFrame(0, &NewFrame)!=NULL
do stuff in the loop...
Wend

***

When should we expect real documentation on the new SDK? The .txt examples/documentation files are pretty skimpy on details. Also, why do you say "guaranteed" to not drop frames?

a loop with that logic is appropriate, just be careful that each time through your while loop you're getting a potential frame otherwise you'd end up trying to process the same frame over & over and it would lock up on you.

For the stuff you're trying to do I think you'll find that the Segment Mode sample on the new Camera SDK is basically going to get you there. The header files in the new Camera SDK are commented very well to help ease implementation.

for example, once you have a frame from frame=camera->GetFrame();

you can do:

if(frame && frame->ObjectCount()>0)
{
cObject *object = frame->Object(0);
float x = object->X();
float y = object->Y();
}

Oh, I said you don't have to worry about dropping frames with the new SDK because it has much better performance than the old SDK and you're going to find it does not exhibit frame dropping.

How large is the camera's FIFO buffer? When using the x.x.037 SDK, is a callback signalled each time a new value is available (at 100Hz), or is the callback timing not synchronous?

On the new SDK, do the properties of items such as "exposure" have the same range as in the SET_OPTION functions of the old SDK?

The Camera's FIFO is around 10 frames. At 100FPS that's around 100ms before the data is actually gone for good.

The callback is synchronized across internal threads in the OptiTrack SDK before triggering the application's callback. In the new SDK it takes a more direct route, which ensures lower latency.

The SetExposure range is the same in the new SDK. For cameras that were also available in the OptiTrack SDK. The is also MinimumExposureValue & MaximumExposureValue() helpers that report the range for the actual device connected--which is the same as the OptiTrack SDK range except for our newest devices.

Does this mean in the old SDK ver xxx.37, a group of 3-4 sequential FrameIDs can all have the same timestamp?