Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libsurvive not delivering any sensor data #294

Open
Zarnack opened this issue Oct 23, 2023 · 5 comments
Open

libsurvive not delivering any sensor data #294

Zarnack opened this issue Oct 23, 2023 · 5 comments

Comments

@Zarnack
Copy link

Zarnack commented Oct 23, 2023

Describe the bug
With commit 464dd97 (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:
Screenshot from 2023-10-23 17-31-29

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:

  • OS: Ubuntu 22.04

Additional context
This also affects the libsurvive_ros2 project as it is pulling the most recent libsurvive commit when building.

@Zarnack
Copy link
Author

Zarnack commented Oct 23, 2023

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: asymingt/libsurvive_ros2#8

@Starcommander
Copy link

I can confirm, that commit 464dd97 breaks controller-data on linux (debian11)
Seems this commit was only tested on windows.

@acochrane
Copy link

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

@JulianGro
Copy link
Contributor

@acochrane are you sure you are on the right issue?
This is tracking a regression caused by commit 464dd97

acochrane added a commit to acochrane/libsurvive_ros2 that referenced this issue Dec 11, 2023
@acochrane
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants