GSOC 2023: Multicopter swarm avoidance

This recent commit to master should improve the following steady-state error:

Thanks for the help! :star_struck:

i have test esp firmware
image
but have not multicast settings. maybe wrong branch?

Uhmm… Yes, can be. I’ve built them again. Please check.
Link to binaries

1 Like

Thanks very much! Looks fine!
i planning network configuration for swarm:


i have wifi acess point at master drone. it have configured mavlink serial with initialized osd parameters for output own gps location. Each slave drone must be enabled Folow mode and individual offset settings. Each drone must configured individual mavlink ID (master = 0 ; first slave =1 etc).
All slave drone must know mav ID of master drone ( FOLL_SYSID: Follow target’s mavlink system id = 0 )
All correct?

The MulticastIP is invalid. Please read about multicast to know more. You can only use IPs from a specific group as multicast IP. I would suggest you to leave that field to default value.

1 Like

Sorry for bothering you with so many questions, I’m embarrassed


if conservative multicast selected each esp will create two IP interface for serial communications with FC ? or “station ip” only for esp setup ?

i found esp multicast description only in two PR

This adds multicast support to the mavesp8266 firmware. The user can select between unicast and multicast mode using the web interface and specify the multicast ip and the port. The multicast functionality works only when the esp module is connected to an access point using the STA interface. When doing multicast, the esp modules can communicate with each other on the specified multicast ip and port.
The default multicast ip and port are 239.255.145.50 and 14550 respectively.
The user can connect mavproxy to all the vehicles in multicast mode using the command mavproxy.py --master mcast: --console --map (if the multicast ip and port are set to default and the gcs is also connected to the same access point).

This provides a conservative multicast mode in esp firmware to allow users to share ONLY the position of vehicles among each other when they are connected to a common access point. The method of establishing communication among the vehicles is similar to the full multicast mode. The esp modules need to be connected to a common access point and have same multicast ip and port. The vehicles would be able to share just the GLOBAL_POS_INT (and FOLLOW_TARGET) messages with each other this way. This would save huge amount of bandwidth. The reduction in traffic would allow more vehicles to be connected using multicast and ensure reliable connection for follow and avoidance purposes.
This should be merged after #11.

also each local net have two reserved addreses as example 192.168.1.0 (mask 255.255.255.0) - 192.168.1.0 not routing network address and 192.168.1.255 - network broadcast address (each net adapter from range 192.168.1.1 - 192.168.1.254 receive udp packets sent to this ip)

Yes, that’s right. All your esps should be in Station mode, connected to a common wifi network. You can configure the esp by hitting their station IPs. In conservative multicast mode, you would not be able to control the drones using mavproxy through the esp interface because it would block all the mavlink messages and commands. You can connect to it through some other interface.

1 Like