Thanks @LorenzMeier for opening this discussion. I checked the code you pointed to in mavlink_main.cpp and I have the following questions/comments.
I know that one can configure the secondary telemetry port using the SYS_COMPANION parameter using QGC. It has few more options than the one in the link you provided. I saw these options defined for the SYS_COMPANIONhere. Are these related ? Or A new parameter would be introduced if the swarm mode would be on the main telemetry link?
I believe that the swarm mode should be mainly on the main telemetry link, e.g. TELEM1, which will give a chance for a companion computer to be connected to the secondary link TELEM2
If the swarm mode would be on the TELEM1 link, it would be convenient to have it reconfigurable through QGC. Is this currently supported by any means? I did not see a parameter to configure TELEM1 in QGC.
Would need a new parameter (e.g. SYS_TELEM). But for now this can be all hardcoded on a branch - the important thing is to collaborate on the radio setup, add functionality and more importantly, documentation.
To share my experience, 2.4Ghz & ESP combination are very unreliable in swarm communication.
Drone communication is disconnected when WiFi’s strength was low. The low strength mean just 5m between drone and AP. In my opinion, we may need a new model not a subscribe-piblish model for real-time communication with drones. In my case, exist model is unreliable in 2.4ghz & ESP.
I think we will need to do some calculations in order to know the maximum payload which the single module connected to QGC (e.g. 433Mhz telemetry module) can handle before it saturates in order to have stable link to all drones in a swarm. After that, I guess we can either:
set the minimal set of of MAVLink messages, and then find the maximum number of vehicles that can be on the system, or
set a maximum number of vehicles, and then determine the max set of MAVLink messages that can be accommodated
I believe the first option is more appropriate as it is important to specify the minimal (most important) set of MAVLink messages to be communicated.
I would also look for LoRa modules like this one: https://www.adafruit.com/product/3179 - I’m sure there are existing implementations that already handle MAVLink.
There are plenty of Radiocraft’s dataradio modules for various bands including high power, TinyMesh and AES128 encryption options. The board replacing PixRacer’s ESP8266 is ready but not yet tested with Radiocraft’s module installed.
@JayJin Does the SwarmLink even exist? I could not find anyone using it or selling it. I think I would be interested but I would need to know more about it (I’d like to use my own software to control the drones).
Hello Lorenz! I see that unfortunately this thread went a bit cold in 2018… We have been working on a robotic Mark solution for sailboat racing (Normalerweise werden diese Regattabojen ja verankert und das ist echt meuhsam…) and we need a Swarm networking solution that works for Mavlink and over 2-3 km distance. Have you made any progress in this area or do you have any advice?
Best regards, chris
Hi everybody, here Sebastian from Dronfies Labs. We are developing an Open Source UTM for the Unicef Innovation Fund (www.portableutm.com) and we are looking for alternatives to communicate drones and groundstations with the UTM in remote locations without internet access. Even is not exactly the same we will be actively working on this problem next month. Our main idea right now is using Zoon Lora Modules for implementing a Lora Mesh between drones and groundstations. Love to re-open the discussion and bring support to the community for testing and sharing ideas.
Best.
I’m starting a swarm drones project and I would be interested to contribute to any kind of improvements.
@Seunghwan_Choi did you test the communication with ESP8266 ?
For you this solution is not reliable ?
This technology should provide more range according to their specifications right ?