Open Zarnack opened 1 year ago
It seems like installing libhidapi-dev
and libudev-dev
and adding -DUSE_HIDAPI=1
as a CMAKE argument in the Makefile fixes this problem.
--> Solution based on this Pull Request: https://github.com/asymingt/libsurvive_ros2/pull/8
I can confirm, that commit https://github.com/cntools/libsurvive/commit/464dd9734a8de20df818fd83e7c1b016b068bb52 breaks controller-data on linux (debian11) Seems this commit was only tested on windows.
So my result using hidapi only solved the problem for one run, now I again have no data. After reverting back to not using hidapi, I have a different issue. At first glance, it appears to be broken at the ros level, with a ghost of the device providing no updated position information, followed by a new unnamed device, which, since it is unnamed, ros cannot collect and publish data for.
[INFO] [rosapi_node-3]: process started with pid [94595] [libsurvive_ros2_node-1] Info: Loaded drivers: GlobalSceneSolver, HTCVive [libsurvive_ros2_node-1] [INFO] [1702321112.651096042] [libsurvive.libsurvive_ros2_node]: Cleaning up. [libsurvive_ros2_node-1] [INFO] [1702321112.651112227] [libsurvive.libsurvive_ros2_node]: Start listening for events.. [libsurvive_ros2_node-1] Info: Adding tracked object WM0 from HTC [libsurvive_ros2_node-1] [INFO] [1702321112.672919563] [libsurvive.libsurvive_ros2_node]: A new device LHB-1AE75962 was added at time 1702321112.652004 [libsurvive_ros2_node-1] [INFO] [1702321112.773071398] [libsurvive.libsurvive_ros2_node]: A new device was added at time 1702321112.673820 [rosbridge_websocket-2] [INFO] [1702321112.894757990] [rosbridge_server_node]: Rosbridge WebSocket server started on port 9090 [rosbridge_websocket-2] [INFO] [1702321126.951110327] [rosbridge_server_node]: Client connected. 1 clients total. [rosbridge_websocket-2] [INFO] [1702321127.101400632] [rosbridge_server_node]: [Client c80b1822-dadc-4b0e-812a-0ffc07e85e7d] Subscribed to /tf [rosbridge_websocket-2] [INFO] [1702321127.102040034] [rosbridge_server_node]: [Client c80b1822-dadc-4b0e-812a-0ffc07e85e7d] Subscribed to /tf_static
@acochrane are you sure you are on the right issue? This is tracking a regression caused by commit 464dd97
I couldn't say if this is the right issue to post on, but it is directly related to the last post by @Zarnack
I WAS able to use the hidapi to get the tracker to work a couple times, which is why it wound up in the PR. But when I started the ROS launch file again, there was once again, no data coming from the tracker.
Seeing this, I updated my TAG as in this branch, and I have success creating transforms based on tracker position.
I think it's related and the problem hasn't been solved in the cntools/libsurvive main branch.
Describe the bug With commit 464dd9734a8de20df818fd83e7c1b016b068bb52 (and after) libsurvive stopped working for me. No matter which application I use (libsurvive-cli, sensors-readout...), no sensor data shows up at all --> tracking is not working. It still seems like it can recognize if a tracker is connected or not.
Picture of sensors-readout application:
Before this commit everything works fine.
I am using one HTC Vive Tracker 3.0 and 4 Basestation 2.0 on an Ubuntu 22.04 machine.
Data This is a log of a survive-cli run with 4 Basestations and 1 tracker. bug.rec.gz
Desktop:
Additional context This also affects the libsurvive_ros2 project as it is pulling the most recent libsurvive commit when building.