Bouwverslag: zelfbouw flight controler op basis van Arduino Uno

Ja, dat is een 4th order low pass filter voor de accelero. En volgens mij wordt dat nog een paar keer over gesampled.

for (int axis = XAXIS; axis <= ZAXIS; axis++) {
filteredAccel[axis] = computeFourthOrder(meterPerSecSec[axis], &fourthOrder[axis]);
}

FourtOrderFilter.h - aeroquad - An Arduino based four rotor R/C helicopter or quadrocopter. - Google Project Hosting

Mijn laatste grafiek was gebaseerd op die filterAccel data.

 

Balen dat het weer een beperkende factor is in het testen. Ik ben nu stap voor stap het programma aan het doorlopen om te kijken of ik zaken kan versnellen. In ieder geval zijn float berekeningen killing voor de snelheid ;-)

 

Het weer zit niet echt mee. Daar komt hopelijk snel een eind aan. Ik ben het hoveren in de huiskamer ook wel zat.

Floats voor de berekening vervangen voor long's en alles x1000 en na de berekening weer delen door 1000? Ik weet niet of je daar wat winst mee behaald en je zit ook met afrondingsfouten. Ik weet wel dat je functie's als pow() moet vermijden. Die vreten enorm veel programma geheugen omdat de processor zelf die functie eigelijk niet bevat.

Het moet lukken om er een flight controller van de bouwen, maar ik denk dat voor deze toepassing de Arduino Uno op z'n teentjes loopt en er niet heel veel meer uit te persen is. De aeroquad software kan ook een octo-copter aan, maar niet met een Uno. Dan is een quad de limit.

De Arduino Due heeft een veel hogere clock en een int is van zichzelf al 32 bits. Misschien een volgend projectje?

 

Een Due met een kloksnelheid van 84MHz in plaats van de Uno met 16MHz zou inderdaad een zegen zijn. Maar zoals je al aangeeft moet het mogelijk zijn om een controller te bouwen met een Uno. Dit gaan we dan ook zeker doen

Of de Uno aan zijn grens zit weet ik niet. Het communiceren via I2C kost ook vrij veel tijd. Zelfs op 400kHz heb je toch ongeveer 200us nodig om gegevens binnen te hengelen van bijvoorbeeld de gyro. In die 200us kan je niets anders dan wachten. ISP @ 10MHz voor communicatie is ook een idee

Ik ga rustig verder puzzelen en kijken hoe ver ik kan komen. Ik zit in ieder geval nog op 250Hz. Vanavond heb ik weer wat looptijd gewonnen door het anders uitvoeren van berekeningen. Ook heeft het geen zin om je ontvanger signalen om de 4ms te bewerken als deze eens in de 16ms door de ontvanger ververst worden.... weer een paar us ;-)

 

Mooi project hoor. Ik lees het met veel interesse. Netjes hoe je het aanpakt en niet voor de makkelijke weg kiest

 

Bedankt Martin!

Vandaag met een redelijke wind even buiten gevlogen. Ondanks de turbulentie werkte de auto level erg goed. Nog niet optimaal en er zit dus nog werk in. Maar voorlopig ben ik erg tevreden.

Na enkele testen en het optimaliseren van de pid hoogteregelaar behaalde ik niet het gewenste resultaat. De quad bleef mooi op hoogte maar na een lange val zakte de quad te ver onder zijn gewenste hoogte. Een passende oplossing heb ik gevonden in een virtuele parachute. Door de laatste 6 metingen bij te houden kan een beter beeld verkregen worden van de richting en de snelheid van de verplaatsing.

Door het gemiddelde te nemen van de laatste registraties kan een soort parachute aan een lange draad gemaakt worden. Dit werkt beter dan de d-functie van de pid regelaar en geeft een mooi remmende functie.




De “parachute” werkt geheel los van de pid regelaar en beïnvloed de vliegkarakteristieken van de quad. Door de nieuwe vliegkarakteristieken functioneert de pid regelaar beter. Als het weer wat rustiger wordt kan ik de boel verder inregelen en volgt er weer een filmpje.

Misschien binnenkort toch maar een gps bestellen?????

 

Je maakt echt reuzestappen! Goed bedacht, je parachute.
De wind gaat gelukkig ook wat liggen komende week.

Nog even over het verwerken van alle signalen:
Het was mij gelukt om met de Uno een Spektrum satalliet ontvanger serieel uit te lezen. Dat scheelt een boel kabeltjes (en een hoofdontvanger) en je kan in 1 keer 7 kanalen uitlezen. Maar dat gaat op 115200 baud, en ook al zijn het maar 16 bytes, daar moet je toch ook weer op wachten. Ander nadeel is dat de Uno maar 1 seriele poort heeft die ook gebruikt wordt tijdens het uploaden van een nieuwe sketch. Maar verder werkt dat echt heel erg goed met een superstrak signaal.

Ik heb een GPS module, maar de aeroquad software is een beetje lomp. Met compiler switches kun je modules aan en uit zetten. Maar er is helaas geen programma geheugen meer vrij om de GPS aan te zetten voor mijn Uno. Ik zit er toch hard over te denken om over te stappen op de MultiWii software. Dat verbruikt een stuk minder geheugen zodat ik ook de GPS kan gebruiken.

 

Slaap jij nog wel Andre.... 00:54 ;-)

Wel leuk om te lezen dat ieder voordeel weer een nadeel heeft bij de Uno. Het serieel inlezen van ontvangersignalen is inderdaad een mooie optie. Maar je heb direct geen schrijf / leesmogelijkheid meer. En voor het debuggen gebruik ik heel vaak de seriële verbinding naar de computer om te controleren wat bepaalde waarden doen.

Zelf vlieg ik met Futaba en die heeft Sbus. Ongeveer hetzelfde als een Spectrum satalliet alleen dan op 100000 baud. Ik heb geprobeerd om dit signaal in te lezen via een interrupt. Maar dat lukte niet door de korte bitlengte van 2us. Vandaar dat ik toch voor de 1000 t/m 2000us signalen heb gekozen in combinatie met een interrupt.

Wat ik wel een mooie optie vind is RASST van Futaba. Dit is een seriele uitgang waarbij alle ontvangersignalen achter elkaar worden gezet. Een soort van seriele communicatie maar dan op basis van pulse lengte. Iets wat ik nu ook gebruik voor de eerste 5 kanalen. Met 1 interrupt kan je met een RASST ontvanger alle kanalen probleemloos inlezen.

Wat ik ook geprobeerd heb is de pulsen voor de esc’s uit te sturen met de Timer1 interrupt. Dit werkt prachtig en je hoeft met het uitsturen van de pulsen ook geen rekening meer te houden. Dit gebeurde volledig automatisch. Alleen was het grote nadeel dat de hardware interrupt die ik gebruik voor het inlezen van de ontvanger signalen verstoord werd. Mooie optie maar helaas niet bruikbaar.

Op dit moment zit ik op een programmageheugen van 22332 bytes. Met 32256 bytes aan totaal heb ik dus nog ruimte genoeg. Ook met het aantal gedeclareerde variabelen blijf ik mooi binnen de grens. Voor mij is tijd nu nog echt de grote boosdoener.

Ik ben inmiddels begonnen om het kompas te implementeren in het programma. Deze heb ik bij het gebruik van een gps zeker nodig. En heb ik ook geen last meer van het driften van de yaw gyro

 

Prachtig, ik volg het met aandacht

Waar heb je het frame, motors en props gekocht als ik mag vragen ?

 

Motoren en props had ik nog liggen. Heb alleen het frame besteld:
DJI Flame Wheel F330 complete frame DJII000367 rcdrones.nl
Eventueel met motoren:
DJI Flame Wheel F330 ARF Includes Motors, ESC, Props rcdrones.nl

 

Mooi verslag,, mooi he quadcopters.
Zelf heb ik een HK setje van de F330 met KK2.1 boardje, gaat als de brandweer.
4x Turnigy motoren en Afro ESC's
Het HK frame is aanzienlijk goedkoper.
Koop meteen 2 frames,, 1 voor reserve
F330 Glass Fiber Mini Quadcopter Frame 330mm
Helaas ff uitverkocht.

 

Vandaag even kort kunnen testen met rustig weer.
Hoogteregeling werkt netjes en blijft keurig op dezelfde. Kompas werkt ook en de yaw hoef ik niet meer aan te raken

Helaas kon ik maar kort testen en was er geen gelegenheid om een film te maken. Die volgt hopelijk zeer binnenkort.

 

Ja, ik slaap ook nog wel eens Maar soms lukt dat wat minder, vooral op zondag avond. Dan wil ik nog wel eens achter de PC kruipen...

Je doet het netjes hoor, nog ruim binnen de geheugengrens en al hele mooie resultaten. Petje af.

Ik heb het probleem gevonden van mijn altitude-hold. Ik heb zelf in de Aeroquad code zitten harken om het geheugenprobleem op te lossen zodat ik gebruik kon maken van de hoogte sensor. Ik had alleen 1 ding over het hoofd gezien: De default instellingen worden niet geladen bij het opstarten van de arduino want die zitten simpelweg nog niet in de EEPROM opgeslagen. Dus dat de altitude af en toe lijkt te werken is een wonder.

Maar nu je toch zo lekker bezig bent met het verwerken van de sensoren heb ik wel een vraag voor je: De aeroquad software heeft 2 standen. 1 = attitude, waarbij de quad zichzelf stabiliseert (voor beginners zoals ik) en 2 = rate (voor gevorderen, loopings mogelijk), waarbij de accel niet wordt gebruikt. Zou er nou niet een soort middenweg te maken zijn waarbij de attitude mode af neemt naarmate de sticks verder off-center worden gehouden?

 

In de nieuwste software update 1.6 van het KK2.1 boardje zit nu de mogelijkheid om ,,self leveling'' uit te schakelen naarmate je meer stick input geeft.
Misschien iets voor jullie om te bestuderen ?
Zelf vlieg ik (nog) alleen in SL, omdat het dan al wild genoeg kan

 

Wat ik zelf (voorlopig) heb gedaan in auto level mode is het volgende:
Vanaf je ontvanger krijg je 1000 - 2000us signaal en is 1500us de middenpositie. In auto level vermenigvuldig ik gewoon de hoek van de quad (gyro / acc combi) met en bepaalde waarde. Met dit signaal stuur ik het ontvanger signaal tegen met maximaal 300us. Op die manier blijft er altijd 200us over om zelf altijd de overhand te nemen. En in midstick kan de auto level zijn werk doen. Dit geeft wel een heel vreemd stuurgedrag 8O Maar voor het testen laat ik het even zo.

Als ik wat meer vertrouwen heb gekregen in mijn programma krijgt de auto level meer "ruimte" om te corrigeren en kan ik de maximale hoek van de quad instellen. En dat vertrouwen groeit met de dag omdat ik nog steeds met dezelfde propellers aan het testen ben

 

@Chris: draait dat boardje ook niet met MultiWii?

@Joop: De invloed van auto-level is dus inderdaad instelbaar als ik het goed begrijp.

 

In mijn ogen kan je alles instellen / programmeren zoals je het wilt. Als je maar weet wat je wilt ;-) De term "meer / minder autolevel" kan je in mijn ogen op vele manieren opvatten.

 

Vandaag eindelijk even tijd gehad om een film te schieten van de laatste vorderingen. In de film vliegt de quad met auto level, kompas lock en hoogteregeling. De hoogteregeling werkt goed genoeg om hem ook in de woonkamer te vliegen.

 

Vandaag zijn de nieuwe onderdelen binnen gekomen. Het zal wel even duren voordat ik dit werkend heb ;-)

 

Die GPS module heb ik ook. Ik heb er tot nu toe alleen wat mee zitten testen. Ik had daarvoor de library "TinyGPS" gebruikt. Wat mij op viel was dat de standaard baudrate van 115200 te snel is om door TinyGPS te verwerken. Na het verlagen van de baudrate naar 38400 werkt dit ding prima, doet het zelfs binnen (voor het raam).

Ik had een document gevonden waarin staat hoe je de configuratie van de GPS module kunt aanpassen, zoek eens op "PMTK_A11.pdf". Om eventueel de baudrate te verlagen moet je een string sturen met een checksum. Niet heel spannend maar daar had ik een site voor gevonden die dat kan: NMEA MTK checksum calculator

Ik heb zelfs nog een stukje code om de checksum te bereken:

void ShowChecksum(char *cmd)
{
int checksum = 0;
for(int i = 0; i < strlen(cmd); i++)
checksum = checksum ^ cmd;

String hexsum = String(checksum, HEX);
if (hexsum.length() < 2) hexsum = '0' + hexsum;
hexsum.toUpperCase();
//Serial.print('Checksum for ' + cmd + ':'); Serial.print('\t');
Serial.println(hexsum);
}

Hopelijk kan je er iets mee.