PRE2017 4 Groep4: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
(Replaced content with '*First Idea *Second Idea')
Line 1: Line 1:
== Group Members ==
*[[First Idea]]
{| class="wikitable"
*[[Second Idea]]
! style="font-weight:bold;" | Name
! style="font-weight:bold;" | Student Id
|-
| Han Wei Chia
| 1002684
|-
| Hans Chia
| 0979848
|-
| Joost Roordink
| 1005406
|-
| Dennis Rizviç
| 1020540
|-
| Minjin Song
| 1194206
|-
| Thomas Gian
| 0995114
|}
 
== Subject ==
 
The subject we choice is: Emergency delivery drone
 
== Objectives ==
 
The primary goal is making a drone that is capable of bringing lightweight medical supplies and equipment to a place of emergency.
This means that the robot will need to be fast, able to deal with/avoid obstacles autonomously and have enough carrying capacity to bring along the medical supplies.
 
== Introduction ==
 
In case of medical emergency it can often happen that bystanders are not able to help the victim because of a lack of proper equipment. In such a scenario it would be useful to be able to deliver this equipment to the site of emergency even before medical professionals can reach it. This is a problem where drones could provide a solution.
 
The main advantage of using drones for this is that they can almost completely ignore traffic. An ambulance can get slowed down if there’s heavy traffic, while a drone can fly straight over it. This means that drones could have a significant speed advantage compared to other means of transport.
 
Using drones also has limits. Regulations put limits on their use(most importantly where they can be used and how heavy a drone may be). A drone is also only capable of carrying objects of limited size and weight, so it won’t be possible to carry any heavy medical equipment around.
 
A drone can of course not carry any persons, so an ambulance still needs to be sent. But having medical supplies/equipment on the spot for bystanders to use even before the ambulance can arrive can in some cases improve the odds of survival.
 
 
== Users ==
The primary user group will be medical professionals, since they will be using the medical supplies carried, and will also be loading and unloading the drone. The main issue here is that loading and unloading the drone needs to be a quick and intuitive procedure. Similarly, telling the drone where the emergency is also needs to be done quickly.
Bystanders of an emergency are a primary user group as well, since the drone might at times be able to arrive before medical professionals. In such a situation, the unloading of the drone would need to be doable/intuitive for them as well, even if they’ve never seen such a drone before.
Note that it is not useful for the drone to provide any further guidance on using the medical supplies. If a drone has arrived at a place of emergency, the bystander will presumably already be in (telephonic) contact with a responder who will be far more capable of giving instructions relevant to the specific emergency than the drone will be able to.
A secondary user group is the public at large: the drone will pass through public spaces while moving towards an emergency, so it should be clear what the drone is doing when it is passing by.
 
== Requirements ==
 
== Approach==
At the start of this project we’ll first start with gathering information regarding the dynamics, ethics, hardware and the software concerning our drone. The main reason for gathering this information is to expand our current knowledge about this subject and get accustomed to different techniques or approaches. After we’re satisfied with the amount of information that we’ve gathered we’re going to aim for creating a prototype.
 
We’ve chosen to create a prototype instead of a completely finished product because of 2 reasons. The first reason is considering the available amount of time for this project, a fully finished product will be to far fetched. The second reason is that the expenses for a drone which is able to transport heavier equipment will be too high considering our budget and equipment. For creating the prototype, we’ve split each part of the construction of the prototype in certain phases.
The first phase will be to specify all requirements regarding our drone. This phase is needed to make sure everyone has the same idea’s regarding this project while leaving no wrong for wrong interpretations. 
 
The second phase of implementation will be to find the correct parts for our drone and order them. The parts will have to be carefully chosen based on calculated which will be derived from the literature study.
 
Since it’s highly unlikely that we’ll obtain all the parts immediately after we’ve ordered them, we’ll be proceeding to the third phase which will look at the software. While the parts will most likely be absent at the start of this phase, we’ll hope to obtain them during this phase so that we’re able to verify the software. The main purpose of this phase is to get accustomed to the coding language and have the features theoretically working. We’re keeping it theoretical, since it’s hard to verify it while the frame is still missing.
 
The fourth phase will be to construct the frame of our drone which will start immediately after the parts arrive and the software has been verified to a certain extent. It is possible for this phase to be started even if the software has not been fully finished.
 
The fifth and last phase to create the drone will be to test it and if needed, fine-tune the code. In this phase we’ll test all our specified requirements and if they fail the test, we’ll try to solve it.
 
We’re planning on achieving the prototype by following these phases as closely as possible and to divide the work equally between our group members. During all phases we’re also planning documenting our progress regarding the drone.
 
== Milestones ==
*Parts ordered
*Parts delivered
*Parts tested
*Basic frame finished
*Prototype
*Frame and hardware coupled
*Quadcopter lifting off the ground
*Quadcopter stabilising
*Quadcopter directional movement
*Quadcopter semi-autonomous
 
 
== Deliverables ==
 
*Requirements
*Parts List
*Physics document
*User Manual
*Logbook
*Planning
*Tracing of requirements to hardware and software
*Final document (including code)
 
== Planning ==
[[File:planning.pdf]]
 
== Literature study ==
[[Summaries of Literature's]]
 
== References ==
<references />

Revision as of 15:25, 6 May 2018

Retrieved from "https://dsdwiki.wtb.tue.nl/index.php?title=PRE2017_4_Groep4&oldid=55750"