Bug #385
open[Motive 2.2] bodies port doesn't get updated.
Added by Youssef Aboudorra 12 months ago. Updated 12 months ago.
Description
Hello Anthony,
We recently updated our motive SW from 1.7.2 to 2.2.0
We were able to connect optritrack-genom3 to the server, however the bodies data port stops updating the values after few moments.
Even the log file shows few data points (5-6 entries max).
We are using the same setup (Host PC, router, client pc), just upgraded motive and configured it with the same streaming parameters (ip, port no., multicast addr), both unicast and multicast don't solve the issue.
Ayham already confirmed that optitrack-genom3 works with motive 2.3 in his lab at Saxion.
I tried 2.3.0 and 2.3.1, same issue.
Appreciate your support in figuring this out.
Regards,
Youssef
Files
| remmina_flight-lab_192.168.0.102.png (262 KB) remmina_flight-lab_192.168.0.102.png | Youssef Aboudorra, 2023-05-06 19:56 |
Updated by Anthony Mallet 12 months ago
(disclaimer: I cannot check on real hardware until next week, May 9th)
I recently tried with Motive 2.2, and you have to use the latest
release 2.3.1 of optitrack-genom3 (with an earlier release it wouldn't
work, so I assume you are using 2.3.1 too). With the fix in 2.3.1 it
was ok for me after a couple of simple tests. I might very well have
missed something, though.
Can you provide the results of the 'ping' request in optitrack-genom3
after connecting to the motive computer?
Can you check and report the local streaming address in the streaming
config pane in Motive ? It has to be your local interface public
address.
Thanks!
Updated by Youssef Aboudorra 12 months ago
Anthony Mallet wrote in #note-1:
I recently tried with Motive 2.2, and you have to use the latest
release 2.3.1 of optitrack-genom3 (with an earlier release it wouldn't
work, so I assume you are using 2.3.1 too). With the fix in 2.3.1 it
was ok for me after a couple of simple tests. I might very well have
missed something, though.
Yes I saw you released a new version, so I am using the latest release 2.3.1 of optitrack-genom3, and Motive 2.2.0 (Natnet 3.1.0.0)
Can you provide the results of the 'ping' request in optitrack-genom3
after connecting to the motive computer?
Here are the results of several ping requests
eltclsh > ::optitrack::ping
rtt 0.01908421516418457 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.021358013153076172 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.01674199104309082 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.020231962203979492 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.021217107772827148 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.019796848297119141 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.019891977310180664 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.01960301399230957 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.015073060989379883 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.032598972320556641 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.021991968154907227 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.0083789825439453125 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.019333839416503906 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.018308877944946289 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.01961207389831543 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.013517856597900391 info {Motive-2.2.0.0, natnet-3.1.0.0}
eltclsh > ::optitrack::ping
rtt 0.019551992416381836 info {Motive-2.2.0.0, natnet-3.1.0.0}
and the results of get_bw requests:
eltclsh > ::optitrack::get_bw cur 0.012254086943864439 avg 0.58565287218975615 eltclsh > ::optitrack::get_bw cur 28.6102294921875 avg 6.1362885664898768 eltclsh > ::optitrack::get_bw cur 0.011207611200543532 avg 8.7882654334553187 eltclsh > ::optitrack::get_bw cur 114.44091796875 avg 10.360227103818557 eltclsh > ::optitrack::get_bw cur 0.010552412906293223 avg 12.667452013915105 eltclsh > ::optitrack::get_bw cur 0.010330467410069507 avg 13.32606021921811 eltclsh > ::optitrack::get_bw cur 0.011765284051480416 avg 14.351613913777411 eltclsh > ::optitrack::get_bw cur 0.012362635623717188 avg inf eltclsh > ::optitrack::get_bw cur 0.01054852225723569 avg inf eltclsh > ::optitrack::get_bw cur 0.011681220574538125 avg inf
Can you check and report the local streaming address in the streaming
config pane in Motive ? It has to be your local interface public
address.
Local interface address is 192.168.0.102, it is the same IP address of the machine on the network. attaching a screenshot of the configuration 
Also I called the bodies port several times, you can see the data of the body called (rb) don't get updated.
eltclsh > ::optitrack::bodies rb
bodies {ts {sec 1683393143 nsec 64535000} intrinsic 0 pos {x 0.047903612256049999 y -0.046451881527900696 z 0.52193516492843628} att {qw -0.86676287651062012 qx 0.49869734048843384 qy 0.0024797057267277323 qz 0.0041142012923957028} vel {} avel {} acc {} aacc {} pos_cov {cov {0 4.7629298510765139e-06 1 0 2 4.7629298510765139e-06 3 0 4 0 5 4.7629298510765139e-06}} att_cov {cov {0 1.1846459904574803e-05 1 2.0587875798133967e-05 2 3.5783937818613016e-05 3 1.0237045472869554e-07 4 -5.8899469395037668e-08 5 4.7629005641042965e-05 6 1.6984783823672598e-07 7 -9.7722996117874408e-08 8 -4.8591450852564802e-10 9 4.7628492306191173e-05}} att_pos_cov {} vel_cov {} avel_cov {} acc_cov {} aacc_cov {}}
eltclsh > ::optitrack::bodies rb
bodies {ts {sec 1683393143 nsec 64535000} intrinsic 0 pos {x 0.047903612256049999 y -0.046451881527900696 z 0.52193516492843628} att {qw -0.86676287651062012 qx 0.49869734048843384 qy 0.0024797057267277323 qz 0.0041142012923957028} vel {} avel {} acc {} aacc {} pos_cov {cov {0 4.7629298510765139e-06 1 0 2 4.7629298510765139e-06 3 0 4 0 5 4.7629298510765139e-06}} att_cov {cov {0 1.1846459904574803e-05 1 2.0587875798133967e-05 2 3.5783937818613016e-05 3 1.0237045472869554e-07 4 -5.8899469395037668e-08 5 4.7629005641042965e-05 6 1.6984783823672598e-07 7 -9.7722996117874408e-08 8 -4.8591450852564802e-10 9 4.7628492306191173e-05}} att_pos_cov {} vel_cov {} avel_cov {} acc_cov {} aacc_cov {}}
Updated by Anthony Mallet 12 months ago
So, I could test on real hardware with Motive-2.2.0. It's working fine
here.
Your bandwidth measurements are (not surprisingly) erratic.
Maybe you can check the streaming rate in Motive: unfold the bottom
right panel where it says "residual 1.10mm" on your screenshot. It
should match your camera rate settings (120Hz by default I think).
You can also check you firewall settings and make sure incoming UDP
packets on port 1510 are not filtered (outgoing on Motive computer,
incoming on yours).
BTW: residual 1.10mm looks high to me, I usually see something more
like 0.1mm. But that's a different topic :)
Updated by Youssef Aboudorra 12 months ago
Your bandwidth measurements are (not surprisingly) erratic.
Maybe you can check the streaming rate in Motive: unfold the bottom
right panel where it says "residual 1.10mm" on your screenshot. It
should match your camera rate settings (120Hz by default I think).
It is 100Hz same as the camera rate (100Hz is max for the cameras we use)
You can also check you firewall settings and make sure incoming UDP
packets on port 1510 are not filtered (outgoing on Motive computer,
incoming on yours).
Both setting of the firewall shouldn't be blocking the connection on both sides, is there a specific outbound rule on the Motive computer firewall (Windows 7) that I need to check?
Is there any tip on configuring the firewall, maybe I missed something. I'm using ufw for my machine.
BTW: residual 1.10mm looks high to me, I usually see something more
like 0.1mm. But that's a different topic :)
Maybe a better calibration is required, also I think the cameras are bit older than the one in LAAS.