3/2/15 Week Progress

This week was heavily focused on sensor research. We needed to know everything about sensors that might be useful to us in the future. I centered my research on accelerometers and ultrasonic sensors. I took notes on my research and shared them with the rest of my group. Those notes can be viewed here:
https://docs.google.com/a/erhsnyc.net/document/d/1IDusj62JcVtWjOUq0Q2_YyC9YIXPkqSnfm2RgsoXeBU/edit

Next week will be focused on both the Linux SDK and the cameras in the drone. Specifically, I will see, along with other members of my group, how the cameras work with the SDK.

- Guilherme Dias

Week of 3/2/15

AR Drone

Notes:

• Quadrotor UAV with each opposite pair or rotors turning clockwise, the other turning counterclockwise  
• Indoor and outdoor configurations
• Powered by brushless engines with three phases, microcontroller
• Automatic detection of blade stopping, stops the all rotors
• Sensors consist of many sensors below the hull
• 6 DOF, MEMS-based inertial units used for pitch, roll, yaw
• Ultrasonic sensor for altitude control
• Camera aiming towards the ground/front facing 90 degrees
• 3 DOF with 3 axis magnetometer and pressure sensor
• Tilt sensors used for hovering and stabilization

Accelerometer:

• electromechanical device used to measure acceleration forces
• movement (vibration) of the sensor creates voltage, which changes the output
• how they work:
• piezoelectric effect: microscopic crystals that get stressed by accelerative forces → creates voltage
• can have two microstructures next to each other → they have capacitance between them → when one moves, capacitance changes → can convert capacitance to voltage using circuits
• can analyze tilt and movement of the drone
• can sense if the drone is falling/crashing
• drone can react if it falls (security measure)
• analog vs digital (based on hardware)
• analog: outputs voltage continuously in proportion to acceleration
• digital: will produce a square wave; acceleration determines amount of time for which the voltage is high
• for 3d movement, we need either a 3 axis accelerometer or two 2 axis accelerometers mounted at right angles
• for a fast moving machine, we need an accelerometer with a larger bandwith (amount of times per second we can get a reliable reading)

Ultrasound Sensors:

• measure properties of sound waves with frequency above human audible range
• based on: time of flight → senses distance; Doppler effect → senses velocity; attenuation of sound waves (combined effect of scattering and absorption (conversion of sound energy to other forms of energy)) → sense directionality
• can detect clear or shiny objects that other sensors do not pick up
• measurements are extremely sensitive to temperature and angle of target
• if transmitting and receiving transducer are used next to each other, the distance calculated will be twice the actual distance
• transducer takes some time to switch between modes (sending and receiving), which causes a problem for short distance measurements

Gyroscopes:

• https://www.youtube.com/watch?v=cquvA_IpEsA - Basic info

• A gyroscope is a device with angular momentum used to capture orientation
• Gyroscopes maintain its orientation in space
• Used by aircrafts to control orientation
• https://www.youtube.com/watch?v=TUgwaKebHTs - Physics
• Possible Gyroscope sensors can be used, rather than the physical
• Gyroscope will keep its orientation, resisting any outside force to change
• Consists of a central rotor within a gimbal
• http://upload.wikimedia.org/wikipedia/commons/e/e2/3D_Gyroscope.png
• Gyroscopic Precession https://www.youtube.com/watch?v=GeyDf4ooPdo

Magnetometers:

• Two purposes: “to measure the magnetization of a magnetic material like a ferromagnet, or to measure the strength and, in some cases, the direction of the magnetic field at a point in space”
• http://diydrones.com/profiles/blogs/advanced-hard-and-soft-iron-magnetometer-calibration-for-dummies
• http://www.engineersgarage.com/articles/magnetometer
• “Since magnetic flux density in air is directly proportional to magnetic field strength, a magnetometer is capable of detecting fluctuations in the Earth's field.”
• Magnetometers detect distortions in the magnetic flux which i
• 3 axis magnetometer 6° precision
• 
• “With a 3D magnetometer, the AR.Drone 2.0 knows its precise orientation with respect to the smartphone, which becomes the reference point. The pilot no longer needs to care about the orientation of the AR.Drone 2.0's front camera, which will accurately track the smartphone's motion and tilt.
• ‘Relative Flight’ mode = conventional flight mode. This disables Parrot AR.Drone 2.0's magnetometer. The pilot manages the quadricopter's orientation with no assistance.”
• tells the drone precisely how it is oriented respective to the control device
• measures magnetic flux density at point where sensor is located.  The max. distance the magnetometer can detect the sensor  is directly proportional to the cube root of the magnetometer's sensitivity

*****

NOTES:

TUMS FLYING THROUGH A STRAIGHT LINE AND AVOIDING OBSTACLES-

http://vision.in.tum.de/teaching/ss2013/visnav2013

http://www.youtube.com/watch?v=9PbcbXoD76k&feature=youtu.be

****  

Week of 1/19/15

Progress: There hasn't been much progress lately (see Problems section). We are still setting up the spiri simulator and the container is ready for printing, although that has not been done yet. However, we found an open source program called OpenCV (Open Source Computer Vision)* that may be able to help with image recognition using the camera that is built into the Spiri, so that the drone can navigate throughout the school. The software seems to have an extensive library available in many languages, as well as a forum in which anyone can post questions and ask for help. This seems to be promising, but we need to try it out before we can determine if it is good enough for what we want.

Problems: Our group is not very well organized and the project is moving along very slowly. This is a major issue that we need to fix very soon.

Plan: In this coming week, we will print the container, fine-tune it, and hopefully finalize it so that the project can move along. Also, we will experiment with OpenCV to see whether is satisfies our needs or not. Furthermore, we hope to have the spiri simulator running sometime this week so we can start learning how it works and have a working demonstration of both the simulator and Gazebo by the end of the week.
Meanwhile, we will attempt to acquire the drone, and since the dev team is not responding, we may need to just buy it as soon as possible. Moreover, Gui will continue to learn the basics of SLAM on the side in case we need to turn to that option, but that would be an extreme case, because it is both difficult to learn and implement.

*OpenCV website: http://opencv.org/

Progress Report: Week of 12/18

Progress:

This week we focused primarily on integrating linux into our project. Linux is the operating system that the spiri drone runs on, so it is essential for the advancement of our project. So far we have figured out how to run linux on a mac computer. This can be done through a bootable usb drive. By putting the Linux disk image on a usb, we were able to boot directly from the drive by holding down the option key while the mac is starting up.  This has allowed us to work on mac computers instead of having to use the one linux computer that Elro has. Gui and Vasil watched many Gazebo tutorials on their website (http://gazebosim.org/tutorials).  Arianna Vetrano Sebastian worked on the container and tried to make it as light as possible by cutting out sections of the container that is not needed.  

Problems Solved:

Sebastian and Arianna solved the problem of how to make shave down the weight of the container so that we could increase the amount of things that could be carried during flight.

Lessons learned:

Arianna and Sebastian learned that we can make the container a bit lighter by adding holes to it since it is excess weight that really does not have any use.

Problems:

Connecting to wifi has been an issue for us because the schools wifi network is very difficult to connect to. Also, nothing on the linux computers are saved. This is because of the nature of the USB drive.

Drives must be configured to boot with persistence in order for basic files and inputs to be saved on the computer. We are still figuring out how to boot with persistence.

Plan:

Ben plans to download Linux onto a PC computer instead of using it on the Mac.  Gui and Vasil plan on continuing to learn Gazebo since that requires times and begin developing algorithms.  Arianna and Sebastian plans on printing out the cylindrical container and figuring out the more effect way of attaching it to the drone.  If we do not get a response from our correspondence by the time we get back to school, we will try calling them up.  We will need the Spiri as soon as possible.

12/11/14 Progress Report

Container
Progress:
 So far we have brainstormed multiple designs for the container.  Originally we were thinking of a cube-shaped box, however we realized such a container might not be the most practical for transporting paper. As of now we are sticking with a cylindrical shaped container where we can roll up papers without needing to fold and wrinkle them.  Although we have not yet received exact dimensions of the body of the drone, we were able to estimate them with measurements we do have.  Using these, we now can now get a better scene of size and have also begun to model the container on Sketchup.


Problems Solved:
After realizing that the top of the drone have ventilations, we needed to figure out a way to situate the container so that they would not be blocked. This week we solved the problem and decided to add stilts that will lift the cylindrical container up above the ventilations.  

Lessons learned:
One lesson we learned was that always think one step ahead.  We should have emailed the company and asked for specific questions such as the dimensions for the body so that what we are creating can be more precise.

Problems:
One problem we now face is how we will attach the stilts to the body of the drone.  During our group presentation, we received many helpful suggestions on how we can go about this.  Some suggestions include attached the silts to the USB port or the four screws (shown in the diagram below).  Another problem is that we still do not know have the drone so once we print out the container we cannot fully test it out. 

Plan:
Our plan for the next week is to print out our container and figure out a way we can attach the stilts to the drone.  In addition, we hope that our correspondence will get back to us with the papers so that we can get the drone.

Week of 12/01/14 Progress Report

       Progress: This week was an important week. We started learning about ROS, which will be useful when we need to program the drone, and we designed a possible container for our drone. However, the most important part of this week was contacting the developers of the Spiri. We were able to email them our questions and tell them about our project, and judging from their answer, they seem eager and willing to help us with our project in hopes of creating more " educational partnerships." They offered us a discount on the drone, which helps with our budget problem, and they offered technical support whenever we need it. They also published all of the information that we needed about Spiri (including the Spiri data sheet) and a simulator for its API, which will be very useful to us while we wait for the Spiri to arrive.
      Problems Solved: One of the major problems that we solved was the budget, which the Spiri developers helped with by offering a discount. We were also able to distribute more tasks among ourselves, which will hopefully speed up the project a little bit.
      Lessons Learned: We learned that communication is very important. By finally contacting the Spiri developers, we realized that our project could move along much faster with their help. Luckily, they are willing to help, and so it is crucial to maintain contact with them from now until the project is complete.
      Problem: The main problem right now is that it is taking a while to learn ROS. It seems to be a little complicated and advanced, and it will certainly delay our project a little bit. We are also working on trying to get a simulator for ROS. Possible candidates for software that we might use are a program called Webots and the Spiri simulator.
      Plan: In order to counterattack the delay that was caused by ROS, we put 3 people responsible for learning it, while the other 2 members of the group take care of any other task that relates to the drone. This will hopefully make learning ROS a little faster.

Sources to learn ROS:
1. http://wiki.ros.org/
2. https://www.youtube.com/watch?v=_WyuAZ1SuTI&index=1&list=PL3064BF19A4F4CD1F

Week of 11/17/14 Progress Report

      This week was focused, again, on research. Since choosing our drone we have discovered that we need to learn more about its operating system and how we are going to be able to program it, so we started learning about ROS (Robot Operating System) using this document: http://www.cs.utexas.edu/~todd/cs378/slides/Week8a.pdf.
  We also took it upon ourselves to learn more about the drone that we chose and its components. We used this website to accomplish this task: http://linuxgizmos.com/linux-powered-quadrocoptor-has-three-cameras/
Moreover, we started looking more into wireless charging, because we believe that it can be much more efficient in out project if we charge the drone wirelessly instead of having it dock at a station every few minutes to recharge. The following 2 websites were used to research wireless charging: http://www.wirelesspowerconsortium.com/technology/magnetic-resonance-and-magnetic-induction-making-the-right-choice-for-your-application.html
http://powerbyproxi.com/wireless-charging/
       We also completed the system architecture for our project. It describes how every component of the project is related and will hopefully be useful to us in the future when we really start developing the project. Also, we started developing the system block diagrams in order to explore different paths to accomplish our ultimate goal, which is to have an efficient and easy to use drone delivery system. Those diagrams are not complete, but they will be in the coming days.
        However, our project did encounter some obstacles. First, when we chose the drone, we only considered its use for our project and failed to take into account the price. While it is not over our budget, it does come close to our limit. It is now priced at around $900.00. Our plan to solve this issue is to find parts that we could make ourselves with the 3D printer, such as the protective ribbons that can be ordered with the drone, thus reducing the cost and allowing us to tailor these parts to our own liking/need.
        Our other problem, and perhaps the most important, is the fact that we are behind schedule. By now, we should already be designing our project and starting to develop it, as shown in the gantt chart*. Ideally, in a couple of weeks, we would start designing the algorithm, but at this rate, it might be tough to do that. Our plan is now to break up the tasks that still need to be done into smaller, more manageable portions, and then distribute them between group members so that they can be done more quickly. Hopefully, if our plan works, we should be within our schedule in 3, maybe 4 weeks.

        Link to Progress Report Presentation: https://docs.google.com/a/erhsnyc.net/presentation/d/1MeY274P74Ll9ivr7eyqvbRyb9BDD5HLxfVg7-sqmIxE/edit?usp=sharing

*I know the gantt chart is hard to see, but we ran into some technical difficulties with the software and could not get a better image.

Sensors and More Drone Information

This weeks work was focused on finalizing our decision for the drone we want to use. In the end we decided to take Spiri over the other drones, simply because of its open source platform. We spent additional time looking at and analyzing dimensions, sensors and properties of the drone we selected. We gathered some information from outside sources on the performance and ability of the Spiri. The work done this week was very similar to last weeks, but we focused more on the abilities of the sensors of the Spiri. These are some of the sources for our information:

1. http://spectrum.ieee.org/automaton/robotics/aerial-robots/spiri-programmable-quadrotor-drone-kickstarter
2. http://thechronicleherald.ca/business/1147707-flying-robot-developer-plans-spring-launch-of-spiri
3. http://www.hackthings.com/meet-spiri-your-autonomous-and-social-creature-that-flies/
4. http://www.gizmag.com/spiri-quadrotor-drone/28700/
5. https://www.kickstarter.com/projects/914887915/spiri?ref=nav_search
6. http://pleiades.ca/about/

A very significant part of our research is going to be on ROS (Robot Operating System) because it will provide the basis for our design and development of the algorithm. On separate note, the other time of the week was spent researching the capabilities of the sensors on board.

1. GPS - Can be used for a variety of things when it comes to keeping track of positioning. To be more specific, the drone will be able to be guided anywhere in school with up to 3.5 to 4 meters accuracy. Now this is not a small distance by any chance, but instead for full on coordination with GPS, it will be used partially to set waypoints/end destinations/docks/etc.
2. 9 axis IMU - Essentially can be used for anything force related when it comes to sensors. It probably wont play a major part in the algorithm, but will serve as safety precaution when it comes to emergencies. A page with PLENTY of intimation can be found here. Basically explains the basics of gyroscopes and accelerators. http://www.starlino.com/imu_guide.html
3. Ultrasonic Sensor - In the case of Spiri, this sensor is located on the bottom of the drone so its major purpose will be to detect height and changes in height. The major benefit of this sensor being on the bottom is that it will extremely useful for docking/parking at pre-launch or landing. 
4. Cameras - By far the most important tool the drone contains. The Spiri comes with 3 different cameras that can film at 1080pi at 30fps. These stereoscopic cameras can be used for a variety of different functions when it comes to sensing the surroundings. First this video provided the basis for what exactly "stereoscopic" means when it comes to cameras and lenses. https://www.youtube.com/watch?v=UOnqoC-dJcg Additionally, the cameras would be extremely useful in the field of Computer Vision. Using this technique, we can analyze points on the wall to create a dynamic path to the designation. A video that I watched was https://www.youtube.com/watch?v=715uLCHt4jE. It explains in depth the basics of computer vision. I will continue to watch the later lectures as well. 

In summary, advances were made in the research of sensors and how they can be used for our purposes. More research is going to be conducted on more advanced methods for maneuvering in 3D space. From here we begin our design for the algorithm along with the possible ways of its implementation. 

Selected Drone and Sensor Analysis

This week was heavily focused on researching drones that could be implemented in our project without going off task. Initially, we looked for prices and eliminated the ones that were over our budget, because regardless of their specifications, they were out of reach. Next we analyzed their sensors, flight time, size, work load and if they were programmable through an already established API. Some of the drones were eliminated because of the prices, straight out. However, some did not make the cut because they lacked the necessary sensors and/or platform for programming. The 9 drones included the Parrot Beebop Drone, the DJI, the IRIS, the Storm Drone 4, the Quanum Nova, the HEXO+, the Spreading Wings WooKong-M, the Phenox and the Spiri. Individually, Gui and I focused on researching the Spiri and Phenox. Arianna spent time researching the Quanum Nova, the HEXO+ and the Storm Drone 4. Sebastian spent his research time on the Parrot Bebop Drone and on the DJI. Lastly, Ben did very extensive analysis of the IRIS. In conclusion, we determined the Spiri to be the most suitable for our project, at least at the current state. It provides an open source programmable environment, has an array of sensors and cameras and also seems stable and reliable. The second drone that was very close to getting picked was the IRIS. It was by the far the largest drone with lengths of 21 inches from motor to motor. The IRIS is able to carry nearly 4 times as much material as the SPIRI, but is rather bulky and large. This being the sole reason we did not pick it. The idea here is to start out small. Once we know its doable at a smaller scale, it could easily be implemented with more advanced and heavy weigh drones.

Decided to take this drone was not easy and the decision itself came with a lot of problems and questions. Initially we needed to determine the load the drone was to carry, regardless of what model it is. Carrying important documents or pens is not a big deal, but having to take a stack of papers could be problematic. It was a hard decision to make because the SPIRI provided a wider arrangement of tools for programming, even with its lower load. The IRIS mentioned vague information on its sensory system, things along the line of "automatic avoidance of obstacles" or "returning to start position". This provided no solid information on whether we can design algorithms and upload them. The price consideration was also another problem. We did not want to take more expensive drones  for the sake of their price. If something was cheaper and functioned better for our needs, it would be more valuable.

Starting with next week, we are going begin researching how to use the sensors attached to our selected drone in the most efficient way. This will include ultra sonic range finders, infrared sensors, accelerometers, altitude sensors and other IMU's that are specific to the drone. We will also spend time learning about methods using the camera for a sensor, and how it could be used for positioning in 3D space. We want to make sure that the sensors that are coming with drone are absolutely acceptable for the job we need to do. In general, I think spending time researching the right drone will lead to more efficient developments in the future.

Progress Report

Progress report

Progress:
This week we researched different drones that could carry out the tasks needed. The drone must be able to carry a certain payload (stack of papers), and be able to maneuver through small spaces with ease. Most importantly, this drone must be able to be programmed autonomously using either raspberry pi or Arduino. Our drone selections must also meet the $1000 budget given to us.

Problems solved:
Budget was a problem at first, but with further research we were able to find a bunch of drones that met our financial limitations.

Lessons learned:
this week, we learned that our drone cannot be perfect. There will always be something (weather it be size, weight, or strength of rotors) that will limit us from having the drone fly at its greatest potential.

Problem:
At this point in our drone research, we have not encountered any problems except for a limited number of drones with reasonable flight times. Some drones only have 12-14 minute flight times, which may not be enough for a long range delivery if it were to be used in a warehouse or large office building.

Plan:
Our plan is to decide on a drone we like and order it. We are also going to move onto the research of our algorithm and hardware. Once the drone arrives, we can play around with the box building and other fun things like that.

Progress Report

Patent Research

Progress:

Tasks Accomplished: This week we continued our research on Patents and through the USPTO we managed to find many new patents that related to our main project. We also did a powerpoint explaining in depth some of the more important patents we found, we explained ways in which what we researched could be implemented into our drone delivery system. This patent research took us longer than we expected but it has helped in opening our eyes to different ideas we could implement. Things such as a main base in various rooms that guides the drone rather than having the drone sense on it own. With our environment being controlled there is no need to have sensors on the drone, a simple mother base could navigate it through the already mapped out hallways. The patents our group members focused on were:

Gui: Containers/Receptacles

Vasil: Delivery/Design & functions of drone 

Arianna: Flying vehicles/robots

Ben: Ornamental design to drone

Sebastian: Batteries (rechargeable)/Navigation 

Problems Solved: 

We were successful in dividing the research and finishing up finding all the patents we could. We also managed to get in our powerpoint on time and present to the whole class. 

Lessons Learned: 

This week, we strengthened our skills/knowledge in patent research and research in general. We were also able to find new ideas/concepts we could integrate into our final design. 

New Ideas: For now like last week, our project idea remains mostly untouched. We are pretty set with what we wanna do and one of our biggest worries at this moment is finding the right drone. However, one idea I did find intriguing was the fact we could have stations in each room to navigate the drone instead of having the drone navigate itself. 

Problem:

We didn’t encounter any big problem this week as we still focused on the patent research and the group was actually able to gain control of more patents. We solved our problem of last week with the lack of patents. 

Plan:

Our plan now is to hopefully move on from the patent research and begin more in-depth research pertaining to the overall construction of our drone and all the coding. We are still pretty unsure where we want to start with this project so it is up to us to stay on track and follow our diagrams. However like I said as far as patent research we should be done.

Patent Research

Progress:
Tasks Accomplished: Successfully started the patent research to find projects similar to ours, or projects that might be the basis for some of the drone's components. We shared a Google Docs spreadsheet to list all the patents that are relevant to our project (see picture below). Moreover, because our project encompasses many categories/projects, we are dividing the research into different classifications, so that each group member can find patents that relate to different components of our project. Group members are researching the following topics:
Gui: Containers/Receptacles
Vasil: Transportation/Delivery
Arianna: Flying vehicles/robots
Ben: Wireless connection to robots (via apps or websites)
Sebastian: Drones

Problems Solved: We were successful in dividing the research into manageable portions for each member, so that research can go faster and so that it can be more efficient.

Lessons Learned: This week, we gained new skills/knowledge regarding patent research and research in general. We are now able to find a patent that relates to our project and go through similar patents so that we can see the extent to which the category has been developed, making it easier to see what we need to do for our own project.

New Ideas: For now, our project idea remains mostly untouched. The main idea that came up through the research, which we might implement into our project, is the idea of a container with a sliding tray. This reduces the space that it occupies when it is closed while still allowing the container to hold reasonable amount of content.

Problem:
The main issue right now is finding patents that are closely related to our project. We are finding many patents that do relate to our project, but not in a very significant way, which makes it a little harder to compare our project to them in a way that might cause changes in our original idea. Besides this problem, everything is running smoothly. However, our original schedule has been pushed back by about a week to allow space for this patent research. When our project officially begins, we will be researching the different components that we will use and how to implement them in our project. In other words, we will be researching the materials/software/hardware that we need in order to complete the project.

Plan:
The plan right now to solve the patent issue is just to research more patents that are similar to the ones we are finding. That way, we will (hopefully) come across patents that have a close relationship to our project or to certain components in our project.
The issue regarding the delay in our project schedule can be easily solved. The project remains as it is described in our Gantt Chart, but everything will be pushed back a week. However, in an ideal situation, where no major problems arise, we will be able to finish certain tasks before the scheduled date. This is, of course, in an ideal situation.
In the coming week, Gui and Vasil will be researching software that will be used in our project, while Arianna, Ben, and Sebastian will be researching the drone that will be used, along with the components required for the drone to complete its objective (sensors, charging station, container, etc.).

Further Planning Completed

     This week was spent completely on developing a proper project schedule. It included all of the tasks that need to be completed before we can assemble our drone for prototyping. Initially, we began by looking at our action plan for the semester. From there we elaborated on possible extensions and requirements for further research on several different components. We placed our research as the first course of action in our project, followed by hardware and software integration. Using the arrow and Gantt charts, we learned that some activities are going to require more time than we predicted. This was incorporated in our project schedule by spreading out the work and creating parallels.

     We encountered some difficulties with the Gantt chart program itself, as well as with creating dependencies in our arrow chart. The Gantt chart program kept freezing and crashing, which slightly hindered our progress on the schedule. The arrow chart was difficult for a couple of reasons. It was very hard to determine some dependencies without some further research on previous nodes. As of now we require nothing new. We just need to begin our research and see how it lifts off to determine further problems/questions.

      As far as showing the work load for individual group members, it will displayed in the pictures attached. As of now, we do not have any experiments to conduct. We just need to begin learning more information of the drone.

We haven’t had much time in the classroom since the last class however we tweaked our drone design because we found out that our prior idea was already thought of.  

The problems that we encountered were:

1. our project has already been done by Amazon and other companies.
2. thinking of a new topic for our project
3. changing our project from a drone delivery system to a first aid kit drone.

Our plan is to design our own first aid kit and attach it to the drone so that it can be delivered to a person in need. We need to research different types of first aid kits and how to make the drone do what we want it to do. We also must make a project map for the future, and include all relevant steps in the map. We are also going to individually assign each person tasks that we believe would best suit them.

Drone Delivery Service Progress Report

This week our group searched for the tools that we would potentially need for our project.  Choosing the drone was a major issue because we need to make sure it can carry the weight, it is compact, can be programable to be autonomous and do much more.  So far we have found some candidates for drones such as the Parrot Bebop Drone (http://www.parrot.com/usa/products/bebop-drone/).  The problems we have encountered this week is basically how we will be able to program the drone and whether or not we should use Raspberry Pi.  Our plan for the following week is finalize which drone to use and to conduct further research on it.  Once we are able to do that we can figure out what program tool whether it be Raspberry Pi or something else. 

Weekly Progress Report

Project groups are required to maintain Weekly Progress Report about their progress. The report is due every Thursday. The writing should be clear and concise. The following list is a template for your report.

• Progress: list of tasks accomplished, problems solved, questions answered, lessons learned, new idea identified, etc. Include any images and/or videos of your experiments, presentations and/or documents of your results, links and/or printing references, and acknowledgements of external support.
• Problem: difficulties encountered, missing information, equipments required, materials missed, open issues, new risks or show stopper identified, etc.
• Plan: steps to attack the problems, action items, experiments to conduct, ideas to try, etc. Show your schedule and task assignment for each group member for the coming week.