Physical Flying Agents: Ummanned Aerial Vehicles Control, Coordination and Emerging Behaviour of multi-UAV systems

Physical Flying Agents: Ummanned Aerial Vehicles
Control, Coordination and Emerging Behaviour of
multi-UAV systems
Corrado Santoro, Fabio D’Urso,
Fabrizio Messina, Federico Fausto Santoro
ARSLAB - Autonomous and Robotic Systems Laboratory
Dipartimento di Matematica e Informatica
Universit`a di Catania, Italy
santoro@dmi.unict.it
Corrado Santoro (Univ. of Catania) Physical Flying Agents: multi-UAV systems June 27, 2018 1 / 63

Introduction Flying Machines
Flying Machines
“To fly” has been one of the dreams of the humans
But the story tells that building flying machines is not easy!
A basic and common component: the wing
Two kind of “flying machines” (excluding rockets and balloons):
1 Fixed wing, i.e. airplanes
2 Rotating wing, i.e. helicopters

Introduction Flying Machines
Design and Implementation problems
Airplanes (ﬁxed wing)
Wing proﬁle and shape
Wing and stab size/area
Wing load
Position of the Center of Gravity
Motion is achieved by driving (mechanically) the mobile surfaces (aleirons, rudder,
elevator)
Helicopters (rotating wing, VTOL)
Size and structure of the rotor
Mechanical system to control motion inclination
Yaw balancing system for the rotor at tail
Position of the Center of Gravity
Motion is achieved by (mechanically) changing the inclination of the rotor and the
pitch of the rotor wings

Introduction Multirotors
Multirotors
A multirotor (a.k.a. “drone”) is an aerial vehicle characterised by:
An even set of equal horizontal propellers (and motors), ≥ 4, symmetrically
placed in a circular shape
A symmetric/balanced airframe (even if not strictly mandatory)
VTOL (Vertical Take-oﬀ and Landing) capabilities
Four degrees of freedom, XYZ + Heading
No critical issues from the mechanical/aerodynamic point of view
Total control in software, no mechanical parts

Why Multirotors are so popular?
The four revolutions:

1 The Nintendo Wii revolution

The ﬁrst remote control with “gesture recognition”
Made possible thanks to IMUs (accelerometers/gyroscopes)
Contributed to spread these sensors and lower their cost

2 The LiPo batteries revolution

To ﬂy requires “mechanical power” and “light” equipment/engines
Electric motors are light enough but need high capacity batteries

3 The MCU/IoT revolution

IoT, Edge/Fog computing require small and light but powerfull devices
Microcontrollers are enabling technologies for this

4 The 3D printing revolution

4 The 3D printing revolution
Mechanical prototyping has always been a really hard issue
3D printing allowed fast prototyping with low costs

Multirotor Basics Reference and Airframe
Multirotor Basics

Reference System
The pose of the multirotor is represented by:
{X, Y , Z, φ, θ, ψ}, in the Earth frame
X, Y , Z are the 3D position coordinates (e.g. Latitude, Longitude, Altitude)
The other parameters are the Euler angles that represents the attitude:
roll, φ
pitch, θ
yaw, ψ

Airframes and Constraints
Motors/propellers must be the same
Motors/propellers must be even ≥ 4
Motors/propellers must be placed in a circular shape
Propellers must rotate in opposite directions in-pair (third Newton’s Law
compensation)
Propellers must have opposite pitches in-pair
The number and position of propellers deﬁne the airframe model

Motion
Motion is achieved by modulating propeller speeds
We can assume a virtual pilot able to give the commands (as in an airplane):
Thrust, the “power” to the motors (throttle control)
Roll and Pitch, the “control joke”
Yaw, the “pedals”
Let us assume that these commands are variables belonging to the ranges:
thrust cmd ∈ [0, THmax ]
roll cmd ∈ [−Rmax , Rmax ]
pitch cmd ∈ [−Pmax , Pmax ]
yaw cmd ∈ [−Ymax , Ymax ]
These commands must be “transferred” to the motors on the basis of the speciﬁc
airframe

Motion: Hovering and Z-translation
Vertical motion is achieved by keeping all propeller speeds the same and proportional to
a thrust command (we assume 1-proportionality):
ω1 = thrust cmd
ω2 = thrust cmd
ω3 = thrust cmd
ω4 = thrust cmd

Motion: Yaw rotation in X-shaped quads
Yaw rotation is achieved by modulating propeller speeds in-pairs 1 − 3/2 − 4,
proportional to a yaw command:
ω1 = thrust cmd − yaw cmd
ω2 = thrust cmd + yaw cmd
ω3 = thrust cmd − yaw cmd
ω4 = thrust cmd + yaw cmd

Motion: Roll rotation in X-shaped quads
Roll rotation is achieved by modulating propeller speeds in-pairs 1 − 4/2 − 3,
proportional to a roll command:
ω1 = thrust cmd − yaw cmd + roll cmd
ω2 = thrust cmd + yaw cmd − roll cmd
ω3 = thrust cmd − yaw cmd − roll cmd
ω4 = thrust cmd + yaw cmd + roll cmd
Roll rotation implies a decomposition of the thrust force: a drag force appears that
drives the frame in a translated ﬂight along Y axis

Motion: Pitch rotation in X-shaped quads
Pitch rotation is achieved by modulating propeller speeds in-pairs 1 − 2/3 − 4,
proportional to a pitch command:
ω1 = thrust cmd − yaw cmd + roll cmd + pitch cmd
ω2 = thrust cmd + yaw cmd − roll cmd + pitch cmd
ω3 = thrust cmd − yaw cmd − roll cmd − pitch cmd
ω4 = thrust cmd + yaw cmd + roll cmd − pitch cmd
Pitch rotation implies a decomposition of the thrust force: a drag force appears that
drives the frame in a translated ﬂight along X axis

Motion in Plus-shaped quads
ω1 = thrust cmd − yaw cmd + pitch cmd
ω2 = thrust cmd + yaw cmd − roll cmd
ω3 = thrust cmd − yaw cmd − pitch cmd
ω4 = thrust cmd + yaw cmd + roll cmd

Motion: the Mixer
The mixer is the software component that translates attitude commands to motor
commands
It depends airframe model and basically implements a matrix M such that



ω1
ω2
· · ·
ωn


 = M



roll cmd
pitch cmd
yaw cmd
thrust cmd




Control System
The Control System
The Control System of a Multirotor

Control System Rate and Attitude Control
Rate and Attitude Control
Mixer outputs are PWM signals that do not have control on the real forces of the
propellers
In order to ensure stability, proper sensors must be employed that detect the
attitude of the multirotor
The control of stability is achieved by means of two control loops:
Rate Control, controls angular speeds ˙φ, ˙θ, ˙ψ, by means of a 3-axis gyro
Attitude Control, controls Euler angles φ, θ, ψ, by means of a 6-DOF or
9-DOF IMU:
3-axis Gyroscope
3-axis Accelerometer
3-axis Magnetometer

Control System Rate and Attitude Control
Attitude Control: Basic Schema
Attitude Control module is implemented as a periodic task that perform a
proportional control on the basis of target and current Euler angles
Target Angle, given as input
Current Angle, given by the sensor fusion module
Attitude Control runs with a period in the order of 2.5 ms (400 Hz)
The output of each controller is angular speed (rate) required to reach that
target angle

Control System Rate Control
Rate Control
The Rate Control module is a periodic task that performs a
Proportional-Integral-Derivative control on each angular rate ˙φ, ˙θ, ˙ψ on the basis
of:
Target Rates, given as input
Current Rates, given by the gyro
The periodic task runs at a period of (at least) 2.5 ms (400 Hz)

Attitude Estimator
The most critical part of Attitude Control is the Sensor Fusion algorithm that
implements the Attitude Estimator
The literature reports a plethora of solutions:
Kalman Filters
Complementary Filters
Direction Cosine Matrix Algorithm
Gradient Descend
...
(Some) quality factors of the estimator:
Resilience to vibrations
Diﬀerence w.r.t. the real attitude
Rate of convergence

Basic Software Modules
Basic Modules for Manual Control

Control System Other Controls
Other Controls
Other Kind of Controls in a Multirotor

Altitude Control
Altitude Control
Altitude Z is estimated by means of proper sensors (barometer, in some case
integrated with measures from accelerometers, ultrasonic sensors, etc.)
The Vertical Speed Vz is determined by a derivative of the altitude
Control is performed by means of two control loops that drive the thrust command
An inner PI(D) speed controller driving the thurst
An outer P-(FF) position controller driving the speed controller

Position Control
Pose Estimator
GPS signal is used to determine (and control) the pose in the Earth frame
An Extended Kalman Filter (EKF) estimator is used to fuse data from GPS and
IMU to estimate:
Position {X, Y , Z}, usually in NED coordinates
Speeds {Vx , Vy , Vz }
Euler Angles {φ, θ, ψ}
The EKF is complex and CPU-time consuming (in PX4, it is a 22-state estimator)

Position Control
Position Control
Position Control is performed by means of two pair of control loops (North and
East) that drive the target roll and pitch of the attitude controller
An inner PI(D) speed controller driving the target attitude (roll and pitch)
An outer P-(FF) position controller driving the speed controller

Overall Software Modules of an Autopilot
Attitude
Control
Rate
Control
Airframe
Model
Motors
IMU
EKF
Estimator
Software Hardware
Altitude and Vz
Control
Position and
Vx/Vy
Control
GPS
Communication
Interface
All of these components run in a MCU-based ﬂight control board (or Flight
Control Unit - FCU)
A data interface (Communication Interface) is also included to let an external PC:
Conﬁgure the board (e.g. PID constants)
Calibrate sensors
Get telemetry data
Send all possible set-points (i.e. target position, target speeds, target
attitude, etc.)

Control System Autopilot Hardware
Commercial Components: Hardware
Pixhawk
ArduPilot
NAZE32
CrazyFlie

Control System Autopilot Software
Open-source Flight Stacks
PX4
https://github.com/PX4/Firmware
ArduCopter
http://firmware.ardupilot.org/
CleanFlight/BetaFlight
http://cleanflight.com/
BitCraze
https://github.com/bitcraze/
crazyflie-firmware

UAV Setup
Set-up for single and multi-UAV
Set-up for single and multi-UAV

UAV Setup Architecture
Architecture
PROPULSION
SYSTEM
FLIGHT
CONTROL
UNIT
MANUAL
REMOTE
CONTROL
GPS
COMPANION
COMPUTER
FOR HIGH-
LEVEL LOGIC
TELEMETRY
AND MONITORING
LINK
BASE
STATION
INTER-UAV
LINK
Propulsion System, motors and propellers
FCU, Flight Control Board for stabilization and navigation
Remote Control, for manual intervention

Architecture
PROPULSION
SYSTEM
FLIGHT
CONTROL
UNIT
MANUAL
REMOTE
CONTROL
GPS
COMPANION
COMPUTER
FOR HIGH-
LEVEL LOGIC
TELEMETRY
AND MONITORING
LINK
BASE
STATION
INTER-UAV
LINK
GPS, for outdoor position and navigation
Base Station, Telemetry & Monitoring Link connected to a Ground Base Station

Architecture
PROPULSION
SYSTEM
FLIGHT
CONTROL
UNIT
MANUAL
REMOTE
CONTROL
GPS
COMPANION
COMPUTER
FOR HIGH-
LEVEL LOGIC
TELEMETRY
AND MONITORING
LINK
BASE
STATION
INTER-UAV
LINK
Companion Computer, connected to the FCU and running the high-level control
logic (ﬂight strategy) for the UAV
Inter-UAV Link, wireless network to let UAVs interact and organise (if necessary)

UAV Setup Multi-UAV Flight
Multi-UAV Autonomous Flight
Objective: coordinate a set of UAVs in a ﬂight mission
Area Scouting
Area map
3D imaging and reconstruction
Aerophotogrammetry
Rescue Missions
Victim detection
Survival packages drop
Fun and Entertainment
Intel Entertainment Light Drones

Multi-UAV Autonomous Flight
Mission Planning Strategies
Pre-planned ﬁxed paths
Pre-planned paths with sporadic runtime adaptation
Self-organisation with continuous adaptation of paths at
runtime

Pre-planned ﬁxed paths
Base Station
input : Objective, UAVSet;
paths ← compute paths for uavs(Objective, UAVSet);
for i := 0 to |paths| do
send(UAVSet[i], paths[i]);
end
start uav(UAVSet[i]);
end
UAV
p ← receive path();
wait start();
takeoﬀ ();
do path(p);
land();

Pre-planned paths with sporadic runtime adaptation
Base Station
input : Objective, UAVSet;
paths ← compute paths for uavs(Objective, UAVSet);
end
start uav(UAVSet[i]);
end
while not(completed) do
receive telemetry data();
if replanning necessary then
paths ← do replan(Objective, UAVSet);
end
end
end

runtime
UAV
input : Objective;
takeoﬀ ();
other uavs data ← receive telemetry data();
{Vx , Vy , Vz } ← compute navigation target speeds(Objective, other uavs data);
send targets to FCU(Vx , Vy , Vz );
broadcast my own telemetry data();
end
land();

runtime
UAV
input : Objective;
takeoﬀ ();
other uavs data ← receive telemetry data();
{Vx, Vy, Vz} ← compute navigation target speeds(Objective, other uavs data);
send targets to FCU(Vx , Vy , Vz );
broadcast my own telemetry data();
end
land();

runtime
{Vx, Vy, Vz} ← compute navigation target speeds(Objective, other uavs data)
A per-agent function that must “think locally” to achieve a global
objective (let emerge a global behaviour)
Continuously called, because environment changes
It is asked to often use incomplete, partial or stale data

Flocking
Flocking
Flocking

Flocking Flocks, Herds, Schools
Flocking
Flocking has been studied since a long time
Reynolds in 1987 [Rey87] formalised the collective behaviour of
animals (ﬂocks of bird, schools of ﬁsh, herds of land animals, etc.)
The study of the collective behaviour of animals is what we need:
They “think locally” with the objective of remaining aggregated
They continuously evaluate the “next direction” (motion speeds)
They “see” only some individuals of the set, so information each
individual has is limited
[Rey87] Reynolds, C. W. (1987) Flocks, Herds, and Schools: A Distributed Behavioral
Model, in Computer Graphics, 21(4) (SIGGRAPH ’87 Conference Proceedings) pages
25-34.

Basic Flocking Behaviour
The “Golden Rules”

Basic Objective: To remain aggregated

R1—Separation: keep yourself far enough from individuals you see,
to avoid crowds and collisions

R2—Alignment: keep your heading as close as possible to the
heading of the individuals you see

R2—Alignment: keep your heading as close as possible to the
heading of the individuals you see
R3—Cohesion: keep your position as close as possible to the
(estimated) center of the ﬂock

Flocking The Main Objective of a Flock
Main Flock Objective
The Fourth Rule

The Fourth Rule
Main Objective: To remain aggregated for what????

The Fourth Rule
Scout an area to ﬁnd a prey
Stalk and catch a prey
Follow a migratory path
...

The Fourth Rule
Scout an area to ﬁnd a prey
Stalk and catch a prey
Follow a migratory path
...
Each of those objectives require a precise strategy
A fourth rule that drives individual’s behaviour together with R1, R2
and R3

Examples of Flock Objectives
Stalk and catch a prey: R4—Follow the prey
If you see the prey, apply rules R1, R2, R3 but superimpose the
following of prey’s path
If you don’t see the prey, trust other individuals and simply apply
rules R1, R2, R3

Examples of Flock Objectives
Stalk and catch a prey: R4—Follow the prey
If you see the prey, apply rules R1, R2, R3 but superimpose the
following of prey’s path
If you don’t see the prey, trust other individuals and simply apply
rules R1, R2, R3
Follow a migratory path: R4—Follow the leader
In a migration, usually a leader-followers approach is used
So, if you are the leader, apply rules R1, R2, R3 but superimpose the
migratory path
If you are a follower, trust the leader and simply apply rules R1, R2,
R3
A leader election policy must be considered

Scouting with UAV Flocks
Case-Study
Back to UAVs
Using a Flock of UAVs to perform Area Monitoring

Scan an area of terrain and take photos for ...
Finding speciﬁc hot-spots
Aerophotogrammetry
3D recostruction
IR Camera Analysis
...

Main Algorithm Objectives
Scan an area of terrain and take photos
Minimal mission time: it is a critical parameter for UAVs
No “overcovering”, i.e. same area part not covered by two or more
UAVs
Scalability: 10 or 100 or 1000 UAVs? It doesn’t matter!
Fault-tolerance: a UAV crashes? Well, the other UAVs will do its
job!
No centralised coordination entity: purely self-organising

Scouting with UAV Flocks Flock Shape
Choosing Flock Shape
Objective: No “overcovering”
Any ﬂock shape where a UAV is not behind another UAV avoids
overcovering
Left Shape does not avoid overcovering
Center and Right Shapes avoid overcovering
In general, any linear shape with no overlapping has the desired
characteristic

Scouting with UAV Flocks Flock Objective
Flock Objective
R4—Scout a certain area of terrain
Implementation
Ideal ﬂock shape: linear
leader-followers approach
The Leader plans the path
The Followers follows the leader

Scouting with UAV Flocks Path Planning
Flock Communication
Agents communicate
Short-range Broadcast Communication + Gossiping
Each agent periodically spread (in broadcast):
1 Telemetry data (its own position)
2 Information on area parts already covered
Data 1 is used by everyone for ﬂocking
Data 2 is used by the leader to perform path planning

Scouting with UAV Flocks Leader Election
Flock Communication
Leader Election
A leader-followers approach requires leader election

Flock Communication
Leader Election
Algorithm for leader election must be fault-tolerant and distributed,
and must guarantee an agreement

Flock Communication
Leader Election
Since each agent periodically broadcasts data, “all agents will soon
know all agents”

Flock Communication
Leader Election
know all agents”
Each agent can individually choose the leader on the basis of a
common rule: e.g. the known agent with the lowest “ID”

Flock Communication
Leader Election
know all agents”
Each agent can individually choose the leader on the basis of a
common rule: e.g. the known agent with the lowest “ID”
If the leader crashes, it won’t send data anymore and soon disapper
from the list of known agents ⇒ the known agent with the lowest
“ID” will be the new leader

Scouting with UAV Flocks Flocking
Flocking Rules
Reynold’s Rules
R1—Separation
R2—Alignment
R3—Cohesion
The concepts must be maintained ...
... but the implementation must consider the main objective:
linear formation line

Flocking Rules
R1—Separation
Vy computed as (inversely) proportional to the distance to the
nearest agent
The aim is to avoid collisions (along y) and to “make space” to host
a new agent into the formation line
Vx (computed by rule R3—Cohesion) is forced to “0” if the agent is
“too close” to another agent (avoid collision along x)

Flocking Rules
R2—Alignment
Objective: to copy leader’s heading
wz (yaw speed) computed as proportional to the diﬀerence between
this agent’s heading and leader’s heading

Flocking Rules
R3—Cohesion
Vx computed as directly proportional to the distance to the formation
line (unless rule R1 intervenes)
Vy computed as directly proportional to the distance to the nearest
agent in the direction of the leader (unless rule R1 intervenes)

Practical Aspects
Practical Aspects
Practical Aspects

Practical Aspects
Algoritm Tuning and Test
Vx , Vy and ωz computed by R1, R2 and R3 are subject to
“proportionality criterias” driven by some coefficients
Such coeffients must be properly tuned
Tuning strongly depends on UAV dynamics
Wrong tuning may cause:
Collisions
Oscillating flock behaviour
Flock partition
Instability

Practical Aspects
Algorithm Implementation, Tuning and Test
Steps

Practical Aspects
Steps
1 Basic Simulation of the Algorithm

Practical Aspects
Steps
2 Graphical 2D Simulation of the Algorithm

Practical Aspects
Steps

Practical Aspects
Steps
4 Simulation of real/physical behaviour of UAVs

Practical Aspects
Steps
5 Simulation of real implementation of the algorithm (includes
ﬂight stack and network)

Practical Aspects
Steps
ﬂight stack and network)
6 Porting to real UAVs

Practical Aspects
Steps
1 Basic Simulation of the Algorithm—Done!
2 Graphical 2D Simulation of the Algorithm—Done!
3 Graphical 3D Simulation of the Algorithm—Done!
4 Simulation of real/physical behaviour of UAVs—Done!
ﬂight stack and network)—Almost Done!
6 Porting to real UAVs—Not yet done :-(

Practical Aspects
Bibliography
Bibliography

Practical Aspects
References
[1] Fabio DUrso, Corrado Santoro and Federico Fausto Santoro: Integrating
Heterogeneous Tools for Physical Simulation of multi-Unmanned Aerial Vehicles,
WOA 2018, Palermo, Jun. 27-29 (2018)
[2] Massimiliano De Benedetti, Fabio D’Urso, Giancarlo Fortino, Fabrizio Messina,
Giuseppe Pappalardo, Corrado Santoro: A fault-tolerant self-organizing ﬂocking
approach for UAV aerial survey. J. Network and Computer Applications 96: 14-30
(2017)
[3] Massimiliano De Benedetti, Fabrizio Messina, Giuseppe Pappalardo, Corrado Santoro:
Web-based Simulations of Multi-agent Systems. Simulation 93(9): 737-748 (2017)
[4] Sebastiano Battiato, Luciano Cantelli, Fabio D’Urso, Giovanni Maria Farinella, Luca
Guarnera, Dario Guastella, Carmelo Donato Melita, Giovanni Muscato, Alessandro Ortis,
Francesco Ragusa, Corrado Santoro: A System for Autonomous Landing of a UAV on
a Moving Vehicle. ICIAP (1) 2017: 129-139

Practical Aspects
References
[5] Massimiliano De Benedetti, Fabio D’Urso, Fabrizio Messina, Giuseppe Pappalardo,
Corrado Santoro: 3D Simulation of Unmanned Aerial Vehicles. WOA 2017: 7-12
[6] Tobia Calenda, Massimiliano De Benedetti, Fabrizio Messina, Giuseppe Pappalardo,
Corrado Santoro: AgentSimJS: A Web-based Multi-Agent Simulator with 3D
Capabilities. WOA 2016: 117-123
Corrado Santoro: UAV-based Aerial Monitoring: A Performance Evaluation of a
Self-Organising Flocking Algorithm. 3PGCIC 2015: 248-255
Corrado Santoro: Self-Organising UAVs for Wide Area Fault-tolerant Aerial
Monitoring. WOA 2015: 135-141

Practical Aspects
Physical Flying Agents: Ummanned Aerial Vehicles
Control, Coordination and Emerging Behaviour of
multi-UAV systems
Corrado Santoro, Fabio D’Urso,
Fabrizio Messina, Federico Fausto Santoro
ARSLAB - Autonomous and Robotic Systems Laboratory
Dipartimento di Matematica e Informatica
Universit`a di Catania, Italy
santoro@dmi.unict.it

Physical Flying Agents: Ummanned Aerial Vehicles Control, Coordination and Emerging Behaviour of multi-UAV systems

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Physical Flying Agents: Ummanned Aerial Vehicles Control, Coordination and Emerging Behaviour of multi-UAV systems

Similaire à Physical Flying Agents: Ummanned Aerial Vehicles Control, Coordination and Emerging Behaviour of multi-UAV systems (20)

Plus de Corrado Santoro

Plus de Corrado Santoro (20)

Dernier

Dernier (20)

Physical Flying Agents: Ummanned Aerial Vehicles Control, Coordination and Emerging Behaviour of multi-UAV systems