AR-Drone: GPS Coordinates & GUI Revamp Adam Howell, Cord Tucker and Tarryn Schantell

Transcription

1 AR-Drone: GPS Coordinates & GUI Revamp Adam Howell, Cord Tucker and Tarryn Schantell 1

2 Table of Contents: Executive Summary 3 Project Description 4 Background and Competition 7 Innovations 9 Impact 10 Project Plan 11 2

3 Executive Summary: Our group is working on an AR Drone project that will give a more user friendly interface and add a GPS unit to the drone; while showing the data we get from the unit to the interface. We believe this is a great way to use these drone for many other uses other than recreational use. The AR Drones could be used by many groups for professional purposes that would greatly help people and possibly save a lot of money for the user group. The biggest market we see that our improvements can help is the municipal level or federal level of government. The way this will help these two groups is with police department s potential man hunts or any action that would need an aerial look. When a municipal or federal governments has to use aerial views most or all use helicopters, those helicopters are very expensive because of fuel and maintenance. If those groups could use an AR Drone that has a GPS unit that shows the data on the video then they would not have to always use expensive helicopters. This would potentially free up more money for salaries or better equipment. Another part of the use by police departments at any level is with man hunts, helicopters are loud and most people today if they are on the run are smart enough to keep an eye out for a police helicopter in the sky. The AR Drone is much quieter and is small. The criminal would not notice a drone as easily as the helicopter. With the growing popularity of these drones people are getting used to seeing these in the sky and we ignore them. This would be another bonus because the criminal would not suspect the drone. Drones are less expensive than their counterpart helicopter. Instead of having to be stored in a hanger these drones can be stored in a closet. The AR Drone is powered by a battery instead of fuel which will be cheaper with the rising cost of fuel. In the area of power, the drone does have a disadvantage to the helicopter by a very limited battery life. The standard battery that comes with the AR Drone only give the user about seven minutes of flight time per battery but the batteries can be easily exchanged in and out. With the AR Drones the user group could use multiple drones at once to also help with the limited battery life. We have purchased the upgraded battery for the AR Drone and have seen a small increase in the flight time from five to seven minutes with the standard up to nine to twelve minutes with the upgraded battery. The time table of the overall project will be from the beginning of September 2013 to May The first part of the first half of this time, or first semester, will be spent of getting the GPS and getting to know the drone. After that getting a working windows interface with the basic design roughly the same to the interface that is out there already. We will then move to installing the GPS unit and getting that component working with the drone. We will need to install drivers onto the drone and insert those into the interface. Once we find the data and how to read it then we can pull it into the interface as live data. We are planning on putting this live data in either the left or right upper corners of the video feed. While working with the windows application we are going to explore the use of a Xbox 360 controller instead of keyboard. Once we get the windows application the way we want we plan to move to an Android application for the Nexus 7 tablet. We expect to work on the Android application 3

4 during the second half, or second semester, of the time. The Android application will make our changes more mobile and give the ability to the end user a simple interface. Project Description: Our group is working on an AR Drone project that will give a more user friendly interface and add a GPS unit to the drone; while showing the data we get from the unit to the interface. We believe this is a great way to use these drone for many other uses other than recreational use. The AR Drones could be used by many groups for professional purposes that would greatly help people and possibly save a lot of money for the user group. Figure 1. AR Drone The biggest market we see that our improvements can help is the municipal level or federal level of government. The way this will help these two groups is with police department s potential man hunts or any action that would need an aerial look. When a municipal or federal governments has to use aerial views most or all use helicopters, those helicopters are very expensive because of fuel and maintenance. If those groups could use an AR Drone that has a GPS unit that shows the data on the video then they would not have to always use expensive helicopters. This would potentially free up more money for salaries or better equipment. Another part of the use by police departments at any level is with man 4

5 hunts, helicopters are loud and most people today if they are on the run are smart enough to keep an eye out for a police helicopter in the sky. The AR Drone is much quieter and is small. The criminal would not notice a drone as easily as the helicopter. With the growing popularity of these drones people are getting used to seeing these in the sky and we ignore them. This would another bonus because the criminal would not suspect the drone. Our project could also be used in military applications for soldiers in the field and if they are pinned down. They could launch a small drone like this and fly it around to a point to find a safe way to escape or to find the enemy that is pinning them down. With the increase in drones within the field of war these could greatly help soldier teams. While this would not be our main focus, this is another application that our project can be used for and that would help. The GPS unit would be plugged into the USB slot that is connected to the drone under the cover. The USB GPS we have bought is very light weight and weighs only about three grams and so this will allow expansion of payload if would like to add anything more. By the USB GPS we have bought we will have to use the drone s capabilities as a Linux Box and install the GPS onto the drone. We have explored dual compiling on our computer and on the drone to have our application able to read the data coming out of the GPS. We have also found a solution of able to compile the drivers on our machine without having to compile on the drone. When we can read the data from the GPS we will need to display that data with the video. We are not just taking coordinate data but also the direction of the compass. By our plan is to have the data coming from the GPS in the upper left or right hand corner of the video given to the user within the interface. One possible way to display the compass is to have a rolling compass at the top of the screen. Figure 2. USB GPS We are also looking at possible adding a distance tracker by either a laser or possibly a second front camera. We are still not for sure about this idea. We could get either one of these working but this may take a lot more time than we have for our project. The main concern is 5

6 the weight limit of the drone itself which is 40 grams. The laser avenue would be the best because it will probably be the lightest for the drone. We would need to use a laser like an Arduino laser. Another constraint would be we would need to use a laser of class two or above where some of those can be expensive. We would also need a dark color for the laser so when outside the laser is not lost in the light. We have found a couple of possible light Arduino Lasers online but not have done any real look into them yet. The other way we have found we could use is mounting a second camera on the front of the drone and doing a lot of calculation with our programing to calculate the distance. This is heavier than a laser and could possibly be to much for the drone and make it not able to fly. Calculating the distance from the drone to a target can add another dynamic for the end user if they are looking for someone or something by able to guide a team or individual to the target. Figure 3. Arduino Laser Drones are less expensive than their counterpart helicopter. Instead of having to be stored in a hanger these drones can be stored in a closet. The AR Drone is powered by a battery instead of fuel which will be cheaper with the rising cost of fuel. In the area of power the drone does have a disadvantage to the helicopter by a very limited battery life. The standard battery that comes with the AR Drone only give the user about seven minutes of flight time per battery but the batteries can be easily exchanged in and out. With the AR Drones the user group could use multiple drones at ounce to also help with the limited battery life. We have purchased the upgraded battery for the AR Drone and have seen a small increase in the flight time from five to seven minutes with the standard up to nine to twelve minutes with the upgraded battery. Another possible project could be looking into making a better battery or redoing the drones systems so that they do not use as much power to increase the battery life to increase the flight time. 6

7 Background and Competition: Right now with the AR Drone software that is out on the market does not allow any addition to the GUI while flight. The company also does not have many accessories for the AR Drone. There is other third party software on the internet what we have found with more to the GUI and we have looked into these. While with the GPS units there is no suggested GPS units for the AR Drone. The only accessory that is given as a suggestion is a flight recorder but the Applications that is already out have these built into them. The mobile application that is out is built by the same company that produces the drone. While the mobile application is a good application and works well with control and use of video camera via front and bottom of the drone. The many limitations of the mobile application right now is that it has no room for growth and that the GUI inside of the application does not give much detail of the flight per the drone. After looking into Windows applications that are built by third party people or groups we have found one that is already an increase in information shown. This Windows application we have found has just not a video display: pitch, row, gnaw (being the height), and an interface for the controller. We have found it is much easier to control the drone with actual joy sticks than on a touch screen. By this we may stick with a windows application where we can use a wired Xbox 360 controller connected to the Windows machine to control the drone. Between joysticks and the touch pads we like joysticks more. Just able to feel the joysticks helps control the drone. While using the mobile application and touch pads we have found our thumbs slipping off the touch areas. Figure 4. User Interface of Windows Application 7

8 Once we get the Windows application to the specifications we like we are going to possibly move onto a mobile application. This will be either for the Nexus 7 tablet or after more discussion a PSP (PlayStation Portable). With the Nexus 7 tablet we would need to use the touch areas with touch events and we are not too keen on with these by the users fingers can slip off. With the PSP the user will have a D-Pad and a set of four buttons. These will all be a setup that the user can feel and keep their thumbs more on the spot and no chances of loss of control. Within either of these we can make the compass on the top of the video. Figure 5. Nexus 7 Tablet While looking around online for similar projects we found projects to control the AR Drone with a GPS unit but none with displaying the data. We are just trying to allow the user to see the data coming from a GPS unit. The only competition that we have found with any correlation to our project is a larger size drone that already has GPS built into it. With our product the market of smaller drones can become very competitive. One major problem that has been found with the smaller drones is if they are flying and battery dies they just drop. With a GPS onboard and allowing the user to see the coordinates they could look at the last known place for the drone if they lose signal to retrieve their drone. This can lessen the guess work when looking for a down drone. 8

9 Innovations: The difference of our approach than any other is that we are trying to something that should already be out there. We are also taking the first part of another problem, that problem is GPS controlling. Where many groups have tried to tackle controlling a drone with a GPS route and get hung up on the implementation of the GPS we are focusing on that and adding that to the user GUI. Potentially another group could take our work and add onto it with the GPS controlling route. After looking at a few other projects that tried to use GPS units with their own drone we found that many of them did not use GPS units with compasses built in. We took that knowledge and found a USB GPS with a built in compass. This will give us directional data as well as coordinates. Most groups usually only work on a mobile application for the AR Drone and try to improve the application that is already out. We have completely ditched the application that the company has put out. We have started with building a Windows application that gives us a good starting point and a possible testing ground for what we would like to do. Once we get everything we would like to do on our Windows application, we can explore an Android application or stay with our Windows application which would still allow us to finish our project. Deciding to go to an Android application or staying with Windows will be on the decision if we can connect our hard controller to our tablet. We would like to stay with joysticks that you can feel in your hands because we found our thumbs slipping a lot on the default application. After some more discussion we have been looking into doing a PSP application instead of an Android application. This would allow us to go to a mobile platform and be able to keep a hard surface like joysticks. With the PSP we would have a D-Pad for the left thumb and a set of four button for the right thumb. We would also gain two bumper buttons on the top of the PSP that we could code to do commands. We would need a modified PSP to take person built applications. PSP can be coded in C++ or C so our Windows application of C# would not be far off. If we are to go to a PSP than that would also be a smaller controller vs. tablet that is a little larger. We would not have as big of a screen as a Nexus 7 tablet but with the tradeoff of the D- Pad and buttons is better than a bigger screen. The PSP does have Wi-Fi capabilities with it and for the research we have done it should not be a hard part if we already have a program in C#. 9

10 Figure 6. PSP (PlayStation Portable) We feel like we can be successful at this time because we are not thinking like other groups that have tried to use GPS units on their AR Drones. We are also trying to only tackle one problem with a GPS instead of trying to get the data and to control our drone with those coordinates. Our problem is much smaller than trying to allow the drone to be controlled by the GPS unit. We are taking that data from our unit and only displaying it. We have thought about the mobility of our project and we have been mainly using a laptop not a desktop like most people would use for a Windows application. This will still give us mobility, maybe not as much as a tablet but could still be deployed out in the field easily. If we are able to connect our controller to our tablet then the amount of material a user needed will be greatly lessened. We see most users agreeing with us on the joystick vs. touchpads argument. Touchpads are great but their major problem is that you cannot feel them. This causes a user s thumbs to slip off of them easily and a possible loss of control of the drone. If a user has a loss of control of the drone that can cause problems of the drone going wild and hurting someone. The loss of control is the number one negative input with use of these within a large crowd. If with using joysticks help us achieve to lower the chance of control and lower the amount of people having this negative outlook. Impact: The major difference that our project will do is give the user the ability to see where their drone is at. This can help out if the drone loses power and drops the user can go back to see the last spot the drone was by the coordinates. This can decrease the amount of the cost users may have to put out by a loss of the machine. Another major impact would be if a governmental group is in search of an object or person. These drones can get into smaller places and fly into area where humans or animals may not be able to get too. This can also decrease the amount of time a human or animal lives are exposed to possible hazardous environments. These drone could only be used for searching 10

11 but once a target is found then this drone could hover in the location of the target. The group that is searching for the target then could look at the coordinates given by the drone and also look for the hovering drone in the air for a more precise location. Granted the coordinates gained from the drone would be accurate. A drone can cover a lot more land in a smaller amount of time than a search group can cover. When searching a large area instead of having groups go out the searching group can launch multiple drones and each one with only one operator. Each drone can quickly move and find what the group is looking for and easily give the coordinates. Our new GUI will be more user friendly and built in a way that an advance user or a novice can use it. With the compass at the top the user will be able to get their directions better and the addition of coordinates will give them a location without guessing. Depending on what platform we decide to go with is how much the user will actually see. While with a Windows application we can show the user s pitch, row and gnaw (being the height). While with a mobile application we cannot show as much. We could show the data of the pitch, row and gnaw without a graphical look under the GPS coordinates. With all of this a user s experience will be much better. Project Plan: The tasks that need to be done are: getting familiar with the drone, get a GPS with the specifications we want, build Windows application, build mobile application for PSP or Android, test/documentation. This is a very high looking at the tasks at hand. Each one of these tasks have many subtasks within them. With becoming familiar with the drone we will have to test the drones that are already in the lab to find one that is in good working order. We will also have to make sure that all the batteries are good, we have also bought a upgraded battery to see how much more time we can get. While working in this task we will need to use the applications that the company that makes the drone has put out on the market. The windows application will need to be built in C#. We have found a couple of Windows applications online that are a good starting point for us. All the licenses are of Apache and open source code. We will need to learn the ins and outs of the application we do use to be able to make improvements. We will need to make it for that the application reads the data coming from the GPS. While working on this we will also need to look for a good GPS that has a digital compass on it. We have found a good USB GPS that is light weight and works on all Operating Systems. Our GPS is not native to Windows so we will need to use the Linux Box of the drone to run the GPS systems and be able to send the data to our application. At first we thought we would need to dual compile between Windows and Linux. We think we have found a way to compile everything on one Windows machine. If this works we will need to find out how the data is being transmitted and what type of format it is in. After we get all that we can work with our C# code to put the GPS and compass into places we want within the GUI. 11

12 Once we have the Windows application with all the specifications we want we can look into the mobile applications we could possibly make between a PSP or an Android device. With this decision we need to weigh the pros and cons of each systems. If we can find a way to connect a controller to the Nexus 7 then we can go with that but until then we will probably go with a PSP application. We all agree on the joysticks or a hard surface that the user can feel and know their thumbs are on the controls. With building the mobile application we will need to make sure that the device we choose can communicate well with our drone. In the case of a PSP we will need to hard code the D-pad and buttons for the controls we want. If we can connect a controller to the Nexus 7 we will also need to code the buttons on the controller. When the application is built we will need to start testing of all the controls and systems to make sure they are working properly. While testing we will need to make sure to take good documentation of everything we do. We will need to keep good documentation during the whole project. With documentation we need to take down any changes we make and make sure we have good comments within our code for if anyone else wants to improve our code in the future then they can understand what we did. From the code we got from other sources as Git repositories there was really little to no comments or documentation. The schedule we have come up with is mainly splitting up the project into two halves like the semesters we have to work on this project. We have put tasks into each half we feel that will be best for those tasks and have the best chance to get them done in a good manner. The tasks for the first semester are to get familiar with the drone, get the GPS and build the Windows application. The second semester will have the building of the mobile application on either of the mobile devices we have found that we may use. The second semester is also reserved for testing with the mobile device and if we have time possibly adding on a distance tracker with an Arduino laser. The first semester can be broken up into two different parts for the different tasks we have. The first part will be the first month and half of getting familiar with the drone and getting the GPS. The rest of the semester will be left for building the Windows application. Because we will need to build application and integrate the GPS within it we feel like giving this so much time is a good idea so if we run into any road blocks we will have plenty of time to fix these glitches. Toward the end of the first semester we can also look into mobile applications again and see which way we want to go with either a PSP or Nexus 7. During the first month of the second semester will be getting the mobile device we want to use and building the basics for the application to run on it. Again the second semester can be broken up into two parts but this time it will be more evenly distributed. The first half will be building and getting the mobile application to our specifications with the integrated GPS and displaying that content on the mobile device. Depending on which mobile device we decide to proceed with will determine how intensive the application will be. With PSP not being as open as an Android devices we will have to find a modded PSP and a wrapper to allow us to run our 12

13 application on the PSP. After the mobile application is working we can begin to test and document everything of how well the drone with GPS works outside and movements with the elements. If we fair amount of time we will look into putting a distance monitor on board where the user could pick on object in front of them and the drone tells them the distance front the drone to the object. The metrics of each part is on the performance of the drone and the application. Right now we have become familiar with the drone and we all can flight it quite well with the default application. With our own application we have been able to fly the drone to the degree with the default application. Once we can obtain the data from the GPS over to the User Interface we can read that data. Each task has its own metrics ranging from flight ability to User Friendly. The overall metric would be the use of our drone and Program in real world applications in the examples stated above. The progress we have made so far is of low level to the problem but progress that needs to be made in order to make this work. With building the Windows application and having it work well with the drone was our biggest step so far. By this we have shown a user does not have to use the application that the company that makes the drone put out on the market and instead make an application to their own specifications and uses. The next metric we are looking to make is by the end of the semester as of getting the GPS and the drone to work with our Windows application to show the coordinates inside of our User Interface. With that deadline we think we can make this and that next semester we can focus on a mobile application. The second semester s metrics will be of building a application on a mobile platform we like and can use easily and keep the same control that we have with the Windows Application. Once we have that we can work on pulling everything together with the mobile platform. The thing that will cost the most is time and energy. The drone we are working with is already within the Senior Design Lab. The GPS unit have found was a low cost of under thirty dollars. The tablet we were provided with as well from the Senior Design Lab. If we decide to go with the PSP we may have to use person money for that or if one of us have a PSP use that. Our budget does not need to be big. Right now we are looking at a budget with a three hundred cap for if we need any parts for the drone. 13