Hi,
I loadad ros and rviz on jetson tx1. I saw that they run on jetson.
However
after I plug in rplidar to Jetson tx1,
I check the authority of rplidar’s serial-port by
ls -l /dev |grep ttyUSB
I dont see a thing on terminal. there is no output.
Could you please help me?
A ttyUSB# (where “#” is 0 through “n”) would be the naming for a serial UART. If rplidar has a serial port and you use a separate serial UART then ttyUSB0 would be the correct name for the first serial UART. If rplidar has its own dedicated USB connector (not serial port), then the device special file name would be completely different and not even start with “ttyUSB”.
Are you using a serial USB UART cable where the rplidar has a standard serial port? Or does the rplidar have a USB connector directly on it?
Also note that serial UART cables with an FTDI chipset are pretty much universally recognized, but a serial UART cable with a different chipset might require a driver addition. lsusb should give some information about any USB device plugged in. An example for one FTDI serial UART is:
Bus 005 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
i am using usb adaptor. it converts uart serial interface to usb.
That is a custom connector on the rplidar, so a 6-pin serial UART can’t be used directly on it. A 3-pin version with GND, RX, and TX can be used if setting flow control to “software” (RTS/CTS is not supported there). I do not know which voltage level is supported on the RX/TX, but it is likely to be something like 3.3V TTL…you’ll need to verify this matches the serial UART you are using since some are 1.8V, some are 3.3V, and others are 12V (an incorrect voltage match could damage the rplidar or the USB serial UART).
On the Jetson side where the USB serial UART has the USB side connected does “lsusb” show which entry is the serial UART? The missing ttyUSB# may be an indicator that the cable is not visible or that the cable uses a non-FTDI chipset. Even if the chipset does not currently have a driver loaded lsusb should at least see the cable exists.
Thanks for reply,
My version is A1.
I re-flashed by JetPack 2.3.1 for L4T [L4T r24.2.1] my tx1.
I will try the installation in Build TX1 Kernel and Modules - NVIDIA Jetson TX1 - JetsonHacks.
I cant excatly understant your sentence. I will direclty install the sh files in the link your said. Is it correct?
"Having naturally selected the additional module (having set in a configuration opposite to it “.” a point - it is important!!! (not a tick!!)). "
In addtion I would like to ask whether or not should I install the files in the below link also in addition to ones in the above link?
Alas, I badly write in English :(. If it is unclear that I tried to explain, then attentively you watch video to the offered link (Build Kernel - NVIDIA Jetson TX1 - YouTube) from 2:58 till 2:59, you need to make also only for a line with USB CP210X family of UART…
Also pay attention that in the files offered *.sh links to specific versions of kernel are specified, you need or to use the same kernel version on jetson tx1, or to comment out and change lines of loading of kernel to the version which is used at you on jetson TX1. On your question on FTDI - I didn’t change setup on it.
English is good. I should have previously read and watched the link you said before asking question.
Many thanks for detailed answer. I think that it will work now.
Hi.
I have same problems with you guys and happy to find this article.
I want to follow this url to rebuild kernel.
[url]http://www.jetsonhacks.com/2017/08/07/build-kernel-ttyacm-module-nvidia-jetson-tx1/[/url]
However, my jetson TX1 has only less than 1GB storage available and they says it took 3GB to re-build carnel… Is my understanding right?
I am very new to this issue and afraid to mess up doing with wrong way.
Most people would build a TX1 kernel via cross-compile. The Documentation download of each L4T version mentions tools to do this with.
You don’t need to rebuild the entire kernel to support rpLIDAR device, you simply need to build the CP210x kernel module (serial converter driver).
For the CP210x driver you can enable it via the kernel configuration (make menuconfig). Device Drivers > USB Support > USB Serial Converter Support > USB CP210x family of UART Bridge Controllers. (For more information see this doc from CP210x vendor)
Thank you for your reply. I am still not sure how to do that compilation，but I found a good explanation about this issue.
https://gist.github.com/chutsu/9bb6abe6f61924c88521adec859c7006
I will try to follow this guy.
I’m assuming L4T R28.1, which is here:
[url]https://developer.nvidia.com/embedded/linux-tegra[/url]
Be sure to download the Documentation, and check for kernel customization. There may be some differences between this and earlier releases for kernel compile (the URL above has a lot of good information, but there may be subtle differences with R28.1 and newer).
I am trying to get the A1 lidar working on a tx2
I successfully modded the kernel to add the cp210x driver and the device shows up on ttyUSB0.
[ 4517.886970] usb 1-2.2: new full-speed USB device number 11 using xhci-tegra
[ 4517.982180] usb 1-2.2: New USB device found, idVendor=10c4, idProduct=ea60
[ 4517.989232] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4517.996875] usb 1-2.2: Product: CP2102 USB to UART Bridge Controller
[ 4518.003492] usb 1-2.2: Manufacturer: Silicon Labs
[ 4518.008372] usb 1-2.2: SerialNumber: 0001
[ 4518.016242] cp210x 1-2.2:1.0: cp210x converter detected
[ 4518.025920] usb 1-2.2: cp210x converter now attached to ttyUSB0
None of the programs I try to use the device with work though.
Rplidar-ros node dies quietly when I run it.
The python rplidar gives me the following error
Traceback (most recent call last):
File “test.py”, line 4, in
info = lidar.get_info()
File “/usr/local/lib/python2.7/dist-packages/rplidar.py”, line 211, in get_info
dsize, is_single, dtype = self._read_descriptor()
File “/usr/local/lib/python2.7/dist-packages/rplidar.py”, line 187, in _read_descriptor
raise RPLidarException(‘Descriptor length mismatch’)
rplidar.RPLidarException: Descriptor length mismatch
…
Everything I have tried works with my lidar on a normal x86 machine and the dmesg looks identical.
Has anyone experienced this?
Thanks,
Nathan