Serial to UDP or TCP

Posted by Wilhelm Matilainen on March 25, 2015 at 12:11pm

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.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –
Follow

Replies

  • Strike Eagle III September 28, 2016 at 6:22pm

    @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).

  • Wilhelm Matilainen February 2, 2016 at 10:31pm
    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
  • deadhurricane November 3, 2015 at 2:00pm

    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?

  • Nikola Rabchevsky March 26, 2015 at 10:16am

    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?

  • Diamond K. March 25, 2015 at 2:11pm

    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? 

    • Christian > Diamond K. March 25, 2015 at 4:09pm

      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?

    • Wilhelm Matilainen > Christian March 25, 2015 at 5:31pm
      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.
    • Diamond K. > Wilhelm Matilainen April 3, 2015 at 12:32pm

      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

    • Developer
      Bill Bonney > Diamond K. April 3, 2015 at 8:56pm

      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.

This reply was deleted.