Streaming rigid-body data using SampleClient

[roberto]

Hi,
I am interested in using Tracking Tools in order to do remote control of vehicles.
I have downloaded latest version of TT and samples and decided to modify SampleClient.cpp in order to forward small text messages containing rigid body data (position, orientation, error plus a timestamp) over UDP network.
I noticed that I have approximately 15 ms of delay between each consecutive samples (the delay is measured by comparing the timestamps generated inside SampleClient), instead of the expected 10 ms which would correspond to the 100 Hz sample rate (TrackingTools shows negligible processing time always less than 1 ms and a frame rate around 100 FPS, probably thanks also to the powerful Core i7 processor on which it is running).
Moreover the MeanError received by SampleClient is always zero.

Thanks,
Roberto

[VincentG]

Are you running the client application on the same PC, as the TT software?

What version of TT are you using?

What version of Windows are you using?

[roberto]

Hi Vincent,
I'm using the latest version of TT 2.2 final. I am running both software in the same PC which is running Windows 7 64 bit in order to support 8 Gb of memory.
Thanks again!
Roberto

[beckdo]

Hi Roberto,

I will have one of our engineers take a look at the SampleClient to determine why this is happening. It should be only a fraction of a millisecond to go between the Tracking Tools and the SampleClient. I would also encourage you to check out the VRPN in the mean time as it has very low latency as well.

Thanks,
D

[morgan]

Hey Roberto -

Using QueryPerformanceCounter things look correct here.

Is it possibly the timer? Many windows timers have only a 15 msec resolution - what timer are you using?

[roberto]

Hi Morgan,
I have tried to use QueryPerformanceCounter but I measured even worst delay, ranging from 15 to 20 / 25 ms with a lot of jitter. Can you post the code from which you measured 10 ms?

Also, I still have always a constant zero value in the MeanError field of the rigid body structure.

Thank you a lot!
Roberto

[morgan]

Hey Roberto,

RE MeanError, its possible TrackingTools is not reporting this, which is why its zero.

RE timing, our test here is simply measuring the elapsed time between subsequent DataHandler callback calls, which gets called by NatNet every time a frame is delivered to the socket. Looks like:

Code: Select all

void __cdecl DataHandler(sFrameOfMocapData* data, void* pUserData)
{
	NatNetClient* pClient = (NatNetClient*) pUserData;

        ...
        ...

        // same system latency test
	g_PerfTimer.Stop();
	double duration = g_PerfTimer.Duration();
	duration *= 1000.0f;	// convert from secs to msecs
	printf("msecs since last frame: %3.2f\n", duration);
	g_PerfTimer.Start();

        ...
        ...
}

g_PerTimer is a simple wrapper around QueryPerfCounter.

This tests correct against the SimpleServer test app that ships with NatNet 2.2 samples. It tests correct if we change the sampling rate of the server (see the Sleep() call SimpleServer's PlayingThread_Func(void * empty) for info).


Are you testing the timing differently?

Are you streaming on the same machine using the local loopback (127.0.0.1) or the actual machine ip address?

[roberto]

Hi Morgan,
I believe we have now a quite similar code for the tests.
I have tried using unicast instead of the default multicast and things got better. I believe that the average sample rate is close to 100 Hz, anyway I still have really a lot of jitter. Sometimes I measured duration (referring to your code) less than 1 or 2 ms followed by duration of more than 20 ms. I do not know what is causing this on my machine.
I would also suggest for future version of your NatNet protocol also to include timestamps directly inside the rigid-body packet, in order to improve as far as possible the timing accuracy (this is really useful for real-time control applications).

The strange fact about the MeanError is that I can see it on the TrackingTool window but not in the rigid-body packet I got with SimpleClient.

Thank you again a lot!

Best,
Roberto

[morgan]

Hey Roberto,

For NatNet sFrameOfMocapData packets from TrackingTools, the fLatency variable contains the TrackingTools timestamp, which is a double, and I believe is milliseconds since capture start. This should be helpful in isolating jitter.

The variability between Unicast and Multicast is a head scratcher. Testing the NatNet SimpleServer/SampleClient here at 100hz over multicast the client timing data looks pretty consistent at ~10 msecs. I've used a modified sleep routine in the SimpleServer as the standard windows sleep is only accurate to 15 msecs:

Code: Select all

// higer res sleep than standard.  standard sleep has max resolution of 15 ms.
int MySleep(int msecs)
{
	// todo - this is better, but should update to latest CreateTimerQueueTimer 
	HANDLE hTempEvent = CreateEvent( 0, true, FALSE, _T("TEMP_EVENT") );
	timeSetEvent( msecs, 1, (LPTIMECALLBACK)hTempEvent, 0, TIME_ONESHOT | TIME_CALLBACK_EVENT_SET );
	WaitForSingleObject( hTempEvent, msecs );
	CloseHandle( hTempEvent );
	return 1;
}

RE the mean error - will look into this. It's possible the mean error is simply not included in the data packet.

Hope this helps.

[roberto]

Hi Morgan,
thank you a lot! _Using fLatency I actually get a measure of the delay which appears coherent with the frame rate displayed on TrackingTools. I still wonder why I get so much jitter from the SampleClient, but hopefully it should be fast enough not to affect too much my application.
Let me know also how it is possible to send the MeanError information from the TrackingTools. Those kind of information can be really useful to decide how much to trust the rigid-body data (for example in case you get close to the boundaries of the tracking volume).
Best,
Roberto