Monocopter experimenteel ontwerp

[Erikf]

Johannes, ik doe even een poging om mee te denken
Ik ben gewent dat in C++ "void main()" het hoofdprogramma is en ik begrijp dat "void loop()" dat voor de arduino is. Mocht ik het fout hebben hoor ik dat graag.

Stel je gaat je programma in 3 delen splitsen:
1) gegevens inlezen invoer()
2) formule, gegevens verwerken loop ()
3) uitvoer (aansturing servo) uitvoer()

deel 2 is de loop()
hierin berekent het programma de waarde die nodig is voor de uitvoer. het leest daarvoor de variabelen "magnetometer", "yaw", "rol", "nick" en "pitch" uit. met deze waarden berekend het de waarde voor de variabele "servo" voor de uitvoer.
Bij een interrupt spring het programma even naar de procedure: deel 1 of deel 2 verder blijft het programma alleen maar de berekening uitvoeren.

Deel 1 is de procedure die de 5 variabelen vult: de magnetometer, yaw, rol, nick en pitch: void invoer()
Bij de eerste interrupt legt het de begin waarde vast waarna het weer terugkeert naar loop()
bij de tweede interrupt legt het de eindwaarde vast en berekent het verschil vervolgens slaat het deze waarde op in 1 van de betreffende variabelen. Hierna springt het weer terug naar loop()

Deel 3 is de procedure voor aansturing van de servo: void uitvoer()
1 x in de 20 ms verwacht een servo een puls dus een timer interrupt zal 1 keer in de 20 ms een puls moeten starten. de variabele "Servo" zal een tweede timer interrupt moeten instellen waarbij de puls weer stopt. hierna kan het programma weer met loop() verder. Misschien kan zelfs het programma tussen de twee interrupts weer terug naar loop()

Het is even een hele andere benadering van het probleem maar ik denk dat je hiermee voorkomt dat de processor onnodig wacht op interrupts door weer terug te springen naar loop(). Het programma hoeft ook niet te wachten tot alle ingangen ingelezen zijn want die worden automatisch iedere 20 ms ververst en in de tussentijd kan het met de "oude" waarden verder.

Het is een heel verhaal geworden, hopelijk is het duidelijk wat m'n gedachtegang is. Wie weet heb je er wat aan.

[Erikf]

heb je ook al over het volgende nagedacht?:
Een servo krijgt normaalgesproken 1 keer in 20 ms een puls. Dat wil dus zeggen dat 20 ms lang de servo een bepaalde stand heeft (we verwaarlozen voor het gemak even de tijd die het nodig heeft een stand aan te nemen).

Hoeveel afstand legt de rotor af in 20 ms? Als de rotor te snel gaat en in 20 ms bijvoorbeeld een halve omwenteling maakt, heb je een uitdaging. Dat gaat lastig sturen worden.

Wat ik me afvraag is of de servo ook vaker dan 1 keer per 20 ms een update accepteert. En anders zou de rotorsnelheid laag moeten zijn.

maar dat staat even los van het programma zelf

[luppie]

Zeer interesante linkjes Ton! ik wist niet dat de minchrafters ook de zelfde taal gebruikten. Misschien dat ik bij hun ook wat info kan krijgen.

Ik denk dat jij misschien wel meer kaas van hebt gegeten als ik Erik. De ontvanger wil ik ook gaan lezen mbv interrupts. Ik begreep wel dat de truc is om de interrupt zo kort mogelijk te houden omdat je anders te veel mist in de loop.

Ik heb al een programma voor interrupts omgebouwd naar 4 ingangen. Maar ik heb nog moeite om deze code te ontleden zodat ik niet 4 uitgangen aan stuur maar één. Ik moet nog uitzoeken hoe de variabele heet waarin de waarde van de ingang staat van de ontvanger. Dus eigenlijk de variabele waarmee de uitgang word aangestuurd.

Bij het testen van de code werkte het ook niet goed. De servo heeft veel last van jitteren en dat word erger of minder erg wanneer je een andere stick beweegt. Dus bijvoorbeeld de servo word aangestuurd door kanaal 1 maar wanneer ik een ander kanaal verander heeft dat invloed op het gestuiter van de servo. Je ziet in de code dat ze bitflags gebruiken om in een loop aan te geven dat er nieuwe informatie beschikbaar is om mee te rekenen.

De orginele code achter deze link

heb je ook al over het volgende nagedacht?:
Een servo krijgt normaalgesproken 1 keer in 20 ms een puls.

Nee dat wist ik niet. Wat ik heb gelezen is dat de tijd dat de puls hoog is belangrijk is en hoe lang de puls laag is niet interessant is (voor mij) omdat dit vaak afhankelijk is ook van hoeveel kanalen er zijn gebruikt op de ontvanger. Maar wanneer een servo misschien wel raar gaat doen wanneer de puls te lang weg blijft/te snel terug komt zou de jitter kunnen verklaren. Deze loop duurt ongeveer 50ms.

Ik ga er van uit dat mijn maximale draaisnelheid 10 rondjes per seconde is (gebaseerd op gevoel en dit filmpje) en ik hoop rond de 5 RPS te komen. Dus max 100 ms per omwenteling. De snelste servo die ik kon vinden is bij 5V 0.07sec.60º dus op en neer 60º is meer dan 140ms. dus de bottleneck qua snelheid zal daar liggen en niet bij de puls verversing.

Lees mijn draadje op het arduino forum maar daar heb ik wat meer info over de servo staan die ze hebben gebruikt in een ander monocopterproject. Lees je direct dat ze daar niet echt weten waar het over gaat want ik krijg weinig concrete antwoorden....

[ton]

Ik heb daar zeker niet meer kaas van gegeten dan wie dan ook,dat vooropgesteld.
Maar ik heb wel besturingstechniek,meet en regel en plc techniek gehad.
Daarom vond ik dit al een leuk expiriment.Wij hebben ook net weer een opfris cursus robotica gehad ivm aanschaf van 2 fanuc robots ( en nog wat ander leuk speelgoed) maar dat is een totaal andere benadering van een probleem.
Hier wordt idd veel met interrups en bitflags gewerkt.
Dat arduino forum heb ik eens bekeken maar zo "opensourced" lijken ze niet te zijn.
Mischien eens meer de robotica fora af gaan struinen en verdiepen in karnaugh diagrammen.
Kan ik wel een keer wat blz. regelen in Jip en Janneke taal als je wilt.Dit moest vroeger in plc taal ivm geheugenvermogen en cyclustijd.Je hebt nl veeeeeel te veel variabelen die timingsproblemen op gaan leveren.
Nogmaals sorry dat ik je niet echt kan helpen
Maar laat je door al die beren op de weg niet van je doelstelling brengen!

[Erikf]

Ik heb even het draadje op het Arduinoforum bekeken en inderdaad jij blijkt een erg uniek project te hebben

Ik ga er van uit dat mijn maximale draaisnelheid 10 rondjes per seconde is (gebaseerd op gevoel en dit filmpje) en ik hoop rond de 5 RPS te komen. Dus max 100 ms per omwenteling. De snelste servo die ik kon vinden is bij 5V 0.07sec.60º dus op en neer 60º is meer dan 140ms. dus de bottleneck qua snelheid zal daar liggen en niet bij de puls verversing.

Als het van -60º naar +60º 140 ms is dan is het 140 ms / 120º ongeveer 1º per ms sec. Volgens mij valt dat juist weer mee. Je hoeft toch niet 60º uitslag te hebben? Volgens mij is dat wel werkbaar.

De formule is volgens mij ook niet zo moeilijk als je bepaalde stappen neemt
1) bepaal je referentie (virtuele voorkant van de monocopter) "richting". Om dit te bepalen zou je met een timer moeten werken en de magnetometer en aan de hand van deze waarden de richting bepalen. Formule hiervoor heb ik even niet voorhanden.
2) richting: referentie + of - Yaw. "richting = richting + yaw" waarbij de yaw positief of negatief kan zijn.
3) rol: Als we de richting als referentie nemen heb je de tijd nodig waar de puls moet beginnen om de servo op het juiste moment op z'n plek te krijgen. dus voor de timer "trigger rol = richting + offset" voor de uitslag: "servo = pitch + rol"
4) nick: Hetzelfde als voor de rol met dat verschil dat de trigger wat later is. Wel moeten deze twee uitkomsten in 1 servo uitgang komen, maar ik denk dat dit voor latere zorg is en zie dit ook niet als een groot probleem.

Dus........... de referentie richting is bepalend voor alles.
Programmeer technisch zou dit dan als eerste moeten werken. Als je dan ook nog een LED laag branden op het moment dat deze bij de virtuele voorkant is zie je zelf ook wat voor en achter is
Als ik jouw was (ben ik niet ) zou ik me eerst op het richting bepalen storten samen met de LED om te zien wat voor en achter is. Daarna kun je met stap twee bezig om de richting te beïnvloeden met de Yaw.

[ph-svv]

Ik zit met telkens groter wordende verbazing dit draadje mee te lezen hoor, knap werk!

[luppie]

Dus........... de referentie richting is bepalend voor alles. Programmeer technisch zou dit dan als eerste moeten werken. Als je dan ook nog een LED laag branden op het moment dat deze bij de virtuele voorkant is zie je zelf ook wat voor en achter is

Lijkt mij ook. Dit is voor mij ook nog wel te bevatten omdat het relatief eenvoudig lijkt. Is

[luppie]

Het belangrijkste onderdeel van dit project is toch de monocopter zelf en omdat de 2e niet vloog ben ik begonnen met monocopter nr. 3.

Deze is weer compleet anders en na voorbeeld van de monocopter van Lockheed Martin.



Dus de motor komt in de vleugel als trekprop en de besturing in een tupperware bakje. Dit keer helemaal geen stabilisatie stangen dus ik vraag me sterk af of dat wel werkt. Hij is ook een stuk groter omdat de vorrige helemaal niet los kwam en in mijn ogen power over had. Resonantie in de prop moet nu minder worden door een drie blads prop dus ik hoop op hogere toerentallen zonder dat de boel extreem trilt. Ook de servo zit in de vleugel en bedrading voor ledverlichting.



Hier nr.2 er bovenop als vergelijking voor de afmetingen:



hier het tupperware bakje met de elektronica. Ik kan hem zo makkelijk afkoppelen en op een testbankje laten draaien op de werkbank. Het kompas en de accelerometer zitten op een schuin stukje zodat ze in stabiele vlucht ongeveer horizontaal liggen.




hier een voorbeeld hoe hij ongeveer aan de vleugel komt. De pinnetjes van de arduino steken er uit zodat ik snel kan programmeren. Ook krijg ik nog een bluetooth seriële verbinding zodat ik draadloos gegevens uit kan lezen tijdens het draaien van de rondjes.


Ik hoop een beetje voor het indoor van zaterdag klaar te zijn en wat rondjes te kunnen draaien. Nog even door sleutelen dus

[ph-svv]

Wel een filmpje maken aub, ik kan er zaterdag (weer) niet bij zijn maar ben wel razend benieuwd. Knap werk Lup!

verstuurd vanaf mijn Android telefoon

[han]

Als nummer 3 mislukt ,ga je dan door ?