px4 network

[aiegoo]

Running Simulation on a Remote Server

It is possible to run the simulator on one computer, and access it from another computer on the same network (or on another network with appropriate routing). This might be useful, for example, if you want to test a drone application running on real companion computer hardware running against a simulated vehicle.

This does not work "out of the box" because PX4 does not route packets to external interfaces by default (in order to avoid spamming the network and different simulations interfering with each other). Instead it routes traffic internally - to "localhost".

There are a number of ways to make the UDP packets available on external interfaces, as outlined below.

Enable MAV_BROADCAST

Enable MAV_BROADCAST to broadcast heartbeats on the local network.

A remote computer can then connect to the simulator by listening to the appropriate port (i.e. 14550 for QGroundControl).

Use MAVLink Router

The mavlink-router can be used to route packets from localhost to an external interface.

To route packets between SITL running on one computer (sending MAVLink traffic to localhost on UDP port 14550), and QGC running on another computer (e.g. at address 10.73.41.30) you could:

• Start mavlink-router with the following command:

  mavlink-routerd -e 10.73.41.30:14550 127.0.0.1:14550

• Use a mavlink-router conf file.

  [UdpEndpoint QGC]
  Mode = Normal
  Address = 10.73.41.30
  Port = 14550
  
  [UdpEndpoint SIM]
  Mode = Eavesdropping
  Address = 127.0.0.1
  Port = 14550

Note More information about mavlink-router configuration can be found here.

Modify Configuration for External Broadcasting

The mavlink module routes to localhost by default, but you can specify an external IP address to broadcast to using its -t option.

This should be done in various configuration files where mavlink start is called. For example: /ROMFS/px4fmu_common/init.d-posix/rcS.

SSH Tunneling

SSH tunneling is a flexible option because the simulation computer and the system using it need not be on the same network.

Note You might similarly use VPN to provide a tunnel to an external interface (on the same network or another network).

One way to create the tunnel is to use SSH tunneling options. The tunnel itself can be created by running the following command on localhost, where remote.local is the name of a remote computer:

ssh -C -fR 14551:localhost:14551 remote.local

The UDP packets need to be translated to TCP packets so they can be routed over SSH. The netcat utility can be used on both sides of the tunnel - first to convert packets from UDP to TCP, and then back to UDP at the other end.

Tip QGC must be running before executing netcat.

On the QGroundControl computer, UDP packet translation may be implemented by running following commands:

mkfifo /tmp/tcp2udp
netcat -lvp 14551 < /tmp/tcp2udp | netcat -u localhost 14550 > /tmp/tcp2udp

On the simulator side of the SSH tunnel, the command is:

mkfifo /tmp/udp2tcp
netcat -lvup 14550 < /tmp/udp2tcp | netcat localhost 14551 > /tmp/udp2tcp

The port number 14550 is valid for connecting to QGroundControl or another GCS, but should be adjusted for other endpoints (e.g. developer APIs etc.).

The tunnel may in theory run indefinitely, but netcat connections may need to be restarted if there is a problem.

The QGC_remote_connect.bash script can be run on the QGC computer to automatically setup/run the above instructions. The simulation must already be running on the remote server, and you must be able to SSH into that server.## Running Simulation on a Remote Server

It is possible to run the simulator on one computer, and access it from another computer on the same network (or on another network with appropriate routing). This might be useful, for example, if you want to test a drone application running on real companion computer hardware running against a simulated vehicle.

This does not work "out of the box" because PX4 does not route packets to external interfaces by default (in order to avoid spamming the network and different simulations interfering with each other). Instead it routes traffic internally - to "localhost".

There are a number of ways to make the UDP packets available on external interfaces, as outlined below.

Enable MAV_BROADCAST

Enable MAV_BROADCAST to broadcast heartbeats on the local network.

A remote computer can then connect to the simulator by listening to the appropriate port (i.e. 14550 for QGroundControl).

Use MAVLink Router

The mavlink-router can be used to route packets from localhost to an external interface.

To route packets between SITL running on one computer (sending MAVLink traffic to localhost on UDP port 14550), and QGC running on another computer (e.g. at address 10.73.41.30) you could:

• Start mavlink-router with the following command:

  mavlink-routerd -e 10.73.41.30:14550 127.0.0.1:14550

• Use a mavlink-router conf file.

  [UdpEndpoint QGC]
  Mode = Normal
  Address = 10.73.41.30
  Port = 14550
  
  [UdpEndpoint SIM]
  Mode = Eavesdropping
  Address = 127.0.0.1
  Port = 14550

Note More information about mavlink-router configuration can be found here.

Modify Configuration for External Broadcasting

The mavlink module routes to localhost by default, but you can specify an external IP address to broadcast to using its -t option.

This should be done in various configuration files where mavlink start is called. For example: /ROMFS/px4fmu_common/init.d-posix/rcS.

SSH Tunneling

SSH tunneling is a flexible option because the simulation computer and the system using it need not be on the same network.

Note You might similarly use VPN to provide a tunnel to an external interface (on the same network or another network).

One way to create the tunnel is to use SSH tunneling options. The tunnel itself can be created by running the following command on localhost, where remote.local is the name of a remote computer:

ssh -C -fR 14551:localhost:14551 remote.local

The UDP packets need to be translated to TCP packets so they can be routed over SSH. The netcat utility can be used on both sides of the tunnel - first to convert packets from UDP to TCP, and then back to UDP at the other end.

Tip QGC must be running before executing netcat.

On the QGroundControl computer, UDP packet translation may be implemented by running following commands:

mkfifo /tmp/tcp2udp
netcat -lvp 14551 < /tmp/tcp2udp | netcat -u localhost 14550 > /tmp/tcp2udp

On the simulator side of the SSH tunnel, the command is:

mkfifo /tmp/udp2tcp
netcat -lvup 14550 < /tmp/udp2tcp | netcat localhost 14551 > /tmp/udp2tcp

The port number 14550 is valid for connecting to QGroundControl or another GCS, but should be adjusted for other endpoints (e.g. developer APIs etc.).

The tunnel may in theory run indefinitely, but netcat connections may need to be restarted if there is a problem.

The QGC_remote_connect.bash script can be run on the QGC computer to automatically setup/run the above instructions. The simulation must already be running on the remote server, and you must be able to SSH into that server.

[mbergotto]

let's start one by one :-) First of all, to enable MAV_BROADCAST, it is explained here: https://discuss.px4.io/t/mav-broadcast-where-is-it/19033

Regarding mavlink router, which I think is needed, I can help setting it up and configuring.

[aiegoo]

I got the same error as in the link above, I can't find the same parameter settings. MAV_BROADCAST

[aiegoo]

https://github.com/mavlink/mavros/tree/master/mavros#installation

the above link shows how to setup netowrks for local connection and presumably over public ip with port binding.... I am sure it's similar to port forwarding.

[aiegoo]

I have attached here. the error log from the raspi console after I ran the script

from tcpdump 14:43:01.106769 IP (tos 0x0, ttl 57, id 17525, offset 0, flags [DF], proto TCP (6), length 369) 175.201.138.9.http > tonylee.50976: Flags [P.], cksum 0x5be9 (correct), seq 1903:2220, ack 2570, win 501, options [nop,nop,TS val 403744221 ecr 874710899], length 317: HTTP, length: 317 HTTP/1.1 200 Server: nginx/1.18.0 (Ubuntu) Date: Thu, 10 Mar 2022 05:43:01 GMT Content-Type: text/plain;charset=UTF-8 Content-Length: 147 Connection: keep-alive

[{"id":"1","lattitude":37.6625114,"longitude":126.7641919,"speed":0.0,"alt":-0.028999999165534973,"battery":12.586999893188477,"state":"DISARMED"}][!http]

14:43:01.106789 IP (tos 0x0, ttl 64, id 3349, offset 0, flags [DF], proto TCP (6), length 52) tonylee.50976 > 175.201.138.9.http: Flags [.], cksum 0xe737 (incorrect -> 0xcc81), seq 2570, ack 2220, win 501, options [nop,nop,TS val 874710904 ecr 403744221], length 0 14:43:01.137657 IP (tos 0x0, ttl 64, id 25808, offset 0, flags [DF], proto TCP (6), length 73) 172.30.1.35.40786 > tonylee.5760: Flags [P.], cksum 0x27f2 (correct), seq 22123:22144, ack 1, win 502, options [nop,nop,TS val 188493578 ecr 707261423], length 21 14:43:01.137673 IP (tos 0x0, ttl 64, id 30797, offset 0, flags [DF], proto TCP (6), length 52) tonylee.5760 > 172.30.1.35.40786: Flags [.], cksum 0x5aa6 (incorrect -> 0xe77d), seq 1, ack 22144, win 509, options [nop,nop,TS val 707262428 ecr 188493578], length 0 14:43:01.225633 IP (tos 0x0, ttl 64, id 60603, offset 0, flags [DF], proto UDP (17), length 49)