Message builder setup

If the node does not publish any IMU information, ensure at first that you set up enabled parameters properly for all the inertial measurements your sensor actually provides! Otherwise, the IMU data pack will never be considered complete and the node will not publish on the imu topic. If, for example, the WT31N sensor does not provide angular velocities, set the enabled parameter in the imu_publisher/measurements/angular_velocity config file section to false.

Absence of quaternion orientation output

If imu_publisher/use_native_orientation parameter is set to true and the sensor does not provide orientation information in native quaternion format, the IMU information will never be published, as it is demonstrated in this issue. If the native quaternion is required, enable it in the sensor's internal settings using the controller application.

Polling interval crash

If you see a lot of messages like QSocketNotifier: Invalid socket <N> and type 'read', disabling..., check the value of the polling_interval parameter. These messages appear when the polling interval is too small (usually less than 20 ms), and it is not enough for the kernel port driver to become ready for accumulating data.

Locked configuration registers

On some Witmotion sensors from the 9xx series, the configuration registers are "locked". These sensors require unlocking for every reconfiguration session, so the special command should be sent before any other configuration packet to let it work. According to the document shared by Witmotion by request, the binary formulation of the command that should be sent to "unlock" the configuration registers is the following (5 bytes should be sent via UART channel):

• 0xFF 0xAA 0x69 0x88 0xB5

Non-standard baudrates

The baud rates over 256000 baud are considered non-standard and they are not supported officially by the underlying Qt backend. However, the official Windows controller application by Witmotion allows to set up the baudrate to values up to 921600 baud. If this was occasionally done, and the node cannot connect to the sensor, the user is strongly advised to reduce the baud rate via the same Windows controller application to 115200 baud and then try to run the node again.

Distinguish between several identical USB devices

This case usually happens when several sensors (not always they are identical themselves) are connected to the same machine via identical USB-to-serial adaptors. Linux kernel does not have ID persistence policy when the USB devices are enumerated during the boot, so the referral paths like /dev/ttyUSB0, /dev/ttyUSB1 may easily change on the next boot when the identical device is connected to the same machine on the different USB port, despite the physical ports themselves are never changed.

To distinguish between such devices there are several ways to do. The most convenient way is to find a detailed description of the USB connection the device has through udevadm:

lsusb
udevadm info -a -n /dev/<DEVICE> | grep -e '{serial}'

The output will include a list of vendor IDs, product IDs and the serial numbers assigned to the device. Repeating this for all the devices connected to the machine, the different serial numbers would be revealed. Then the udev rules list could be created as something like this:

SUBSYSTEM=="tty", ATTRS{idVendor}=="<VendorID>", ATTRS{idProduct}=="<ProductID>", ATTRS{serial}=="<SerialNumber>", SYMLINK+="device_name"

This will create the dedicated virtual file with the name /dev/device_name persistent for the device with the mentioned SerialNumber. However, some cheap devices (especially, USB-RS232 adaptors) do not have identical serial numbers, so this approach is not always usable.

The second approach is to examine the USB bus ID assigned to the device:

lsusb -tvv

This will show the tree of USB bus connections with paths assigned in /dev/bus and /sys/bus namespaces. Then it is possible to access the device directly by the listed path.

The third approach is to examine the driver subsystem name to distinguish the devices by a unique name. To do that, examine the /dev directory for subdirectories created by the driver, like, for example, serial/ for TTY devices, or v4l/ for web cameras. Then enter the subdirectory to access the device by its persistent ID, like this:

/dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_919E375F-video-index0