Prototype PRE2 Groep1
| Overzicht | Pagina's | ||
|---|---|---|---|
| Home | Autonomie | Concurrentie | Wetgeving |
| Week 1 | Veiligheid | Privacy | Prototype |
| Week 2 | Enquête | Commerciële Analyse | Producteisen |
| Week 3 | Project Doelen | ||
| Week 4 | |||
| Week 5 | |||
| Week 6 | |||
| Week 7 | |||
| Week 8 | |||
| Logboek | |||
Samenvatting
Op deze pagina beschrijven we ons prototype in detail. De beoogde werking van het prototype is het volgende: met een applicatie op een mobiele telefoon kan de drone geroepen worden (in de praktijk zou dit via een computer in een distributiecentrum gaan). Met behulp van de GPS coördinaten van de mobiele telefoon vliegt de drone naar de telefoon toe. Eenmaal aangekomen houdt de besteller zijn telefoon ter verificatie tegen de drone aan. Als de drone deze NFC-chip herkent springt de drone open en kan het pakketje gepakt worden. Als de gebruiker het pakketje uit de drone heeft gehaald, kan hij op zijn telefoon een 'oke' doorgeven, waarop de drone terugvliegt naar zijn thuisbasis.
Componenten
Het prototype bestaat uit een samenstelling van de volgende componenten:
- Parrot AR drone 2.0 (beschikbaar gesteld door Lambèr Royakkers)
- Arduino Mega(beschikbaar gesteld door Ruud van den Bogaert)
- NFC Shield(beschikbaar gesteld door Ruud van den Bogaert-Aangeschaft €24.50) http://www.antratek.nl/nfc-shield
- WI-FI Shield(beschikbaar gesteld door Ruud van den Bogaert-Aangeschaft €65.90) http://www.antratek.nl/arduino-wifi-shield
- Flight recorder voor Parrot AR
- Smartphone met Android 4.4.2 (API 19)
Componenten testen
= Parrot Drone en Flight Recorder
Voor de Parrot AR Drone 2.0, moest een WiFi/UDP connectie vanaf de laptop naar de Flight Recorder opgezet worden waarover de GPS-waypoints werden verstuurd. Hiervoor werd het communicatie protocol MAVLink gebruikt, wat ingebouwd zit in de software QGroundControl.
Als eerste werd de laatste versie van deze software gebruikt (v2.2.0), hiermee was het echter enorm moeilijk om een werkende verbinding op te zetten, omdat bepaalde instellingen niet toegankelijk waren. Een ‘communication channel’ kon wel gemaakt worden, maar hierlangs kon – om onbekende redenen – geen waypoints verstuurd worden.
Na veel online zoeken en vragen en weinig online antwoorden is besloten om over te stappen op versie v1.1.0, waarmee de verbinding veel makkelijker te maken was. Dit lukte dan ook vrij snel, waarna het testen van verschillende flightpads kon beginnen.
Uit online fora bleek namelijk dat er maar een beperkt aantal type commands gebruikt konden worden; alleen ‘waypoint’ en ‘land’, respectievelijk aangevend waar de drone heen moet vliegen en waar hij moet landen. Dit besloten we op de proef te stellen omdat het voor ons prototype mooi zou zijn als hij ook het command ‘takeoff’ kon gebruiken, waardoor hij na het landen weer op zou kunnen stijgen en naar de thuisbasis terug kon vliegen.
De eerste test – na wat kinderziektes zoals hoogte, snelheid en kijkrichting aangepast te hebben – was geslaagd. Hierin hadden we echter alleen de ‘waypoint’ en ‘land’ type flightpads. Toen erna een probeert werd met ‘takeoff’ command lande de drone eerst wel, maar steeg daarna niet meer op. Dit was erg jammer en betekende dus dat we ten allen tijden met de laptop in WiFi range van de drone moesten blijven om na het landen de instructies te geven om terug naar het beginpunt te keren.
Arduino met NFC en Wi-Fi shields
Op de arduino worden 2 shields geplaatst. Het WI-FI shield en het NFC shield. Voordat er begonnen kan worden met programmeren moet de arduino met de beide shields verbonden worden. Hiervoor worden de testscripts gebruikt die door de fabrikanten beschikbaar worden gesteld.
Voor het WI-FI shield dient eerst de firmware te worden geupdate.[1] Hierna is het mogelijk om de beschikbare netwerken te scannen.[2]
Voor het NFC Shield moeten er libraries worden toegevoegd om de NFC Shield aan te sturen.[3] Hierna kan er met het beschikbare testscript gekeken worden of het shield een NFC tag ziet. Er is hiervoor een niet geprogrammeerde NFC tag uit een smartphone gebruikt. Hierdoor zit er geen data in.
In bovenstaande afbeelding is te zien dat het shield scant voor een tag. Zodra het de ongeprogrameerde chip vindt van de smartphone, geeft het de melding dat de lengte van de data niet ontcijferd kan worden. Dit is logischerwijs wat verwacht wordt: De shield ziet de tag zodra deze in de buurt komt, maar kan deze niet lezen omdat deze geen data doorstuurt.
Het combineren van de shields is niet direct mogelijk. Eerst werd gedacht dat er gemakkelijk een connectie geplaatst kon worden tussen de Arduino en het WI-FI shield, daar er 4 pinnetjes bij het NFC shield mistte bij de brug. Toen deze geplaatst is, bleek dit niet te werken. Na wat research ( http://www.circuitsathome.com/mcu/running-multiple-slave-devices-on-arduino-spi-bus-data-formats/comment-page-1#comment-25250 ) lijkt het te liggen aan het dubbel gebruik van dezezelfde poort. Hierom is de poort van het NFC shield omgelusd van poort 10 naar poort 9, zodat poort 10 voor het WI-FI shield gebruikt kan worden. Er is toen in de library van het WI-FI shield de verwijzing naar poort 9 weggehaald, zodat poort 9 niet gebruikt zou worden door het WI-Fi shield. Hierna is er-zoals in de handleiding- gewerkt om het wifi shield direct op de arduino te plaatsen, waardoor er een lus van 6 poorten nodig was om de ICPS pins van de NFC shield aan te sturen/uit te lezen. Hierna is de library van het NFC shield omgeschreven daar deze een ander data-format gebruikt(MSB first) dan de overige verkrijgbare shields(LSB first). Hierna is echter hetzelfde probleem ervaren: Beide shields zijn los uit te lezen, maar zodra ze op elkaar worden gezet is enkel het WI-FI shield uit te lezen.
Hierna zijn de shields verwisseld(NFC eerst, dan WI-FI) en is er wederom een lus gelegd tussen de poorten waar de NFC shield geen brug voor heeft. Dit resulteert echter in hetzelfde resultaat.
Sequence Diagrammen
We hebben een Message Sequence Chart (MSC) gemaakt om de communicatie tussen verschillende onderdelen in ons prototype overzichtelijk te maken. Het prototype bestaat uit 4 onderdelen die met elkaar communiceren: De android applicatie op een smartphone, een laptop die dient om de GPS-coördinaten van de smartphone naar de flight recorder van de drone over te zetten en om de verificatie code van de telefoon naar de arduino over te zetten, de arduino met NFC shield en de drone.
We hebben ook een MSC gemaakt om inzicht te geven in hoe het proces er uiteindelijk uit moet zien in een bedrijf.
Dit is de totale implementatie van ons idee zoals wij het ons voorstellen. Er zijn 3 onderdelen die met elkaar communiceren: Een smartphone (met een iOS/Android app) van de klant, een drone en een centrale die de communicatie tussen de klant en de drone verzorgt.
