I have written two tutorials how to get Pixhawk's serial connected to UDP or TCP on my blog: http://matilai.net/blog/pixhawks-serial-to-tcp/ and http://matilai.net/blog/pixhawks-serial-to-udp/.

I hope those guides will help someone in this group.

Note that those commands are executed on a linux single board computer connected to a Pixhawk and not directly on a Pixhawk.

The program called socat is a common tool on linux and it's written in C. For these reasons I prefer it over any Python or similar creation.

Views: 4411

Replies to This Discussion

Thanks - this is a great guide.  I've been experimenting with Odroid C1 and Pixhawk. 

Thanks for posting this.  I'm interested in your blog post "Pixhawk's serial device named automatically"... does this technique dynamically re-assign the Pixhawk to /dev/pixhawk if the pixhawk crashes and comes back as a different serial device name in linux?  For instance, if the pixhawk is addressed as /dev/ttyACM0 and it crashes, the pixhawk may come back up as /dev/ttyACM1 (and so on).  Would the technique detailed in your blog post then re-map /dev/ttyACM1 to /dev/pixhawk? 

Yes, exactly.

Please clarify when this technique "Pixhawk's serial device named automatically"... is necessary?

If one of the PixHawk telemetry ports is connected to the companion computer with a USB to serial adapter (e.g. FTDI)?

If the USB micro usb interface of the PixHawk is directly connected to the USB Host of the companion computer?

If one of the PixHawk telemetry ports is connected to the UART interface of the companion computer? Should always be /dev/ttyAMA0 ?

What do you mean with "if the pixhawk crashes"? This should never happen? Otherwise drone will crash also without any control?

If usb is used on a host computer, then the serial is renamed each time it is plugged. If you're using direct uart connections, then this is not needed.

For example, if you plug a pixhawk to your pc it's always at /dev/pixhawk.

Good information.  I've been using a program called ser2net for things like this.  The main trunk of the project doesn't do UDP and the one patch to do UDP is unreliable.  Can you elaborate on the UDP parameters you're using?  You've got two ports going there.  Why is that?

They are all documented here: http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_UDP_RECVFROM

QGroundControl requires one read port and one write port.

UDP is like fire and forget system.

I've encountered situations where, when re-opening a serial connection to the Pixhawk in Linux using mavutil, the Pixhawk will simply stop providing data and the mavutil function recv_msg() will endlessly return "None".  It seems like the Pixhawk's serial interface has crashed and, yes, I'm using the latest firmware (ArduRover 2.49).  The only way I've found to resolve the issue is to do a hard reboot of the pixhawk by sticking a paperclip into the hardware reset hole.  I wrote code to reset the linux USB bus/device that the Pixhawk is using (mimic'ing the user unplugging/re-plugging the device), but nothing seems able to recover the pixhawk serial device from this state.  Have you ever encountered this issue?  I've been running my Pixhawk serial device at high baud rate (460800), but I've seen the same behavior at 115200.  I've also noticed that mavutil's wrapper function to open a serial device defaults all hardware and software Flow Control to "OFF", but not sure if that could be related to this issue.  Any thoughts?

here's an excerpt from dmesg showing the failed reset of the Pixhawk:

    [ 2900.925332] usb 1-1.4: reset full-speed USB device number 12 using dwc_otg

    [ 2901.031821] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device

    [ 3054.045151] cdc_acm 1-1.4:1.0: failed to set dtr/rts

another:

    [ 3282.004971] usb 1-1.4: reset full-speed USB device number 12 using dwc_otg

    [ 3297.084870] usb 1-1.4: device descriptor read/64, error -110

I assume you are using an on board computer. I'd recommend not using USB connection, but connecting using a real serial port.

For a USB connection it doesn't matter what you set baud or flow control to, it's ignored as it's a CDC virtual com port, not a real serial port.

Wilhelm your work looks very interesting, but both links to your blog seem to timeout, do you have another way for me to access the serial to UDP connection guide?

Here are the commands for serial to tcp/udp
socat /dev/pixhawk,lockfile=pixhawk.lock tcp-listen:5760,fork
socat /dev/pixhawk,lockfile=pixhawk.lock,b115200 udp-recvfrom:14555,fork,sourceport=14550

@Wilhelm - this is great.  This could be really useful for connecting offboard control to a sim.  Any chance you can re-post the contents of your blog here?  or did all it have were the commands? An explanation of what the above commands do would be awesome! (to avoid trying to parse it from the link you gave above).

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service