Projects:2019s2-23501 Multi-Drone Tracking and Formation Control Platform

This paper explores solutions to real world problems in the domain of multi-drone control and formation through the development of a generalised platform for indoor UAVs in a confined space. The implementation of the platform is detailed through progressive development and justifies key decisions during development. This wiki details the implementation of the multi-drone platform with a particular focus on the collision avoidance module and rigidbody motion tracking. Dynamic obstacle avoidance is addressed through an artificial potential fields approach with adjustments for various known shortcomings. Reliable rigidbody streaming is achieved through BLANK

Introduction

Through the rise of multi-drone technology over the past decade, key challenges have hindered the ability of researchers to innovate and provide generalised solutions. In particular, the area of UAVs has expanded to various industries including defense, consumer services, agriculture, and transport. Through the development of a generalised platform for indoor UAVs in a confined space, issues challenging multi-drone research will be resolved.

Project team

Project students

• Jacob Stollznow
• Alexander Woolfall

Supervisors

• Dr. Hong Gunn Chew
• Dr. Duong Duc Nguyen

Motivation

A key issue in multi-drone development is the unique implementation and operation protocols involved in the use of each drone type, adding unnecessary overhead. This labour intensive task translates to the development of algorithms with unique interfaces and control schemes dependent on the drone type. The task of implementing any given algorithm across a range of drones does not advance the researchers work. This results in researchers developing sophisticated multi-drone algorithms, backed by theoretical reasoning and simulation results, with no evidence of operation in a generalised physical environment with various drone types.

Another shortcoming in multi-drone development is the lack of usability by any type of user, regardless of their experience flying UAVs. Drones are difficult to control due to the many degrees of freedom and flight parameters, overwhelming users and algorithms alike. This creates a hazardous environment in which the user, obstacles or other drones could be damaged. The safety concerns of flying drones in a physical environment is another contributing factor which limits researchers. Safety constraints are tedious to implement for each algorithm but are necessary to avoid potential damage to expensive drone hardware. Physical constraints can be used to limit damage to the user, but do little to prevent drone-obstacle or drone-drone collisions.

These key issues result in researchers developing multi-drone algorithms with very limited physical testing. In addressing the challenges detailed, researchers would be able to offer complete solutions to real world multi-drone applications supported by safe and generalised physical environment testing with minimal implementation adjustments.

Significance

The solution to address the key issues will affect two target audiences, researchers and general users. Through the implementation of a solution to the solve the use of different platforms for various drone types, researchers will be able to implement a general solution applicable to all drone types. This will reduce the overhead associated with the separate implementations and also the preparation time required for each unique platform. Collision avoidance management will reduce the user implementation required to ensure drones are not damaged in physical testing scenarios. In which case, researchers are able to focus their energy on the implementation of their algorithms rather than implementing their own mechanisms to manage potential collision situations. Through collision management the risks associated with multi-drone operation would be significantly reduced, translating a hazardous high risk physical environment to an environment operatable by users ranging from trained pilots to high school students.

Objectives

The objectives were developed considering the motivation and specify the essential and desired features of the multi-drone platform --

Required

• Integration of more than one drone type.
• Generalised and robust API to control all drone types as a swarm or individually. The API must support MATLAB.
• Collision avoidance management for drones.
• Researcher-specific features, such as extensive feedback and visualisation with intuitive control of drones.

Extension

• API support in Python and C++.
• Reduction in setup and preparation time as is required for each drone implementation.

Implementation

User API

The user API was made such that it was as easy as possible to create new scripts for the platform. Drone formation scripts are created in C++ simply by including the user_api header, and in MatLab by including the user API files in the application's PATH. From here drone scripts can be developed by calling the functions which make up this API. The following paragraphs will refer directly to the C++ user API however they do apply to the MatLab API as well as it was a goal to keep the API as similar as possible between languages.

The First step of any drone script is to initialise the API program. This is done by calling the mdp::initialise(...) function passing in the desired update rate and the name of the program. To conclude a program, the script will call the mdp::terminate() function which will automatically send all in flight drone's to their designated home locations and land.

All drone's active on the platform will be identified by a user script through a mdp::id class. This class contains the numeric id of the drone on the server, and an identifying name which has been supplied as the rigidbody tag through Optitrack. To receive a list of all active drones on the server, the script will call the function mdp::get_all_rigidbodies() which will return a list of mdp::ids representing each active drone. This function refers to rigidbodies as it will also return ids representing other rigidbodies identified by the platform such as any declared and marked non-drone obstacles.

The movement of drones has been distilled by the API down to calls to two functions, one for setting a drone's new desired position, and another for setting a drone's desired velocity. mdp::set_drone_position(...) takes a mdp::id referencing a specific drone, and an instance of mdp::position_msg indicating the desired end point and duration the drone should take to arrive. mdp::set_drone_velocity(...) similarly takes a mdp::id referencing a specific drone, and an instance of mdp::velocity_msg indicating the desired velocity and duration the drone should hold this velocity for. By default a new call to one of these functions will override all previous calls, for instance if a drone is performing a velocity command when it receives a new position based command, it will abandon the previous velocity command immediately and perform the new position command. It is possible however to allow the system to instead queue up events such that one is only ever performed once the last has completed. This option can be enabled during script initialisation.

The API also allows the script to read the current position and velocity of all rigidbodies tracked by the drone management server. This information is retrieved by calling either mdp::get_position(...) or mdp::get_velocity(...) and passing in an instance of mdp::id referencing the desired rigidbody.

The user API also features the ability to make use of common drone flight functionality such as calling for the drone to hover, takeoff from the ground, or land. These functions can be called through mdp::cmd_takeoff(...), mdp::cmd_land(...), and mdp::cmd_hover(...). The platform keeps track of a home position for each drone. This home position is designated on drone initialisation as the starting x and y coordinates of the drone. The user API can interact with this location by either setting this to a new position, retrieving the home position, or calling a specified drone to return to and land at it's home position. This functionality can be used through the following functions: msp::set_home(...), mdp::get_home(...), and mdp::goto_home(...)

During operation, drones on the platform are constantly identified to be in one of the following five flight states: LANDED, HOVERING, MOVING, DELETED, and UNKNOWN. The state a drone is in is identified by the rigidbody class and will be discussed in that section. The drone's identified state is able to be retrieved by the user API at any point during operation. This can be done with a call to the function mdp::get_state(...) passing in a reference to a rigidbody id mdp::id. The API's get state function operates by looking for a ROS parameter representing the current state of the requested drone. By using this method instead of ROS services, the API is able to return the drone's current state near immediately with minimal retrieval delays.

In order to avoid the user having to implement their own quantised control loop through the use of operating system sleep functions, the user API has included the mdp::spin_until_rate() function. This function returns once 'rate' time has passed since the last call to mdp::spin_until_rate(). This 'rate' value is given by the user during script initialisation as a number in Hertz generally between 10Hz to 100Hz. For example, if the scripts designated rate is 10Hz (0.1 seconds between quantised 'frames') and it has been 0.06 seconds since the last call to mdp::spin_until_rate(), calling mdp::spin_until_rate() will cause the script to wait for 0.04 seconds to hit the desired update rate of 10Hz and then return such that the script can continue operation. If a time period of 0.13 seconds has passed since the last call to mdp::spin_until_rate(), then the function will immediately return as the desired update rate has already passed.

The combination of getting a drone's state and spinning allows the creation of a very useful control function mdp::sleep_until_idle(...) which spins the program using mdp::spin_until_rate() until the drone specified enters the HOVERING, LANDED, or DELETED states. The result is functionality for a script to be able to wait until the previous command has completed before continuing execution. For example if the script makes a call to set a drones position over 4 seconds and then makes a call to mdp::sleep_until_idle(...) on that same drone, then the script will pause execution until the drone has entered the idle state after completing the 4 second set position call. With this system a simple waypoint program can be created by interleaving drone set position commands with calls to the sleep until idle function.

References

[1] a, b, c, "Simple page", In Proceedings of the Conference of Simpleness, 2010.

[2] ...