Project plan: Robust Autonomous Navigation using a Multicopter

Size: px
Start display at page:

Download "Project plan: Robust Autonomous Navigation using a Multicopter"

Transcription

1 Project plan: Robust Autonomous Navigation using a Multicopter AS Automaatio- ja systeemitekniikan projektityöt Wille Keltikangas 79709E Antti Paloposki Sakari Pesonen Henry Sanmark Lauri Vänttinen 84532B

2 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

3 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 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 ( 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 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

5 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 KV (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.

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

7 6. Work schedule Wee k Hours (each) Antti Wille Henry Sakari Lauri Studying and setting up Studying Galileo and OS installing Studying and setting up Frame designing and part choosing Studying Galileo and OS Further studying of & Lidar testing Lidar testing Further studying of Frame building Frame building Lidar integration with Lidar integration with Lidar integration studying & Platform testing Studying & Platform testing Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Coding Integration with Testing Testing Testing Testing Testing Testing Testing Testing Testing Testing Testing Testing Testing Testing Testing Final touches Final touches Final touches Final touches Final touches Documenting Documenting Documenting Documenting Documenting