Project plan:  

Robust Autonomous Navigation using a Multicopter

 AS-0.3200 Automaatio- ja systeemitekniikan projektityöt

 Wille Keltikangas 79709E

Antti Paloposki 218342

Sakari Pesonen 218371

Henry Sanmark 226347

Lauri Vänttinen 84532B

             

  

1. The goal of the project work The goal of this project is to build an autonomously flying multicopter. The multicopter will navigate using a map generated by the onboard LiDAR. It will be able to pass through doorways and avoid obstacles. It will be possible to control the multicopter with a radio transmitter and through TCP/UDP sockets using WLAN.  The total amount of workload per week is around 15 hours a week (see “Time and team management” for further details), and the project shall last approximately 14 weeks. Therefore the total credits of this project is approximately 8 credits per team member.  Image 1) Visualization of a map created by LiDAR 

  

2. The structure of the work Work items with time estimates in brackets: 

● Choosing parts (10h) ● Ordering parts (4h) ● Studying Galileo (100h) ● Building the frame of the multicopter (40h) ● Assembling and testing the hardware of the multicopter (100h) ● Programming hardware (1200h) 

○ LiDAR ■ Study ROS 

○ ArduPilot ○ Sensors ○ Wlan receiver/transmitter ○ Radio receiver/transmitter 

● Creating the controllers (200h) ○ Wlan and Radio 

3. Time and teamwork management  The team has a weekly workshop on Mondays from 17 onwards. Most of the work will be done in these workshops, but everyone will also do individual work in their spare time. These workshops will take approximately 4 hours, but the actual time is based on the current status of the project. In addition, every team member shall use several hours in individual work so the actual time consumed in the project is 15 hours a week.  The team shall mainly use “Sähköpaja” and its tools in assembling and the actual development in Mondays. Individual work is done in various places, such as home.  The communication between team members is managed with weekly meetings and with various communication applications, such as IRC and WhatsApp. Therefore every team member is reachable every single day, if some additional work must be done.  The team will use phabricator (http://phabricator.org/) to keep track of tasks and time used in these tasks.   Deadlines for the project are very hard to define, since they are very much dependent on when we will receive the ordered parts.   

4. Risk management  Possible risks while working on the project: 

● Purchasing the components ○ The components does not arrive or they are wrong ones 

● Broken components ○ Components will be broken during the development 

● Getting replacements ○ It takes time to get replacement components 

● Failures in software algorithms and the mechanical assembling ○ Human failures in design 

● Failures in mechanical design ● Insufficient computing power of planned hardware ● Bad ideas about the implementation (eg. our plan could not work from the very beginning) ● Bad documentation of the components and therefore bad implementation in this project 

○ The working component or algorithm will not be useful if its documentation is not sufficient 

● The wrong estimation of the workload ○ Some tasks might require significantly more work than thought 

 Possible broken components/too difficult hardware configuration/insufficient computing power will be solved with alternative hardware solutions. (e. g. replacing Intel Galileo with Raspberry pi, etc.) We already have some spare parts and in case of an emergency we can buy more replacements from finnish vendors in order to save shipping time.  The parts we purchased are also available in Finland for a higher price. If replacements are needed, we can use local vendors for quadcopter parts to save time in shipping and prevent breaking of the workflow.  Software development failures can be considered as fatal. Because the main functionality of the project is based on software implementations, all bugs which could cause crashes or completely unintentional use must be avoided. Even though the software is not considered as safety­critical, it could be useful if the principles of safety­critical software development is used. Besides, the testing must take at least half of the time alongside the actual software development. All possible testing code must be developed and system­level testing phases shall be applied. In addition, our software development ideas could not possibility work in real life, and therefore our plans shall be flexible enough to be changed swiftly.  All possible principles of simple software implementation shall be used to improve readability and further development. Coding conventions must be clear and easily understandable. This will also 

help in situations, when multiple team members are developing the software  at the same time, so group can understand each others coding idea.  Because it is hard to estimate the actual workload of several tasks, the actual development must be started from the most simple implementation. It must be defined that which areas are our main priority and minimum requirements. Therefore, all additional work must be applied only after the minimum requirements have been met. Therefore we could avoid situations, that we were trying to implement too complicated features without actually focusing the main functionality.  

5. Multicopter assembly & components  Item  Amount 

RPLidar (Remote sensing device)  1 

Sharp GP2Y0A02YK0F (Infrared sensor)  4 

Intel Galileo Gen 1 (Microcontroller)  1 

Pixy CMUcam5 (Camera)  1 

Carbon fiber ­ roving  1 

Epoxy  1 

Glassfiber  1 

Nylon fabric  1 

Multistar 2212 ­ 920KV (Motors)  1 

Turnigy Multistar ESC 2­4S (Speed Controller)  4 

Arduino (Safeguard)  1 

HKPilot Mega 2.7 (Flight Controller)  1 

Ultrasonic Module HC­SR04 (Ultrasound sensor)  5 

Turnigy Nano­Tech 3000mAh (231g) (Small rechargeable battery)  1 

ZIPPY Flightmax 4000mAh (306g) (Large rechargeable battery)  1 

DJI Phantom 2 (Propellers)  4 

 The multicopter frame will be made by first putting carbon fiber, glassfiber and epoxy in a styrofoam mold coated with the nylon fabric. Then we use an air compressor to create a vacuum inside the mold and wait for the mass to harden. The size of the frame will be fitted to the size of the propellers as it will be built to protect them from possible impacts.  

The propellers will be mounted on the motors that have a speed controller attached to them. The speed controllers will be attached to the flight controller that is based on the open source ArduPilot platform. The flight controller along with all the sensors will be attached to a separate arduino that will be used to monitor sensor readings used in collision avoidance. A radio receiver will also be connected to the flight controller for testing the platform and motors.   The weight of the components is a serious concern, so we have selected two different size rechargeable batteries to use in the project. This gives us the the choice between adding more weight on the copter in the form of sensors and controllers or by using the larger battery and gaining more operational time.   Image 2) Rough 3d model of the final copter. 

           

6. Work schedule  

Week 

Hours (each) 

Antti  Wille  Henry  Sakari  Lauri 

38  15  Studying and setting up ROS 

Studying Galileo and OS installing 

Studying and setting up ROS 

Frame designing and part choosing 

Studying Galileo and OS 

39  15  Further studying of ROS & Lidar testing 

Lidar testing  Further studying of ROS 

Frame building  Frame building 

40  15  Lidar integration with ROS 

Lidar integration with ROS 

Lidar integration  ROS studying & Platform testing 

ROS Studying & Platform testing 

41  15  Coding  Coding  Coding  Coding  Coding 

42  15  Coding  Coding  Coding  Coding  Coding 

43  15  Coding  Coding  Coding  Coding  Coding 

44  15  Coding  Coding  Coding  Coding  Coding 

45  15  Ardupilot Integration with ROS 

Ardupilot Integration with ROS 

Ardupilot Integration with ROS 

Ardupilot Integration with ROS 

Ardupilot Integration with ROS 

46  15  Testing  Testing  Testing  Testing  Testing 

47  15  Testing  Testing  Testing  Testing  Testing 

48  15  Testing  Testing  Testing  Testing  Testing 

49  15  Preparing for Demo 

Preparing for Demo 

Preparing for Demo 

Preparing for Demo 

Preparing for Demo 

50  15  Final touches  Final touches  Final touches  Final touches  Final touches 

51  15  Documenting  Documenting  Documenting  Documenting  Documenting