Logboek+Maarten+2de+semester

__Maandag 12 maart__
Het is al een tijdje geleden dat ik nog gepost heb op deze wiki pagina. Maar ik heb zeker niet stil gezeten. De afgelopen maand heb ik mij bezig gehouden met het aanpassen van de source code van de Urbi ardrone driver. De rede: De driver die we gebruikten voldeed niet langer aan onze wensen. Hoe zo? -> De driver bood geen ondersteuning voor het aanpassen van de loopgains (PID gains).Bovendien ondersteunde deze alleen een oude firmware versie van de ardrone. Waarom moeten de loopgains worden aangepast? -> De default waarden van sommige gains zijn niet optimaal ingesteld voor het vliegen boven gras. Bovendien zou het zeer handig zijn moesten we de gains kunnen bijregelen tijdens het vliegen.

Sinds 2 december 2011 heeft de maker van de ardrone urbi driver zijn source code online gezet, althans de embedded versie waarbij er geen video support aanwezig is. Dit was onze kans om de drivercode zelf te modificeren en de ontbrekende features toe te voegen. Helaas was, zoals al eerder vernoemd, de ondersteuning van de videostream niet aanwezig in de vrijgegeven source code. We hebben nog geprobeerd om de maker van de driver te contacteren, maar deze wilde niets van zich laten weten. Daarom heb ik een poging gedaan om zelf ook de video support te implementeren.

Na lang zoeken ben ik er vandaag eindelijk in geslaagd om een werkende videostream te implementeren. Ook heb ik nog een paar features toegevoegd zoals het op afstand veranderen van de camera view (voorste camera, onderste camera, beeld in beeld,...) en het toevoegen van het emergency commando (dit werkte voordien niet goed). Nu rest alleen nog de implementatie voor het instellen van de loopgains. Ik veronderstel dat dit niet al te veel werk zal zijn. De driver die ik nu gecompileerd heb is geschreven voor de ardrone firmware 1.5.1.

__Maandag 3 april__
Vandaag heb ik de balltracking demo aangepast zodat een beweging van het balletje in de x-richting de roll van de drone bedient ipv de yaw. Ik heb dit eerst geprobeerd met de bestaande p-regelaar van de yaw. De ARDrone schommelde heen en weer en ik kreeg hem niet stabiel (ondanks het verkleinen van Kp, de gain van de p-regelaar). Na wat opzoekwerk over PID regelaars, heb ik een PD regelaar geïmplementeerd in urbiscript. Daarnaast heb ik ook een regelmarge toegevoegd. Als de afwijking van het middelpunt kleiner is dan een bepaalde waarde, regel ik niet bij. Na wat geëxperimenteerd te hebben met de PD gains, behaalde ik toch een vrij mooi resultaat. De drone stabiliseert vrij mooi en de reactietijd is redelijk klein. De volgende dagen ga ik proberen om het systeem verder te optimaliseren op gebied van stabiliteit.

__Woensdag 11 april__
De afgelopen dagen ben tot de conclusie gekomen dat het uiteindelijke algoritme voor het tracken van de boomgaard (geschreven door dries), toch wel redelijk lang duurt naar processing time toe. We spreken hier over een 3-tal frames per seconde (zonder optimalisatie tot hiertoe). Om op basis van deze gegevens een stabiel regelcircuit te maken is niet eenvoudig. We sturen namelijk met snelheden de drone aan. Als de sensorwaarde niet snel genoeg geupdate wordt, schiet de drone voorbij zijn doel zonder af te remmen. We hebben dit getest door het balltracking algoritme kunstmatig te verlengen via een delay tot ongeveer 300ms process time. De regeling was niet veel meer waard.

De enige manier om dit probleem op te lossen was gebruik maken van positioneringsgegevens die we wel snel konden verkrijgen: de navdata. De ardrone stuurt tijdens de vlucht ook de gegevens door van zijn IMU tegen een relatief hoge frequentie (kan tot 200Hz). De gegevens die ons interesseren zijn de yaw (bepaalt door de yaw gyro) en Vy, de zijwaartse snelheid ingeschat door de drone a.h.v. accelerometers en het onboard visiesysteem. De yaw voor de regeling met de yaw snelheid, vx voor de regeling met de roll (we gaan beide regelmethoden eens uitproberen). Door een combinatie te maken met het visiesysteem en de navdata zouden we de voordelen van beide systemen kunnen combineren. De navdata zorgt voor snelle feedback gedurende korte periodes, en het visiesysteem geeft de richting aan en compenseert de drift van de navdata.

Een eerste idee was het ontwerpen van een positiecontroller op basis van de navdata, dan zouden we rechtstreeks posities van het visiesysteem kunnen doorgeven aan de positiecontroller. De positiecontroller neemt dan de positie aan (positie op de y-as of rotatie rond de z-as) met als terugkoppeling de navdata. Het grote probleem dat hier opdook was het bepalen van het setpoint van de positiecontroller a.h.v de output van het balltracking algoritme. Het probleem was: "wanneer moet nu juist het setpoint veranderd worden". De oplossing bleek helaas te omslachtig te zijn. De positiecontroller hebben we echt gemaakt, maar daar stopte dan ook het verhaal.

Het tweede idee was eigenlijk een verbetering op de eenvoudige regellus van de eerste versie van het balltracking algoritme (toen het algoritme nog 'snel' draaide). Het idee was een sensor te ontwikkelen die de relatieve positie (waarde tussen -1 en 1) teruggeeft aan de regellus (niks nieuws op zich). De output van de sensor zou echter berekend worden op basis van de navdata __en__ op basis van de output van het visiesysteem (een intelligente mix van beide gegevens). Om dit klaar te krijgen heb ik een aantal dagen nodig gehad omdat er onderranden nog aanpassingen moesten gebeuren aan de ardrone driver en het balltracking algoritme. Vandaag ben ik er in geslaagd om een eerste versie van het systeem werkende te krijgen dat werkt via de yaw. Het werkt ook echt goed. Met een framerate van 3 frames per seconde blijft hij de bal op een stabiele manier tracken. Ik ben zeer tevreden.

__Zaterdag 14 april__
Ondertussen heb ik ook een poging gedaan om via de roll hetzelfde te proberen. Dit was echter niet zo'n succes omdat ik hier een PID regelaar voor gebruik. Het probleem zit in de D component die erg gevoelig is voor plotselinge veranderingen. Het sensor systeem compenseert de plotselinge veranderingen in de output van het visiesysteem met de navdata, maar dit lukt niet altijd even mooi. De output is nog altijd vrij noisy. Daardoor zal de D regelcomponent erg agressief uit de hoek komen. De besturing kan dan extreem schokkerig worden. In de onderstaande grafieken zie je de output van de sensor in functie van de tijd (hier in samples weergegeven). De sample periode is 50ms. +1 = rechter uithoek van het camerabeeld -1 = linker uithoek van het camerabeeld fusion = output van de sensor = combinatie van visie en navdata vision = alleen de output van het visiesysteem Test met de yaw: Ik laat hierbij het balletje in de rechter ooghoek van de drone zien waarna deze zich bijstelt (de p-gain is vrij groot gekozen, vandaar de lange uitslingertijd).

En dan hetzelfde maar voor de roll beweging: Ik hou het balletje stil en geeft de drone een duwtje naar links (dit gebeurt ergens rond sample 130). Doordat ik de D-gain redelijk klein moest zetten om het schokken te voorkomen, blijft deze lang uitslingeren. Het is over het algemeen zeer moeilijk om dit goed te krijgen. Ik hoop in de nabije toekomst het systeem met de roll sterk te kunnen verbeteren. Hiervoor zal ik het algoritme van de sensor moeten aanpakken vrees ik.

__Maandag 16 april__
Vandaag heb ik eens geprobeerd om de output van het visiesysteem te interpoleren (lineair) ipv te werken met de combinatie visie - navdata. Hiervoor moet de interpolator telkens wachten totdat de volgende sample binnen is eer deze kan beginnen te interpoleren. De delay is dus iets groter. Bij het testen was de teleurstelling groot aangezien dit hetzelfde deed als het systeem zonder interpolatie. Ik kreeg de drone er niet stabiel mee.

Ik heb de urbi ardrone driver ook aangepast zodat ik nu de loopgains van de drone zelf in realtime kan aanpassen tijdens de vlucht. Dit is nodig voor de altitude control bij het vliegen over lang gras.

__Vrijdag 20 april__
Het is me gelukt om het regelsysteem met de roll goed te krijgen. Ik heb hiervoor de update frequentie van het visiesysteem verlaagt (tot 1 a 0,5 samples per seconde) en zuiver afgeregeld op de navdata. Als de drone stabiel is (na 1 a 2 seconden) geef ik een nieuwe visiecoordinaat aan het regelsysteem. Dit zorgt ervoor dat de regeling met de roll niet meer schokkerig verloopt (omwille van de sprongen is de visiedata). Ook heb ik een truuk gebruikt om de resterende schok die om de 1 a 2 seconden komt sterk te onderdrukken zonder de D-functionaliteit te beïnvloeden. De regeling verloopt zeer smooth en is in alle omstandigheden stabiel.

Om de beste positionering te verkrijgen gaan we waarschijnlijk gebruik maken van beide methodes: Regeling met de yaw en regeling met de roll. Yaw: Roll:
 * Voordeel: eens op het goede pad zal de drone altijd in de goede richting vliegen (uitgezonderd windstoten die hem opzij duwen).
 * Nadeel: Bij grote afwijkingen van het pad zal de drone slechts zeer langzaam terug naar het midden navigeren.
 * Voordeel: kan zich bij (grote) afwijkingen bijna onmiddellijk terug naar het midden positioneren.
 * Nadeel: Na verloop van tijd begint de yaw te driften en moet er een yaw correctie gebeuren wil de drone rechtdoor blijven vliegen.

Het volgende idee is om een regelaar te maken die het beste van beide methodes combineert. Hiervoor ga ik gebruik maken van de roll regelaar die af en toe wordt overgenomen door de yaw regelaar om een yaw correctie uit te voeren zodat de neus altijd in de goede richting blijft staan.