[ROS2] Test reports for ROS2 version on different sensors

[twdragon]

This issue is dedicated to place the test reports of ROS2 version of this driver. All contributors are encouraged to place the test reports they have for this driver on the different Witmotion sensors here. Please link here also the other issues containing test results and experience feedback under the following template:

Tested sensor

<sensor model, case type, connection type>

List of tested modes

• list or table of tested baudrates,
• frequencies,
• polling rates,

Maximal duration of stable working (approx.)

Encountered issues and crashes

ROS1 issue: #16

[gsokoll]

Tested sensor

WT901C-TTL, with WitMotion TTL-USB adapter cable

List of tested modes

Baud: 9600, 57600, 115200
Polling rates: 10Hz, 100Hz

Encountered issues and crashes

Device works fine with WitMotion.exe app under Windows. Can set different baud rates and polling frequencies without problem.

Can not get it to work under Ubuntu 22.04 with ROS2 Humble. Regardless of configuration (baud rate, polling frequency), it always reports the following.

cmp@mele1:~/trot_ws$ ros2 launch witmotion_ros wt901.launch.py 
[INFO] [launch]: All log files can be found below /home/cmp/.ros/log/2023-05-11-08-57-47-628690-mele1-16756
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [witmotion_ros_node-1]: process started with pid [16757]
[witmotion_ros_node-1] [INFO] [1683759467.797155161] [ROSWitmotionSensorController]: Controller started
[witmotion_ros_node-1] [INFO] [1683759467.797345009] [MinimalPublisher]: QT spin !!!!!
[witmotion_ros_node-1] [ERROR] [1683759468.199331411] [ROSWitmotionSensorController]: Sensor error: No data acquired during last 3 iterations, please check the baudrate!
[witmotion_ros_node-1] [INFO] [1683759468.199378377] [ROSWitmotionSensorController]: Entering SUSPENDED state
[witmotion_ros_node-1] QObject::killTimer: Timers cannot be stopped from another thread
[witmotion_ros_node-1] QObject::~QObject: Timers cannot be stopped from another thread
[witmotion_ros_node-1] QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
[ERROR] [witmotion_ros_node-1]: process has died [pid 16757, exit code -11, cmd '/home/cmp/trot_ws/install/witmotion_ros/lib/witmotion_ros/witmotion_ros_node --ros-args --params-file /home/cmp/trot_ws/install/witmotion_ros/share/witmotion_ros/config/wt901.yml'].

Launch.log output is:

1683760901.5459187 [INFO] [launch]: All log files can be found below /home/cmp/.ros/log/2023-05-11-09-21-41-538783-mele1-20854
1683760901.5461226 [INFO] [launch]: Default logging verbosity is set to INFO
1683760901.6677451 [INFO] [witmotion_ros_node-1]: process started with pid [20855]
1683760901.7071021 [witmotion_ros_node-1] [INFO] [1683760901.706649358] [ROSWitmotionSensorController]: Controller started
1683760901.7075522 [witmotion_ros_node-1] [INFO] [1683760901.706821295] [MinimalPublisher]: QT spin !!!!!
1683760901.7079248 [witmotion_ros_node-1] Opening device "ttyUSB1" at 57600 baud
1683760901.7081082 [witmotion_ros_node-1] Instantiating timer at 50 ms
1683760901.9087548 [witmotion_ros_node-1] [ERROR] [1683760901.908408072] [ROSWitmotionSensorController]: Sensor error: No data acquired during last 3 iterations, please check the baudrate!
1683760901.9090066 [witmotion_ros_node-1] [INFO] [1683760901.908444299] [ROSWitmotionSensorController]: Entering SUSPENDED state
1683760901.9095328 [witmotion_ros_node-1] QObject::killTimer: Timers cannot be stopped from another thread
1683760901.9096880 [witmotion_ros_node-1] QObject::~QObject: Timers cannot be stopped from another thread
1683760901.9098196 [witmotion_ros_node-1] QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread
1683760901.9108186 [witmotion_ros_node-1] Suspending TTL connection, please emit RunPoll() again to proceed!
1683760902.0318766 [ERROR] [witmotion_ros_node-1]: process has died [pid 20855, exit code -11, cmd '/home/cmp/trot_ws/install/witmotion_ros/lib/witmotion_ros/witmotion_ros_node --ros-args --params-file /home/cmp/trot_ws/install/witmotion_ros/share/witmotion_ros/config/wt901.yml'].

User is member of dialout group and has permission to the device.

cmp@mele1:~/trot_ws$ ll /dev/ttyUSB1
crw-rw-rw- 1 root dialout 188, 1 May 11 09:12 /dev/ttyUSB1
cmp@mele1:~/trot_ws$ groups cmp
cmp : cmp adm dialout cdrom sudo dip plugdev lpadmin lxd sambashare

Correct port is selected. Other serial devices are working fine.

Not sure what else to try.

[gsokoll]

Managed to get it working, more or less. One issue was a combination of the device not being configured to output quarterions, and the parameter "use_native_orientation" being set to true.

But other big issue was choice of polling interval and output rate. I did not expect that the device would fail depending on these settings, until I read through "Test reports for ROS1 version on different sensors" #16 and saw how common this problem was.

My test results (only checking whether the ROS node would launch successfully and run for a minute or two; not testing whether it would remain working for hours).

OK ?	Baud	Output rate (Hz)	Polling Interval (ms)
✔️	115200	20	10
✔️	115200	20	20
❌	115200	20	50
✔️	115200	20	70
❌	115200	20	100
✔️	115200	50	10
❌	115200	50	20
✔️	115200	50	30
❌	115200	50	40
✔️	115200	50	50
✔️	115200	100	5
❌	115200	100	10
✔️	115200	100	15
❌	115200	100	20
✔️	115200	100	25
✔️	115200	100	30

It appears that the node will fail if the output rate is a multiple of the polling interval (eg 20 Hz and 50 ms, or 20 Hz and 100 ms).

Is this an issue with the driver code, or the device itself? It does not provide much confidence to use the devices in moving equipment....

[twdragon]

@gsokoll in this case it seemed to be a serial port kernel driver issue because the node crashes only in one of the following cases:

• there is no data over the line when the poll starts (the device did not produce any data while the poller waits for the next firing);
• the poller received the incomplete Witmotion data packet over the corrupted line or buggy kernel driver, so the Qt backend cannot deliver the data

In your case it seemed the kernel driver periodically hangs up filling the buffer and it may pass some poller firing moments. I can suggest to experiment with lower baudrates (primarily setting the proper baudrate on the device using official control application or one of the example control applications included in the driver library)

[gsokoll]

I doubt very much this is a kernel driver issue, but will do some more testing.

[gsokoll]

I have tested further with various baud rates. The behaviour is very consistent - when the polling interval matches the output rate interval, the node fails immediately when starting with "Sensor error: Timed out waiting for data, please check device connection and baudrate!"

OK ?	Baud	Output rate (Hz)	Polling Interval (ms)
✔️	57600	20	10
✔️	57600	20	20
✔️	57600	20	40
❌	57600	20	50
✔️	57600	20	70
❌	57600	20	100
✔️	19200	20	10
✔️	19200	20	20
✔️	19200	20	40
❌	19200	20	50
✔️	19200	20	70
❌	19200	20	100
❌	9600	20	10
✔️	9600	20	20
✔️	9600	20	40
✔️	9600	20	50
✔️	9600	20	70
❌	9600	20	100

Even when the choosing a "good" set of output rate and polling intervals, the node would not reliabkly run for an extended period of time. For example, with baud rate of 115200, output rate of 20 Hz, and polling interval of 40 ms, the node would start successfully but testing repeatedly it ran for the following periods of time before failing with the same timeout error as before:
4 hrs, 1 min
1 hr, 17 mins
21 mins
1 hr, 48 mins

Fix for Timeout Errors
Further examination of the source code indicates the timeout error is due to faulty logic in the read data function. Changes to address this issue has been tested and the code runs reliably for more than 12 hours in every case. Refer to #26

OK ?	Baud	Output rate (Hz)	Polling Interval (ms)
✔️	115200	20	10
✔️	115200	20	20
✔️	115200	20	40
✔️	115200	20	50
✔️	115200	20	70
✔️	115200	20	100

[YuilTripathee]

From my test for Yahboom 10-axis IMU. I got these topics to be published:

1. \imu
2. \magnetometer
3. \temperature

And these were the combinations that worked: (output rate presumably 200 Hz from the source's claim: https://category.yahboom.net/products/imu) I didn't change any settings for that.

OK?	Baud	Polling interval (ms)
✅	9600	0.5
✅	9600	1
✅	9600	5
✅	9600	10
✅	9600	20
✅	9600	30
✅	9600	40
✅	9600	50
✅	9600	60
✅	9600	70
✅	9600	100
✅	9600	200
❌	14400	20, 50, 100, 200
❌	38400, 921600, 115200	50 on each

Apparently, only 9600 baud seem to work in my test (with the best of my testing ability and knowledge).