Using pymavlink prevents mavros from running

I’m writing some Python code to communicate with my Pixhawk2, running ArduRover, and am running into a problem. Here’s my simple script, where I use pymavlink to listen for the APM hearbeat:

#!/usr/bin/env python

from pymavlink import mavutil

master = mavutil.mavlink_connection("/dev/ttyTHS2", baud=921600)

print "Waiting for heartbeat.."
hb = master.wait_heartbeat()
print " it"


This code works (as far as I can tell). It detects the heartbeat, and exits cleanly. However, if I use it, I cannot thereafter run mavros. If I do, it (the mavros process) exits with the following error:

[ INFO] [1522178284.642819047]: serial0: device: /dev/ttyTHS2 @ 921600 bps
[ WARN] [1522178284.658598556]: FCU protocol: v2.0
[ INFO] [1522178284.658695100]: GCS URL: udp://@
[ERROR] [1522178284.658787388]: serial0: receive: End of file
[ INFO] [1522178284.659888124]: udp1: Bind address:
[ INFO] [1522178284.660145915]: udp1: Remote address:
terminate called after throwing an instance of 'std::system_error'
  what():  Resource deadlock avoided

This appears to me like the OS thinks the serial connection is still ‘owned’ by some object created in my Python script but the script has exited and all resources should be released. What’s going on here? How do I fix this?

which version of mavros are you using ?
on a just booted system does launching mavros works directly ?

I’ve built mavros from source; it looks like I have a snaspshot of the code from December 14, 2017. Yes, if I reboot the system after this error (or if I never run my script) mavros works perfectly.

try with the lastest version or master. Normally, I have fix this problem (It is a problem from boost asio)

1 Like

Sounds like maybe another tegra kernel bug, or pymavlink is holding onto the port. Does lsof show anything?
sudo lsof |grep ttyTHS2

@khancyr shoots and scores. Fetching the latest mavros source code and building it fixed my problem. No idea what the real issue was, though.

Try sudo fuser -v /dev/ttyTHS2

it was a problem in boost asio that mavros use… it didn’t configure the serial port correctly and then think it receive EOL when trying to open the port when it was just noise. But it should be fix either by mavros and next boost asio release