Bouwverslag: zelfbouw flight controler op basis van Arduino Uno
- Topicstarter JoopB
- Startdatum
Geen van beide ;-) De servo library is gebaseerd op TIMER1 en werkt niet goed als je meerdere interrupt gerelateerde zaken wilt regelen. In ieder geval op een Arduino Uno. Mijn methode staat beschreven onderaan de eerste post van dit draadje.
Het schakelen van de uitgangen kost tijd. Voor een goed signaal is het belangrijk om daar rekening mee te houden.
Ofwel, ik selecteer ze op lengte (van kort naar lang) en stuur vervolgens de uitgangen allemaal hoog. Eerst de korte, daarna oplopend tot de langste. Vervolgens kijk ik naar de micros() timer en schakel ze stuk voor stuk weer uit. Omdat je dan de kortste als eerst weer uitschakelt heeft de schakeltijd geen invloed op de pulslengte.
Krijg je een beetje dit beeld:
Om te controleren of de signalen stabiel zijn kan je er een scope of digitale servo op aansluiten. Dan zie of hoor je direct of het signaal stabiel is.
Het schakelen van de uitgangen kost tijd. Voor een goed signaal is het belangrijk om daar rekening mee te houden.
Ofwel, ik selecteer ze op lengte (van kort naar lang) en stuur vervolgens de uitgangen allemaal hoog. Eerst de korte, daarna oplopend tot de langste. Vervolgens kijk ik naar de micros() timer en schakel ze stuk voor stuk weer uit. Omdat je dan de kortste als eerst weer uitschakelt heeft de schakeltijd geen invloed op de pulslengte.
Krijg je een beetje dit beeld:
Om te controleren of de signalen stabiel zijn kan je er een scope of digitale servo op aansluiten. Dan zie of hoor je direct of het signaal stabiel is.
Laatst bewerkt door een moderator:
Geen van beide ;-) De servo library is gebaseerd op TIMER1 en werkt niet goed als je meerdere interrupt gerelateerde zaken wilt regelen. In ieder geval op een Arduino Uno. Mijn methode staat beschreven onderaan de eerste post van dit draadje.
Het schakelen van de uitgangen kost tijd. Voor een goed signaal is het belangrijk om daar rekening mee te houden.
Ofwel, ik selecteer ze op lengte (van kort naar lang) en stuur vervolgens de uitgangen allemaal hoog. Eerst de korte, daarna oplopend tot de langste. Vervolgens kijk ik naar de micros() timer en schakel ze stuk voor stuk weer uit. Omdat je dan de kortste als eerst weer uitschakelt heeft de schakeltijd geen invloed op de pulslengte.
Krijg je een beetje dit beeld:
Om te controleren of de signalen stabiel zijn kan je er een scope of digitale servo op aansluiten. Dan zie of hoor je direct of het signaal stabiel is.
Ahja jij doet het via een CD4075, ik stuur ze direct omdat ik ruim de timing heb om het te doen.
Maar jij stuurt dus ook direct aan, eens ff naar kijken
Laatst bewerkt door een moderator:
Vandaag de nieuwe algoritme kunnen testen voor de altitude hold functie. Werkt best aardig dacht ik zo
Dit is een indrukwekkende prestatie!!!
Laatst bewerkt door een moderator:
Bedankt voor je reactie! Altijd leuk om te lezen
Het is alweer een poos geleden sinds mijn laatste update. Door werk en privé heb ik wat minder tijd kunnen besteden aan dit project. Maar ondanks dat hebben we weer niet stil gezeten. Na het mooie succes van de hoogteregeling ben ik mij nu gaan richten op de gps. En ook daar komen we weer voldoende uitdagingen tegen ;-)
De gps die ik gebruik geeft via en seriële verbinding vijf keer per seconden zijn informatie door volgens het NMEA protocol. Dit betekend dus iedere 200ms een nieuwe positiebepaling. Dat ziet er bijvoorbeeld uit als:
$GPGGA,053740.000,2503.6319,N,12136.0099,E,1,08,1.1,63.8,M,15.2,M,,0000*64
$GPGLL,2503.6319,N,12136.0099,E,053740.000,A,A*52
$GPGSA,A,3,24,07,17,11,28,08,20,04,,,,,2.0,1.1,1.7*35
Deze informatie bevat onder andere:
Latitude = 2503.6319(N)
Longitude = 12136.0099(E)
Aantal gebruikte satellieten = 8
De snelheid van de seriële verbinding is 57600bps. Omdat ik de hardware seriële verbinding vrij wil houden heb ik geprobeerd om de gegevens in te lezen met de SoftwareSerial library. Dit echter zonder succes omdat 57600bps net te snel was voor deze library. Uiteindelijk ben ik uitgekomen op de AltSerial library die wel 57600bps aankon. Dat probleem is dus opgelost.
Nu bestaat er ook een library voor de Arduino genaamd TinyGPS. Dit stukje software filtert de NMEA code en produceert vervolgens de noodzakelijke informatie. Werkt prima en redelijk stabiel. Ondanks dat zaten er enkele punten in waardoor ik toch besloten heb om mijn eigen software te schrijven om de NMEA code te ontcijferen.
Dit is inmiddels grotendeels gereed en heb ik de eerste testen gedaan. Ondanks de korte interval van 200ms per positiebepaling geeft de gps toch een zeer stabiele positie zonder ruis. Wel een bijzondere ervaring om om de 20cm een nauwkeurige en stabiele waarde te krijgen
Als de wind een beetje meewerkt hoop ik deze week de eerste testen te kunnen doen. Voorlopig eerst met alleen een PD-regelaar. Daarna kan ik het uitbreiden met alles wat noodzakelijk is. Dus hopelijk volgt er binnenkort weer een film van de eerste resultaten
Als het goed is komt deze week ook de 434MHz zender / ontvanger binnen voor de telemetrie. Als de specificaties kloppen is het mogelijk om op 1200bps een afstand van 1000 meter te overbruggen. Dat zou voorlopig voldoende moeten zijn.
De gps die ik gebruik geeft via en seriële verbinding vijf keer per seconden zijn informatie door volgens het NMEA protocol. Dit betekend dus iedere 200ms een nieuwe positiebepaling. Dat ziet er bijvoorbeeld uit als:
$GPGGA,053740.000,2503.6319,N,12136.0099,E,1,08,1.1,63.8,M,15.2,M,,0000*64
$GPGLL,2503.6319,N,12136.0099,E,053740.000,A,A*52
$GPGSA,A,3,24,07,17,11,28,08,20,04,,,,,2.0,1.1,1.7*35
Deze informatie bevat onder andere:
Latitude = 2503.6319(N)
Longitude = 12136.0099(E)
Aantal gebruikte satellieten = 8
De snelheid van de seriële verbinding is 57600bps. Omdat ik de hardware seriële verbinding vrij wil houden heb ik geprobeerd om de gegevens in te lezen met de SoftwareSerial library. Dit echter zonder succes omdat 57600bps net te snel was voor deze library. Uiteindelijk ben ik uitgekomen op de AltSerial library die wel 57600bps aankon. Dat probleem is dus opgelost.
Nu bestaat er ook een library voor de Arduino genaamd TinyGPS. Dit stukje software filtert de NMEA code en produceert vervolgens de noodzakelijke informatie. Werkt prima en redelijk stabiel. Ondanks dat zaten er enkele punten in waardoor ik toch besloten heb om mijn eigen software te schrijven om de NMEA code te ontcijferen.
Dit is inmiddels grotendeels gereed en heb ik de eerste testen gedaan. Ondanks de korte interval van 200ms per positiebepaling geeft de gps toch een zeer stabiele positie zonder ruis. Wel een bijzondere ervaring om om de 20cm een nauwkeurige en stabiele waarde te krijgen
Als de wind een beetje meewerkt hoop ik deze week de eerste testen te kunnen doen. Voorlopig eerst met alleen een PD-regelaar. Daarna kan ik het uitbreiden met alles wat noodzakelijk is. Dus hopelijk volgt er binnenkort weer een film van de eerste resultaten
Als het goed is komt deze week ook de 434MHz zender / ontvanger binnen voor de telemetrie. Als de specificaties kloppen is het mogelijk om op 1200bps een afstand van 1000 meter te overbruggen. Dat zou voorlopig voldoende moeten zijn.
Laatst bewerkt door een moderator:
Ik dacht dat je een bluetooth module ging gebruiken?
Deze module is het:
APC220 Radio Communication Module
Ja bluetooth is puur voor settings, ik wil de RF gebruiken voor live data feed.
Lekker bezig Joop!
Ik wel eens met Delphi van die NMEA strings uit elkaar gepeuterd. Toen nog met m'n GPS bluetooth module van m'n Tomtom. Dat werkte prima. Je hebt niet alle strings nodig, al komen ze wel voorbij.
Als ik het goed heb kan ik bij mijn GPS module grofweg opgeven welke type strings er gestuurd gaan worden. Dat scheelt weer een prak aan info wat je niet hoeft te verwerken.
Succes maar weer. Ik ben benieuwd naar je volgende video, de laatste was indrukwekkend.
Ik wel eens met Delphi van die NMEA strings uit elkaar gepeuterd. Toen nog met m'n GPS bluetooth module van m'n Tomtom. Dat werkte prima. Je hebt niet alle strings nodig, al komen ze wel voorbij.
Als ik het goed heb kan ik bij mijn GPS module grofweg opgeven welke type strings er gestuurd gaan worden. Dat scheelt weer een prak aan info wat je niet hoeft te verwerken.
Succes maar weer. Ik ben benieuwd naar je volgende video, de laatste was indrukwekkend.
Je kan de niet nodige strings uitschakelen, op die manier kan je ook sneller de waarden inlezen en hoef je niet onnodige info te parsen.
Persoonlijk denk ik dat alles afhangt van je setup of je zaken aan moet passen in de configuratie van de gps. 
De gps die ik gebruik communiceert "out of the box" op 57600bps. Zet ik dit uit tegen 10 bits per byte kom ik uit op 5760 bytes per seconden. Een NMEA string volgens het NMEA protocol is maximaal 82 byte lang. Lang niet alle regels zijn dit.... maar toch. Dan kom ik uit op 70 regels per seconden. 8O
Daarnaast is de gps zo "slim" om niet alle NMEA record in gelijke mate door te sturen. De $GPGLL (lon / lat positie) komt bijvoorbeeld vaker langs dan $GPGSV (satellieten in beeld).
Het filteren van de data neemt in verhouding tot de seriële communicatie nauwelijks tijd in beslag. De ongewenste NMEA records worden gewoon genegeerd en verdwijnen in /dev/null
Het uitschakelen van specifieke NMEA records levert naar mijn mening dus geen snelheidswinst op.
De gps die ik gebruik communiceert "out of the box" op 57600bps. Zet ik dit uit tegen 10 bits per byte kom ik uit op 5760 bytes per seconden. Een NMEA string volgens het NMEA protocol is maximaal 82 byte lang. Lang niet alle regels zijn dit.... maar toch. Dan kom ik uit op 70 regels per seconden. 8O
Daarnaast is de gps zo "slim" om niet alle NMEA record in gelijke mate door te sturen. De $GPGLL (lon / lat positie) komt bijvoorbeeld vaker langs dan $GPGSV (satellieten in beeld).
Het filteren van de data neemt in verhouding tot de seriële communicatie nauwelijks tijd in beslag. De ongewenste NMEA records worden gewoon genegeerd en verdwijnen in /dev/null
Het uitschakelen van specifieke NMEA records levert naar mijn mening dus geen snelheidswinst op.
Persoonlijk denk ik dat alles afhangt van je setup of je zaken aan moet passen in de configuratie van de gps.
De gps die ik gebruik communiceert "out of the box" op 57600bps. Zet ik dit uit tegen 10 bits per byte kom ik uit op 5760 bytes per seconden. Een NMEA string volgens het NMEA protocol is maximaal 82 byte lang. Lang niet alle regels zijn dit.... maar toch. Dan kom ik uit op 70 regels per seconden. 8O
Daarnaast is de gps zo "slim" om niet alle NMEA record in gelijke mate door te sturen. De $GPGLL (lon / lat positie) komt bijvoorbeeld vaker langs dan $GPGSV (satellieten in beeld).
Het filteren van de data neemt in verhouding tot de seriële communicatie nauwelijks tijd in beslag. De ongewenste NMEA records worden gewoon genegeerd en verdwijnen in /dev/null
Het uitschakelen van specifieke NMEA records levert naar mijn mening dus geen snelheidswinst op.
Ik doelde voornamelijk ook op het verwerken binnen de GPS, hoe minder signalen hij moet voorbereiden hoe sneller hij is.
Dit doe ik bijvoorbeeld ook voor mijn NTP Stratum-1 Server.
Hierbij is het belangrijk dat ie op enkele nanoseconden accuraat is, en dus puur tijd geeft en meer niet, in ons geval van een quad willen we iets meer, ivm coordinaten en hoogte om dit weer te gebruiken.
Maar stelregel is wel dat je zo min mogelijk info moet krijgen van je GPS zodat de GPS alleen de informatie verwerkt die je ook echt nodig hebt, scheelt ook weer iets in de accuraatheid en stabiliteit
Tja, die stelling lijkt mij niet echt logisch. Een gps-ontvanger bestaat grofweg uit twee delen. Het eerste (ontvanger)deel voor het ontvangen en produceren van de tijdgerelateerde zaken. Gezien de noodzaak van nauwkeurigheid kan je als gebruiker deze tijd niet verstoren. Dit deel zorgt voor de maximaal haalbare nauwkeurigheid van de gps ontvanger.Maar stelregel is wel dat je zo min mogelijk info moet krijgen van je GPS zodat de GPS alleen de informatie verwerkt die je ook echt nodig hebt, scheelt ook weer iets in de accuraatheid en stabiliteit
Het tweede deel van de gps-ontvanger voert de berekeningen uit voor positie, snelheid, enz. Deze berekeningen worden gemaakt op basis van de gegevens uit het eerste deel. Het enige wat je hier kan doen is meer of minder informatie opvragen. Maar de basisgegevens uit het eerste deel veranderen hierdoor niet.
Alleen gps-ontvangers die door de fabrikant zijn overgewaardeerd kunnen problemen geven als je deze maximaal gaat “belasten”. Dan raakt het rekendeel wel in de problemen omdat de gevraagde stroom van data niet op tijd af is. Door de noodzakelijke rekentijd werk je met oude signalen uit het eerste ontvangerdeel.
Krijg je problemen met de nauwkeurigheid die beter wordt naarmate je de minder data vraagt, heb je te maken met een gps-ontvanger die niet kan wat de leverancier stelt. Dit heb ik in post 74 ook al aangehaald. Veel gps-ontvangers zijn gewoon overgewaardeerd.
En natuurlijk is een seriële verbinding van 9600bps in combinatie met 10Hz ook geen reële combinatie. Je haalt het gewoon niet om alle NMEA-data 10 keer per seconden binnen te halen op 9600bps. En toch zie je het bij veel goedkope gps ontvangers gewoon staan.
Vroeger was het iig zo, maar dat zal wel komen door de baudrate zoals je zegt, tegenwoordig heb je met 115200bps genoeg ruimte, en de chips in de GPS ontvangers zijn ook aardig rap momenteel.
Vroegah jaar of wat geleden moest je wel de NMEA sentences uitzetten om accurate results te krijgen, maar toen waren de GPS modules ook nog niet 115200 capable, max was 9600bps toen, meeste zelfs 4800.
De huidige GPS receiver die ik voor de NTP server gebruik draait nog steeds op 9600 bps, met PPS signaal, en alleen de tijd sentence, meer gebruik ik er niet van, voor de quad moet ik nog gaan kijken, heb inmiddels in de datasheet gelezen dat ie prima ook op 115200 kan, dus dan hoef ik ook niets meer uit te zetten.