Hexacopter With Gripping Module: Mechatronic Engineering, 180 Credits

Degree Thesis
Mechatronic Engineering, 180 credits
Hexacopter with gripping module
Degree Project Mechatronic Engineering,

15 credits
Anders Bogga, Emil Andersson

HALMSTAD
UNIVERSITY
Abstract
The 2018 CPS-VO challenge is a competition focusing on the development of a
drone which has the ability to search a area for a lost drone and recover it to a specific
destination, all this is to be done autonomous. To participate in the challenge three
thesis projects was done by three different teams. Those three projects combined
created an autonomous hexacopter to compete with in the challenge.
The thesis focuses on the development of a hexacopter with a gripping module which
is to be used in the challenge. There are two main goals with the thesis. The first goal
was to create a computer model of a hexacopter with a gripping module to be used in
a simulation software called Gazebo. The simulation is controlled via Robot Operating
System and is used as a basis for hardware development.
The second goal was to use the results from the simulation to build a real hexa-
copter with a gripping module which can be used in the challenge. The hexacopter
construction was based on own designs and all fabrication of parts for the gripping
module was done using SolidWorks and 3D printers.
The result became a hexacopter with a high thrust and a gripping module which can
grab and hold on to recovered objects. The hexacopter was used during 2018 CPS-VO
Challenge which was taking place in Arizona in May 2018.
Sammanfattning
2018 CPS-VO challenge är en tävling med fokus på utvecklandet av en drönare med
egenskapen att söka av ett område och hitte en förlorad drönar och bärga denna, allt
detta autonomt. För att kunna delta i tävlingen gjordes tre separata examensarbeten.
Dessa tre examensarbeten tillsammans bildade en autonom hexakopter som användes
i tävlingen.
Fokus i detta examensarbete ligger på utvecklandet av en hexakopter med en grip-
modul som kan användas i tävlingen. Det finns två huvudmål med detta arbete. Det
första målet var att skapa en digital modell av hexakoptern och gripmodulen som kun-
de användas för att simulera hexakoptern i Gazebo. Simuleringen styrs med ROS och
användes som en grund till hårdvaruutvecklandet.
Det andra målet var att använda resultaten från simuleringen till att bygga en riktig
prototyp av en hexakopter med en gripmodul som senare kunde användas i tävlingen.
Konstruktionen av hexakoptern baserades på en egen design och all tillverkning av
delarna till gripmodulen gjordes i SolidWorks för att sedan skrivas ut på en 3D skrivare.
Resultatet blev en hexakopter med en hög lyftkapacitet och en gripmodul som kan
gripa tag och hålla i ett objekt. Hexakoptern användes under 2018 CPS-VO challenge
som ägde rum i Arizona i Maj 2018.
i
ii
Contents
Abstract i
Contents iii
Acronyms v
1 Introduction 1
1.1 Goals & Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Thesis limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Specification of requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Related work 3
3 Theory & background 5

3.1 Multicopters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 The parts of a multicopter . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Software & Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Dronecode Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.3 Catkin build system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4 MAVROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.5 Gazebo Physics Simulator . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.6 SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Gripping module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Gripping mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 Arduino Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3 Servo motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Method 13
4.1 Choosing a multicopter frame . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Setting up a simulation platform . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Modelling the hexacopter for simulation . . . . . . . . . . . . . . . . . 13
4.2.2 Modelling the gripping module for simulation . . . . . . . . . . . . . . 14
4.2.3 Simulating with Gazebo & ROS . . . . . . . . . . . . . . . . . . . . . 15
4.2.4 Simulation tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Hardware choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 Hexacopter hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.2 Gripping module hardware . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.3 Feedback test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Gripping module design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1 Structural testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Results 29
5.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Hexacopter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1 Squeezing claws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.2 Gripping claws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Spacers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5 Gripping module test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6 Challenge results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Discussion & conclusions 39

6.1 Problem statement answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Future improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.3 Social requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4 Lessons from the CPS-VO Challenge . . . . . . . . . . . . . . . . . . . . . . . 42
iii
References 43
7 APPENDICES 44
7.1 Specification of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2 Time plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.3 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
iv
Acronyms
3D Three Dimensional. 1, 3, 10, 13, 15, 20, 24, 39, 41
AC Alternating Current. 7
ADC Analog to Digital Converter. 11
API Application Program Interface. 8, 10, 15
CAD Computer-Aided Design. 1, 10, 13, 14, 30, 39, 40
CPS-VO Cyber Physical Systems Virtual Organization. 1, 2, 13, 29, 39, 42
DC Direct Current. 6, 7, 11
ESC Electronic Speed Controller. 7, 13, 20
FEA Finite Element Analysis. 25, 26
GPS Global Positioning System. 8, 9

GUI Graphical User Interface. 10
HITL Hardware In The Loop. 29, 39
IDE Integrated Development Environment. 11

IMU Inertial Measurement Unit. 9, 10
LIDAR Light Detection And Ranging. 10

LiPo Lithium-ion Polymer. 7, 20, 41
LIPS Linköpings Projektstyrningsmodell. 13
MAVLink Micro Air Vehicle Communication Protocol. 8, 9, 15
PID Proportional-Integral-Derivative Control. 16
PLA Polylactic Acid. 25, 31, 41

PWM Pulse-Width Modulation. 7, 11, 21, 22
RADAR Radio Detection And Ranging. 8, 10

ROS Robot Operating System. 1, 3, 8, 9, 13, 15, 16, 17, 22, 29, 34, 39, 40
RPM Revolutions Per Minute. 6, 20
SDF SDFormat. 10, 15, 16, 40
TPU Thermoplastic Polyurethane. 31, 41
UAV Unmanned Aerial Vehicle. 8, 37, 42
v
1 Introduction
The use of drones is steadily increasing and they incorporate many different areas of tech-
nology. A study made by Single European Sky ATM Research (SEASAR), which is project
run by the European Commission, predict that before 2020 there will be more than 5 million
drones in circulation just for leisure, then on top of that there is also military, government
and commercially used drones. Expected mission types for drones are different types of
surveying and light load movement [1].
For a drone to be able to interact with the real world and have the capability to carry
light loads it needs to be fitted with some external gripping device. This thesis focuses
on constructing a drone that can carry light loads by integrating a control system for a
gripping module with an on-board computer. The results from this thesis along with the
results from two other theses will be used in a challenge hosted by Cyber Physical Systems
Virtual Organization (CPS-VO) in May 2018.
CPS-VO is a collaboration between academia, government and industry created to assist
in the development of cyber-physical systems. In 2018 CPS-VO organise a challenge [2]
mainly for undergraduate students to create a multicopter vehicle with the capability to
search for, pick up and bring back another crashed multicopter.
1.1 Goals & Purpose

The first goal of this is to create a computer model of a drone with a gripping module
attached to be used in a simulation program. The lessons learned from the simulations are
to be used to aid in the development of the real drone. The first goal has to be done by half
time to qualify for the CPS-VO Challenge.
The second goal, which in part will be based on the results from the first goal, is to
design and choose the mechanically related parts for the drone as well as constructing a
lightweight, sturdy, gripping module to be placed on the drone and implemented with the
companion computer on board.
The purpose of the project is to be one out of three bachelor thesis projects fused into
one complete solution that will be used to compete against other teams in the CPS-VO
Challenge, as well as investigating the questions from the problem statement below.
1.2 Problem Statement

• What is important to be aware of when creating a simulated environment, for a mul-
ticopter, to provide a foundation for later construction stages?
• What is important to consider when constructing a multicopter with a gripping mod-
ule, and how does the module affect the multicopters performance?
1.3 Thesis limitations

To be able to participate in the CPS-VO challenge the software requirements are to use the
open source software Robot Operating System (ROS) and PX4 flight stack for the drone
auto pilot. The organisers from CPS-VO supply a server with simulation capabilities based
on the simulating program Gazebo. The intention is to use the results from the project in
the challenge and therefore that is the simulator that will be used during the project.
The thesis is focused on building and choosing parts for a drone with a controllable
gripping module and since the market for drones and drone parts is quite big it means
there are many configurations available. Parts for grippers however are rarely tailored to
a specific drone and therefore the project naturally puts more construction focus on the
gripping mechanism. The fabrication of parts for the gripping module will make use of Three
Dimensional (3D) printers and the Computer-Aided Design (CAD) software SolidWorks
because of the short time to produce prototypes and the low cost of plastic filament.
There will be no design or production of electronic parts which means that as far as
possible prefabricated parts will be used, that includes motors, motor controllers, PCB
boards, flight control computers, etc. The flight control of the drone will be handled by a
PX4 compatible flight controller and will therefore not be developed independently.
1
The aerodynamic design of the drone and gripper will not be studied, instead the design
will be kept as symmetric as possible to avoid uneven weight distribution and wind flow.
1.4 Specification of requirements

Some aspects to take into consideration when constructing a drone are the following:
• Lift capacity: It is important to know the weight of all components so that the total
weight is not heavier than the total thrust from the motors.
• Energy: The amount of energy on a drone is limited to the capacity of the battery.
Increasing the capacity of the battery means adding more weight, more weight means
more thrust is needed, more thrust means a higher energy consumption, therefor con-
servation of energy is important. Every system on the drone uses power and the total
usage in comparison to the total capacity needs to be balanced.
The drone and the gripping module specifications are partly based on how the pick up
scenario was phrased and some software requirements from the organisers, the requirements
were not as clear as they are described below since it is a summary from the web page,
emails and discussions. The specification of requirements for the drone and gripping module
were however based on the following:
CPS-VO 2018 Challenge requirements
• The geometric shape of the object to pick up should be similar to the drone being used
in the challenge.
• The object to pick up should weigh 10-20% of the drone used for the pick up. This
means that the drone should manage to lift a load of at least 10-20% of its own weight.
• The drone should have the ability to both pick up and drop off the object intended to
lift.
• The drone should be capable of a pick up and drop of mission of about 15 minutes.
• There are no limitations on how the object should be picked up and some modification
to the object can be done to make it easier to grasp and detect.
• Software:
– For control of the drone Robot Operating System and PX4 flight stack should be
used.
– Before to the final challenge a simulation of the drone and the gripping module
should be created so that a prejudging of the team’s ability can be done.
With all that in mind a Specification of Requirements have been made and can be seen in
appendix.
2
2 Related work
In the report Avian-inspired grasping for quadrotor micro UAVs [3] researchers at Pennsyl-
vania University focus their efforts on a quick pickup of an object by imitating the behaviour
of an eagle grasping its prey. Drones are not energy efficient and by having a quick pick
up resources can be used elsewhere like giving the drone a longer reach. A high level of
integration is needed between manipulator and navigation system for the solution to work.
A report with a different approach to gripping from IEEE called Grasping Without Squeez-
ing: Design and Modelling of Shear-Activated Grippers [4] focuses solely on the technique of
grasping an object with adhesion-controlled friction which lowers the squeezing force making
it possible to lift fragile and deformable objects.
Object manipulation from a drone in flight using a manipulator require kinematic and dy-
namic models as well as a navigation system that can tolerate reaction forces from the
external environment. In the paper Aerial Manipulation Using a Quadrotor with a Two
DOF Robotic Arm [5] the authors take the arm into consideration when creating the math-
ematical model instead of regarding it as a disturbance to the PID controller.
Another different technique is to use granular material placed inside an elastic bag which
is pushed onto an object, the gas between the granules is evacuated and the bag contracts
around the granules which make them hold their form. The report Universal robotic gripper
based on the jamming of granular material [6] investigates what materials to use and comes
to the conclusion that it is able to grasp complex shapes particularly well.
ROS is very useful when controlling a robot and in the paper On 3D Simulators for Multi-
Robot Systems in ROS: MORSE or Gazebo? [7] several alternatives for simulation to go
with it are presented. Most simulators use C++ programming language except for MORSE
which is Python based. The most supported and used simulator is Gazebo which is main-
tained by Open Source Robotics Foundation which also maintain ROS. The results from the
study showed that MORSE could simulate at a higher real time factor than Gazebo under
heavy load. Both simulators are open source and free to use.
There is a lot to take into consideration when constructing a multicopter and in the paper
Design and Prototyping High Endurance Multi-Rotor [8] design and analysis is thoroughly
looked at in spite the disadvantages of multi-rotor air crafts such as reliance on heavy bat-
teries and the need for constant propulsion.
Conclusions from related work:
Attributes that need to be defined that are related both to the object being manip-
ulated and the device grasping it are the following:
• Circumstances: Depending on under what circumstances the object is being
picked up it can require higher levels of integration of the control system for the
manipulator. If the pick up is happening under a controlled, uniform, situation
it requires a less complex control system meaning it can be more robust and
have a bigger chance of success.
• Size: The size of the object matters and affects the size of the mechanism, and
in what way the mechanism needs to grab the object. The shape of the gripper
is therefor affected directly by the size of the pick up object.
• Shape: Either a generic way to pick up objects needs to be used or a more
tailored solution based on what the intended object to pick up is. If the shape
is very difficult to grasp the gripper might need to be less generic.
• Surface friction: The way an object is picked up is dependant on if it can
be held by inward force alone and if the friction of the gripper on the object is
enough or if there is a need to mitigate the force of gravity in another way.
• Control: A control system with plenty of community support while developing
can be helpful during development.
• Simulation: To be able to test a robot before it is used a simulator can save
a lot of time and resources.
3
4
3 Theory & background
The theory relevant to this thesis can be divided into three parts:
1. Multicopters: Describes what the different parts are called and what relevance they
hold and how they work.
2. Software & simulation: Explains what software is intended to be used mainly for
simulation but also during flight.
3. Gripping module: Contain information about different mechanisms for gripping and
how servo motors work and how they can be controlled using development boards like
the ones from the Arduino family.
3.1 Multicopters
A multicopter, more commonly known as a drone, is a helicopter with more than two
propellers. Different types are called quadcopter see in figure 3.1.1, hexacopter see in figure
3.1.2 and octacopter see in figure 3.1.3, where quad, hex and octal stands for how many
propellers the multicopter have. More than two propellers make the multicopter easier to
control compared to a helicopter, but at the expense of the load capacity and fly time.
The structure of a multicopter can be varied to look very differently depending on what is
needed, the key design feature how ever is to keep the propellers in a symmetric pattern.
The illustrations below show common quad-, hex- and octa-configuration.
Figure 3.1.1: Quadcopter Figure 3.1.2: Hexacopter Figure 3.1.3: Octocopter
The propeller on a helicopter uses a pitch mechanism while a multicopter has a fixed pitch.
This means that a helicopter can keep a constant speed on the propeller while using the pitch
mechanism to move, the multicopter need to change the rotation speed on some rotors to
be able to move. By increasing and decreasing the speed on the motors the multicopter can
create different movements, up, down, forward, backward, pitch, roll and yaw. Changing the
speed up and down requires more energy than changing the pitch mechanism in a helicopter.
A multicopter is considered to have a simple mechanical structure and therefore it is
cheaper to build and easier to work with as long it is in a small size. Larger multicopters
can be built by adding more propellers which will increase the load capacity but also increase
the energy usage which in turn might require a larger battery for the fly time to remain the
same [9, p. 3–5].
3.1.1 The parts of a multicopter

The following are the main parts of a multicopter [9, p. 33–54].
Frame
The frame is basically the body of the multicopter. Shape and material can vary depending
on size and design. A larger frame often have more arms than a small frame and a large
frame is often built in carbon fibre or aluminium or both combined while a small one often
is in plastic.
The motor axes create a circle and the diameter of this circle is used to specify the size
of the multicopter. The size is usually measured in millimetres. This size determines the
5
maximum size of the propellers and by adding longer arms larger propellers can be used.
Propellers
• Size & pitch: Propellers are normally named after their size and pitch by referring
to a four digit number. The two first digits describe the radius and the two last digits
describe the pitch, both measured in inches. The pitch is defined as ”the distance a
propeller would move in one revolution if it were moving through a soft solid, like a
screw through wood.”.
• Material: Commonly used material for propellers is carbon fibre, plastic or wood.
Carbon fibre is more expensive than plastic and wood but has the advantages such as
less vibration, lighter and stronger.
• Number of blades: The amount of blades on the propeller can vary and the most
common are two, three or four blades. By increasing number of blades the char-
acteristics are changed, more blades result in a higher thrust while the efficiency is
decreased.
Motors
The most common motor used on a multicopter is brushless Direct Current (DC) motor,
this due to a high efficiency, small size and low cost. Some important parameters are the
following:
• Size: The name of a motor for multicopters often contains a four-digit number. This
number specifies the size of the motor in millimetres. An example is the Sunnysky
X4110S 460KV, where 4110 is the number specifying the size. 41 is the diameter of
the stator while 10 is the height, so this motor has a stator which is 41 mm wide and
10 mm high.
• KV: When choosing motor the KV value is important. This is a value that describes
the motors rotation relative to the voltage supplied, the Revolutions Per Minute (RPM)
per Volt (RPM/Volt).
For example, when powering the previously mentioned Sunnysky X4110S 460KV with
22.2V, it would rotate:
KV ∗ V = RPM ⇒ 460 ∗ 22.2 = 10212 RPM
If looking at the Arris X2205 2300KV which has a higher KV value, this would rotate:
KV ∗ V = RPM ⇒ 2300 ∗ 16 = 36800 RPM
The value describes the speed of the motor without a load, when adding a propeller
the speed will decrease depending on the propeller specifications.
A motor with low KV is often able to generate more torque than one with a high KV,
and is therefore more suited drive a larger propeller. Low KV combined with high
torque gives a slower but heavy-lifting multicopter while a motor with high KV would
be better for a low weight racing drone due to the speed.
• Thrust to weight ratio: This is an useful guideline when building a multicopter. It
says that the thrust of all the motors together should be at lest twice the weight of the
drone. This guideline is used to ensure that the motors always have enough thrust to
handle, e.g. situations where it needs to make rapid movements or strong winds. It is
calculated by the following formula:
Thrust
= Thrust-to-weight ratio
Weight
• Thrust: The following two tables, figure 3.1.4 and figure 3.1.5, show the specification
of the previous two mentioned motors. This tables are provided by the manufacturer.
The thrust depends on which propeller and what voltage is provided. As seen in the
tables, the Sunnysky X4110S 460KV have a maximum thrust of 2520 gram while
the Arris X2205 2300KV has a maximum thrust of 1010 grams. The total thrust is
6
calculated by multiplying the thrust with the number of motors. For example if a
hexacopter was provided with the Sunnysky X4110S 460KV it would give a maximum
total thrust of:
6 ∗ 2.52 = 15.12kg
Figure 3.1.4: Arris X2205 2300KV
Figure 3.1.5: Sunnysky X4110S 460KV
Electronic Speed Controllers (ESCs)

An ESC is an electrical circuit that is used to control the speed on the motor. This is done
using a Pulse-Width Modulation (PWM) signal which the flight controller circuit sends to
the ESC. Based on the PWM signal the ESC transform the power from a DC battery to a
three phase Alternating Current (AC) like signal which control the speed of the motor.
Batteries
One of the most commonly used batteries for multicopters is the Lithium-ion Polymer (LiPo)
battery. Two important parameters when describing batteries are the capacity, measured
in ampere hours (Ah), and and voltage, measured in volts (V). The nominal voltage of a
single LiPo cell is 3.7 V, and when fully charged it can reach up to 4.2 V.
LiPo batteries are often described with an S-number, like 1S, 2S, 3S etc. This refer
to how many cells connected in series are in the battery. For example, a 2S is equal to
2 ∗ 3.7 = 7.2V while a 6S is equal to 6 ∗ 3.7 = 22.2V . Easy to remember is that in a battery
connected in series increase the voltage whereas a battery connected in parallel increase the
capacity.
7
Electronics for control & calculation
A flight controller is a small computer on a drone which handle the control of the motors
making it able to be navigated in air. Different complexities of flight controllers exist making
it all from only being able to be manually controlled to having a full on autopilot making
the drone able to fly autonomously.
A common expression for a second computer on board a multicopter which handles other
tasks than the flight controller is a companion computer. This computer can run a separate
program which sends signals to the flight controller as means of navigation. The companion
computer can make use of different sensors like a camera, a Radio Detection And Ranging
(RADAR) system, lasers etc. to calculate and take decisions on where to navigate to.
When the autopilot fails or just simple control of the drone is enough a hand control can
be used together with a radio transmitter to manually control the multicopter by sending
control signals to the on board receiver.
3.2 Software & Simulation

3.2.1 Dronecode Project
The Dronecode Project is a platform that offers everything needed to fly a drone. It supplies
an open source solution to flight-controller hardware, autopilot software, ground control
station software and Application Program Interfaces (APIs) for development. Several other
organisations, like the developers behind ROS and Gazebo, cooperate with the platform.
The Dronecode Project is an end-to-end Unmanned Aerial Vehicle (UAV) solution and
include three main parts [10].
• PX4: An autopilot software that is used to control the flight of a UAV which use spe-
cific vehicle control hardware that can use Global Positioning System (GPS), positioning-
and distance sensors etc. PX4 supports a wide range of different air frames and also
provide several vehicles to use for simulation in Gazebo.
• Micro Air Vehicle Communication Protocol (MAVLink): A lightweight header
only message library using a publish-subscribe structure which is optimised and useful
on applications with limited communication bandwidth.
• QGroundControl: Is a flight control station which provide configuration, setup as
well as UAV flight support and mission planning.
3.2.2 Robot Operating System

ROS.org [11] gives the following description:
”ROS (Robot Operating System) provides libraries and tools to help software
developers create robot applications. It provides hardware abstraction, device
drivers, libraries, visualizers, message-passing, package management, and more.
ROS is licensed under an open source, BSD license.”
ROS works like a peer-to-peer network of processes and can either be run on just one machine
or divided over many. It is designed to be as thin as possible, meaning it does not add on
unnecessary extra features. Because of this, it can easily be integrated with other robot
software frameworks. ROS mainly runs on Unix-based platforms and is tested on Ubuntu
and Mac OS. Which means most support for ROS exists for those operating systems.
A short conceptual overview of ROS related to the thesis is summarised below:
• Packages: The main part for organising software in ROS. It can contain nodes, mes-
sage definitions, configuration files, etc. which all work together to create a package.
• Stack: A stack is a collection of packages working together.
• Nodes: Nodes are computational processes and a control system normally use many
nodes where each node controls a specific process. A node can control a sensor, a
motor or control path planning etc. The code to write a node make use of a client
library like rospy (python) or roscpp (C++).
8
• Topics: Topics are distribution systems for messages. This is where the specific data
from computations in nodes are posted. Other nodes can subscribe to or publish new
data in as many nodes as needed, as long as it sticks to the message type connected
to that topic.
• Message: A .msg file defines the data structure of a message being sent. ROS provides
a library called std msgs which contains predefined messages like int8, float32, string,
time, etc. A package can also define its own message types if needed.
• Master: The master keeps track of the Computation graph which makes nodes able
to find the right topics etc.
• Parameter server: In the parameter server all data is stored in parameters, it is
part of the master.
• Services: Instead of just subscribing and publishing to topics a service can be used
which provides the ability to send a request and not continue until a reply has been
given.
• Actions: Actions is what is called a higher-level-concept and it consists of the actionlib
package. Actions are like services but there is a possibility to cancel the request as
well as to get feedback about the progress.
As an example figure 3.2.1 illustrate how a small part of a ROS system controls navigation
based on imaging from a camera by using subscribers, publishers and topics.
Figure 3.2.1: ROS concept
3.2.3 Catkin build system

The Catkin build system [12] is used to build packages in ROS. It uses a collection of CMake
macros and associated Python code. A Catkin workspace consists of 4 spaces:
• Source Space: Location folder = src, contain source code to all packages.
• Build Space: Location folder = build, where CMake is invoked to build packages.
• Development Space: Location folder = devel, where build targets are placed before
being installed.
• Install Space: Not needed but good to have, defaults to /usr/local which is not
recommended or optimal [13], it contain installed builds.
3.2.4 MAVROS
MAVROS is a ROS-node that provides communication driver for autopilots using MAVLink
protocol. Several different plugins can be added to provide support and publish topics like
9
radio, actuator control, GPS data, Inertial Measurement Unit (IMU) states, local-position,
manual control, safety areas, set points etc.
3.2.5 Gazebo Physics Simulator

Gazebo [14] is a free open source 3D physics simulator which can accurately simulate in-
door and outdoor environments with robots of different kinds. It can be used to simulate
algorithms and robot design before building a real robot. Gazebo supports four different
kinds of physics engines, the default one which is being used for this thesis is called Open
Dynamics Engine (ODE) [15]. Gazebo has an easy to use Graphical User Interface (GUI)
trough which a robots virtual behaviour can be observed while running different code and
algorithms.
3.2.6 SDF
The behaviour of the physics engine and geometry in a simulation can be described to
Gazebo by using .xml code structured in SDFormat (SDF) [16], below is a short descriptive
list of elements and attributes relevant to the thesis that is used to describe robots and the
environments they are in. The information is relevant to the SDF API version 1.5 [17].
• World: The world element describes an entire world that can contain models, lights,
physics-engine attributes, camera settings etc.
• Physics: The physics element contain the properties of the dynamics engine like what
engine to use and if it should have any general attributes spanning all objects like how
many contacts collision objects can have or how exact the calculations should be. All
properties have a default value but sometimes values like what real time update rate
it should be or how big the calculation step time should be can be tweaked to improve
performance.
• Model: The model element describes a geometric object with or without joints. A
whole robot might contain many different joints and links whereas a simple model of
a box might only contain a link and no joints.
• Link: Describes a physical link with properties like inertia, mass, collision geometry,
visual geometry, texture, position etc.
• Sensor: Describes properties and type of sensor which can be an IMU, RADAR, Light
Detection And Ranging (LIDAR) or other types of sensors.
• Joint: Joints describe kinematic and dynamic properties of a connection between
links.
• Collision: The collision geometry of a link is where that link collides with other
collision geometry. What is referred to as a collision box can be of a simpler geometry
than the visual one to simplify calculations for the physics engine. Both the visual
and the collision element can be either a mesh in the form of .stl or .dae which are
both 3D CAD files, or a simple geometric shape like box, cylinder, sphere etc.
• Visual: The visual element can be more complex than the collision element, and can
even contain textures, materials and light maps to appear more real.
3.3 Gripping module

3.3.1 Gripping mechanisms
In this thesis these three types of mechanisms for creating motion that can be used for
moving a gripping device have been considered:
• Worm gear: Worm gears are gears where one of the gears have a screw-like thread
which drives another gear, often resulting in a movement change of 90◦ . The movement
transferred when the worm slides on the gear resulting in higher friction then a regular
gear pair. Often worm gears result in a high ratio, meaning it takes many revolutions
on the worm gear to revolve the paired gear once [18, p. 34–36]. Figure 3.3.1 illustrates
a worm gear drive.
10
Figure 3.3.1: Worm gear drive [19]
• Lead screw: A lead screw is a nut which is lead by a screw. If the screw rotates
the nut moves up or down and if the nut rotates the screw moves up or down. By
fastening something to either the screw or the nut and keeping the other static a linear
movement can be created.
• Direct drive: When something is directly driven the part that creates the rotational
movement, often a motor, is fastened directly to the part needed to be rotated, often
centred to avoid uneven movement.
3.3.2 Arduino Boards

An Arduino board is a simple easy to use programmable device designed to connect to sen-
sors, relays, motors etc. It is inexpensive and most boards are based on the AVR family
8-bit microcontroller. To easily program an Arduino board the Integrated Development
Environment (IDE) has been developed and is open source just like the hardware designs
for all the boards.
There are several Arduino boards to choose from and one of the smallest ones is the Ar-
duino Nano which can be based on the ATmega328p or the ATmega168 which is identical
microcontrollers apart from the amount on on-board memory. An Arduino board is pretty
much just a carrier board for the microcontroller meaning what every characteristics the
microcontroller has defines the board. As an example of what relevant features a micro
controller can have the following describes the ATmega328p/Atmega168 [20, p. 13–38]:
• In-system programming by on-chip boot program.

• 6 PWM channels (Explained further in the Servo chapter)
• 23 programmable Input/Output (I/O) lines.
• Six- or eight-channel 10-bit Analog to Digital Converter (ADC).
• Two-wire serial interface (Compatible with I2 C)
3.3.3 Servo motors

A servo motor is a motor designed to have its rotation angle, speed and acceleration con-
trolled. The term servo does not imply what type of motor is being controlled, just that is
has position feedback. Basically the motor controller receives a feedback signal indicating
the position of the motor shaft and redetermines how to alter the next control signal to be
sent to the motor. Generally on smaller servos aimed at hobbyists, external feedback signal
as shown in figure 3.3.2 is not provided, some versions with it do however exist.
Simpler servomotors consists of a DC motor which gets controlled by a microprocessor
which in turn receives control signals in the form of PWM signals from an external computer.
The motor control can be either analog or digital, one difference being that the digital control
is more responsive and provides a greater torque. The most inexpensive way to provide
position feedback from the motor shaft is to apply a potentiometer to it, other more exact
sensors like optical or magnetic rotary encoders can also be used [21, p. 73–87].
11
Figure 3.3.2: Servo with feedback
12
4 Method
The project model used is Linköpings Projektstyrningsmodell (LIPS) [22], and in large
context is structured in the following three phases:
• Phase one - Before: Phase one is when the planing of the project, and gathering
of a theoretical base takes place. Some examples of activities during the phase is
researching other similar projects, formulating a specification of requirements, defining
project limitations, setting up a time plan, familiarising with new software etc. After
phase one a rough plan of execution is finished and ready to be used for phase two.
• Phase two - During: The second phase contain the basis for the project methodol-
ogy and focus on implementing and testing the theoretical ideas from phase one into
practice.
The methodology content is structured around three main steps, step one is the simu-
lation part where a digital 3D model is created, which is used for simulation in Gazebo
and controlled with ROS.
The second step is the creation and assembly of hardware by using the results from the
simulations. Mechanical design iterations are made using CAD design and additive
manufacturing, other parts need to be purchased, e.g. motors and electronics. The
end of the second phase contain integration with other systems, testing, etc.
• Phase three - After: Under the third phase the work completed during phase two
is evaluated and analysed, the final report is finalised containing conclusions, results
along with thought, discussions and future improvements from the authors.
4.1 Choosing a multicopter frame

To be able to start simulations and to design a gripping module a decision on what frame
configuration to use has to be taken.
Quadcopters require fewer motors, ESCs and propellers but are vulnerable if any of those
parts fail during flight. A six, or more, rotor copter has a bigger chance of staying in the
air if a propeller or any part driving a propeller fail. A good control system can potentially
compensate for the loss of thrust by increasing the speed on the other working propellers,
but depending on what thrust to weight ratio the copter has it might not be enough.
It is not only the thrust that gets affected but also the steering, a hexacopter can, if it
looses one propeller, shut the paired parallel propeller down and be steered as a quadcopter,
the same goes for a octacopter which can be steered as a hexacopter. A quadcopter however
can not simply be downgraded to a tricopter since the steering works differently.
The final frame choice was based on future potential, a higher chance of handling motor
failure and costs. The hexacopter can handle motor failure better than a quadcopter while
still being more cost effective to build in comparison to a octocopter and above. One of the
most commonly used and tested hexacopter frames, which was the frame chosen for this
thesis, is the DJI F550.
4.2 Setting up a simulation platform

To understand what is important when building a hexacopter with a gripping module simu-
lations were made using Gazebo and controlled using ROS. The first step towards creating
an environment where a gripper mounted on a hexacopter could be tested was to implement
a hexacopter similar to the one intended for use in the real world into Gazebo.
A functioning simulation of a hexacopter was also required by the the hosts from CPS-VO
to show the capabilities of the team.
4.2.1 Modelling the hexacopter for simulation

The software used for simulations has support for working multicopter models but no hex-
acopter models that could be modified to add on a prototype of a gripping module. After
creating a model of a hexacopter, a gripping module can be added for pick up and drop off
tests, but before that 3D models were created and imported into Gazebo.
13
To create models to be used both in Gazebo and for construction calculations the the
CAD software SolidWorks [23] was used. A hexacopter as well as different gripper solutions
were modelled and converted to .stl format which can be handled both by the simulation
software as geometry meshes and by the slicing software supplied by 3D printer manufac-
turers. The fact that Gazebo can use the same format as the 3D printers means that any
models created and used for simulation can later be printed and used on the final prototype.
There were no accurate digital models of the DJI F550 hexacopter frame, so instead they
had to be modelled from scratch. The frame of the multicopter consists of a bottom plate, a
top plate, six arms, a motor on each arm and propellers. Starting out the measurements had
to be estimated only from knowing that F550 describes the diameter between propellers.
The aim in the end was how ever to have an identical CAD model of the drone to used in
the competition.
The top and bottom can be estimated by studying images of the frame plates, and as
a starting point the plates in figure 4.2.1 were modelled based on the DJI S550 hexacopter
frame, which is similar to the F550. Later when the real F550 plates arrived the plates in
figure 4.2.2 were modelled exactly to aid in the design work.
Figure 4.2.1: S550 plates Figure 4.2.2: F550 plates
Two different types of arms were modelled, one regular original shape plastic version
and one extended third party supplier aluminium version. Variations of the plastic arms are
common and many finished models appear online. The extended aluminium arms however
do not appear online and instead the manufacturer was contacted and a rough model was
supplied which is shown in figure 4.2.3 and later refined as shown in figure 4.2.4.
Different propellers are available online so there was no need to model that. Gazebo does
not take into account the shape and size of the propellers when simulating flight so there
was no need to model accurate propellers. Motors to put the propellers on were modelled
so that the propellers did not have to rotate in mid air, this motor is shown in figure 4.2.5.
This was a more cosmetic decision and could have been ignored, it does how ever provide a
more realistic simulation in terms of looks.
Figure 4.2.3: Rough arm Figure 4.2.4: Refined arm

Figure 4.2.5: Motor
4.2.2 Modelling the gripping module for simulation

The development of the gripping module started with finding a solution possible to im-
plement in Gazebo. Modelling granular material or adhesion controlled friction materials,
which are two solutions mentioned under Related work require deep understanding of the
physics engine, as well as modelling viscous material. A working concept which was possi-
ble to implement in the simulator was needed and therefor a claw like concept was chosen.
Mounting the claw on a rope or a winch was decided against for it to not be affected by
winds. Since the idea was to have a claw underneath the hexacopter that meant alot of space
14
would be used and legs to land on or some kind of mechanism to make landing easier would
have to be constructed. By using the claws as landing gear weight and space could be saved
and the first concept was visualised by having six identical arms under the hexacopter. The
first concept is shown in figure 4.2.6.
Figure 4.2.6: First hexacopter with gripper concept.
4.2.3 Simulating with Gazebo & ROS

To be able to implement and control the 3D generated models in Gazebo with ROS both
programs need to be installed and communicate with each other. ROS uses the PX4 flight
stack to control the drone via MAVLink and the physics engine in Gazebo calculates what
happens during collisions and flight while the simulation runs. Below is a description of how
that was achieved.
Setting up ROS with PX4
Installing ROS is covered very thoroughly on the ROS.org web page and many distribu-
tions exist. The most stable and up to date version available at the time was ROS Kinetic,
which was chosen over a the older versions, and the newest less tested version.
The step after that is to setup the PX4 flight stack together with MAVLink and MAVROS.
The PX4 flight stack is combined with the MAVLink API trough which the simulator gen-
erates fake sensor readings to be used by the flight stack.
PX4 then listens through a port for sensor reading or control signals, which need to
follow the MAVLink protocol. When it is all set up a hexacopter can be controlled both
via ROS scripts or via QGroundControl with virtual joysticks or a USB control pad. The
hexacopter can then be simulated by loading a vehicle file via a ROS .launch script, the idea
is to simulate the specific hexacopter that will be used with a gripping module and that
requires a model of both the hexacopter and the gripping module to be implemented. To
control the gripping module a plugin has to be created since that is a more unusual function
and not supported by PX4.
Model implementation
To simulate a hexacopter with an attached gripping module in Gazebo every moving joint
on the gripper must be defined as well a working model of the hexacopter is needed. An
easy way to get started with an model of a hexacopter is to modify an already working
version which is supplied by the PX4 flight stack. The hexacopter available trough PX4
use many different plugins and with has different inertial and mass definitions then the final
hexacopter to be used. To start it was enough to to get a working geometry on which the
gripping module could be attached, and that was done by switching out the base link and
propellers as well as redefining the correct pose for all collision and visual elements. All
inertia and mass properties was kept and all plugins for motors and MAVLink connections
was also kept for the hexacopter to be able to fly.
The exported .stl files of the hexacopter and gripper was defined in an SDF file under visual
geometry and possibly under collision geometry. It is important to be aware of where the
centre of the coordinate system is defined for the stl-file to be able to control the placement
15
of the mesh with the pose attribute. Below is a short description of how geometry was added
to the model:
1. The <static>true</static> was used to make the model totally static. This to easier
see that all models are placed correctly and gravity not changing their position during
simulation. The same behaviour can be achieved by pausing the simulation, but then
joints can not be tested by applying an external force.
2. All links were added with their calculated positions and rotations using the tag
<pose>x y z roll pitch yaw</pose>.
3. Positions were double checked to be sure they were are correctly calculated.
4. Joints were added to to all links and axis limits and movement limitations were added.
5. The model was made dynamic again using <static>false</static> to see if the behaved
correctly.
6. Joint testing was done in Gazebo by choosing the model intended to control and then
pull out the menu to the right and apply forces, velocity or set position. The model
also contain values for PID controllers which can be tuned depending on mass, friction,
inertia etc.
7. If the geometry was working as intended sensors and plugins was added to the model,
and finally a test-flight was performed.
Creating a plugin for the gripping module

The types of grippers intended to be created in this thesis rotate around at least one axis
where the motor supplies the torque and movement. For this to be simulated in Gazebo via
ROS topics, a plugin was created to control the movement of joints. Joints can be controlled
in three different ways:
• Position control by setting to what positions in radians the joint should be moved to.
• Applying an external force to a joint which makes it rotate.
• Setting a velocity to a joint. If a the joint is fixed around an axis, meaning it is a
revolving joint, it will get a spike in velocity which in turn will be slowed down by any
friction coefficient affecting it.
An easy way to get an arm to rotate and then stop at a desired location is to use position
control, another good aspect of using position control is that the joint behaves like a servo
motor. One downside of using position control is that the holding torque is not defined and
how much the arms push back or how rigid they are needs to be handled by increasing the
joint friction.
Plugins for Gazebo are coded in C++ and need to be located so that Gazebo can use
them in the simulator, it is good practice to place it in the src folder of the Catkin package
containing the model and then pointing the Gazebo plugin there. The idea behind the plugin
is to create something that listens to published messages in ROS topics and then moves one
or more joints to the position stated in the message by telling Gazebo where to move the
joint to. The creation of the plugin is based on tutorials updated and maintained by the
Gazebo community [24]. The plugin it self contain the following:
• Inclusion of Gazebo and ROS libraries as well as message types to be published in
topics by the plugin.
• Definitions of specific Gazebo, ROS and SDF variables.
• A main function with pointers, Proportional-Integral-Derivative Control (PID) initia-
tion and starting values for joints.
• ROS initiation, node and topic definitions as well as defining a publisher, a subscriber
and setting up queue handling for messages.
• A callback function that does something on every publish to a certain topic. For
instance if a message of π is published the joint should move a half a revolution i.e.
180◦ .
• Finally the plugin needs to register with Gazebo.
16
When the .cpp file was finished it was placed in the src folder of the relevant Catkin package.
A description of dependencies, required packages, message-types and link-libraries was also
added to the CMakeLists.txt file so that the compilation of the plugin would work correctly.
Initially the package lacked a Build folder and it needs to be created and then the C++
file was built using CMake. It is important to make sure the GAZEBO PLUGIN PATH:=
pointer is pointing at the Build folder otherwise Gazebo will not be able to find the plugin.
Controlling the gripper via ROS
When all the implementation was done the gripping module was able to be controlled using
topics in ROS. Every arm had the potential to be individually controlled and the idea was
to hover above the intended object and pick it up while in the air. This was later changed,
after testing, to have the hexacopter land on the object.
4.2.4 Simulation tests

When all models had been implemented and a working simulation was possible, as shown
in figure 4.2.7. Tests were made using Gazebo, to control the drone a both manual off
board control and automated action scripts were developed and used. The scripts used
for off board control of the the drone, which takes an x-,y- and z-axis input in meters,
was developed by Dennis Mannhart and uploaded to GitHub under the name Stifael [25].
The automated navigation scripts where created by Patrick Karlsson and Emil Johansson,
computer engineers at Halmstad University.
In the simulator the drone can hold a hovering position quite steady but in the real world
winds can make it float around, for the sake of making the solution as sturdy as possible a
decision was taken to have the drone land on top of its object and then grip on to it. Since
the hexacopter needed to land on top and grab on to the object three of the legs rotated
inwards slightly so that the other three legs could close while the drone was in a landed
position.
Figure 4.2.7: Hexacopter with gripper in Gazebo.
The following three tests were conducted after each other and result of each test flight was
studied and improvements were done after each test. Each test is shown in figure 4.2.8.
• Pick up: A controlled landing on top of an object similar to the one to be picked up
in the real world was done. The inner gripping claws were closed on the object and the
drone ascended to about 0.5 meters, then the other gripping claws were closed around
the object. Then the drone continued flying to the next destination.
17
Test outcome:
– The second triplet of gripper claws were made longer to be able to clasp
around the object better for a better secondary gripping safety.
– Initially the friction on objects were set very low, this was noticed during
testing and friction was increased.
– It was noted that the pointy gripping surface of the inner gripping claws
were not ideal and needed improvement if it were to work better in the
real world.
• Holding during flight: The drone was allowed to fly full speed to the new destination
while holding on to the object. When the destination was reached a controlled decent
was done to about 0.5 meters.
Test outcome:
– If the object was able to move while grasped it affected the hexacopters
ability to navigate and it was noted that a steady grasping of the object
was needed for reliability. It was then decided that a different way of
holding on to the object was needed. The initial idea for the Squeezing
Claws were therefore formed, but not implemented due to the difficulty
of modelling the solution in Gazebo.
– The continuous collisions happening while holding the object was affect-
ing the simulation and the real-time-factor dropped significantly. To im-
prove simulation the collision boxes in the arms were removed and simpler
collision boxes for the centre plates were added.
• Drop off: When the hexacopter was at the altitude of 0.5 meters the outer gripping
claws opened and then the inner gripping claws were opened. The object was dropped
of and the hexacopter later returned to a new position for a final landing.
Test outcome:
– Landing while still holding on to the object was decided not to do in case
it moved around while grasped, this also makes the drop of quicker and
in turn more energy efficient.
Figure 4.2.8: Gazebo pick up and flight tests.
4.3 Hardware choices

4.3.1 Hexacopter hardware
Most of the parts on a hexacopter are dependant on each other and when choosing one part
it puts a new set of demands on another. The one most important characteristic to figure
18
out is the weight if the hexacopter, since that in turn puts demand on all parts except the
ones handling calculations for navigation. The full weight of the drone was hard to exactly
pin point before the gripping module was developed and the on board computer was decided
on, but a rough estimation during research for off the shelf parts was set to 6 kg and with
a 20% pay load the final weight in flight would be 7.2 kg.
To aid in the search for parts an online calculator called xcopterCalc [26] was used, it provides
data from different manufacturers and is helpful way to double check calculations. Based on
the arm length and motor shaft placement the largest possible propellers were about 12.8
inches = 325.12 millimetres wide, an illustration is shown in figure 4.3.1.
Figure 4.3.1: Hexacopter dimensions.
• Motor: The motors together with the propellers needed to provide enough thrust to
lift the hexacopter with the gripping module and a payload of up to 20% of the total
weight. Since the aim is to follow a 2:1 thrust to weight ratio, the total minimum
thrust needed to be at least 14.4 kg.
Thrust Thrust
= Thrust to weight ratio ⇒ = 2 ⇒ Thrust = 2 ∗ 7.2 = 14.4 kg
Weight 7.200
To choose the motor a lot research was done and the following aspects were taken into
consideration:
1. Thrust: Of course thrust depends on what propeller is fitted and most manufac-
turers provide data sheets providing information on how much thrust is gained
depending on what battery voltage and propeller is provided.
2. KV-value: The KV-value is in part also connected to what wattage the motor
can handle. If the motor has a low KV-value less heat is created and the motor
can be mounted with wider, or more pitched propellers, which provides more
thrust.
3. Size: The aluminium arms chosen had to be able to fit the motors that were
picked.
19
4. Weight: The weight was not a huge deciding factor since the other attributes are
more important, but it was still taken into consideration when choosing motors.
5. Cost: The cost of motors can vary alot and since six of them are needed, as well
as spares, it was important to not choose motors that were too expensive, since
that would impact what other parts were possible to choose.
Many motors were compared and double checked using the online tool and with a
thrust requirement of 14.4 kg and the final choice was the Sunnysky X4110S 460KV
that with 12x38 propellers give the total thrust of 2520 · 6 = 15120 g. The motors
require 22.2V which means 6S LiPo batteries are needed and the motors can run on a
max continuous current of 26A, which in turn decides the required current the ESCs
should handle. The datasheet for Sunnysky X4110S 460KV can be seen in figure 3.1.5.
• Propeller: The recommended propeller size from the manufacturer was 12x38 but
to get a slightly more responsive hexacopter 12x55 propellers were chosen. This also
provided more thrust which made the motors able to hover on a lower RPM than with
the 12x38 propellers. The potential downside of choosing a more pitched propeller is
that the wattage, and with that the heat, will increase in comparison to the chart,
since the air friction will increase. The maximum stated wattage for the motors are
577 W, which is when used at 100%, a situation that almost never will happen, so
instead of choosing a motor based on an unrealistic situation the increased thrust and
responsiveness was chosen. The material for the propellers were easy to find in carbon
fibre, which is light and strong.
• Battery: The motor choice decided the battery voltage, which was 22.2V and 6 cells
(6S). More Ah gives longer flight time, but also adds on more weight, which gives a
shorter flight time, the key was to find good middle ground. Since the challenge is
located in Arizona the multicopter needs to be transported via air plane. Most airlines
only allow LiPo batteries under 160 Wh to be transported and the maximum Ah of a
6S battery allowed on the plane is therefore:
Wh 160
= ≈ 7.2Ah
V 22.2
Not only did the batteries have to be below 7.2 Ah they also needed to fit on the
hexacopter. Batteries with fitting dimensions were found and had 5.8 Ah and the
dimensions allowed for three to be carried by the hexacopter giving it a total capacity,
when connected in parallel, of 5.8 · 3 = 17.4 Ah. This gave the hexacopter the ability
to have 5.8, 11.6 or 17.4 Ah depending on mission length. Using the online calculator
estimated the flight time to 5, 10 and 15 minutes.
• ESC: When choosing the ESC it must be compatible with the motors and the battery.
ESCs are sold in 5 A steps and as a safety precaution 40 A ESCs were chosen.
• Flight controller & companion computer: One of the requirements from the
challenge organiser was to have a PX4 enabled flight controller, and another team
working on the navigation system chose the Pixhawk 2.1. The companion computer
was chosen to be an Nvidia TX2 by another team working on image analysis and cases
for them as well as other electronics is mentioned under section 4.4.
4.3.2 Gripping module hardware

Motor choice
When deciding on what type of motor was to be used for the gripping module a couple
of different options were available. To make the grippers behave similar to the grippers
simulated a position controlled motor was needed. Position control can be achieved with
basically any motor as long as it has some kind of encoder or device to keep track of how
much and in what direction the motor is going. When that is set up all that is needed is a
feedback system that stops the motor in time, or even winds it back if needed.
To fit all the other parts on the hexacopter and to keep it from not becoming too tall
the main goal was to create a thin solution for the grippers. If one motor were to be used
it would have to either be mounted standing, have a 90 degree gearbox like a worm gear, or
solve it some other way. Most solutions with one motor would need specialised gears, either
20
bought or produced, and the 3D printers available was not able to make small gears that
reliable enough to base the gripping module design on. Instead the decision was taken to
use small servo motors that normally is used in radio controlled cars and similar machines.
Most servo motors are able to move 120◦ or more and that is a wide enough angle to
be able to grip on to an object, during the simulation tests an angle of 90◦ was enough.
The low weight of the servos makes it possible to have one servo motor per gripper without
it becoming to heavy. The following three servo motors were tested and below is a table
showing their characteristics:
Name: Tower Pro SG90 Adafruit 1450 BMS-390DMH

Stall torque 4.8 V(kgf · cm): 1.8 1.6 4.6
Stall torque 6.0V (kgf · cm): N/A 1.8 5.4
Gear material: Nylon Aluminium Aluminium
Weight: 9g 15.81g 22.5g
Type: Analog Analog Digital
Travel angle: ≈ 180◦ 120◦ 120◦
The SG90 has nylon gears and early on in tests some teeth from the gears broke of
and ended up blocking movement inside the servo. To avoid this the Adafruit 1450 servo
motor was purchased for testing because of the aluminium gears and the external feedback
cable it provides. The torque of the Adafruit 1450 was not convincingly powerful when
used for direct drive with a long gripping claw mounted. To provide a higher torque the
DMS-390DMH was chosen as a step up from the Adafruit 1450.
Choosing a development board
To provide PWM signals to the servo motors a development board needed to be chosen. The
gripping module has six motors that can be controlled individually by six different PWM
signals which require six PWM ports on the board. To be able to make us of the feedback
signals from the servo motors six analog ports are required. Both the Arduino Uno, Arduino
Nano and Arduino Micro have the all ports required. The table below show a comparison
between the three different Arduino boards that were considered for the project [20, p. 55].
Model: Arduino Uno Arduino Nano Arduino Micro

Clock speed(MHz): 16 16 16
RAM(KB): 2 2 2.5
Storage(KB): 32 32 32
PWM pins: 6 6 7
Analog pins: 6 8 8
Digital Pins: 14 14 20
Input voltage(V): 7-12 7-9 7-12
Weight: 25g 7g 5g
Price: 109kr 69kr 295kr
Dimensions(WxD): 68x50.5 43.18x17.78 30x18
The low weight and small size of the Nano and the Micro compared to the Uno makes them
a better choice. When comparing the price of the Nano and Micro, the price is similar but
the Nano is easier to find in cheaper clone versions, since it is an older version than the
micro. The clone version provides the same functionality as the original. The final decision
was to use the Arduino Nano based on its low price, similar functionality and small size.
Power conversion/distribution
The battery used on the multicopter is 22.2V while the servo motors used to the gripping
module need 4.8-6V. To run the servo motors a converter was needed which could convert
the voltage from the battery but still provide a high enough current. There was no data sheet
available to show how much current the servo motors needed but by mounting a gripper on
a servo and then forcing it out of its position showed that it could go as high as 0.4-0.6A. To
be on the safe side and to take peak current use into consideration a value of 1.5A per servo
motor was decided on. Since there are 6 servo motors that means the power converter needs
to be able to provide 9A. The two most common ways of power conversion is by using linear
regulators, which burn away the excess energy, or a switching regulator, which turns the
power on and off in quick succession. The linear regulator are quite inefficient but handy to
21
use for low currents, while the switching regulators are able to handle higher currents since
they are more efficient. A switching regulator using a buck converter was chosen and had
the following specifications:
• Input voltage: 4.5-30V

• Output voltage: Adjustable between 0.8-30V
• Output current: 0-12A
Servo motor control

Controlling a servo motor by using ROS was done by programming the Arduino Nano to
create and subscribe to several ROS topics. The data in the messages from the topics
are converted to PWM signals and sent as a control signals to the servo motors. The
package ROSSerial, made to handle serial communication between two computers, handle
the communication between companion computer and the Arduino Nano.
By having a node translating the commands sent from the plugin in Gazebo, the real
servo motor and the virtual grippers can be controlled using the same messages.
A servo motor that provides and external signal from the potentiometer inside can be
used for more advanced control that can be needed when a servo motor is subjected to
a static object. The way the servo motor is controlled is by first sending a position to
the servomotor for closing it, which is 180, then the servo motor will try to travel to that
position. If the servo motor hits an object on its way there it will keep on pushing and
pushing, exerting more force and drawing a higher current. Instead, when the position
should be done, adding a delay is enough, a feedback system can provide the actual position
of the motor shaft, which can be fed back as the control signal making it stop where it is.
By doing this the only signals needed to send i 0 or 180, telling it to move counter clockwise
or clockwise, it will then stop on the static object.
It is not common for micro and mini servos to provide external feedback signals but since
the hardware for it, meaning the potentiometer inside, is already there a modification can
be done to a servo motor to provide the feedback externally, this is shown in figure 4.3.2.
Figure 4.3.2: Feedback modification of DMS-390DMH
By using a multimeter and measuring the pins on the potentiometer while the servo motor
was running it was possible to find what pin was used to provide feedback to the small PCB
inside. A wire was soldered onto the output connection on the potentiometer and then that
wire was connected to a pin on the Arduino Nano.
The illustration in figure 4.3.3 show how the full system is connected including MOSFET
transistors which act as switches that can turn on or of the triplets of claws.
22
Figure 4.3.3: Full system overview
4.3.3 Feedback test

To understand out how the external feedback signal could be used a test to graph the voltage
curve was done. The values presented in the graph in figure 4.3.4 was based on the average
value, based on 100 values, of the feedback signal. By reading the value of the feedback at
specific degrees and saving it to a file, a list containing values for feedback were paired with
what degree was given as a control signal. Initially the early and late values of the feedback
signal seemed to be the same and to get an understanding of what the characteristics of the
potentiometer looked like Matlab was used to script plot a graph to get a visualisation of
the feedback.
Figure 4.3.4: Feedback from servos
In the graph it is clear that the feedback is almost linear in the interval of 30◦ − 150◦ .
Between the values 0◦ − 30◦ and 150◦ − 180◦ the feedback signal stays unchanged indicating
that there is no need to send signals in those regions. If the ratio between angle and feedback
signal is studied along the curve it differs from low angle to high angle indicating that the
potentiometer is not perfectly linear, but linear enough for the application in this thesis.
23
4.4 Gripping module design
To begin with several different solutions for gripping on to an object was investigated. The
ones mentioned under Related Work is some of them. Initially a solution only using one
motor was favoured and two concepts using a similar movement concepts but with different
arms were created:
Figure 4.4.1: Lead screw claw Figure 4.4.2: Worm gear claw
The inspiration for the concept in figure 4.4.1 came from the Makeblock Strong Gripper [27].
Some change of the design has been done to get a lower weight and a wider opening.
The downside of those solutions was that they created a lot of space downwards and the
hexacopter would have to have an even higher mid section, or a more integrated design by
cutting the center boards. The lower center board on the hexacopter is used as a power
distribution board and can not be modified in that way. The gears produced with the 3D
printer were not reliable enough to be chosen as a functional design and the ideas were not
used.
When simulations in Gazebo started to work and a solution for claw needed to be im-
plemented a simple gripping arm was designed for direct drive of a single motor, see figure
4.4.3 and figure 4.4.4. There are many problems that can be solved by having one motor per
arm and some new ones that arise. When there is one motor per arm the movement of each
claw can be controlled individually and if the object to be grasped is of an uneven shape the
way in which the gripping is done can be non symmetric. A first set of grippers shown in
figure 4.4.2 were developed and used during simulation, the functionality was simpler than
figure 4.1.1 but still provided a good enough grasping ability to serve as a base on which to
develop further.
Figure 4.4.3: Long & Short Figure 4.4.4: Concept
Landing on all six arms were tested and was stable, later on when the design changed slightly
the choice to only land on three arms were taken. A tripod uses a similar design is stable
enough to hold as the hexacopter lands. Real tests and simulation tests gave the insight that
a pointy gripping claw was not reliable enough to use in the final design and the arms from
24
figure 4.1.1 was reinvented to be used by a direct drive solution. The dual arm grippers
have the ability to keep the outer gripping part steady trough out its movement and therefor
can be designed to push a bigger area onto the object to be gripped.
Figure 4.4.5: Dual arm gripper
To be able to make the dual arm grippers compact enough to be able to close without
having the other three claws become unstable and long, the design of all six claws had to be
developed further and and the concept of having a triplet of claws that squeeze to hold on to
the object, as well as having a triplet of claws that close around the object was developed.
This concept is shown in figure 4.4.5.
4.4.1 Structural testing

Part of the process of creating parts with SolidWorks was using Finite Element Analysis
(FEA) of the parts. It can be a very powerful analysis tool if used correctly, it is however
difficult to get an accurate FEA on 3D printed parts in Polylactic Acid (PLA) plastic since
they hardly ever are solid. The slicing software often provide features like different types of
infill and layer thickness to save time and material. The infill can also be printed in different
geometrical patterns which also affects the properties of the part. Three different types on
infill can be seen in figure 4.4.6 below:
Figure 4.4.6: Infill variations from slicer software
The mechanical properties of PLA plastics also degrade depending on how much UV-light
has affected it. The FEA tests presented in this thesis are therefore only used to provide an
indication of where weaknesses exist in the geometric design of the part.
Even though the above mentioned issues affect the reliability of the analysis some parts
have still been analysed, with the main focus being on investigating the tensile strength.
The mechanical properties of non annealed PLA plastic can differ between manufacturers
and blends and the specification used during analysing in this report was based on the PDL
Handbook Series on Polylactic Acid [28].
Since the gripping claw is the part on the hexacopter that might be subjected to most force
during a landing or a near crash it is important to be able to know if and what it can
withstand. By subjecting the part to different forces in different magnitudes and angles in
SolidWorks a more sturdy part can be developed and produced.
Figure 4.4.7 below show a FEA of the gripping claw with a force affecting it from the
side, which could happen during landing. The force affecting the part is 300N ≈ 30kg and
100N ≈ 10kg. At 100N the part seems to hold, there is a red spot experiencing 88.4MPa,
which probably will be where the part will break if more force is applied. When increasing
25
the force to 300N, the reason for the red spot is more clear, it is the starting point for how
the claw twists under a force from the side.
Figure 4.4.7: FEA of gripping claw 300N & 100N
Figure 4.4.8 below show the result of a FEA with a force affecting the claw at the base
where the purple arrows are. The force applied is 300N which is close to 30kg. During a
normal landing the force would not be that large since the drone only weighs close to 6 kg.
However if it was a rough landing or a crash, that could very well be the accelerated force
affecting the part.
The yield strength in this analysis is set to 49MPa and the limit for when the colour
shows red set to 88.2MPa, which is 1.8 times the yield strength of the material. The probe
point in the middle of the red area shows that the stress on the part in that particular point
is over 91.3MPa, which most certainly would result in a breakage.
When the same analysis was done using only 70N, which is more similar to the hexacopter
weight, that same point was only subjected to 14.4 MPa, putting it well under the limit of
49MPa.
When the above results are compared with how a gripping claw broke during a test flight
with a hard landing the similarities can be seen when comparing figure 4.4.8 and figure 4.4.9.
26
Figure 4.4.8: FEA of gripping claw 300N
Figure 4.4.9: Hard landing

breakage
27
5 Results
5.1 Simulation
Requirement nr 1: ”The gripping module must have a simulated counterpart model which
can be integrated with a simulation of the drone being used for the CPS-VO Challenge. The
simulation software to be used is Gazebo.”
The first stage in the CPS-VO Challenge 2018 is to upload and participate in a simulation
using a server hosted by GRASP lab at Pennsylvania University. Integration bash scripts
for Linux has been coded with help from the contact person at GRASP, Jnaneshwar Das,
and a successful pick up and drop of simulation has been completed.
The simulation platform was setup with a full from-scratch model of a drone with a
gripping module attached. The model has a downwards facing camera and an implemented
plugin controlling the claws. A simulation environment, shown in figure 5.1.1, based on
satellite imagining of Timpa Airfield outside Tuscon in Arizona has been created together
with a simpler model of a drone acting as a crashed pick up target. To control the servo
motors a translation node has been implemented passing on control signals used with the
Gazebo plugin to the real gripping module, creating a simple Hardware In The Loop (HITL)
simulation. part from this simulation is shown in figure 5.1.2, figure 5.1.3 and figure 5.1.4.
All the software has been tried and implemented with a modified version of an au-
tonomous drone ROS package called simulation control which was created by the search
algorithm group at Halmstad University.
Figure 5.1.1: Environment Figure 5.1.2: Pick up
Figure 5.1.3: Picked up Figure 5.1.4: Drop off
As a further step towards having a finished simulation model a more detailed model was
added in the simulation. This was done in the final stages of the project and only the less
complex claws were programmed to move. The implementation of the final design is however
a step towards creating a realistic simulation that could be perfected and later used for more
precise simulations, see figure 5.1.5.
29
Figure 5.1.5: Final simulation version
5.2 Hexacopter
The finished hexacopter with gripping module attached consists of cases for electronics,
spacers to hold and make room for batteries, two different types of gripping claws and a
camera mount. Figure 5.2.1 show the CAD drawing made using SolidWorks and figure 5.2.2
show the real hexacopter carrying a light load while flying.
Figure 5.2.1: CAD version of hexacopter
Figure 5.2.2: Real version of hexacopter
30
5.2.1 Squeezing claws
The squeezing claws have two arms, one that is moved by a servo motor and one that
provides a second rotational point on the part that is rotated on to the object, see figure
5.2.3. The arms hold on to a triangular shaped plate, which is the part being rotated on
to the object, and one rubber tip holder which has a flexible material which bends inwards
linearly. The triangular shaped plate and the rubber tip rotates between the arms making
the squeezing claws very compact. The idea is that the rubber part is pushed on to the
object that needs to be held so that the rubber is squeezed onto and around any uneven
parts. The rotational design makes the gripping area stay vertical when it is being moved
which gives the ability to create an equal surface pressure for grabbing an object.
All parts are created using 3D printers and the hole claw consists of PLA plastic, screws
and nuts, except the rubber tip which printed using Thermoplastic Polyurethane (TPU),
which is a mix between hard plastic and soft silicone. TPU is elastic and bends like rubber,
it comes in different hardness and has a much higher surface friction then PLA plastics.
Since the squeezing claws will have to rely on holding an object only based on inwards force
the rubber tip is designed with a hook-like surface to help grab on.
Figure 5.2.3: Squeezing claws
To solve the problem of the squeezing claws sliding on the object due to low friction from
hard PLA plastics a rubber tip printed in TPU was designed to horizontally deform around
the object, see figure 5.2.4. Several different solutions were tested with different thickness,
internal shape and material softness.
Figure 5.2.4: Rubber tips Figure 5.2.5: TPU
To see if the motors provided a strong enough torque the rubber tips were simply put on
a scale and pushed down on with a finger to se how much downwards force was needed to
deform them around a finger. The torque provided by the Bluebird servo motors were more
than sufficient when using TPU with a Shore-value of 60D, which describes how flexible the
material is. Tests were done with Shore-values of 95D, 85D and 60D.
31
The servo motor holder, see figure 5.2.6, for the squeezing claw needed to have two slots for
arms since it has two rotational points. The reason for designing it in three parts is to make
it simple in case an arm breaks and needs to be changed.
Figure 5.2.6: Servo motor holders
5.2.2 Gripping claws

The second triplet of claws shown in figure 5.2.7 are longer and provide two different func-
tions, act as landing legs, and to grasp around and if possible underneath the object. Before
landing the arms will open fully and be used as legs, and after take of, with the squeezing
claws holding a object, the gripping claws will close to secure the recovered object.
Figure 5.2.7: Squeezing claw function
The part holding the servo motor and gripping arm itself went trough many iterations of
design. Initially a push-lock mechanism was designed to minimize the use of fasteners like
screws and nuts, see figure 5.2.8.
Figure 5.2.8: Servo motor holders (push-lock)
After the first real world test, and crash, it was noted that a quicker way to change out the
gripping arms would be preferred. Real world use also showed that the base plate of the
drone was not strong enough and flexed too much when landing or gripping. To solve the
issue the servo holders were connected to create a base structure under the hexacopter, see
figure 5.2.9. A camera needed to be fitted to the drone and was integrated into the servo
holder along with the control unit for the servos which is an Arduino Nano.
32
Figure 5.2.10: Arm
Figure 5.2.9: Assembled Figure 5.2.11: Servo
5.3 Cases
Two different case were designed and built to protect and hold most of the electronics on
board. The first design, figure 5.3.1, was mainly designed to protect the companion computer
and made use of a sturdy design of a geodesic dome. Unfortunately the design made it hard
to access the electronics during development and testing so it was only used during the first
test flight.
Figure 5.3.1: Top and bottom view
To solve the issues that the first case had two different, more practical cases, were
designed. The top case holds and protects the Nvidia TX2 companion computer and the
bottom case holds the rest of the electronics. The two cases, figure 5.3.2, are meant to be
mounted on top of each other with four easy to get to screws for easy access to the bottom
case during development and testing.
Figure 5.3.2: Functional cases
5.4 Spacers
To be able to hold the batteries on the bottom section of the hexacopter six spacers, figure
5.4.1, were designed and 3D printed. The spaces created extra room for the batteries as
well as acting as fastening materials for all six gripping arms. All six spacers had to be
designed differently because of the way the servo holders had to be fastened. The spacers
were fastened in the bottom plate of the multicopter and then another bottom plate was
fastened to the spacers which was cut out in acrylic.
33
Figure 5.4.1: Spacers
5.5 Gripping module test

To test the following three requirements the gripping module was used as a stand alone rig
subjected to a series of scenarios.
• Requirement nr 5: ”The gripping module must be able to be integrated with a com-

puter running Robot Operating System (ROS)”
• Requirement nr 6: ”The gripper must be able to pick up an object shaped similar to
the drone being used.”
• Requirement nr 7: ”The gripper must have the ability to hold on to an object as
well as being able to let it go.”
An empty frame with a battery attached on the top was used as the intended object to
lift, called the dead hexacopter. Figure 5.5.1 shows the dead hexacopter which has a weight
of 1402 grams. Figure 5.5.2 shows the test rig connected to a power supply and a laptop
with a Linux system running ROS.
Figure 5.5.1: Dead hexacopter Figure 5.5.2: Rig, power supply & laptop.
To test the capabilities of the gripping module it was subjected to seven different place-
ment scenarios. The first scenario can be seen in figure 5.5.3 where the rig is centred above
the dead hexacopter and the legs are centred between the arms. In figure 5.5.4 and figure
5.5.5, the rig is still centred above the dead hexacopter but the legs are rotated so that they
are placed closer to the arms of the hexacopter, marked with yellow circles.
34
Figure 5.5.3: Centered Figure 5.5.4: Half rotation Figure 5.5.5: Full rotation
In figure 5.5.6 and figure 5.5.7 the rig is placed with an offset in relation to the centre
of the dead hexacopter placing either one or two of the inner squeezing claws closer to the
center of the hexacopter. Two example pictures of when one of the inner squeezing claws
is moved closer, marked with a yellow circle, to the center can be seen below. Scenario six
and seven work the same except the two opposite claws move closer to the center.
Figure 5.5.6: Offset half, one arm adjacent. Figure 5.5.7: Offset full, one arm adjacent.
Initially the tactic for gripping the dead drone was to first use the inner grippers, then
lift the object by hand, then close the outer grippers, as a final step a shake test to how well
the dead drone was held on to was conducted, see figure 5.5.8.
35
Figure 5.5.8: Lifting & shake test
After each step the drawn current was noted, and if the step was successful it moved on
to the next. The first tactic performed well except in the extreme cases when the module
was in the two positions called full rotation and offset full.
The second tactic rely on the weight of the hexacopter forcing the outer grippers stay
open but letting the inner grippers close. A double signal was sent to close both grippers
and then after a short delay the whole module was lifted and the outer grippers could close
as it was lifted. This tactic worked really well since it more or less scoops up the dead drone
and even the extreme situation were able to be gripped.
Figure 5.5.9 show the results from the gripping module test.
Figure 5.5.9: Results from gripping module test
5.6 Challenge results

The 2018 CPS-VO Challenge was held over the span of three days, where the first day was
meant for testing and the second and third day was meant for scored runs.
Day 1
The purpose of the first day of the challenge was to let teams conduct full systems tests and
flights in the new environment. This so that all teams could prepare without having the
pressure of doing scored runs. A lot of preparations were done during the first day and since
there had been no full systems test in Halmstad using all three theses some issues arose that
had not been anticipated. There was issues with connecting via WiFi to the hexacopters
hotspot and some Linus SFTP issues.
36
To be allowed to participate in the challenge a permission to fly on the airfield was needed.
To get this the team had to show that the pilot could take over from autonomous and
manually control the hexacopter, which was completed at the end of the first day.
Day 2
During the second day problems emerged. One of them was occurred every time the team
went out on the airfield to try the drone, the signal between the auto pilot and the companion
computer was lost. Troubleshooting was done and it seems like the system was affected by
the heat when the drone was placed in the sun. The lid on the top case was removed to let
air in and the fan on the Nvidia TX2 was turned on. Spacers between the top and bottom
case were added to lets some more air in and it seemed to work a little better. It also seemed
to work if the Nvidia TX2 was started as quick as possible after the battery was plugged in.
When returning to the hotel the team discovered that some of the servos for the claw
was damaged. There seems to be two reason the servo motors broke:
1. Overloaded motors from the time when there was no MOSFET-transistors to turn of
the running servo motors while not in use. This from tests in Halmstad during rough
winds and hard landings.
2. The limits of where the servos should stop were set to close to the internal stops. The
internal stops affected the servo motor at 0 − 35 degrees and 155 − 180, all locations
between that gave it some room to move before hitting a stop. Since the claws initially
was calibrated to start at 35 degrees any push lower then that made it hit the stop
and possible damage the stop or the gearbox and eventually the motor it self.
Due to earlier problems there was no spare part left, so the decision was taken to only use
the squeezing claws, which needed three servos, and to keep the other two working servo
motors as spares, in case more broke.
The first scored run was done in the end of the day but there was still issues with
connectivity, the team collected 10 points for a autonomous landing, which every team
should have been able to achieve using QGroundControl.
Day 3
On the evening of the second several preparations were made like new scripts isolating a
proper coverage test and a descending test, which were the key parts of a successful attempt.
The third day started with testing the scripts and they seemed to work fine. A scored run
was done and it was close to flawless except that the drone swayed to the west while landing
which put it slightly of centre of the dead drone. The pick up was unsuccessful and so was
the drop of. The resulting points for the run was 40 out of 100. The team was in high spirits
and it seemed as if a perfect run was not so far of.
Another problem emerged when the image analysis framework TensorFlow which is
trained to recognise the dead drone, instead started sensing the shadow of the hexacopter
instead of the dead drone. As soon as the hexacopter takes of the image analysis program
starts and when it senses an object it stops and starts descending on it. Since the sun was
high and the shadow was almost right underneath it happened as soon as the hexacopter
took of. To solve it the shape of the drone was changed by attaching other objects to the
frame to bring down the threshold for recognising and object. Unfortunately it was not
enough and the hexacopter was not able to descend on the dead drone.
In the end the team manged to get 40 points which was enough for a second place, and
also received honorable mentions for best UAV design.
37
38
6 Discussion & conclusions
6.1 Problem statement answers
The focus from the beginning has been on designing a gripping module for a hexacopter.
The idea from the start was to design according to a rescue scenario described by the hosts
from CPS-VO. The scenario was to be able to search for and rescue a crashed drone. Looking
at what different drones that were possible to buy on the market that was already flight
ready it was noticed that they could not handle much payload, so the decision was made to
design and build one instead. Building a drone allowed for heavier payload, more powerful
hardware and the and the freedom to design a more complex gripping device.
Trough out the design work of the gripping device there was an aim keep it generic in
both function and design, and to be able to pick up other objects then the dead drone
required was always important. With that in mind when starting the simulations the first
object that was successfully picked up was a simple sphere with tiny mass. Almost half
the project was spent understanding how the simulation and control software worked and
answers to the first question stated in the beginning of the thesis can now be given.
What is important to be aware of when creating a simulated environment,
for a multicopter, to provide a foundation for later construction stages?
• Delays, disturbances and unreliability: A feature that helped in both early and later
stages of simulation was to have a similar behaviour to a real hexacopter, which includes
delays and disturbances which make it more difficult to when navigating and hovering.
Because of that factor of unreliability a decision was taken to simply land on the object
that needed to be pick up. This is of course not the most generic way to pick up objects
in case they have landed awkwardly or on uneven terrain, but it is more in line with
what drones would be used as according to the study from SESAR, which is light load
transport.
• Mass & inertia: Not having correct mass and inertia values during simulation can be a
source of bad disturbances. Having exact values is mostly useful in later simulations when
more reliable data is needed. Correct values can often only be supplied when a clear idea
of what the drone being piloted will look like.
• Same control: Another very helpful attribute to focus on when simulating with the
intent to move on to real world tests is to have a similar or identical control system
for both simulator and reality. When programming it is therefore useful to try to have
similar control variables for both reality and simulation. The combination of using ROS
and Gazebo a very good choice for that reason.
• Mixing simulation and reality: Mixing simulations and real world tests so that one
is not caught up in solving issues that might not be as important in reality as they seem
in a simulator. Many issues that might be unknown for too long can be caught if HITL
simulations can be done as quick as possible. One problem that surfaced was that the
servo motors moved the claws quicker then the simulations in Gazebo.
• Reliable models: One issue, which might be overlooked is the importance of good
modelling software. If the physics engine is provided with a faulty or overly complex
model the calculations might not only be wrong but there might also be a high number
of unwanted calculations being done. Initially, for the sake of being able to use .dae files,
the program SketchUp was used for modelling and the quality of the 3D files were quite
low. Many holes and unwanted surfaces and collisions made the simulator unable to use
the files sometimes, and at other times they slowed down the simulator by triggering
unwanted collision calculations. When SolidWorks, which is a professional CAD software
was used the issues vanished and the models were beautiful in comparison.
• Computer performance. If heavy simulation is needed it is very important to have a
powerful GPU and CPU to be able to get a smooth reactive simulation. When simulating a
drone this was extra important since the flight behaviour was affected instantly depending
on what real time calculation factor was able to be achieved.
39
The second question is broadly defined and relate to both hardware and software. The
reason for the broad definition is that a gripping module can be designed in very different
ways and the answers provided here tries to cover some of the ideas that was discussed
during the design process.
What is important to consider when constructing a multicopter with a grip-
ping module, and how does the module affect the multicopters performance?
• Power & thrust: Unless the gripping module is very simple, like a rope with a hook
or something similar, the weight and size will increase on the multicopter. That in turn
will increase the power consumption. If the gripping module is electrically powered that
will also increase the power consumption. It is for that reason a good idea to first specify
what type of object needs to be picked up and then increase the thrust capacity and
batteries to cope with the new added weight and power consumption. The time when a
multicopter uses the most power is, not unsurprisingly, when it is flying. It is therefore
important to not spend too much time in the air when picking up an object. In the report
Avian-inspired grasping for quadrotor micro UAVs [3] the solution to that is to grasp the
object quickly, like an eagle. It might be a problematic solution if the object was very
small or unexpectedly shaped. The reason an eagle grabs its prey quickly might also have
to do with the fact that the prey try to get loose or even fight back, which the proposed
object for pick up would not, at least not in the context of picking up a crashed drone.
The solution to land on top of an object has the potential to save energy, precisely grab
on to and have the possibility to handle heavy loads.
• Sensor blockage: Depending on the size and what sensors the multicopter uses there is
a risk of the target object blocking those sensors. A dangerous scenario would be if the
multicopter was to use a laser sensor for height sensing and the object blocks that sensor
making the multicopter rise indefinitely.
• Landing: There is a big chance that a gripping module will be placed on the underside
of the multicopter. No matter if the module is a claw like device, a winched magnet
or a string the multicopter still has to be able to land with the module attached. It
is therefor important to take the ability to land into consideration when designing the
gripping module.
• Stability: There can be risks when picking up objects connected to stability both in the
air and on the ground while taking of. If the object is heavy or picked up non symmetrically
it can affect the center of gravity on the drone. The flight controller might be unable to
compensate and making the drone drift, spin or wobble. It is therefore important to get
a stable centred grip on the intended target, or to have an advanced enough navigation
system to handle such changes.
6.2 Future improvements

There are many improvements to be done when considering the project as a whole system
consisting of a hexacopter with a gripping module that has simulation support.
As it is now a base model of the hexacopter exists in Gazebo and the full drone is devel-
oped in reality. To get a fully working system for testing the simulation of the hexacopter
would need some improvements since it at the moment consists of a simpler model then the
real one. The simulation has a plugin to control the grippers but three of them need to be
changed to reflect the double arm squeeze grippers that now is mounted on the hexacopter.
An improvement to the rubber tips grabbing the dead drone would have to be either sim-
ulated as a soft object with high friction or in some other way get the grippers to stick to
the pick up object.
An even more useful improvement would be to investigate the mass and inertia charac-
teristics on the real world hexacopter and add that to the SDF file which defines the model
in Gazebo. That can be done using real world tests or by simplifying the models and use
SolidWorks for near to real calculations. When the inertia and mass characteristics have
been added the simulated steering behaviour can be compared to reality. Ideally they would
be identical.
The way the grippers are controlled via the plugin in ROS and Gazebo can also be
improved by adding proper actions which provide feedback to the system about when the
grippers reach their destination.
40
The hardware works very well when looking at the hexacopter it self, it is strong, can lift
heavy and is quite reactive. The size could be made smaller and in turn the weight could be
improved. As it is now the size of the upper cases are defined by the size of the companion
computer which as it looks now wont change. There is an empty space between the battery
packs and then lower electronics case. The electronics from the bottom case could with
some new CAD designs and prints be moved down and the drone might loose some weight
and size.
Improvements can also be done to the gripping module. The longer gripping arms can
sometimes vibrate, which causes the system to draw a higher current. This might be possible
to improve by simply applying a bit more friction to the arms while they rotate in their
socket, or by using a different servo motor where the dead band can be programmed.
Another gripping module related improvement that could be done is to calibrate the way
the Arduino calculates the stopping position in degrees by mapping it to the nonlinear curve
of the potentiometer.
6.3 Social requirements

• Economy: Halmstad University funded the construction and development of the
hexacopter including enough spare parts to build two whole hexacopters, this to ensure
a successful participation in the challenge. The estimated cost for one hexacopter
including spare parts, chargers, batteries, cases for transportation etc, ended up at
61760 SEK. The estimation does not include the 3 KG of filament used by 3D printers
during development of claws, spacers, cases and dead drone replicas, filament cost
around 300 SEK/KG. Costs related to travelling and accommodation is not included
either.
If a similar project was to be held at a private company the costs would be significantly
higher since no personnel costs are included. The sum of 61760 SEK would only be
enough for about one months work for one engineer.
• Environment: Different parts consist of different materials and to create an overview
of what materials was used to build the hexacopter the following list helps:
– 3D printed parts:
∗ PLA: A biodegradable plastic that is made from starch. PLA can both be
recycled and used again, or composted or burned.
∗ TPU: The TPU used in this project is an ECO-friendly TPU which is bio
degradable, there are however all kinds of TPU and not all are environmen-
tally friendly.
– Propellers: Made from Carbon Fibre which is held together by some type of
resin, this is one of the parts of the hexacopter which is not very easy to recycle,
however only one propeller broke during development.
– Electronics: Many different types of materials, all parts used on the hexacopter
in this thesis is RoHS compliant, meaning they contain less hazardous materials
and are easier to recycle.
– Arms: Made out of aluminium which is easy to recycle and does not harm the
environment severely if the hexacopter were to crash somewhere hard to reach.
– Batteries: The batteries are the hardest part to recycle if anything were to hap-
pen. It is also the part of the hexacopter that could render all of the parts hard
to recycle if they were to get pierced and ignite. It is therefor important that the
batteries are protected, and they are, when flying the hexacopter.
• Rules / Safety: In Sweden there is some rules issued by ”Transportstyrelsen” and
in the USA the Federal Aviation Administration has similar rules. The following
examples of Swedish rules which apply to drones with a weight of less than 7 kg:
– The drone need to be marked the name of the pilot and phone number.
– If flying during when it is dark, lights need to be used on the drone.
– Do not fly higher than 120 meters.
– Do not fly closer to an airport than 5 km.
41
– Do not fly over military areas, prisons, nuclear plants or nature reserve.
Another safety issue which had to be taken into consideration when travelling to the
USA is LiPo batteries. There are rules that apply when travelling with LiPo batteries
on airplanes. The rules differ depending on which airline company is operating the
flight. One common rule is that LiPo with more than 110Wh need to be carried in
the hand luggage and if it is more than 160Wh it is not allowed on the flight. As a
general guide line it is a good idea to keep all LiPo batteries in the hand luggage since
a potential fire can be noticed, and stopped, earlier.
• Integrity: One integrity issue is when using a drone with a camera and taking picture
at public areas. In Sweden there is a law saying that pictures taking at public areas
with a drone need a permission before being published on any social media. To obtain
this permission, an application must be made at ”Lantmäteriet”.
6.4 Lessons from the CPS-VO Challenge

First of all it is very good to have a real situation where the final results should be used
for. In the case of this thesis it is the CPS-VO challenge. To have a working prototype of
a hexacopter with a claw was crucial and it served as a hard unmovable dead-line. Some
lessons that other people can try to learn from are the following:
• Get a working UAV that can run programs as quick as possible. When
everything started alot of effort was put into the simulation, which was useful, but
it also took more then half the time of developing the real UAV. None of the team
members had any prior knowledge or experience with flying UAVs. To have a full
system that works is more important then having a good one. This goes for a the
gripping module as well, a full module should have been finished much earlier for
proper tests. If the module had been done earlier endurance tests could have been
done to see if the servo motors would hold up, which they did not.
• Try to do as much full systems testing as possible before going. The intention
was to do this but in the end of the project effort had to be put into writing reports and
finishing up. The last date for the report was on the 11th and the trip was scheduled
for the 12th, it was unfortunate that the dates were so close together.
Apart of what was mentioned above it would have been very helpful to have an adminis-
trator responsible for travel booking appointed early on in the project so that students did
not have too book and organise as well as investigating and writing a thesis.
42
References
Theses
[3] Justin Thomas et al. Avian-inspired grasping for quadrotor micro UAVs. http : / /
www.jtwebs.net/wp-content/uploads/2013/04/idetc2013.pdf. [Online; accessed
29-Jan-2018].
[4] Elliot Wright Hawkes et al. Grasping Without Squeezing: Design and Modeling of
Shear-Activated Grippers. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=
&arnumber=8239707. [Online; accessed 02-Mar-2018]. 2017.
[5] Suseong Kim, Seungwon Choi, and H. Jin Kim. Aerial Manipulation Using a Quadrotor
with a Two DOF Robotic Arm. http://ieeexplore.ieee.org/stamp/stamp.jsp?
tp=&arnumber=6697077. [Online; accessed 02-Mar-2018]. 2013.
[6] Eric Brown et al. Universal robotic gripper based on the jamming of granular material.
http://www.pnas.org/content/pnas/107/44/18809.full.pdf. [Online; accessed
02-Mar-2018]. 2010.
[7] Farzan M. Noori et al. On 3D Simulators for Multi-Robot Systems in ROS: MORSE
or Gazebo? http : / / ieeexplore . ieee . org / stamp / stamp . jsp ? tp = &arnumber =
8088134. [Online; accessed 02-Mar-2018]. 2017.
[8] Mauro Gatti. Design and Prototyping High Endurance Multi-Rotor. http://amsdottorato.
unibo.it/7124/1/gatti_mauro_tesi.pdf. [Online; accessed 01-May-2018]. 2015.
Studies
[1] SESAR Joint Undertaking. European Drones Outlook Study. https://www.sesarju.
eu/sites/default/files/documents/reports/European_Drones_Outlook_Study_
2016.pdf. [Online; accessed 25-Feb-2018]. Nov. 2016.
Books
[9] Quan Quan. Introduction to Multicopter Design and Control. ISBN 978-981-10-3382-7.
Springer, 2017.
[18] Stephen P. Radzevich. Dudley’s handbook of practical gear design and manufacture.
CRC Press, 2012.
[20] John M. Hughes. Arduino: A Technical Reference. O’Reilley Media Inc., 2016.
[21] Matthew Scarpino. MOTORS for MAKERS - A Guide to Steppers, Servos, and Other
Electrical Machines. QUE, 2016.
[22] Tomas Svensson and Christian Krysander. Projektmodellen LIPS. Studentliteratur,
2011.
[28] W. A. W. A. Rahman Lee Tin Sin Abdul R. Rahmat. PDL Handbook Series: Polylactic
Acid. Elsevier, 2012.
Online Sources
[2] 2018 CPS Challenge. https://cps-vo.org/group/CPSchallenge. [Online; accessed
29-Jan-2018].
[10] Dronecode Project. https://www.dronecode.org/about/. [Online; accessed 2-Mar-
2018].
[11] ROS Wiki: Documentation. http://wiki.ros.org/. [Online; accessed 27-Feb-2018].
[12] Catkin build system. http://docs.ros.org/api/catkin/html/. [Online; accessed
2-Mar-2018].
[13] Catkin workspaces. http://wiki.ros.org/catkin/workspaces. [Online; accessed
3-Mar-2018].
[14] Gazebo. http://gazebosim.org/. [Online; accessed 28-Feb-2018].
43
[15] Russel Smith. Open Dynamics Engine. http : / / www . ode . org/. [Online; accessed
28-Feb-2018].
[16] SDFormat. http://sdformat.org/. [Online; accessed 28-Feb-2018].
[17] SDF API 1.5. http://sdformat.org/spec?elem=sdf&ver=1.5. [Online; accessed
28-Feb-2018].
[23] SolidWorks. http://www.solidworks.com/. [Online; accessed 29-Jan-2018].
[24] Gazebosim tutorials. http://gazebosim.org/tutorials/browse. [Online; accessed
4-Mar-2018].
[25] Stifael - Offboard scripts. https://github.com/Stifael. [Online; accessed 7-May-
2018].
[26] xcopterCalc. https://www.ecalc.ch/index.htm. [Online; accessed 7-May-2018].
[27] MakeBlock Strong Gripper. https : / / www . openhacks . com / uploadsproductos /
181623471 - makeblock - strong - robot - gripper . pdf. [Online; accessed 30-May-
2018].
Images
[19] Worm gear drive. http://www.clker.com/cliparts/D/5/G/i/b/9/engine-hi.png.
[Online; accessed 05-May-2018].
44
Specification of Requirements
Referral
Type: Description:
number:
The gripping module must have a simulated counterpart model which can be integrated with a
1 Simulation simulation of the drone being used for the CPS-VO Challenge. The simulation software to be used
is Gazebo.
The propulsion system on the drone must be able to be controlled by a flight controller using the
2 Hexacopter
Px4 flight stack.
The drone must at least be able to carry an object weighing 20% of its own weight after the
3 Hexacopter
gripping module has been attached.
The gripping module must be able to be integrated with a computer running Robot Operating
4 Software
System (ROS).
5 Gripping module The gripper must be able to pick up an object shaped similar to the drone being used.
6 Gripping module The gripper must have the ability to hold on to an object as well as being able to let it go.
Test of Specification of Requirements

Referral
Type: Description: Test: Date: Tested:
number:
The gripping module must have a
simulated counterpart model which can
The simulated model will be
be integrated with a simulation of the
1 Simulation made and tested in the simulation 2018-03-03 ✓
drone being used for the CPS-VO
software Gazebo.
Challenge. The simulation software to
be used is Gazebo.
The propulsion system on the drone If the Px4 flight controller can
2 Hexacopter must be able to be controlled by a flight send control signals and fly the 2018-04-12 ✓
controller using the Px4 flight stack. drone the requirement is fullfilled.
The drone must at least be able to A flight test with the drone with
carry an object weighing 20% of its own the module attached holding on to
3 Hexacopter
weight after the gripping module has an object weighing about 20% of
been attached. the drones total weight.
The Module will be integrated
The gripping module must be able to
with a computer running Ubuntu
4 Software be integrated with a computer running 2018-03-09 ✓
and ROS. If it works the test is
Robot Operating System (ROS).
confirmed.
Physical test will be done when
the construction is finished by
placing the gripper over the
The gripper must be able to pick up an
intended object and send
5 Gripping module object shaped similar to the drone 2018-05-03 ✓
commands to close on it. The
being used.
gripper should then be moved
upwards to make sure it can hold
on to the weight of the object.
Physical test will be done when
the construction is finished by first
The gripper must have the ability to sending commands to close the
6 Gripping module hold on to an object as well as being gripper lifting the object, and then 2018-05-03 ✓
able to let it go. sending commands to let go of
the object. The test can be
combined with nr. 5.
Time plan
Estimated Hours Week Plan
Activity: Difference:
hours: worked: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Research / Education 217 227 10 25 31 14 22 10 12 15 12 17 10 10 10 7 7 7 8
Presentation / Seminar 78 84,5 6,5 10 10 12 12 12 12 10
Documentation: Other 79 69 −10 15 5 12 8 8 7 8 8 8
Meeting 22 18,5 −3,5 4 4 2 2 2 2 2 2
Organising 30 41,5 11,5
Gazebo / Simulations 105 154,5 49,5 10 25 25 25 20
Software creation 43 25 −18 10 13 15 5
Building hardware 180 307 127 5 15 20 25 30 39 21 25
Testing 40 50 10 20 20
Documentation: Half time report 115 137,5 22,5 20 20 20 20 20 15
Documentation: Final report 125 129 4 5 5 5 15 10 10 30 27 18
Total: 1034 1243,5 209,5 40 40 40 50 57 57 62 60 63 62 50 55 47 61 60 63 52 47 36
32 53 74 91 71 84 73 100 71 48 45 36 41 100100 62 86 91
Milestones:
Date: Description: Achieved:
Send in project plan approved by supervisor to the
2018-01-31 ✓
course examiner.
2018-02-02 Presentation at the project plan seminar. ✓
Demonstrate a search and recovery simulation to
2018-03-03 CPS-VO, i.e. a simple gripping module design ready ✓
and implemented in ROS and Gazebo.
Finish construction of hardware design alternatives
2018-03-07 ✓
for the half time seminar.
Half time project report finished, approved by
2018-03-08
supervisor and sent in to course examiner and ✓
12:00 PM
opponents.
2018-03-14 Presentation at the half time seminar. ✓
2018-04-04 Software development finished. ✓
2018-04-16 Final hardware design finished and constructed. ✓
2018-04-30 Tests of hardware and software integration finished. ✓
2018-05-11 Send in final report approved by supervisor to the
✓
12:00 PM course examiner.
2018-05-15
2018-05-16 Attend outdoor challenge at Timpa Airfield in Arizona. ✓
2018-05-17
2018-05-22 Presentation at the final seminar. ✓
Anders Bogga
Mechatronic Engineer
2015 - 2018
Emil Andersson
Mechatronic Engineer
2015 - 2018
PO Box 823, SE-301 18 Halmstad

Phone: +35 46 16 71 00
E-mail: registrator@hh.se
www.hh.se

Hexacopter With Gripping Module: Mechatronic Engineering, 180 Credits

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hexacopter With Gripping Module: Mechatronic Engineering, 180 Credits

Uploaded by

Copyright:

Available Formats

Degree Thesis

Mechatronic Engineering, 180 credits

Hexacopter with gripping module

Degree Project Mechatronic Engineering,

Anders Bogga, Emil Andersson

3 Theory & background 5

6 Discussion & conclusions 39

CAD Computer-Aided Design. 1, 10, 13, 14, 30, 39, 40

CPS-VO Cyber Physical Systems Virtual Organization. 1, 2, 13, 29, 39, 42

ESC Electronic Speed Controller. 7, 13, 20

FEA Finite Element Analysis. 25, 26

GPS Global Positioning System. 8, 9

HITL Hardware In The Loop. 29, 39

IDE Integrated Development Environment. 11

LIDAR Light Detection And Ranging. 10

LIPS Linköpings Projektstyrningsmodell. 13

MAVLink Micro Air Vehicle Communication Protocol. 8, 9, 15

PID Proportional-Integral-Derivative Control. 16

PLA Polylactic Acid. 25, 31, 41

RADAR Radio Detection And Ranging. 8, 10

SDF SDFormat. 10, 15, 16, 40

TPU Thermoplastic Polyurethane. 31, 41

UAV Unmanned Aerial Vehicle. 8, 37, 42

1.1 Goals & Purpose

1.2 Problem Statement

1.3 Thesis limitations

1.4 Specification of requirements

Figure 3.1.1: Quadcopter Figure 3.1.2: Hexacopter Figure 3.1.3: Octocopter

3.1.1 The parts of a multicopter

KV ∗ V = RPM ⇒ 460 ∗ 22.2 = 10212 RPM

KV ∗ V = RPM ⇒ 2300 ∗ 16 = 36800 RPM

Figure 3.1.4: Arris X2205 2300KV

Figure 3.1.5: Sunnysky X4110S 460KV

Electronic Speed Controllers (ESCs)

3.2 Software & Simulation

3.2.2 Robot Operating System

Figure 3.2.1: ROS concept

3.2.3 Catkin build system

3.2.5 Gazebo Physics Simulator

3.3 Gripping module

3.3.2 Arduino Boards

• In-system programming by on-chip boot program.

3.3.3 Servo motors

4.1 Choosing a multicopter frame

4.2 Setting up a simulation platform

4.2.1 Modelling the hexacopter for simulation

Figure 4.2.1: S550 plates Figure 4.2.2: F550 plates

Figure 4.2.3: Rough arm Figure 4.2.4: Refined arm

4.2.2 Modelling the gripping module for simulation

Figure 4.2.6: First hexacopter with gripper concept.

4.2.3 Simulating with Gazebo & ROS

Creating a plugin for the gripping module

4.2.4 Simulation tests

Figure 4.2.7: Hexacopter with gripper in Gazebo.

Figure 4.2.8: Gazebo pick up and flight tests.

4.3 Hardware choices

Figure 4.3.1: Hexacopter dimensions.

4.3.2 Gripping module hardware

Name: Tower Pro SG90 Adafruit 1450 BMS-390DMH

Model: Arduino Uno Arduino Nano Arduino Micro

• Input voltage: 4.5-30V

Servo motor control

Figure 4.3.2: Feedback modification of DMS-390DMH