Problem to launch (Ubuntu 22, ROS-2 Humble) about bluespace_ai_xsens_ros_mti_driver

[pshved]

Hi @waltejon we faced a similar problem at Bluespace; could you please try this fix and see if it works?
#17

[Steven-GH]

Hi @waltejon,
Are you in the dialout group? You can check this by using the groups command.

I also recommend updating the param/xsens_mti_node.yaml file. Set scan_for_devices to false and enter the port ("/dev/ttyUSB0"). Can you give that a try?

[waltejon]

@StevenXsens: Thank you for the answer! 😊

I followed you recommondations. However, the isse is still open. It seems like that the XSENS is still not found, although the driver is now searching directly at the port /dev/ttyUSB0 the XENS is connected to.

@StevenXsens: Do you have an idea what the problem is? Could a different baudrate be a problem?

dialout group

I used the groups command. According to the feedback, I would assume that I am in the dialout group.

YAML file

I also updated the YAML file you mentioned (see below).

    ros__parameters:

        ## Device settings, provide one of the following:
        ##  - scan_for devices = 
        ##          true:   the driver ignores port and baudrate settings, scans for devices on all ports and selects the first found
        ##          false: = Requires correct port and baudrate both to be specified
        scan_for_devices: false
        port: "/dev/ttyUSB0" # port name, e.g. '/dev/ttyUSB0'
        baudrate: 115200 # non necessary for some devices

[waltejon]

A different baudrate might be not the problem.

In addition to the comment above (#16 (comment)), I checked different baudrates

• 9600 bauds,
• 38400 bauds,
• 57600 bauds,
• 76800 bauds,
• 115200 bauds,
• 230400 bauds,
• 460800 bauds,
• 576000 bauds.

For every of these baudrates, the launch stucked while "Scanning port /dev/ttyUSB0".

[Steven-GH]

Hi @waltejon,

If you plug in your MTi and then send dmesg from a terminal, does it say that your device has been attached to /dev/ttyUSB0?
Also, are you using a direct USB cable or a USB cable with a black converter box along the cable?

[Marcel2103]

Thank you, @pshved this fixes also for me the error with humble. The pull request should get accepted.

[waltejon]

@pshved: Thanks for the hint regarding your fix.

I changed the threading.cpp according to your commit. However, the XSENS is still not recognized (see Figure below).

[waltejon]

@StevenXsens:

When I send dmesg from a terminal (#16 (comment)), I get the following feedback:

[  810.678399] usb 2-2.2: Product: MTi-300 AHRS
[  810.678427] usb 2-2.2: Manufacturer: Xsens
[  810.678428] usb 2-2.2: SerialNumber: ******B6
[  810.706366] usbcore: registered new interface driver usbserial_generic
[  810.706693] usbserial: USB Serial support registered for generic
[  810.708372] usbcore: registered new interface driver xsens_mt
[  810.708379] usbserial: USB Serial support registered for xsens_mt
[  810.708393] xsens_mt 2-2.2:1.1: xsens_mt converter detected
[  810.708888] usb 2-2.2: xsens_mt converter now attached to ttyUSB0

The XSENS MTi-300-2A5G4 is connected using a direct USB cable. There is no converter box along the cable.

[waltejon]

@StevenXsens, @pshved: I also need to say that my Ubuntu 22 machine is a virtual machine (VMware). However, I connected the XSENS to the Ubuntu machine and not my host machine (Windows 11). Since, the device is listed when I command lsusb and dmesg, I assumed that this connection might be valid, although a virtual machine is used.

[Steven-GH]

Hi @waltejon,

Have you rebuilt the xspublic library after making changes to threading.cpp? Best is to force this from the xspublic folder using make -B. After that, run colcon build again.

I have just tried running the driver with an MTi-300 connected over USB, on an Ubuntu 22.04 virtual machine (VirtualBox), and it was able to detect the device. I think I've used the same modifications as you have so far.

[waltejon]

@StevenXsens: In the first attempt, I did not command make -B from the xspublic folder, but I commanded colcon build. However, when I rebuild the library using make -B from that folder and afterwards colcon build, the device is still not found.

jw@wapiti:~/ros2_ws$ ros2 launch bluespace_ai_xsens_mti_driver xsens_mti_node.launch.py
[INFO] [launch]: All log files can be found below /home/jw/.ros/log/2022-11-09-15-05-56-582358-wapiti-8133
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [xsens_mti_node-1]: process started with pid [8134]
[xsens_mti_node-1] RCUTILS_CONSOLE_STDOUT_LINE_BUFFERED is now ignored. Please set RCUTILS_LOGGING_USE_STDOUT and RCUTILS_LOGGING_BUFFERED_STREAM to control the stream and the buffering of log messages.
[xsens_mti_node-1] [INFO] [1668002756.702574283] [xsens_mti_node]: Creating XsControl object...
[xsens_mti_node-1] [INFO] [1668002756.710962182] [xsens_mti_node]: Found baudrate parameter: 115200
[xsens_mti_node-1] [INFO] [1668002756.711399212] [xsens_mti_node]: Found port name parameter: /dev/ttyUSB0
[xsens_mti_node-1] [INFO] [1668002756.711726116] [xsens_mti_node]: Scanning port /dev/ttyUSB0 ...

[waltejon]

@StevenXsens: I would have two questions if I may ask:

• Could the XENS itself be the problem for this driver issue? The device I have (MTi-300-2A5G4) is a bit older. However, it is working fine and with my MT Manager I can access the IMU data. So, I would have assumed that my device would be supported by this driver.

• Do you also use ROS2 Humble? Which branch of this repository did you use? Foxy or Galactic? I tried both, but in both cases the same issue is happening.

[Steven-GH]

Hi @waltejon,

I am also using the MTi-300-2A5G4, so that can't be the issue. You might want to check if your device is running the latest firmware version though (1.8.2). Additionally, clicking the Revert button in MT Manager might help. This will reset the factory defaults of your device.

I'm running ROS2 Humble and using the Foxy branch.

[waltejon]

@StevenXsens: Thank you for the tips I followed. However, this issue is still open.

jw@wapiti:~/ros2_ws$ ros2 launch bluespace_ai_xsens_mti_driver xsens_mti_node.launch.py
[INFO] [launch]: All log files can be found below /home/jw/.ros/log/2022-11-09-16-29-24-243753-wapiti-2933
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [xsens_mti_node-1]: process started with pid [2934]
[xsens_mti_node-1] RCUTILS_CONSOLE_STDOUT_LINE_BUFFERED is now ignored. Please set RCUTILS_LOGGING_USE_STDOUT and RCUTILS_LOGGING_BUFFERED_STREAM to control the stream and the buffering of log messages.
[xsens_mti_node-1] [INFO] [1668007764.460467704] [xsens_mti_node]: Creating XsControl object...
[xsens_mti_node-1] [INFO] [1668007764.474280354] [xsens_mti_node]: Found baudrate parameter: 115200
[xsens_mti_node-1] [INFO] [1668007764.474801375] [xsens_mti_node]: Found port name parameter: /dev/ttyUSB0
[xsens_mti_node-1] [INFO] [1668007764.475062305] [xsens_mti_node]: Scanning port /dev/ttyUSB0 ...

I updated the firmare to the latest version (see Figure below). I also reverted the settings to the factory defaults by using the MT Manager.

[Steven-GH]

Hi @waltejon,

I am sorry but at this point I am a bit at loss about what else the problem can be, mostly because I cannot reproduce it on my side with a very similar setup.
What you can still try is to run the C++ example code that is part of the MT Software Suite on your Ubuntu system. It uses the same xspublic library, so you would need to implement the same changes again in threading.cpp before building the code. But you can run it with sudo and it will exclude the ROS environment, which might give different results. Anyway, the example is called example_mti_receive_data and is located at [MTSDK folder]\examples\mtsdk\xda_public_cpp. See also: https://base.xsens.com/s/article/Introduction-to-the-MT-SDK-programming-examples-for-MTi-devices?language=en_US
If you need help with this, please send us a message at [email protected].

[waltejon]

Problem is now solved. I repeated all the steps again in a new workspace and now it works.

How the problem was solved?

• (Firmware update)
• Pull request #17
• make -B from xspublic and colcon build from ROS2 workspace #16 (comment)

@StevenXsens: Thank you very much for your help and all the tips! 😊

From my side, this issue could be closed.