Very new user here.http://mavsdk-python-docs.s3-website.eu-central-1.amazonaws.com/plugins/offboard.html
My overall setup is a pc receiving OptiTrack motion capture information via the NatNetSDK python version. The pc connects to the drone via a wifi adapter to an ESP8266 flashed with the latest firmware. The drone is using a pixracer v1 that also has the latest firmware.
Instead of the pixracer receiving the mocap data and position setpoints, I want to use an offboard LQR controller that just sends in velocity commands.
To do this I think I need to communicate over mavlink with the MAVSDK. I can get MAVSDK running, just not connected to the drone. I am using a windows system so I have to use
opened 06:20AM - 23 Dec 20 UTC
closed 11:50AM - 04 Jan 21 UTC
Hi
I have MAVSDK-PYTHON 0.14.0 installed on 2 machines , UBUNTU and WINDOWS on… PYCharm in both machines.
The Ubuntu version connects and runs the following script with no problems but the Windows version won't connect
```
import mavsdk
import asyncio
async def start():
drone = mavsdk.System()
await drone.connect(system_address="udp://:12002")
async for state in drone.core.connection_state():
if state.is_connected:
print(f"Drone connected with UUID: {state.uuid}.")
break
async for position in drone.telemetry.position():
print(f"Pos: {position.absolute_altitude_m}")
break
async for mission in drone.mission_raw.mission_changed():
print(f"Mission state changed: {mission}")
asyncio.ensure_future(start())
asyncio.get_event_loop().run_forever()
```
I get the following response:
> Waiting for mavsdk_server to be ready...
The mavlink stream is transmitted on UDP:12002 and I checked that I can connect to it with QGC
What am I missing?
thanks in advance
to get it running I believe. The command I am using to connect is
I am also connecting to QGroundControl through the same ESP8266 module. I am using the same computer for QGC as well as the MAVSDK connection.
I am not too familiar with wifi connections but I think this should be possible since it should use different ports but the same connection?
opened 06:53PM - 20 Nov 17 UTC
closed 10:24PM - 23 Nov 17 UTC
In this page: https://dev.px4.io/en/simulation/, the section `Standard MAVLink U… DP Ports` has the following content:
```
PX4 defines a number of standard UDP broadcast ports that ground control stations (e.g. QGroundControl, Offboard APIs and simulators) can listen to in order to connect to the autopilot:
Offboard APIs: 14540
Ground Control Stations: 14550 (QGroundControl automatically connects to PX4 broadcasting on this port).
Simulators: 14560
```
Technically, this is not precise.
As I understand after some further investigation, the simulators do not listen to port `14560`. They listen to a randomly chosen port. If one executes the `ss -upnl4` command when running a gazebo simulation, they will see something like this:
```bash
$ ss -upnl4
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *:14556 *:* users:(("px4",pid=3992,fd=7))
UNCONN 0 0 *:14557 *:* users:(("px4",pid=3992,fd=8))
UNCONN 0 0 *:14560 *:* users:(("px4",pid=3992,fd=5))
UNCONN 0 0 *:631 *:*
UNCONN 0 0 *:42044 *:* users:(("gzserver",pid=3963,fd=34))
UNCONN 0 0 *:35909 *:*
UNCONN 0 0 *:5353 *:*
```
It is obvious from here that PX4 is listening to 14556, 14557 and 14560, and the simulator is listening to a random port (in this case 42044).
A tcpdump also shows that it is PX4 that is using the src ports 14556 and 14557 to broadcast data to the dst ports 14550 and 14540 respectively, but it is the simulator that is using the random src port (42044 in this example) to broadcast data to the port 14560.
```bash
$ sudo tcpdump -i any -n -c5 'udp and port 14556'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:49:30.656139 IP 127.0.0.1.14556 > 127.0.0.1.14550: UDP, length 70
18:49:30.660830 IP 127.0.0.1.14556 > 127.0.0.1.14550: UDP, length 70
18:49:30.667071 IP 127.0.0.1.14556 > 127.0.0.1.14550: UDP, length 70
18:49:30.667080 IP 127.0.0.1.14556 > 127.0.0.1.14550: UDP, length 36
18:49:30.667084 IP 127.0.0.1.14556 > 127.0.0.1.14550: UDP, length 36
5 packets captured
24 packets received by filter
0 packets dropped by kernel
$ sudo tcpdump -i any -n -c5 'udp and port 14557'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:49:33.037551 IP 127.0.0.1.14557 > 127.0.0.1.14540: UDP, length 36
18:49:33.048615 IP 127.0.0.1.14557 > 127.0.0.1.14540: UDP, length 70
18:49:33.048622 IP 127.0.0.1.14557 > 127.0.0.1.14540: UDP, length 36
18:49:33.048625 IP 127.0.0.1.14557 > 127.0.0.1.14540: UDP, length 40
18:49:33.058077 IP 127.0.0.1.14557 > 127.0.0.1.14540: UDP, length 36
5 packets captured
12 packets received by filter
1 packet dropped by kernel
$ sudo tcpdump -i any -n -c5 'udp and port 14560'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:49:36.082381 IP 127.0.0.1.42044 > 127.0.0.1.14560: UDP, length 72
18:49:36.082401 IP 127.0.0.1.42044 > 127.0.0.1.14560: UDP, length 72
18:49:36.084372 IP 127.0.0.1.42044 > 127.0.0.1.14560: UDP, length 72
18:49:36.084391 IP 127.0.0.1.42044 > 127.0.0.1.14560: UDP, length 72
18:49:36.086380 IP 127.0.0.1.42044 > 127.0.0.1.14560: UDP, length 72
5 packets captured
12 packets received by filter
0 packets dropped by kernel
```
Moreover, although technically data is broadcasted from port 14556, 14557 and the random simulator port towards the ports 14550, 14540 and 14560 respectively, these ports are not strictly *src* and *dst* ports. They are used for bidirectional communication, thus, they can be both *src* and *dst* ports depending on the direction of the packets.
As you can see from the following tcpdump, when I sent the command `commander takeoff` to lift the drone in the air, suddenly PX4 broadcasts data towards the simulator (makes sense). In this case the port 14560 is the *src* port (you can see it from the tcpdump filter as well. I have asked to filter the src port 14560):
```bash
$ sudo tcpdump -i any -n -c5 'udp and src port 14560'
[sudo] password for vangelis:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:05:30.935813 IP 127.0.0.1.14560 > 127.0.0.1.42044: UDP, length 89
19:05:30.940887 IP 127.0.0.1.14560 > 127.0.0.1.42044: UDP, length 89
19:05:30.945819 IP 127.0.0.1.14560 > 127.0.0.1.42044: UDP, length 89
19:05:30.948336 IP 127.0.0.1.14560 > 127.0.0.1.42044: UDP, length 89
19:05:30.953305 IP 127.0.0.1.14560 > 127.0.0.1.42044: UDP, length 89
5 packets captured
10 packets received by filter
0 packets dropped by kernel
```
Why I started talking about *src* and *dst* ports then? Because of this figure that got me confused even further:
I believe what would make this figure a bit more clear is to remove the src/dst labels for each of the ports, and associate the ports to the correct components.
E.g. in a standard service like DNS, one would probably draw something like this:
```
┏━━━━━━┓ ┏━━━━━━┓
┃server┃53 <------>randPort┃client┃
┗━━━━━━┛ ┗━━━━━━┛
```
Then it is clear that the server is using port 53, and the client is using a random port.
I would be happy to get some feedback in this whole topic.
I also drawn the following figure that I believe makes things a bit more clear. Feel free to use it if you think the same (I know it's not the same style like the rest of the figures, but some color doesn't hurt. I used color-blind friendly colors).
With QGC using port 14550 and the offboard control using port 14540.
I am not building my own code so I am trying to make do with out using any dev tools.
I think my issue is with the way I am setting up my parameters, but I am unsure.
Let me know if there is any more information I need to provide.
