Troubleshooting¶
No USB Port / No Data¶
Kobuki’s FTDI chip is flashed with a special identifier that allows programs to uniquely identify the device as a kobuki. This in turn allows for udev rules that conveniently establish it’s presence under /dev/kobuki.
Is it just Working?¶
Important checks that you can expect to see if and once it’s working:
Does kobuki appear as USB device?
> lsusb
0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Do you see it in dmesg when you insert the usb cable?
> dmesg
[ 118.984126] usb 3-1: new full-speed USB device number 5 using xhci_hcd
[ 119.139253] usb 3-1: New USB device found, idVendor=0403, idProduct=6001
[ 119.139257] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 119.139259] usb 3-1: Product: iClebo Kobuki
[ 119.139261] usb 3-1: Manufacturer: Yujin Robot
[ 119.139263] usb 3-1: SerialNumber: kobuki_A505QO28
[ 119.150240] usbcore: registered new interface driver usbserial_generic
[ 119.150249] usbserial: USB Serial support registered for generic
[ 119.152383] usbcore: registered new interface driver ftdi_sio
[ 119.152403] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 119.152505] ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
[ 119.152530] usb 3-1: Detected FT232RL
[ 119.152665] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0
and when you remove it?
[ 184.386124] usb 3-1: USB disconnect, device number 5
[ 184.386507] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 184.386547] ftdi_sio 3-1:1.0: device disconnected
Problems & Solutions¶
- No /dev/kobuki?
# copy across udev rules
> sudo cp 60-kobuki.rules /etc/udev/rules.d
> sudo service udev reload
> sudo service udev restart
- Does kobuki stream data?
Check if anything is streaming - even when you don’t have a program explicitly connected, you should see a stream of unusual characters.
> cat /dev/kobuki
If you don’t have any streaming, check that your kernel has the ftdi_sio kernel driver built. Refer to kobuki_core#24 for more discussion.
- Everything seems fine, yet I still can’t get the kobuki driver to communicate with it.
You may not be in the correct group, try the following and logout/login (or reboot):
> sudo addgroup $(USER) dialout
Unique Device ID?¶
Each Kobuki comes with a unique device ID imprinted on the FTDI chip at the factory. This can be retrieved with the kobuki-version-info program that comes as part of the kobuki_core package.
$ kobuki-version-info
Version Info:
Hardware Version: 1.0.4
Firmware Version: 1.2.0
Software Version: 1.1.0
Unique Device ID: 97713968-842422349-1361404194
If you need to engage with the company that you bought the Kobuki from, this is the number to report.
Version Mismatch¶
Your driver may give you a warning when it detects that your firmware’s minor version is behind the latest supported by your driver:
Robot firmware is outdated; we suggest you to upgrade it
(hint: https://kobuki.readthedocs.io/en/devel/firmware.html)
Robot firmware version is 1.0.0, latest version is 1.2.0.
or error if a major version upgrade is required (usually indicative of a Serial Protocol change):
Robot firmware is outdated and needs to be upgraded
(hint: https://kobuki.readthedocs.io/en/devel/firmware.html)
Robot firmware version is 1.0.0, latest version is 1.2.0.
If this happens, then refer to the upgrade instructions in Firmware.
Malformed Payload¶
A malformed payload error occurs when Kobuki receives an unexpected byte or series of bytes in the long packets arriving on the serial connection. A typical error message will look something like:
[ERROR] Kobuki : malformed sub-payload detected. [225][170][E1 AA 55 4D 01 0F ]
[ERROR] Kobuki : malformed sub-payload detected. [42][170][2A AA 55 4D 01 0F ]
[ERROR] Kobuki : malformed sub-payload detected. [94][170][5E AA 55 4D 01 0F ]
[ERROR] Kobuki : malformed sub-payload detected. [63][170][3F AA 55 4D 01 0F C0 E8 00 00 00 ]
This is usually due to one of two causes:
- Old or overly long cables
- An FTDI driver configured with long latency
The first problem is easily diagnosed - simply try replacing cables (to be certain, ensure the cable length is under 2m).
The second problem is also easily diagnosed:
# Replace ttyUSB0 with ttyUSB# if it's not on the first port
$ cat /sys/bus/usb-serial/devices/ttyUSB0/tty/ttyUSB0/device/latency_timer
# If you see 16, your udev rule has not configured a non-default value (too slow!)
16
This was caused by a change in the kernel post the kobuki release which switched the default latency from 1ms to 16ms. As a result, the throughput is sub-optimal for Kobuki’s use case. See kobuki#382 for more details (only if you’re curious!).
The udev rules for Kobuki have already been updated to re-configure this latency for 1ms. If you’re seeing 16ms, it means you haven’t yet migrated to using the new udev rules.
Simply grab a copy of the new udev rule 60-kobuki.rules and:
# copy across udev rules
> sudo cp 60-kobuki.rules /etc/udev/rules.d
> sudo service udev reload
> sudo service udev restart
The key change is in the addition of a ATTR{device/latency_timer}=”1” field in the rule.