xavier cannot recognize xsens (Solved)

as title… xavier does not regard xsens imu as an usb device.

Hi xiy,
Do you have TX1 or TX2 to check if it can be detected? for cross-platform comparison.

I think it cannot be detected too, because I see the same problem on tx2 (https://devtalk.nvidia.com/default/topic/1006148/jetson-tx2/tx2-and-xsens-imu-through-micro-usb-adapter/). The problem on tx2 was solved by this repo(https://github.com/jetsonhacks/buildJetsonTX2Kernel), However, I don’t find solution for xavier so far.

What do you see from:

zcat /proc/config.gz | grep XSENS

Likely you just have to add the driver (if you build a module it is a simple file copy).

If it is USB do you see it in “lsusb”? USB is just a pipe, it isn’t the driver actually running the device.

Hi linuxdev,
The output is


I can see the Xsens IMU by ‘lsusb’:

Bus 001 Device 004: ID 2639:0017 Xsens MTi-G 7xx GNSS/INS

However, xavier doesn’t mount it as a serial port, because I see nothing by “ls /dev/ttyUSB*”

USB is not responsible for the “/dev” entry…the driver which USB hands it over to is responsible for that creation. Seeing it in “lsusb” simply implies the USB system has announced the device’s presence. Now the device needs a driver to take ownership of hardware which the USB pipe talks to. Until you put the module in for the hardware via CONFIG_USB_SERIAL_XSENS_MT (and perhaps other dependencies…the config editor, e.g., “make nconfig”, would figure that out though) no driver exists to take ownership. One of my favorite sayings applies: “The lights are on, but nobody is home”.

Yes, I see. We has tried to compile the module(https://github.com/xsens/xsens_mt), but failed, we will continue working on it. Anyway, thanks for your help.

Xavier kernel module build instructions are similar to the TX1 and TX2 steps, and adding the module, if you started with the original config.gz and same kernel source, would be a simple file copy. Cross compile instructions are given with the official documentation.

Some notes on native compile of a module are given here:

Note that you could run a config editor, e.g., my favorite these days is “nconfig”, just prior to the “modules_prepare” step. You would probably need to add package “libncurses5-dev”:

sudo apt-get install libncurses5-dev

…then prior to modules_prepare:

make nconfig

Cross compile instructions would be similar. If you have an error from a compile, then list the steps and someone can probably point out what needs to change.

i have same problem.
could you give me how to solving this problem ?

Keep in mind that I do not have the actual device to test. However, from what you see above you will find that there are two requirements.

The first requirement is that the kernel feature supporting this must be enabled (possibly requiring a kernel module being added, or perhaps an updated kernel if module format is not supported). See #4.

If the #4 post shows you have not enabled the kernel feature, then we can explain building this. It isn’t hard, but some details sometimes frustrate new users.

Once the kernel feature is in place the device special file (in “/dev”) should show up, but you may still need software to work with it.

The second requirement is that there may be user space software to install, and I do not know what software is used with this. This is where things get difficult since the user space software (ordinary programs and libraries) are often provided for the desktop PC architecture only, and the Jetson is arm64/aarch64/ARMv8-a, and not desktop PC architecture. Binary files for a PC won’t work even if they are for Linux. Either the files have to be for the right architecture, or else they have to be built from source code (and often someone else must create third party software since sometimes companies do not release source code format).

Can anyone here suggest what software is required beyond the kernel feature being enabled?


I am also facing the same problem. Can you elaborate on how to build the kernel module?

I am using ROS wrapper provided by XSens and I could compile the code, so I think may be it works for arm64/aarch64/ARMv8-a, can’t say for sure. But the device is not recognised in /dev/ttyUSB*

If you run “dmesg --follow”, and then plug in the USB device, what shows up upon plug in? This should show what USB is broadcasting, and in turn could help figure out what driver should (or does) take ownership. Before compiling a kernel module it would be good to see for sure what the device identifies itself as (and if there is a serial port, then this will list separately from the other parts of the device).

[75137.346179] usb 1-4: new full-speed USB device number 11 using tegra-xusb
[75137.368603] usb 1-4: New USB device found, idVendor=2639, idProduct=0003
[75137.368617] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[75137.368625] usb 1-4: Product: MTi-30 AHRS
[75137.368631] usb 1-4: Manufacturer: Xsens
[75137.368638] usb 1-4: SerialNumber: 036823BD

This is what I get after I run “dmesg --follow” and connect the USB device.

So we know USB is working as it should, and that after adding the driver (perhaps in the form of a module which is somewhat easy since it is only a file copy), then it should work (I don’t know if there is other user space software required, but the device special file should appear when the driver is present).

There are instructions with official documentation on building kernels, and in this case just a kernel module. Would you be compiling natively on the Xavier, or are you cross compiling? If cross compiling, are you using an Ubuntu 18.04 host? There may be some minor differences depending on release, so what is the output of “uname -r”?

“uname -r” gives out 4.9.140-tegra. I am compiling natively on Xavier.

I have followed steps from https://base.xsens.com/hc/en-us/community/posts/211806629-MTi-300-not-working-on-NVIDIA-TX1-platform-Kernel-3-10-96- but it did not work. I was also going through the L4T documentation on kernel customization, but could not completely understand how to proceed. Is there any specific way to add the driver kernel module?

That particular URL is for a much older kernel on a TX1. Some kernel compile information is available in a number of places and there are a number of ways to do this. Compiling natively on the Xavier does simply things somewhat. In what follows keep in mind that you want to match the configuration of the running system, and that also means your “.config” feature “CONFIG_LOCALVERSION” should be:


Following this you would use some sort of config editor, e.g., “make nconfig” to find the “XSENS” symbol/feature, and enable with the “m” key (for module build…versus “y” key which would replace the entire kernel). Information already shown above should be useful, but here is some more (different feature versus XSENS, but still the ideas/procedures are correct):
(uses the directly downloaded “kernel_src.tar.bz2”, but anything with the right source will work)

Here is a more detailed procedure, and uses the “source_sync.sh” script:
(you’ll need to know the tag name for your particular release, which depends on “head -n 1 /etc/nv_tegra_release”…you haven’t mentioned which release you have)

Any menu editor, or direct edit of “.config” should take place after you have the original/current config in place. The “tegra_defconfig” is usually the same thing, but if you follow the information on using “/proc/config.gz”, then this is directly extracting the current configuration and will be correct even if you’ve modified the kernel in the past and have a non-default kernel configuration.

Note that in this last example it does build the kernel itself, the file “Image”, but this doesn’t mean you need to install it. I recommend building “Image” prior to building modules simply as a sanity check to be sure the config and source are correct. When finished there will be “.ko” file somewhere in the source for the XSENS module, and this will get copied into the Jetson. Because the XSENS is in kernel source in “drivers/usb/serial/”, and because the “uname -r” is “4.9.140-tegra”, the implication is that the file copy goes to:

/lib/modules/$(uname -r)/kernel/drivers/usb/serial/
# Which works out to be:

Then you’d want to run “sudo depmod -a” and reboot (technically you may not need to reboot, but I advise doing so).

Hi, apologies for the late reply. I was busy with some other things.

I could finally solve the issue. I have already copied the xsens_mt.ko file to /lib/modules/$(uname -r)/kernel/drivers/usb/serial/ earlier.

The thing that was missing was to run “sudo depmod -a”. I could finally detect the Xsens device on /dev/ttyUSB*

Thanks for the help.

I finally solve problem!