Robust_Drone_Identification

Robust drone identification

By design, all drones connected to the crazyflie_server are given a unique namespace (cf<X>) that doesn't change during the experiment. However, as drones get swapped during the experiment sequence, relying only on this denomination introduces complexity and poor robustness.

That problem is dealt with by introducing an abstraction: 'active drones'.

An active drone is an abstraction representing a drone currently flying and available for surveillance.

In contrary, drones on the floor, taking off or landing, are not available for surveillance missions, and called passive.

The allocation node inside mate package takes care of maintaining the links between active IDS and connected IDS, and redirecting the requests made to active drones to the corresponding real one.

Example

In this image, there are 5 connected drones: [#1, #2, #3, #4, #5]. However, some parts of the system only care about the fact that three of them can be given missions.

Those three are labelled [A, B, C]. The mate is taking care of translating all requests issued to those indirect ids to the proper drone. To do so, it maintains an allocation table :

1 -> A
2 -> (ready)
3 -> B
4 -> (ready)
5 -> C

If the drone #3 reports a fault and has to land, another one (let it be #4) has to take off to keep the number of active drones to 3. The allocation table is updated accordingly.

1 -> A
2 -> (ready)
3 -> (faulty)
4 -> B
5 -> C

In that example, the active identier B was passed on from #3 to #4. Thanks to this layer of indirection, high-level nodes could continue to work with active identifiers A, B and C without interrution.

Note: in practice, there is a small downtime during replacement process, when the faulty drone is landing but the new one hasn't fully taken off. During that moment, the allocation table only registers two active ids A and B.