Jetson TX1 does not detect rplidar A2

Hi everyone,

I am a newbie in Jetson Kit. I have bought a Jetson TX1 Kit. Since the memory of Jetson TX1 is low, so I have bought a SSD and connected with Jetson TX1 by SATA, and successfully configure the Kernel, synchronized SSD. Then, I installed ROS, ZED camera package, and rplidar ros package. Only one problem I met that Jetson TX1 could not detect rplidar. Can you please give me some ideas ?. I have read many information on web, however, I still could not find out the way to fix it.

Thanks in advance,


Hi there, the rpLIDAR is probably not being detected because you need to build the kernel driver module for the CP210x serial converter that it uses - see this post:

JetsonHacks has a tutorial for building kernel modules:

Thank you dusty_nv,

I have installed CP210x before, and I also tried with JetsonHacks tutorials. However, I still could not see the ttyUSB for rplidar. I just wonder whether the version of Kernel and version of Jetpack should be matched. I installed Jetpack 3.2 for Jetson TX1. And, I installed the Kernel 4.4.38 to reconfigure the Kernel for Jetson TX1 ( after I command: " uname -r " on Terminal, “4.4.38.jetson-v0.1” appeared " ). I have checked that 4.4.38 Kernel support for Jetpack 3.2

Hope to hear from you soon,

If “uname -r” changed, then the base Image file was changed. All that would have been needed is to add a kernel module, and the base kernel could be left alone. If you have rebuilt the kernel, then you must also rebuild all of the modules (which are now searched for in “/lib/modules/4.4.38.jetson-v0.1” since this is the new “uname -r”).

Really a kernel is three things:

  1. The base kernel version, e.g., "4.4.38".
  2. The configuration.
  3. The modules found at "/lib/modules/$(uname -r)/".

If CONFIG_LOCALVERSION was “.jetson-v0.1”, then tradition would be to assume the base kernel was different in configuration, but not in source code, versus other builds of the same source. “4.4.38” is the same kernel. “.jetson-v0.1” is someone’s idea of a naming note to indicate what configuration was used, but you don’t really know if it is truly different without comparing the original “/proc/config.gz” to the new “/proc/config.gz”. Regardless of whether or not it differs, the old kernel would be looking for its modules in a different place than the new kernel. If the new module is not in the new location, then it won’t be found.

Do you have the full content of “/lib/modules/4.4.38-tegra/” duplicated in “/lib/modules/4.4.38.jetson-v0.1”? Is the new CP210x module in this new location?

Thanks linuxdev,

I have checked “/lib/modules/4.4.38-tegra/” and “/lib/modules/4.4.38.jetson-v0.1”, the content of “4.4.38-tegra” still lack some files in comparison with “4.4.38.jetson-v0.1”. You mean that I must copy whole content of “4.4.38-tegra” to “4.4.38.jetson-v0.1” ?

In theory “4.4.38.jetson-v0.1” is a superset of “4.4.38-tegra”. “4.4.38.jetson-v0.1” should contain everything in “4.4.38-tegra”, plus whatever new driver you added. Not everything gets added in module format though, so anything added as a non-module will not have a module. When you add by non-module addition (or remove non-module features) you are advised to rebuild all modules from source (not always necessary, but you may not know until testing and it is easier to just build all of the modules when non-module features change).

How did you determine your config when building the new kernel? Knowing how that differs is key to knowing what has changed.

Thank you so much linuxdev,

I solved the problem, however, I do not know how it works.

I installed again the Kernel and set the name is “4.4.38-tegra” but not “4.4.38.jetson-v0.1”.I have seen in /lib/modules/ has “4.4.38” and “4.4.38-tegra”. It seems that 4.4.38-tegra issuperset of 4.4.38. I installed CP210x module as normal as before. Just one different thing is that I set name “4.4.38-tegra” but not “4.4.38.jetson-v0.1”

Can you please explain the reason ?

Thank you so much,

The “4.4.38” is from the source code version. Anything after that is just a human giving a tag to distinguish some sort of configuration…and to determine where modules are searched for.

When you changed the kernel, you changed what “uname -r” responds as due to the naming tag…not due to source, and not due to configuration…although naming is traditionally changed if configuration is changed (“tradition” isn’t a technical requirement for building a kernel). When you change “uname -r”, you change where modules are searched for. If and only if the “.jetson-v0.1” was an exact match in configuration to the one NVIDIA supplies as “-tegra” would they be truly the same (because then both the source code version and the configurations would be duplicates).

If you look at “/proc/config.gz” while a kernel is running, then it will tell you what the current build configuration is. This isn’t a real file, it is the kernel pretending to be a file and instead showing how it is configured. You would need to run each kernel in turn, save a copy of its “/proc/config.gz”, and then compare them to know how they differ.

Most likely there is a different module in the “/lib/modules/4.4.38-tegra/” versus the “/lib/modules/4.4.38.jetson-v0.1/” directory trees. You might explore those directory trees and find out which modules are in one, but not in the other.

Hi linuxdev,

Thanks so much for your explain