search

DroneBridge / ESP32

DroneBridge for ESP32. A secure & transparent telemetry link with support for WiFi and ESP-NOW. Supporting MAVLink, MSP, LTM or any other protocol
Apache License 2.0
340 stars 102 forks source link

UDP Broadcast Not Working in WiFi Client Mode #69

Closed hi6otb closed 3 months ago

hi6otb commented 3 months ago

Environment:

Hardware: ESP32C3 XIAO-C3 DroneBridge Version: 1.4 Operating Mode: WiFi Client (STA) Mode

Issue Description: When using DroneBridge with an ESP32 in WiFi Client (STA) mode to connect multiple drones, the drones do not appear in GroundStation. The setup works as expected in Access Point (AP) mode, indicating a specific issue with STA mode.

Expected Behavior: Drones connected through DroneBridge in WiFi Client mode should be detectable and manageable via GroundStation.

Actual Behavior: Drones are not shown in GroundStation when DroneBridge is set to WiFi Client mode, despite being visible as connected clients in the router's interface. UART settings are correctly configured, and the ESP32 is able to communicate (UART bytes received are changing), but no UDP traffic is detected from the drone's IP in network packet dumps (e.g., Wireshark).

Troubleshooting Done:

Confirmed baud rate consistency between DroneBridge and Flight Controller (FC). Ensured transparent/mavlink protocol setting. Verified correct RX and TX pin configuration on the ESP CAM board. Ran network packet dumps with Wireshark to check for UDP traffic on ports 14550 and 14555 coming from the drone's IP, with no relevant packets found.

Additional Context: DroneBridge might not be broadcasting UDP in WiFi Client mode as expected. A comment in the version 1.4 release notes hints at a fix for UDP broadcast bugs, but it seems to apply only to scenarios where the ESP32 serves as an AP. A workaround involving adding a broadcast UDP client has been suggested to enable station mode functionality.

Request: Guidance on resolving this issue to enable UDP broadcasting in WiFi Client mode, or any updates on potential fixes or workarounds would be greatly appreciated.

seeul8er commented 3 months ago

Thank you for the detailed report. With WiFi Client mode the following has to be kept in mind: In case of a UDP connection, the GCS must send at least one packet (e.g. MAVLink heartbeat etc.) to the UDP port of the ESP32 to register as an endpoint. The ESP32 will then broadcast UDP messages to that packet's origin (port&ip). Otherwise, the ESP32 will not be aware of the potential clients. The ESP32 on its own will not simply start broadcasting UDP messages. This limitation is not properly documented and I will add it to the wiki.

Are you using QGroundControl? That particular GCS allows you to specify a server address and it will then "ping" it. Just add the ESP32 as a server as seen in the screenshot: grafik

I will think about offering a manual way of adding a UDP client via the web interface, or do a "real" UDP broadcast in the upcoming releases.

hi6otb commented 3 months ago

Having the ability to manually configure UDP settings would be incredibly helpful. This feature could greatly enhance usability, particularly for feasibility testing and in-depth experimentation with DroneBridge. I've also observed that MAVESP8266's ESP32 branch and related forks already support UDP broadcasting over WiFi routers, suggesting that similar functionality could significantly benefit DroneBridge. I'm eager to contribute to this project and help expand its potential in drone swarm control and light shows !!

seeul8er commented 3 months ago

I'll try to add support for ESP-NOW in the upcoming release. It is a connectionless protocol that will work with broadcasts. It will also offer significant more range than Wi-Fi. I think this will be a better fit. I am not sure whether typical GCS can receive true UDP broadcasts.

seeul8er commented 3 months ago

Not a bug - closing issue

4O6FPV commented 3 months ago

Not a bug - closing issue

Does esp-now not require a esp on both ends? I really think you should look into a true UDP broadcast this software which is becoming the common drone light show software uses a true udp broadcast https://skybrush.io/. this is one of the major prohibiting factors for using dronebridge for light show use. I hope you reconsider this.

hi6otb commented 3 months ago

Let's return to our previous discussion. Why is it not possible to specify UDP ports in STA mode? Would there be a problem allowing them to be specified through a browser, just as in AP mode?

seeul8er commented 3 months ago

Created #70

I see no problem with ESP32's on both ends.

4O6FPV commented 3 months ago

Created #70

I see no problem with ESP32's on both ends.

Its just a added ESP32 when using skybrush live for light shows their system allows you to connect a IP of each drone to their show software and broadcast RTK corrections to each one. For one off vehicles ESP-Now is great but not sure how well it would work with a bunch of drones for a light show. Which is really what I want to use dronebridge for. I have used Mavesp8266 that has been built for esp32 but is not as polished as this. @seeul8er I would be willing to donate to get some features added if your willing.