Hexacopter with gripping module

(1)

Degree Thesis

HALMSTAD

UNIVERSITY

Mechatronic Engineering, 180 credits

Hexacopter with gripping module

Degree Project Mechatronic Engineering,

15 credits

(2)

(3)

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 hexahexa-copter 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 är en tävling med fokus p˚a utvecklandet av en drönare med egenskapen att söka av ett omr˚ade och hitte en förlorad drönar och bärga denna, allt detta autonomt. För att kunna delta i tävlingen gjordes tre separata examensarbeten. Dessa tre examensarbeten tillsammans bildade en autonom hexakopter som användes i tävlingen.

Fokus i detta examensarbete ligger p˚a utvecklandet av en hexakopter med en grip-modul som kan användas i tävlingen. Det finns tv˚a huvudm˚al med detta arbete. Det första m˚alet var att skapa en digital modell av hexakoptern och gripmodulen som kun-de användas för att simulera hexakoptern i Gazebo. Simuleringen styrs med ROS och användes som en grund till h˚ardvaruutvecklandet.

Det andra m˚alet var att använda resultaten fr˚an simuleringen till att bygga en riktig prototyp av en hexakopter med en gripmodul som senare kunde användas i tävlingen. Konstruktionen av hexakoptern baserades p˚a en egen design och all tillverkning av delarna till gripmodulen gjordes i SolidWorks för att sedan skrivas ut p˚a en 3D skrivare. Resultatet blev en hexakopter med en hög lyftkapacitet och en gripmodul som kan gripa tag och h˚alla i ett objekt. Hexakoptern användes under 2018 CPS-VO challenge som ägde rum i Arizona i Maj 2018.

(4)

(5)

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 Link¨opings 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

(8)

(9)

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.

(10)

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.

(11)

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.

(12)

(13)

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

(14)

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

Weight = Thrust-to-weight ratio

• 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

(15)

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.

(16)

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 positioning-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++).

(17)

• 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

(18)

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 outin-door 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.

(19)

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].

(20)

(21)

4 Method

The project model used is Link¨opings 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 simusimu-lation 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.

(22)

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

(23)

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

(24)

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◦.

(25)

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.

(26)

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

(27)

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

Weight = Thrust to weight ratio ⇒

Thrust

7.200 = 2 ⇒ Thrust = 2 ∗ 7.2 = 14.4 kg 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.

(28)

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:

W h

V =

160

22.2≈ 7.2Ah

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

(29)

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◦ ₁₂₀◦ ₁₂₀◦

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

(30)

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.

(31)

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.

(32)

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

(33)

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

(34)

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.

(35)

Figure 4.4.8: FEA of gripping claw 300N

Figure 4.4.9: Hard landing breakage

(36)

Hexacopter with gripping module

Degree Thesis

HALMSTAD

UNIVERSITY

Mechatronic Engineering, 180 credits

Hexacopter with gripping module

Degree Project Mechatronic Engineering,

15 credits

Contents

Acronyms

1

Introduction

1.1

Goals & Purpose

1.2

Problem Statement

1.3

Thesis limitations

1.4

Specification of requirements

2

Related work

3

Theory & background

3.1

Multicopters

3.2

Software & Simulation

3.3

Gripping module

4

Method

4.1

Choosing a multicopter frame

4.2

Setting up a simulation platform

4.3

Hardware choices

4.4

Gripping module design