Prototype PRE2 Groep1

Navigatie

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)
• Flight Recorder voor Parrot AR (beschikbaar gesteld door Lambèr Royakkers-Aangeschaft €85.91)
• 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
• Smartphone met Android 4.4.2 (API 19)

Componenten testen

Parrot AR.Drone 2.0

Na een paar proefvluchten met de beschikbaar gestelde AR Parrot 2.0 drone, is gebleken dat GPS niet standaard ingebouwd zit. De drone kan enkel met de hand aangestuurd worden, en bevat geen soft- en hardware die GPS opvraagt en/of naar een GPS locatie toevliegt.

Parrot biedt zelf een zogenoemde flight recorder aan waarmee dit wel mogelijk is. Het gebruik hiervan is eenvoudig. Er is software beschikbaar waarmee GPS paden voor het vliegen in de flight recorder worden geladen. Echter is dit weer een investering van een kleine 100 euro. Er is dus gezocht naar alternatieven. Er is namelijk een arduino beschikbaar gesteld.

Er is hierop gezocht naar andere projecten met een Parrot 2.0 waarbij de drone autonoom zou vliegen. http://www.instructables.com/id/Autonomous-AR-Parrot-Drone-20-Flying/?ALLSTEPS http://www.nodecopter.com/hack

Het vliegen met deze projecten gaat zonder dat je de drone tijdens de vlucht bestuurd. Helaas houdt het ook in dat tijdens de vlucht niet gecontroleerd word of de drone op de positie is wat de bedoeling was. Er wordt bijvoorbeeld geprogrammeerd dat de drone op moet stijgen, naar voren vliegen met een pitch van 1 voor 5 sec, dan 'naar rechts' moet draaien, naar voren vliegen met een pitch van 1 voor 5 sec en moet landen. Het is nu enkel onduidelijk waar de drone naartoe vliegt. Behalve dat de 'naar rechts' en een waarde voor de pitch erg globaal gezegd wordt is elke vlucht anders omdat de omgeving variabel is. Zo is de wind bijvoorbeeld variabel. Zelfs als binnen gevlogen wordt is een vlucht bijna niet reproduceerbaar omdat de drone dan exact georiënteerd moet zijn als eerder.

Het is dus duidelijk dat er in ieder geval een regelaar aan boord moet zijn om te valideren dat de drone naar de juiste locatie toevliegt. Dit zou kunnen met een GPS op de arduino en dan software schrijven om de gps te vertalen naar een beweging. Dit is echter erg tijdrovend, daar dit niet eerder is gedaan. Een 2e mogelijkheid is om de flight recorder van parrot aan te schaffen, waar de software al voor beschikbaar is. Een alternatief is dat aangenomen wordt dat autonoom vliegen van/naar een GPS locatie mogelijk is, en dat de drone met de hand aangestuurd wordt.

Parrot Drone in combinatie met 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 konden – 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. Hierna is het mogelijk om de beschikbare netwerken te scannen.

WI-FI scan

Voor het NFC Shield moeten er libraries worden toegevoegd om de NFC Shield aan te sturen. 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.

NFC scan

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.

Na bijeenkomst van 22 December:Op de bijeenkomst van 22 december is met de docenten besproken dat het koppelen van de NFC met WIFI nog niet gelukt was. Hierop is geadviseerd om bij verschillende medewerkers van de TU langs te gaan die meer kennis hebben op dit gebied. Tijdens een bezoek aan Ruud van den Bogaert, vertelde Ruud dat het wellicht aan de voeding zou kunnen liggen, omdat er meer vermogen gevraagd kan worden door het circuit. Wanneer het hier niet aan zou liggen zou hij na het kerstreces eventueel wel tijd hebben om het bordje door te meten. Hieruit zou dan komen welke poorten er gebruikt worden door beide bordjes. Er is toen gekeken of het zou werken bij aansluiting van een externe voeding, dit was niet het geval. Tijdens het kerstreces is het circuit doorgemeten waaruit bleek dat poort 9 en poort 10 gebruikt worden door respectievelijk de NFC en WI-FI shield, wat al verwacht werd omdat dit eerder zo ingesteld is. Verder gebruiken beide shields de 6 middelste SPI poorten. Wanneer de beide bordjes een zelfde DATA format hebben zou dit ook te combineren zijn, dit blijkt hier echter niet het geval.

De combinatie van de beide shields is toen verworpen. Na overleg met de groep is gebleken dat het inladen van GPS coördinaten niet mogelijk zou zijn via de arduino en er dus al een computer met QGroundControl nodig was. Wanneer de combinatie van de beide shields wel zou werken zou dit weinig extra functionaliteiten bieden behalve dat de NFC code draadloos zou kunnen worden doorgestuurd. Het prototype komt hiermee wel dichter bij het model van de drone van 'het bedrijf'.

Hierna is een script ontworpen dat bij een specifieke code('Dr0ne') een positief signaal geeft en later dus een servo zou kunnen bedienen(om een deurtje open en dicht te laten gaan. Op dat moment was er nog geen servo beschikbaar dus is er gebruik gemaakt van de ingebouwde LED. Hier is later de servo en een externe LED op aangesloten.

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.

Opgeleverd prototype

Het opgeleverd prototype bestaat uit een Parrot Drone met Flight recorder. Aan de accu van de drone is een arduino met componenten aangesloten. Verder is er een Android applicatie en een server applicatie ontwikkeld.

Arduino

In het opgeleverde prototype wordt de arduino via een externe voeding aangesloten op de accu van de drone. Op de arduino zit het NFC shield, een servo, een LED en een voorgeprogrammeerde script( Arduino script).

Wanneer een NFC zender de code 'Dr0ne' via een peer to peer verbinding stuurt naar het NFC shield zal de servo geactiveerd worden en het 'doosje' open gaan. De servo blijft voor ~10 seconde in deze positie waarna de servo weer terugkeert naar zijn originele positie. Intussen zal de LED sneller gaan knipperen om te indiceren wanneer het poortje zal gaan sluiten.

Android Applicatie

Het interface van de app is bewust simpel gehouden, ten eerste omdat het een prototype betreft en ten tweede omdat het geen nut heeft om overbodige informatie aan de gebruiker te laten zien. Bovenaan het scherm is te zien met welk netwerk de telefoon verbonden is, daaronder staan de laatst bekende GPS-coördinaten en nauwkeurigheid. In het midden van het scherm is een invulveld waar het IP-adres van de server ingevuld dient te worden. Daaronder bevindt zich een knop om een pakketje te bestellen en relevante status informatie.

Screenshot van de app

De Android applicatie heeft 3 belangrijke functies:

• GPS-locatie

Hiervoor benadert de app de GPS-module in de telefoon om informatie over de huidige locatie. De GPS-module stuurt ongeveer elke seconde een update en de app haalt daaruit de latitude, longitude en nauwkeurigheid en geeft deze waardes weer in het interface. De hoogste nauwkeurigheid die behaald kan worden is 3 meter, dat wil zeggen dat er een kans van 68% is dat de echte locatie binnen een cirkel om de gegeven latitude en longitude ligt met een radius van 3 meter. Het is belangrijk dat de GPS functionaliteit van de telefoon is ingeschakeld.

• Wi-Fi verbinding met de server

Om verbinding te maken met de server moet de gebruiker het IP-adres van de machine waarop de server applicatie draait handmatig invoeren. Dit is gedaan om het makkelijker te maken om het systeem te testen in verschillende netwerken waar het IP-adres elke keer anders is. Het benodigde IP-adres is het interne IP-adres omdat we er vanuit gaan dat de telefoon en de server zich in hetzelfde netwerk bevinden. Om de locatiegegevens naar de server te sturen moet de gebruiker op 'Order package' drukken. De app maakt dan een AsyncTask, een asynchrone taak, aan zodat de normale gang van zaken in de app niet verstoord wordt terwijl er data naar de server wordt verstuurd. In deze taak wordt een socket geopend met het IP-adres van de server en de poort 50505. Nadat de socket geopend is kan de data naar de socket worden geschreven in een zogenaamde stream, dit heeft als voordeel dat er data geschreven kan blijven worden zolang de socket geopend is. Het protocol dat gebruikt wordt is TCP/IP omdat UDP niet met stream data kan omgaan. De app schrijft in de geopende socket de latitude en longitude van de laatst bekende GPS locatie. Als alle data is verzonden wordt de socket weer gesloten.

• NFC-authenticatie

In eerste instantie was het idee om een random gegenereerde authenticatie code via Wi-Fi naar de Arduino te sturen, echter waren er problemen met het Wi-Fi shield (zie hierboven) waardoor we hiervan zijn afgestapt. In de huidige situatie is er een string ("Dr0ne") 'hardcoded' in de Arduino geprogrammeerd, de Arduino checkt elke gescande NFC tag met deze string en als ze overeenkomen gaat het kluisje open. De NFC functie staat altijd aan in de app, dat wil zeggen dat de app wacht tot er een NFC tag gescand wordt. Wanneer er een tag in de buurt van de telefoon is (3 tot 4 cm) krijgt de gebruiker een bericht op het scherm om opnieuw op het scherm te drukken om gegevens te verzenden, dit is standaard gedrag van Android en heeft verder niks met de app te maken. Als de gebruiker vervolgens op het scherm drukt gaat er een callback naar de app. De app zet dan een zogenaamd NdefMessage in elkaar, dit is een bericht dat volgens een afgesproken standaard wordt opgebouwd, hierdoor kunnen alle apparaten die zich ook aan deze standaard houden het bericht lezen. In het bericht staat enkel de string "Dr0ne" welke de Arduino zal vergelijken met de ingeprogrammeerde code om dan tot de conclusie te komen dat ze hetzelfde zijn en het kluisje zal open gaan.

Android App en Source code

Server

De server applicatie is geschreven in Java. Als de server wordt opgestart opent deze een socket met poortnummer 50505 en accepteert nieuwe connecties via deze socket. Als er een nieuwe connectie is start de server een thread waarin de data die door de socket komt gelezen wordt. De latitude en longitude die verstuurd zijn door de app worden gelezen en opgeslagen. Vervolgens maakt de server waypoints van deze data. Als de connectie gesloten wordt schrijft de server de waypoints naar een file genaamd "generated_wp.txt". Dit tekst bestand kan daarna ingelezen worden met het programma QGroundcontrol.

Server executable en Source code