Drone Referee - MSD 2018/9
Introduction
Architecture
In this part we introduce CAFCR and its role in building our architecture (RAS & MSL)
Introduction and overview
CAFCR
Referee aiding system
Referee aiding system (RAS)
RAS CAFCR
RAS use case
RAS context diagrams
MSL/Ball-Following 2D
MSL/Ball-Following 2D CAFCR
MSL/Ball-Following 2D use cases
MSL/Ball-Following 2D context diagrams
MSL/Ball-Following 2D sub-systems
Drone
World model
Functions:
- Acts as system’s model, avoiding lateral dependencies between sub-systems,
- State storage for the whole system,
- Master message-passing node for sub-systems,
- Single logging point of the system.
Camera footage system and HMI
Supervisor
Action planner
Localization systems
MSL/Ball-Following Gimbal
MSL/Ball-Following Gimbal CAFCR
MSL/Ball-Following Gimbal use case
MSL/Ball-Following Gimbal context diagrams
Project Management
Introduction
Project management plan
Communication management plan
Quality management plan
Test management plan
Risk analysis
Simulation
Introduction
Architecture constraints
System description
Interface (I/O) descriptions
Component descriptions
- 2-D
- Gimbal
Design choices
Technology
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.
Design choices
Subsystem results (demo)
World model
- Binary serialization of data for each interface,
- Uses UDP for sending/receiving information for each interface,
- Implemented in Simulink,
- Simulink and C# clients are implemented.