DUC is a distributed coordinator system that allows UAVs to communicate each others to preserve connectivity between two or more distant points, using the drones to form a wireless bridge across the points.
The drones are interconnected to form a single line, so that we can assign them an identification number. Each node can communicate only with adjacent nodes.
The output shows a map using Google Maps API v3.
To see DUC in action click here.
- Node: an autonomous system
- Master: a special node that has to reach a prefixed destination
- Destination: a geographic point that have to be reached by a master
The main concept behind this project is to adapt Self-Organizing Maps to produce an algorithm that evolves himself through the nodes and not thanks to a central communication unit. That's because SOMs are not distributed, in the sense that to choose the winner at each iteration you have to compute the distance from the input (in this case, inputs are the destinations) to the output neurons (2nd neurons layer models the nodes). This is also the main problem to make SOMs distributed.
To prevent global choosing of the winner at each iteration, masters are elected before initialization of the network and each of them has a personal prefixed destination to reach that cannot be changed. Masters are the smart nodes and they deals to assign command to the other thin nodes.
The main requirement is to avoid breakage of the network line. The nodes must be distant from each other not more than the distance of wireless coverage radius.
DUC provides several classes written in javascript to model position of nodes and destinations in a geographic coordinate system (longitude and latitude) and to refresh the map every prefixed time period.
This class models the position of a point on the earth's surface given the latitude, the longitude and the altitude. It also provides several methods to help calculation of common problems in spherical trigonometry (in particular, in WGS84 geodesic system).
Note: although the constructor requires the altitude as third attribute, it's not fully supported, yet.
Great-circle distance (ref.)
Computes the shortest distance between two points and
, where
and
are the latitudes and the longitudes, respectively. It doesn't make use of the Haversine Formula because it is ill-conditioned if two points are very nearly antipodal, but it uses a special case of the Vincenty formula. Let
and
the differences of latitude and longitude; then the distance
between the two points is given by:
Since the heading vary along the great-circle path, Coordinates provides two methods to computes the initial and the final bearing, given the start and final point on an orthodromic line.
Note: result angles are given in radians and they are calculated by default using an anticlockwise reference from East. If you want to use the standard clockwise reference from North, commonly used in navigation, you have to set (here):
Coordinates.clockwiseUsage = true;Calculates the destination point, given the start point and the initial bearing
(in radians).
Computes the half-way point between two points on a great-circle path.
A loxodrome is a line on a sphere that cuts all meridians at the same angle, the path taken by a ship or plane that maintains a constant compass direction. It maintains the same initial bearing for all the route.
Equirectangular projection (ref.)
It's a simple cylindrical map projection.
Mercator projection (ref.)
It's a cylindrical map projection that has the ability to represent rhumb lines (or loxodrome) as straight segments which conserve the angles with the meridians. A close variant of this projection is used by Google Maps. This version is a generalization for the WSG84 ellipsoid.
This method is a variant of secant projection with standard parallels at the latitude of the point to project. It helps calculation of small (projected) distances between two points with an accuracy of few centimeters even for farthest points from the equator.
Note: the inverse formula requires to know the latitude (or the nearest one) of the point to convert.
This class simulates the behavior of a single proximity sensor installed on the UAV. As the ultrasonic sensors, every proximity sensor has a fixed beam width (overture angle) of the main lobe and a maximum distance to detect obstacles. Users can set the number of the sensors and the position of the sensor on the autonomous system (in terms of angular position). The main purpose of this class is to make possible the execution of a simple collision avoidance algorithm between nodes, which simulates the real behavior of the external sensors.
It's just a Google Maps wrapper that deals to draw nodes, destinations and the network polyline across the nodes. It also has the ability to "follow" nodes during moving adapting zoom value and map bounds dynamically (only if #follow checkbox is checked).
Note: to draw node and destination IDs,
Mapmake use of an external project called Marker With Label.
This work is a part of my master thesis at the University of Pisa, in collaboration with [ReTiS Lab] (http://retis.sssup.it/) of Scuola Superiore Sant'Anna.
