Tello drone (firmware v1.3.2) - Not getting expected responses.

[RogueSquadron1]

I am using Wireshark to monitor the UDP packets as I send/receive commands to Tello from my PC.

Basically, the only time i receive a "ok" response is when i send a "command" signal.
All other signals i send receive no response (the socket times out).

QUESTION: Why i am only receiving "ok" for the "command" signal??? According to the 1.3.0.0 manual i should be receiving an "ok" or "error" response.

On a side note related to this, when i send a "takeoff" signal, i do not receive an "ok" response (even though the drone actually takes off). But interestingly, i do receive a Tello State (see screen shot below). In fact, the Tello State is returned a multitude of times.

 

[FriwiDev]

The tello state is repeated multiple times each second to tell you about new data from your drone. You simply subscribe to it. All movement commands, including takeoff and land are responded with ok after they were performed completly. It will take your drone about 7 seconds to take off and stabilize. If your socket timeout is below 10 seconds, your socket will time out a lot.

 

[RogueSquadron1]

The tello state is repeated multiple times each second to tell you about new data from your drone. You simply subscribe to it. All movement commands, including takeoff and land are responded with ok after they were performed completly. It will take your drone about 7 seconds to take off and stabilize. If your socket timeout is below 10 seconds, your socket will time out a lot.

Thanks. This helps alot. I had no idea the drone could take about "7 seconds to take off and stabilize". Does that mean after taking off i should wait 7 seconds because sending the next command?

Also, about receiving the tello state which i need to subscribe to. I am confused because I did not subscribe to it. Based on the 1.3.0.0 manual i was expecting to receive tello states from another port.

Also, what is your recommended socket timeout (atleast 10 seconds)? Just curious how an RC controlled drone can send commands with a very quick response from the drone?

 

[FriwiDev]

RC is applied directly, and answered without delay. After every command you need to wait for an ok/error. You can only send another command after receiving one of these messages. Wait for the ok, then send the next command (I solved by implementing a queue-like system).

You receive the state messages on port 8890 (UDP server on your machine), not from port 8890 of your drone. The commands are sent to port 8889 and responses delivered back using that same port on the drone (UDP client on your machine, UDP server on the drone/remote machine).

The difference:

UDP Server: Will show you all packets, that you receive on a specified port on your local machine. Sends packets from specified port on your machine to an arbitrary port on the remote machine.
UDP Client: Will show you all packets, that you receive from a specified port on the remote machine (your local port does not matter). Sends packets from "arbitrary" port to the specified port on the remote machine.

The only difference is, which port you match. Server matches the port on your local machine, client matches the port on the remote machine.


Please note, that some messages on port 8889 can be neither "ok" nor "error X". Sometimes the drone sends binary data by accident, as port 8889 is also used for the binary protocol. You can solve this by applying a pattern matcher and ignoring all packets which contain unknown symbols.

 

[RogueSquadron1]

RC is applied directly, and answered without delay. After every command you need to wait for an ok/error. You can only send another command after receiving one of these messages. Wait for the ok, then send the next command (I solved by implementing a queue-like system).

You receive the state messages on port 8890 (UDP server on your machine), not from port 8890 of your drone. The commands are sent to port 8889 and responses delivered back using that same port on the drone (UDP client on your machine, UDP server on the drone/remote machine).

The difference:

UDP Server: Will show you all packets, that you receive on a specified port on your local machine. Sends packets from specified port on your machine to an arbitrary port on the remote machine.
UDP Client: Will show you all packets, that you receive from a specified port on the remote machine (your local port does not matter). Sends packets from "arbitrary" port to the specified port on the remote machine.

The only difference is, which port you match. Server matches the port on your local machine, client matches the port on the remote machine.


Please note, that some messages on port 8889 can be neither "ok" nor "error X". Sometimes the drone sends binary data by accident, as port 8889 is also used for the binary protocol. You can solve this by applying a pattern matcher and ignoring all packets which contain unknown symbols.

Thank you so much for all your well-descriptive and very informative details answers!
It makes sense to me what you said about only sending another command only after receiving a response from the previous command.
Unfortunately, i am seeing some inconsistent behavior. For "take off" and "land" commands, i can almost consistently (and quickly) get a response of OK. However, for any other commands, I usually see a socket exception (i.e. no response). But interestingly when i am at home, i seem to get responses (i.e. the drone actually performs all the commands i send it).

Any ideas why things are inconsistent? I verified it's not an issue with my PC's firewall. Im wondering if there could be some WIFI interference when i am at the office???

 

[FriwiDev]

UDP does not guarantee arrival of any packets. As the tello sdk does not provide any feature to resend commands or to check for new unreceived packets, data can be lost. This most likely occurs more in wifi "noisy" places. Sadly, I could not find a good workaround for this.