Having trouble at least with sending data from a Jetson TK1 dev board to a Pixhawk flight controller over a USB serial connection (unclear if there is trouble receiving since the Pixhawk won’t send anything unless commanded to do so).
The Pixhawk shows up as /dev/ttyACM0 with the alias /dev/serial/by-idusb-3D_Robotics_PX4_FMU_v2.x_0-if00
Works ONLY when I use the command “cat /dev/ttyACM0” quickly after plugging in the device. Then I can use, e.g., “echo ‘whatever’ > /dev/ttyACM0” in another terminal and get back data in the terminal running the cat command.
If I wait too long after plugging the device in or kill the cat command and try it again, I get nothing when trying to send commands out using echo as above. My knowledge of Linux’s inner working is somewhat shallow, that it only works when it does because I get to the device before some service kicks in and screws things up. On the Pixhawk site it’s mentioned that the modemmanager package can cause issues but I’ve already purged it from the system and that did not help.
Output from lsusb (Pixhawk is first device):
Bus 002 Device 006: ID 26ac:0011
Bus 002 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Relevant dmesg info (looks the same as it does on when connected to a desktop and working properly):
[ 809.886035] usb 2-1.2: new full-speed USB device number 5 using tegra-ehci
[ 809.904840] usb 2-1.2: string descriptor 0 malformed (err = 2), defaulting to 0x0409
[ 809.915489] usb 2-1.2: New USB device found, idVendor=26ac, idProduct=0011
[ 809.915542] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 809.915586] usb 2-1.2: Product: PX4 BL FMU v2.x
[ 809.915625] usb 2-1.2: Manufacturer: 3D Robotics
[ 809.915662] usb 2-1.2: SerialNumber: 0
[ 809.929989] cdc_acm 2-1.2:1.0: This device cannot do calls on its own. It is not a modem.
[ 809.941960] cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device
[ 814.813519] usb 2-1.2: USB disconnect, device number 5
[ 816.285030] usb 2-1.2: new full-speed USB device number 6 using tegra-ehci
[ 816.483316] usb 2-1.2: New USB device found, idVendor=26ac, idProduct=0011
[ 816.483366] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 816.483406] usb 2-1.2: Product: PX4 FMU v2.x
[ 816.483443] usb 2-1.2: Manufacturer: 3D Robotics
[ 816.483476] usb 2-1.2: SerialNumber: 0
[ 816.497378] cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device
Some USB devices & cameras have problems on Jetson TK1 due to automatic suspending of inactive USB ports to save power. So you might need to disable USB auto-suspend mode. This will disable it temporarily until you reboot:
To execute commands automatically on every bootup, you can put your commands into the “/etc/rc.local” bootup script. For example, run this on your board:
sudo gedit /etc/rc.local
Then add this near the bottom of the file but before the “exit” line:
Disable USB auto-suspend, since it disconnects some devices such as webcams on Jetson TK1.
echo -1 > /sys/module/usbcore/parameters/autosuspend
Save the file , then reboot the device:
You may also find some debugging help with “evtest”. Looking at files under /dev/input you should be able to see events generated, e.g., a constant stream if looking at a mouse while it moves. This would allow you to narrow it between events stopping and user software ignoring.
Disabling the USB auto-suspend mode worked. Doing ‘cat /dev/ttyACM0’ now floods the serial output with garbage for some reason, but I’m able to use screen to interface with the shell on the Pixhawk device without any problem.
It looks like it uses the generic USB communications interface, so I doubt it requires any special drivers. Still, that modem class for USB may not be configured on this Jetson…I’m not where I could look to see which driver it is. Even so, often the device special file will need to be renamed via a udev rule to get the name which is expected…which means the ttyACM might be there, but use a different name (a case where the driver is installed, but until the udev rule goes in, it won’t be found as expected). If you monitor “dmesg” (on Ubuntu 16.04 and up try “dmesg --follow”) as you insert or remove the USB connector it might tell you about the tty…take a look at that and see if it mentions drivers or tty.