Hello HalH,
To begin, we would recommend that you refrain from uninitializing the client. You may be running into a timing issue in which you are calling a cleanup method on the assembly object after it has been destroyed.
Are you sending any commands to Motive? This could be as a simple request for the frame rate or to control Motive.
Cheers,
Steven
--
Steven Andrews
OptiTrack | Customer Support Engineer
Problems of Streaming Data from Motive to Matlab
-
- NaturalPoint Employee
- Posts: 718
- Joined: Mon Jan 19, 2015 11:52 am
Re: Problems of Streaming Data from Motive to Matlab
Hello Steven
thank you, sorry the late reply (was away),
I've followed your recommendations and also did some hardware changes,
At the hardware level: I have added 8 Go of DDR3 so that I have 16 Go now
(CPU is i7-2630QM 2GHz, this is a professional labtop with Windows 7 pro),
At the software level: I am now using Matlab r2013b and Motive 1.8.0 (final release).
in Matlab: I have modified my scripts and put the client initialization and unitialization
in my main function so that it is initialized only once for all takes (run in a batch mode), in each take I use the addlistener function to extract data from NatNet client and store them take by take on my disk in .mat files.
I've tested the two versions (client initialization in the main -V1- vs in my subfunction -V2).
Matlab behaves better (no crash for both) but now Motive crashes only for V2 !
So thank you for telling me about this unitialization stuff: it definitely helps even if I need to test it again.
Another related problem is that I do not get the nb of samples i'm supposed to get
(say 10 seconds of recording x 360 frames = 3600 frames, instead I have only 1500 to 2000 frames stored in matlab), whatever the client initialization stuff...
Regarding all these issues:
- i'm using a labtop so it might behave better with a desktop PC (i should test that),
- regarding the second problem, I've noticed that the Point Cloud item (bottom bar of the Motive menu) display highly variable fps from (from 200 to 360 fps), the latency is displayed in red and ranges around 3 to 7 ms. Does this explain my "undersampling" issue ?
( I attach a plot of the Timing Samples over a short period of recording - instead of 2520 samples I have only 1200 stored frames, and time is not increasing in regular intervals...)
Once again sorry for such a long explanation and thank you for your time !
HalH
thank you, sorry the late reply (was away),
I've followed your recommendations and also did some hardware changes,
At the hardware level: I have added 8 Go of DDR3 so that I have 16 Go now
(CPU is i7-2630QM 2GHz, this is a professional labtop with Windows 7 pro),
At the software level: I am now using Matlab r2013b and Motive 1.8.0 (final release).
in Matlab: I have modified my scripts and put the client initialization and unitialization
in my main function so that it is initialized only once for all takes (run in a batch mode), in each take I use the addlistener function to extract data from NatNet client and store them take by take on my disk in .mat files.
I've tested the two versions (client initialization in the main -V1- vs in my subfunction -V2).
Matlab behaves better (no crash for both) but now Motive crashes only for V2 !
So thank you for telling me about this unitialization stuff: it definitely helps even if I need to test it again.
Another related problem is that I do not get the nb of samples i'm supposed to get
(say 10 seconds of recording x 360 frames = 3600 frames, instead I have only 1500 to 2000 frames stored in matlab), whatever the client initialization stuff...
Regarding all these issues:
- i'm using a labtop so it might behave better with a desktop PC (i should test that),
- regarding the second problem, I've noticed that the Point Cloud item (bottom bar of the Motive menu) display highly variable fps from (from 200 to 360 fps), the latency is displayed in red and ranges around 3 to 7 ms. Does this explain my "undersampling" issue ?
( I attach a plot of the Timing Samples over a short period of recording - instead of 2520 samples I have only 1200 stored frames, and time is not increasing in regular intervals...)
Once again sorry for such a long explanation and thank you for your time !
HalH
- Attachments
-
- TimeStamps.jpg (60.41 KiB) Viewed 2957 times
-
- NaturalPoint Employee
- Posts: 718
- Joined: Mon Jan 19, 2015 11:52 am
Re: Problems of Streaming Data from Motive to Matlab
Hello HalH,
You may be running the cameras at a faster rate than the Point Cloud can keep up with. The stream will not send data if the Point Cloud (3D Live Reconstruction) cannot keep up. If your latency reports 3ms to 7ms, you are going over the time slice of 1/360 ~ 2.8. Extra ram will not help with this.
Below are a few options.
You can try to reduce the overhead in the data by making sure your camera masks are up to date and by reducing the overall number of markers and rigid bodies being tracked. You can also reduce any smoothing on the rigid bodies and disable Ray Ranking in your Reconstruction Settings.
If you are currently only tracking a couple of rigid bodies with just a handful of markers, then a desktop with higher specs may help with the performance, but this is not a guarantee.
You can also reduce the frame rate.
If you were running with your system live, you might try recording a take, then doing a Reconstruct and Autolabel on the recorded take. You can then stream the processed 3D data, which should not have any dropped frames.
Best regards,
Steven
--
Steven Andrews
OptiTrack | Customer Support Engineer
You may be running the cameras at a faster rate than the Point Cloud can keep up with. The stream will not send data if the Point Cloud (3D Live Reconstruction) cannot keep up. If your latency reports 3ms to 7ms, you are going over the time slice of 1/360 ~ 2.8. Extra ram will not help with this.
Below are a few options.
You can try to reduce the overhead in the data by making sure your camera masks are up to date and by reducing the overall number of markers and rigid bodies being tracked. You can also reduce any smoothing on the rigid bodies and disable Ray Ranking in your Reconstruction Settings.
If you are currently only tracking a couple of rigid bodies with just a handful of markers, then a desktop with higher specs may help with the performance, but this is not a guarantee.
You can also reduce the frame rate.
If you were running with your system live, you might try recording a take, then doing a Reconstruct and Autolabel on the recorded take. You can then stream the processed 3D data, which should not have any dropped frames.
Best regards,
Steven
--
Steven Andrews
OptiTrack | Customer Support Engineer