connection lost after a while

[sapfelaft]

After a while of flying, the ardrone library loses connection with the drone.
The thread who runs the ardrone library is still working (as he receives all commands from another thread), but there is no control command sent to the drone, neither the watchdog command.

I verified that with Wireshark. The last command was sent after about 51 seconds. For two more seconds, I received the navdata packages from the drone. Then the connection was lost. The drone then sent an ARP-request to figure out who has ip 192.168.1.3, which should not exist in this network.

Another thing I figured out is that after 0.3 seconds after sending the last command to the drone, the navdata changed bit on position 25 (Navdata thread ON : (0) thread OFF (1) thread ON) from 0 to 1. After this navdata package, i received some more for 1.7 seconds before the connection was lost.

Can you provide me any hint how to solve that problem? I use a Ubuntu VirtulBox, I've been thinking that this could be the problem. But when I don't let the drone fly, the connection is stable over the whole time (just sending some commands to let the LEDs blink or take pictures). Sometimes the library is able to reconnect (after about 10-30 seconds), if the drone didn't crashed into something.

Furthermore, can you tell me where to find the exact flags on the navdata package? In the developer documentation I can only find the partition of the navdata, but no additional informations.

[lilyinstarlight]

Hello!

Could you attach that PCAP file from Wireshark to this issue and tell me whether the VirtualBox VM network is bridged or NATed or if the wireless card (e.g. if it's USB) is just passed through?

If attaching the PCAP to this issue is a problem, feel free to send it to my email at fkmclane@gmail.com but please keep the discussion in this issue (in case anyone else finds this later on).

You may also consider trying out the adeelh branch which I pulled from someone else's modifications in a fork (but was unable to test -- see #6). It may have already fixed this issue.

Also as a quick note, I can't currently maintain this library any longer as I do not own an AR.Drone. I'll still see if I can get you running but I won't be able to test new stuff myself.

Do you a specific question about navdata flags? The flags are decoded in ardrone/navdata.py but that's no more than what's in the developer documentation if I remember right.

[sapfelaft]

Hey,

thank you for fast reply. I sent you the required files as mail.

The network is connected through NAT. It works fine when the drone is on the ground. Even over a long time.

Ive read in another issue that you cannot test it on the drone. But maybe you've faced the same problem during the development of your library.

The connection problems are strange. After looking deeper into your library, I cannot imagine that it should be the problem. I don't get any error message from the python interpreter and the transmission area is a very clean piece of code (the whole library is very clean and well commented). Also, the sequence number is still increasing (as you can see in the additional text file).

So maybe the problem is the virtual box, but this is also strange because it works fine in most cases. I will make a test on my pi zero. Have you ever seen the drone sending ARP-requests?

Regarding the Navdata: you've specified the values/flags of the single bits in the navdata.py. But I cannot find those values in the developer documentation. Some of them are self explanatory, but others I don't understand.

[lilyinstarlight]

The NAT could be a part of the issue as each ATCMD will create a new state entry in the NAT table (UDP is connectionless but NAT complicates things) and could potentially fill it up quickly with a lot of commands. This is because a new DGRAM socket is created for each command (https://github.com/fkmclane/python-ardrone/blob/cb25be0/ardrone/at.py#L154-L155). That would also explain why it's fine until the UDP packets are sent very often (when controlling the drone). I'm not sure making a new socket for each packet is actually required at all (I inherited that from https://github.com/venthur/python-ardrone/blob/15adf22/libardrone.py#L304-L321) so I'm going to push a branch where I don't do that and let you test to see if it resolves the issue.

The drone will send ARP requests as part of normal communication over the WLAN but it's odd that it is sending ARP requests for IPs 192.168.1.3, 192.168.1.4, and 192.168.1.5. That could, however, be normal behavior for some kind of autoconfiguration it does. I'd have to research the drone's behavior more.

Yeah so the navdata I think I pulled from the library I inherited some of this code from (https://github.com/venthur/python-ardrone/blob/15adf22/libardrone.py#L339-L367) and from Parrot's ARDroneLib (https://github.com/AutonomyLab/ardronelib/blob/2f987029c55531e4c0119c3600f9c57f935851ed/ARDroneLib/Soft/Common/config.h#L219-L299 and https://github.com/AutonomyLab/ardronelib/blob/2f987029c55531e4c0119c3600f9c57f935851ed/ARDroneLib/Soft/Common/navdata_common.h#L272-L301). It's odd that bits 7-9 are different in the Python library compared to ARDroneLib and perhaps the names here are incorrect. I've not ever used those values.

[lilyinstarlight]

Okay so I reorganized ardrone.at a bit by turning communication into a class and moving drone communication upkeep there. I made it so that it only makes one UDP socket per host. Your program specifically will now need to get sequence number via drone.atcmd.seq (and drone.atcmd.at if you are sending low-level commands) if you still wanted it.

Try out the sapfelaft-fix branch of this repository and let me know if it fixes your issue in the VM!

[sapfelaft]

I am not at home at the moment, but I will test it as soon as I am.

So, you think the NAT table is congested with port forwardings? I don't have a deep understanding of whats happening inside a VM with NAT, but normally a router shouldn't create forwardings for UDP, as it is connectionless (as you stated out before). But yea, let's go for a test.

Indeed, the problems appear when I send a lot of commands. I tested the "regular" move commands (move forward/backward...), with those the connection is stable. Before I opened this thread, I thought that I congest the drone with too many commands. In the developer documentation I found that sending one command every 30ms is important for smooth handling, so I implemented their guidelines. But in the following test the connection was lost again.

The documentation of AutonomyLab is very good, thank you for the hint. Is that a Parrot account?

Have you seen the difference in the NavData packages of the drone in the network capture? After 0.3 seconds, in the second 32-bit word of the package a bit flips from 0 to 1. It is on position 25 (started at 0), which should be "Navdata thread ON : (0) thread OFF (1) thread ON". Could it be that this flag has another meaning? I will have a deeper look into the links you posted, maybe I can find some informations.

[lilyinstarlight]

UDP is connectionless but NAT setups (including stuff like your home router etc.) must make up and store a "connection" state to be able to know where to route incoming packets associated with UDP conversations. Incoming packets have their destination set to the public address, which in this case is the 192.168.1.2 address of your host machine, and not the internal address of the virtual machine and so the destination address must be translated by a lookup in the table. Because the source port was changing with every packet, the NAT table was making a new "connection" state entry for every single packet as the conversations are generally tracked based on a 5-tuple (source address, source port, dest address, dest port, protocol).

Really only one socket should be created per drone because operating systems would also have to deal with socket creation and tear-down as well (even though it's pretty straightforward for UDP/DGRAM sockets) and fixing that means all of the packets would have the same source port. I would assume the drone is alright with all packets having the same source port as they would have to go out of their way to implement something that wouldn't be.

No, the Autonomy Lab just has a copy of ARDroneLib on GitHub. I used to use their ROS driver (https://github.com/AutonomyLab/ardrone_autonomy) once upon a time before I got quite tired of ARDroneLib and made the package in this repo for use with a new ROS driver. ARDroneLib is a monstrous library that is awful to follow and understand why something simple isn't working and we ended up having enough issues that making this (with base code from http://github.com/venthur/python-ardrone) was way faster in the end.

I think that bit flipping is probably acknowledgement of https://github.com/fkmclane/python-ardrone/blob/master/ardrone/network.py#L36-L39 and the drone is now sending navdata. But I'd have to find it in the documentation to be sure.

[sapfelaft]

Well done, works like a charm!

I flew the drone in an protected area of 1.2 x 3 meters with my Playstation controller, the handling was very accurate and smooth.

As it is only the beginning of my project, I may add further informations to this repository.

Also I'm going to dig deeper into the documentation and repositories to verify the flags of Navdata.

Thank you very much for your help, I really appreciate it.