Use server port 22223

[jnippula]

Mocap server uses different server port according to message protocol version and endianess. User can define the base port number, which is used for legacy 1.0 protocol version. Other port numbers are based on the base port (e.g. protocol 1.1 little-endian: base-port +1). The base port should not be used for new clients using newer protocol versions, but other related port shall be selected (base port + n)

Currently the mocap_pose sends handshake request to that base-port (22222), but due to protocol 1.1. and little-endianess, the server responds back from base-port+1 (22223). This causes routing issue in case the mocap-pose is not running in same subnet, but the NAT device checks the translation table and gets confused, because the response does not come from the same port where request was sent.

To fix this, the mocap-pose shall send the initial request already to the correct port (base-port+1) which shall be used for it's protocol/endianess combination.

Link to documentation: https://docs.qualisys.com/qtm-rt-protocol/#connecting

[jnippula]

This fix is needed for fmo-fc-adapter system where the mocap-pose is running in docker container inside the adaptervm of PMC, and it accesses the mesh network via separate netvm.

[maseabunikie]

Does this work already or we need to reconfigure the QTM server too?

[jnippula]

It requires only this mocap_pose change, no need to change anything in QTM server side. Our QTM server is already switching to 22223, even if mocap_pose is trying to send request to 22222 port.

[mehmetkillioglu]

Looks good to me, and complies with the official docs 👍

Has it been also verified with a normal drone?

Does this change require a qualisys_cpp_sdk submodule update? Or does it already support the protocol version 1.1 with the current submodule revision?

[jnippula]

No, this does not work. The issue is not the port selection, because the rt_protocol's Connect() method already takes care of selecting proper server port. The original implementation is correct, we should provide only the base port into the Connect() method and the extra information about sdk version and endianess!
so, the connection problem in fmo-fc-adapter must be something else, I probably mixed the things in testing setup.

Need to close this PR because it does not really work. My bad..

[maseabunikie]

ok. No problem. Thanks for testing it. 👍