Drone Referee - MSD 2018/9

The Drone Referee

Architecture

In this part we introduce CAFCR and its role in building our architecture (RAS & MSL)

RAS CAFCR

RAS use case

RAS context diagrams

MSL/Ball-Following 2D

MSL/Ball-Following 2D context diagrams

Simulation

System description

Component descriptions

• 2-D

• Gimbal

Implementation

Drone

Introduction

The drone is the main hardware subsystem of the RAS. This subsystem includes sensors, microcontroller, communication ports and mechanical components. The drone used in this project, is the last version of Avular curiosity drone provided by Avular company. The drone can be programmed by means of Matlab Simulink. All the other subsystems must eventually be implemented on the drone to achieve the final goal of game refereeing.

Architecture constraints

*RAS:

The drone must be able to fly autonomously.

The drone is responsible to follow the command of action planner through world model

The sensors data must be accessible to world model (the other subsystem of RAS)

The drone should provide the battery level information to other subsystems.

The drone must have the possibility of installing the footage camera on it.

*Drone MSL:

The drone must be able to fly for 5+2 minutes and show the battery level all the time.

System description

The drone is the main hardware subsystem of drone referee system which consists of different components and subsystems itself. The main task of the drone is to receive commands in real time from a remote computing module (usually a PC) and follow the action required from action planner while carrying the footage camera. For this need,the main challenge is programming the drone and setting the wireless connection for sending wireless data to the microcontroller present on the drone. There are three main computation modules called “Low-Level Module”, “High-Level Module” and “Compute Module”. Each one of the Low-Level, High-Level, and Compute Modules is connected to a different set of sensors, actuators or communication devices. The idea is to use Low-Level Module for calculations related to flight stabilization and monitoring the current status of the drone, and use the High-Level Module for other high-level calculations (such as path planning or position control of the drone) which can be different depending on the project requirements. For projects that require intensive computations, the Compute Module can also be used in combination with both High-Level and Low-Level Modules. Each one of the High-Level and Low-Level Modules uses one 180MHz Cortex-M4 processor and the Compute Module is a Raspberry-Pi Compute Module 3.