whoenig / NatNetSDKCrossplatform

Crossplatform version of the OptiTrack NatNet SDK
13 stars 8 forks source link

Optitrack Connection Issue - Ubuntu 20.04 #3

Closed The-SS closed 2 years ago

The-SS commented 2 years ago

Hi Wolfgang,

When I use this package to get Optitrack raw data on a machine running Ubuntu 20.04, I get the following output

$ ./natnettest 192.168.1.133
1 264
NatNetVersion: 0.0.0.0
ServerVersion: 2.10.0.0

I can ping 192.168.1.133 and I get Optitrack rigid bodies using vrpn_client_ros, but when I try to get the point cloud, I am out of luck.

I tried using an older machine running Ubuntu 16.04 and actually got the raw point cloud data.

I have the wired network configuration on both machines setup basically the same and just moving the OptiTrack ethernet cable between the two machines. Do you have any ideas about why the Ubuntu 20.04 machine is not receiving the data?

Thank you. -Sleiman

whoenig commented 2 years ago

I use this with Ubuntu 20.04 and Motive 2.3 and 3.0 without issues.

One thing you could try is the official SDK (it does have a Linux version now, although this is not open-source). If the official one works, this would indicate that there is a bug in this repo, otherwise it might be a configuration problem in Motive or the network configuration (I don't recall that I changed anything on my Ubuntu).

The-SS commented 2 years ago

I downloaded the NatNet SDK 4.0.0 for Linux, compiled it per the instructions and ran ./SampleClient 192.168.1.133 (where 192.168.1.133 is the IP address of the Windows machine with Motive 1.10). I received raw point cloud data over to my Ubuntu 20.04 machine. Here is a sample:

FrameID : 2403470
Timestamp : 20028.92
Software latency : -nan milliseconds
Transit latency : -inf milliseconds
Timecode : 00:00:01:36.0
Rigid Bodies [Count=0]
Skeletons [Count=0]
Markers [Count=7]
Labeled Marker [ModelID=0, MarkerID=6557] [size=0.02] [pos=0.10,-0.12,0.11]
Labeled Marker [ModelID=0, MarkerID=6581] [size=0.02] [pos=0.32,-0.08,0.11]
Labeled Marker [ModelID=0, MarkerID=6582] [size=0.02] [pos=0.12,0.02,0.14]
Labeled Marker [ModelID=0, MarkerID=6583] [size=0.02] [pos=0.29,0.08,0.11]
Labeled Marker [ModelID=0, MarkerID=6586] [size=0.02] [pos=0.07,0.04,0.12]
Labeled Marker [ModelID=0, MarkerID=6587] [size=0.02] [pos=0.19,-0.08,0.13]
Labeled Marker [ModelID=0, MarkerID=6591] [size=0.02] [pos=0.07,-0.03,0.12]
Force Plate [Count=0]
Device [Count=0]

Having confirmed that, I tried this package again, but ./natnettest 192.168.1.133 returns

NatNetVersion: 0.0.0.0
ServerVersion: 2.10.0.0

I also tried your other libmotioncapture package. When I run ./motioncapture_example optitrack 192.168.1.133 from libmotioncapture/build, I get:

terminate called after throwing an instance of 'std::runtime_error'
  what():  Motive does not use multicast. Please update your streaming settings!
Aborted (core dumped)

(my Motive settings have Multicast enabled with command port 1510 and data port 1511).

It seems that I can (through the official SDK or VRPN) receive data but this package is having some issues. Any ideas what I can check/edit to make this work?

whoenig commented 2 years ago

I have heard from multiple people that there are issues with Motive 1.x. This is tricky to debug, since I don't have that version. What is your use case? One option would be to add support for the pre-built SDK in libmotioncapture. The other option would be to debug/analyze the packet stream that you get from Motive 1.x. The third option would be to upgrade to Motive 2.x or 3.0, both of which are tested and I have access to.

The-SS commented 2 years ago

I'm setting up Crazyswarm on this new machine. Since mocap_helper.launch didn't show any raw data, I tried checking with this (as you've recommended in some other issues/discussions). Since it seemed that the issue was not in Crazyswarm but rather on the libmotioncapture side, I brought up this issue here.

The-SS commented 2 years ago

I upgraded to Motive 2.0.1 (cannot use anything newer for now). The script responds differently now. On the new machine with Ubuntu 20.04, /natnettest 192.168.1.133 returns:

NatNetVersion: 88.208.50.0
ServerVersion: 3.0.0.0

then nothing happens. On the new machine with Ubuntu 16.04, I get the marker data after that.

NatNet SDK 4.0.0 returns the same data on both machines.

whoenig commented 2 years ago

what about https://github.com/IMRCLab/libmotioncapture in the case of Motive 2.0.1?

The-SS commented 2 years ago

That returns

supportsRigidBodyTracking: 1
supportsLatencyEstimate: 1
supportsPointCloud: 1
supportsTimeStamp: 1

then nothing happens. (I only ran this on the Ubuntu 20.04 machine).

whoenig commented 2 years ago

I think the best short-term solution will be to add a new backend to libmotioncapture that links to NatNetSDK 4.0, see https://github.com/IMRCLab/libmotioncapture/issues/1. PRs are welcome - I am not sure when exactly I'd get to implement this myself (probably about 2h of work in total).

The-SS commented 2 years ago

Which version of Boost are you using?

whoenig commented 2 years ago

the default of 20.04: 1.71

The-SS commented 2 years ago

Summary so far: this package works with Motive 1.10.4 or Motive 2.0.1 with Ubuntu 16.04 (Boost version 1.58) but not with Ubuntu 20.04 (Boost version 1.71).

whoenig commented 2 years ago

I doubt it's because of boost. I added support for the official SDK.

Please report back if this works for you.

The-SS commented 2 years ago

Thanks for adding that so quickly!

I have several updates about this issue.

TL;DR: The closed-source SDK support worked but integration with Crazyswarm was not tested. This seems to be an issue with our setup and not with the package itself, so older versions of Motive might still work with the open-source solution.

I'll close the issue here. If we get the Crazyswarm integration done, I'll let you know. If we have problems with that integration, I'll open an issue on Crazyswarm.

Thanks for your help!

Update: even with the fresh Ubuntu 20.04 install and installing ROS with no errors, the package is still not receiving data from Motive 2.3 using the open-source implementation. It does however receive data using the closed-source SDK.