This package is based on both vrpn_client_ros and optitrack_vrpn but intended for use in ROS2. Similar to optitrack_vrpn, this package makes a few modifications to the vrpn client to cater to specific aerospace applications with an optitrack mocap system as described below.
The default OptiTrack coordinate system has the x-axis forward, y-axis up, and z-axis to the right. This package converts to the ROS standard ENU frame, as well as the NED frame for aerospace applications.
To keep the ENU and NED frames consistent, the OptiTrack x-axis is assumed to be "North." This means that a translation along that axis will correspond to to a translation along the NED x-axis, but along the ENU y-axis. For both ENU and NED, the body x-axis goes out the front of the vehicle. These conventions are consistent with REP 103.
The OptiTrack system timestamps its motion capture frames very precisely. However, these timestamps are defined relative to when the Motive software was started, and do not use the system time.
On the client side, there are two options for timestamping the data. One option is to stamp each message with the current system time on the client computer when the message arrives. This method is affected by network latency, and will also result in jitter in the timestamp deltas due to the polling mechanism of the VRPN library and changing network latencies. The other option is to use the Motive timestamps, but these timestamps appear to be many years in the past compared to the system time.
This package uses a hybrid approach for timestamping data. For the first N (default N=100) messages, the Motive timestamp is compared with the client system-time time-of-arrival stamp. The minimum of the differences between these timestamp sources (corresponding to the lowest-latency message) is then used to define an offset between the client system time and the Motive time. All following messages are then timestamped by adding this constant offset to the Motive timestamps.
This method solves the problem of jitter in the timestamp deltas. It does not, however, correct for the network latency. If this is important for your application and you are not able to sufficiently reduce the network latency, one potential solution is to run this node on the same Windows machine as Motive, using the Linux subsystem for Windows. You can then set up an NTP server/client to synchronize the client system time to the Windows system time or vis-versa.
The code requires VRPN to work. Unfortunately, currently the package is only available in noetic and older ROS releases and can be installed with:
apt-get install ros-noetic-vrpn
If you want to stick to ROS2 or do not have access to noetic packages you can clone the following repository to the src folder of your ros_overlay_ws:
git clone --single-branch --branch debian/noetic/vrpn git@github.com:ros-drivers-gbp/vrpn-release.git
This will likely change in the future as ROS2 is still under development. See this issue for more info.
I only use pose in my project, so I did not port anything else (TF, twist, accel). Also multiple sensors per tracker are not ported. If there is anyone who would like to use the other features and is willing to test them, I'd be happy to help.
Check that the server IP address in sample.params.yaml matches with mocap. In Motive, this IP address can be found by going to View->Data Streaming Pane ("Local Interface" field).