Massive latency in HWT906 with dev board and USBC connection.

[FPSychotic]

Tested sensor

<sensor model, case type, connection type>
HWT906 with dev board
<machine, architecture, CPU, kernel>
Jetson Orin NX , ARM64,
List of tested modes
ROS driver,

list or table of tested baudrates,

921600 is the only that works by default
frequencies,
polling rates,
any, 5 to 50ms

Always massive latency of 40sec or more.
Tested native orientatation true or false, rc clock true or false, always that massive latency when work.

IMU static TF is not published , please add a TF publisher in the node.

https://github.com/yowlings/wit_node after change the bauds in the code it works at 1000hz. Maybe you could check why is working and not yours.

Thanks.

[twdragon]

@FPSychotic TF information should not be published by IMU driver, you should add the transform publisher node in your launch file declaring the installed position of your sensor.

921600 is the only that works by default

If this baudrate is set up on the sensor board, the Qt backend cannot access the sensor. Can you change this setting of your sensor to 115200 baud using the official Windows application, and then retry?

after change the bauds in the code it works at 1000hz.

Do you know what are the acquisition rates your sensor really supports? Does it really have 1 KHz acquisition frequency?

What do you mean the delay? You wait 40s and then the messages start being published? Or the sensor starts throw out the data after restart? Are the timestamps of the published IMU messages corresponding to the real time or they are delayed?

[FPSychotic]

Hi, thanks for your reply Yes HWT906 is announced as 1000hz, and In the other unofficial node get such speed, it looks a quite basic driver but worked. The node start immediately, but the readings arrive with a 40sec delay, movement you makes, will take 40sec in be visualised in RVIZ. Also in RQT readings are very weird, are not fluid

…

On Sat, 15 Apr 2023, 23:12 Andrei Vukolov, ***@***.***> wrote: @FPSychotic <https://github.com/FPSychotic> TF information should not be published by IMU driver, you should add the transform publisher node in your launch file declaring the installed position of your sensor. 921600 is the only that works by default If this baudrate is set up on the sensor board, the Qt backend cannot access the sensor. Can you change this setting of your sensor to 115200 baud using the official Windows application, and then retry? after change the bauds in the code it works at 1000hz. Do you know what are the acquisition rates your sensor really supports? Does it really have 1 KHz acquisition frequency? What do you mean the delay? You wait 40s and then the messages start being published? Or the sensor starts throw out the data after restart? Are the timestamps of the published IMU messages corresponding to the real time or they are delayed? — Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AITQOVAQLOQU5IE5XXL7SITXBMMOFANCNFSM6AAAAAAW7VPCYA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[FPSychotic]

The timestamps are in sync with the system ones, they are correct, but the readings take that time in arrive.
Please find attached picture you can see the wit IMU timestamp, and the livox's imu timestamp as comparation.
As maybe relevant info I use ptpd to synchronize the ROS system, in example with the lidar via Ethernet.

[FPSychotic]

after change from windows app to 115200 it works at 200hz. Won't work at 1khz. Won't work any baudrate or poll rate above that.
would be nice cant get full functionality at 1000hz , thanks.

[twdragon]

@FPSychotic I will register it as a feature request. Can we also try to find the documentation about the operational codes to set the proper acquisition frequency above 200 Hz? Our current setup has no proper rates and opcodes to document, so we cannot build the real backward compatible library for your given sensor.

Anyhow, the first thing we can try is to set the acquisition rate for the given baudrate 115200 baud, it could work. However, we need the sensor opcode documentation and it will be very good if you could share your own, once you have it.