Hallo zusammen,

eine Frage, FlightCtrl arbeitet mit 20Mhz, microdrohnes (professionell und sehr teuer)
grenzt sich gegenüber OpenSource Projekten auch mit 40Mhz ab (ARM7).

Wie wichtig ist das Tempo des Pic für's Flugverhalten.
Im Datenblatt der Muratas sehe ich eine Response Time von EMC-03 bei 20mSec.

Das heißt ja, max. 50x pro Sekunde könnte ein Gyro abgefragt werden. Nur 20Mhz sind doch
20 Million Vorgänge/Rechenschritte pro Sekunde. Müßte doch eigentlich reichen. Pro
Gyro Abfrage hätte man noch 400.000 Rechenschritte Platz.

Könnte der Microkopter auch mit 10Mhz fliegen?
(Ich hoffe "Software & Programmierung" stimmt als Thema)

Danke & Viele Grüße aus Neuss
Askan Simon

hi,

es geht nicht nur um das auslesen der gyros sondern vorallem um das abarbeiten der integrale vom ACC.
den MK kann man "schwindelig fliegen", da der 644 mit seinen 20MHz ziemlich an seine grenzen stößt wenn er heftige integrale ausrechnen muss.
mit 40MHz wäre man da sicherlich besser unterwegs.

allerdings: der MK ist die "günstige variante" der High-End Quadrokopter. Ein Arm7 oder 9 kostet im verhältnis zu den 644ern schonmal ne ganze ecke mehr.
die hohen kosten allein für den PIC würde sicherlich viele einsteiger vom Bau abhalten.

Andere Projekte (Arm-o-Kopter, UAVP NG) haben mehr Rechenpower und somit sind theoretisch bessere Flugeigenschaften möglich. Für mich als Student kommen solche Projekte auf Grund eines fehlenden goldscheissenden Esels nur leider nicht in Frage. Den MK hingegen kann ich mir gerade so leisten.

klar, ein Quadro kann, wenn man wenige zusatzfunktionen benutzt und sich nur aufs fliegen konzentriert sicher auch mit 10MHz und ohne beschleunigungssensor in der Luft bleiben, der MK stellt somit den übergang zwischen reinen Gyro-Stabilisierten und Gyro + Acc stabilisierten Fluggeräten dar und das macht er meiner Meinung nach ausgezeichnet.

man munkelt ja, dass das NaviBoard dann einen Arm7 draufhaben wird, ob dieser einige Rechenoperationen der FC übernehmen wird habe ich bisher aber noch nicht herausfinden können.


mfg
Rob

Hallo Askan,

die auf der FlightControl läuft die Regelschschleife für die Lageregelung mit 2ms d.h. mit 500Hz. Das ist meines Wissens nach schneller als bei irgendeinem vergleichbaren Quadrokopter. Das macht natürlich alles auch nur Sinn, wenn die verwendeten Bruschlessregler entsprechende Regelgeschwindigkeiten haben. Man muss bei solchen Betrachtungen immer auf das schwächste Glied in der Kette achten.

Allerdings ist die FC mittlerweile wirklich an ihrer Rechenkapazitätsgrenze angelangt. Für rechenhungrige Extras bleibt da nichts mehr übrig. Daher ist es auch der richtige Weg von Holger und Ingo weiterführende Aufgaben mit der NaviCtrl zu lösen, auf der dann ein Arm 9 mit bis zu 96 MHz werkelt.
Das sollte für die mittlere Zukunft ausreichend Rechenleistung sein.

Grüße Gregor

Hallo

Rober-t da irrst du dich. Der LPC2148 ARM7 kostet 11,95€, also vergleichbar mit dem 644P.
Der Quarz ist der gleiche.

Die Entwicklungsumgebung wird nur teurer, aber die haben sogar schon einen Bootloader drauf und können per ser. oder USB programmiert werden.

Gruß Wolfgang

killagreg meinte

die auf der FlightControl läuft die Regelschschleife für die Lageregelung mit 2ms d.h. mit 500Hz. Das ist meines Wissens nach schneller als bei irgendeinem vergleichbaren Quadrokopter.

naja...

ich spreche jetzt mal vom ARM-o-Kopter: 1ms regelschleife für alles - ausnahme kompass, GPS und baro.

auch der X-3D, der FP und das NG sind hier schneller als der MK - man könnte also sagen, der MK ist fast schon der langsamste unter den quadrokoptern - nix für ungut...

die kosten für einen kompletten ARM7 basierten kopter können deutlich günstiger sein, als ein MK nachbau - allerdings ist es nicht ganz so DAU-sicher... dafür dann aber auch gleich mit "ordentlichen" gyros...

die entwicklungsumgebung im ARM-o-Kopter fall ist vollständig open-source (winarm) - die firmware (noch) nicht. das behalte ich mir noch vor, so lange noch grosse änderungen an der tagesordnung stehen.

lg, hans.

Hallo Simon,

die FlightCtrl schlägt sich mit den 20MHz ganz gut.
Das NaviBoard hat einen ARM9 mit 96MHz bekommen. Der soll auch die SD-Karte usw. bedienen.
Die Hardware ist so ausgelegt, dass das NaviBoard auch die komplette Fluglageregelung machen könnte und die FC nur die Messwerte erfasst.

Gruss,
Holger

ufo-hans meinte

ich spreche jetzt mal vom ARM-o-Kopter: 1ms regelschleife für alles - ausnahme kompass, GPS und baro.

Gilt so auch fuer's NG.

Wir haetten sogar die Moeglichkeit mal 2kHz auszuprobieren... vom Timing liegt das noch locker drin...
... nicht dass ich denke es bringe noch viel.

Die Kosten fuer nen ARM sind nicht gross. Da sind die besseren Sensoren schon eher die Teilchen, die etwas teurer sind. Viel macht das aber auch nicht aus.

Gruss
- Amir

Hallo,

vielen Dank für die wiedermal superschnelle und ausführliche Antwort.

Viele Grüße aus Neuss
Askan

Hi,

killagreg meinte

die auf der FlightControl läuft die Regelschschleife für die Lageregelung mit 2ms d.h. mit 500Hz.

Ist auch sehr stark von der FC Version ab.
Eine 0.67 und davor war deutlich schneller als die Versionen ab 0.68.

Ich hab mal beim rumspielen die untere Grenze der, für meinen MK, Regelschleife rausgefunden.
Es ziemlich genau 200Hz.
Bei 210 Hz liegt der MK schön sauber in der Luft. Bei 190Hz fängt er an sich ganz bös zu verhalten.

Und wegen ARM: den 644 kann fast jeder noch löten. Den ARM lötet so gut wie keiner mehr von Hand.
Außerdem ist er nicht so robust an den Pins. Ein 644 verzeiht schon mal. Ein ARM nicht.

Bye
Mikeljo

mikeljo meinte

Und wegen ARM: den 644 kann fast jeder noch löten.
Den ARM lötet so gut wie keiner mehr von Hand.

ob nun 44 beine, oder 64, macht den kohl auch nicht mehr fett.
der pinabstand ist der selbe.

gegen kurzschlüsse an den ports, helfen schutzwiederstände.


.

Hoi Mikeljo,

mikeljo meinte

Und wegen ARM: den 644 kann fast jeder noch löten. Den ARM lötet so gut wie keiner mehr von Hand.
Außerdem ist er nicht so robust an den Pins. Ein 644 verzeiht schon mal. Ein ARM nicht.

Desshalb stecken wir auch ein ARM7 Headerboard auf das NG und ueberlassen die ganze ARM Loeterei fuer den Moment den Maschinen. Die paar Gram Gewicht sind das Wert.

Gruss
- Amir

Super Sache!

Da haben wir demnächst also Intel im Kopter und damit in der Luft? Ist ja dann doch fast wie die alte Werbung von Intel das deren CPUs voll abgehoben sind.

Diese ARMen Dinger sind ja wohl fast überall verbaut!?
In meinem IPod und Handy haben ich die schon gesehen.

Ja wenn die auf einem Board fertig verlötet kommen, macht das bestimmt Freude und unerfahrende Löter haben weniger Fehler und daher mehr Spaß weil schneller Erfolge erzielt werden.

Wobei ich mir doch sehr viel Zeit lasse und alles Überdenke, bei dennoch auftretenden Fehlern ich diese analysiere um draus zu lernen. Hat auch eine gewisse Fazination, manchmal liegt es im Detail.

mfg

nighteagle

mikeljo meinte

Den ARM lötet so gut wie keiner mehr von Hand.

übung macht den meister! nach einigen übungsversuchen an alten grafikkarten bekommt man das mit einer fetten spitze (NICHT dieses dünne SMD-spitzen-gedöns!) und entlötlitze so sauber hin, dass nach der flussmittelentfernung kein sichtbarer unterschied mehr zu einer maschinellen lötung besteht.

aktuell benötige ich für einen ARM7 ca. 10 minuten...

lg, hans.

Es gibt da noch das Berliner Ein-Mann-Projekt mit dem Günni-Board. Dieses arbeitet mit nur 8 MHz und funktioniert genauso. Hat einige Interessante Features wie im Flug umschaltbare Settings. Günni meinte auch, er kenne sich mit Regelungstechnik nicht aus, es funktioniert einfach.

Hi,

JUERGEN_ meinte

mikeljo meinte

Und wegen ARM: den 644 kann fast jeder noch löten.
Den ARM lötet so gut wie keiner mehr von Hand.

ob nun 44 beine, oder 64, macht den kohl auch nicht mehr fett.
der pinabstand ist der selbe.

Komisch ich hab grad einen 644 und einen ARM9 vor mir liegen...... Das sieht ned nach gleichem Pinabstand aus!
Beim Arm brauchste schon ne Lupe nur um die Pins überhaupt unterscheiden zu können.

JUERGEN_ meinte

gegen kurzschlüsse an den ports, helfen schutzwiederstände.

[Klugschiss on] Dat Dingens heißt WIDERSTAND![Klugschiss off]
Weils Widersteht und ned weils wiederkommt! Sagte schon mein ET-Lehrer.

ufo-hans meinte

mikeljo meinte

Den ARM lötet so gut wie keiner mehr von Hand.

übung macht den meister! nach einigen übungsversuchen an alten grafikkarten bekommt man das mit einer fetten spitze (NICHT dieses dünne SMD-spitzen-gedöns!) und entlötlitze so sauber hin, dass nach der flussmittelentfernung kein sichtbarer unterschied mehr zu einer maschinellen lötung besteht.

aktuell benötige ich für einen ARM7 ca. 10 minuten...

Glückwunsch.
Aber der Otto Normallöter wird son Teil nicht mehr löten können. Das ein Profi sowas kann.....

Bye
Mikeljo

mikeljo meinte

Aber der Otto Normallöter wird son Teil nicht mehr löten können. Das ein Profi sowas kann.....

ich hab mein erstes SMD-teil vor ca. 1,5 jahren gelötet - das war ein ATmega8 auf einem BLctrl 1.0

also von "profi" keine rede - man wächst mit der aufgabe!

killagreg meinte

die auf der FlightControl läuft die Regelschschleife für die Lageregelung mit 2ms d.h. mit 500Hz. Das ist meines Wissens nach schneller als bei irgendeinem vergleichbaren Quadrokopter.

Nö, alle AscTec Quadros/Octos (X-3D, FunPilot, AutoPilot) laufen auf 1kHz. die MD regelt nur mit 120Hz.

killagreg meinte

Das macht natürlich alles auch nur Sinn, wenn die verwendeten Bruschlessregler entsprechende Regelgeschwindigkeiten haben. Man muss bei solchen Betrachtungen immer auf das schwächste Glied in der Kette achten.

Das ist richtig! Deswegen brauchts auch nen X-BL (beim khz) oder nen MK-Regler (bei 500hz)

ARM7 per Hand löten ist ziemlich einfach wenn man mal die Technik erklärt bekommen hat (2-3 Minuten). Schwieriger sind da schon BGAs, MLFs oder SC70...

jast meinte

Deswegen brauchts auch nen X-BL (beim khz) oder nen MK-Regler (bei 500hz)

oder einen quax... nur der vollständigkeit halber...

lg, hans.

Zitat

Es gibt da noch das Berliner Ein-Mann-Projekt mit dem Günni-Board. Dieses arbeitet mit nur 8 MHz und funktioniert genauso. Hat einige Interessante Features wie im Flug umschaltbare Settings. Günni meinte auch, er kenne sich mit Regelungstechnik nicht aus, es funktioniert einfach.

Und das ist in Bascom geschrieben und fliegt wirklich richtig gut!
Nur mit PD Regler ist das fast so sportlich wie ein X-BL
Gruß Boris

Hoping I don't offend anyone by this (long) post... The MK project is very cool, so below is just a humble suggestion.

killagreg meinte

Allerdings ist die FC mittlerweile wirklich an ihrer Rechenkapazitätsgrenze angelangt.

Dafür habe ich mal ins Code geschaut, ob es optimiert ist. Vielleicht is da noch etwas zu gewinnen, zum Beispiel in fc.c :

* warum werde kein bit shift benutzt bei teilen oder multiplitzieren?

 stick_nick = (stick_nick * 3 + PPM_in[EE_Parameter.Kanalbelegung[K_NICK]] * EE_Parameter.Stick_P) / 4; 

konnte, glaub ich, auch sein:

 stick_nick = (stick_nick * 3 + PPM_in[EE_Parameter.Kanalbelegung[K_NICK]] * EE_Parameter.Stick_P) >> 2; 

* if statements konnen geordned werden nach warscheinlichkeit:

// Empfang schlecht
 if(SenderOkay < 100)
....
 else 
// Emfang gut 
 if(SenderOkay > 140)
...

ist bei normalen emfang langsamer als

// Emfang gut 
 if(SenderOkay > 140)
...
else
// Empfang schlecht
 if(SenderOkay < 100)
.... 

* Vielleicht ein bisschen mehr else statements:

if(tmp_long > AUSGLEICH) tmp_long = AUSGLEICH;
if(tmp_long < -AUSGLEICH) tmp_long =-AUSGLEICH;

werde:

if(tmp_long > AUSGLEICH) tmp_long = AUSGLEICH;
else if(tmp_long < -AUSGLEICH) tmp_long =-AUSGLEICH;

Es gibt mehr von diese sachen. Also, wass denkt ihr? Nutzt optimierung?

Generell ist code optimization eine sehr gute idee, allerdings kommt man schnell an die grenze des lesbaren und was viel viel wichtiger ist:
Mein SysInf Prof sagte schon immer man soll den Compiler seine Arbeit ruhig machen lassen, man darf ihn nur nicht bei behindern.
Soll heissen: probiers mal aus und guck dir danach den ASM code an der raus kommt. Da wird sowas meist schon gemacht... Es sei denn man baut wirklich sachen die nen Compiler nicht versteht und deswegen "dumm" uebersetzt

Aehm CaScAdE, ich geb dir recht bei Bitspielereien... das macht der GCC meistens selber besser und wenn man ein /2 macht, dann wird das schon zu nem Shift optimiert (wenn man Optimizing richtig eingestellt hat).

Was Scheveningen dann aber noch anspricht, Sachen wie "if() else" statt "if(); if()" sollten wirklich noch etwas bringen. Es wuerde mich erstaunen, wenn der GCC inzwischen so smart geworden ist, um das zu erkennen.

Auf der anderen Seite hat mich das Ding schon einige male ueberrascht und vielleicht beherrscht er inzwischen ja auch solche Optimierungen...
... wie du richtig sagst: Um's genau zu wissen muss man's ausprobieren und den Assembler Code anschauen.

Gruss
- Amir

Kann er nicht beherrschen...
Woher soll er wissen welcher Fall bei if/else am oeftesten vorkommt...
Dazu muesste er Laufzeitinformationen haben, die ihm aber fehlern.

Insofern denke ich duerfte das schon noch was bringen, vor allem in der Main-Loop

tantive meinte

Kann er nicht beherrschen...
Woher soll er wissen welcher Fall bei if/else am oeftesten vorkommt...
Dazu muesste er Laufzeitinformationen haben, die ihm aber fehlern.

Wahrscheindlichkeitssortierung kann er sicher nicht ohne Laufzeitinformationen, da geb ich dir recht. Zwei hinter einander kommende if() deren Bedingung jeweils das negierte der anderen ist, waeren schon moeglich zu erkennen.

Gruss
- Amir

Habe den Makefile und Assember Code von H&I in das SVN anschaut.

Der H&I Makefile sagt avr-gcc -Os, und dass ist wichtig! Gcc optimiert also nicht O3.

Dann habe ich test Code compiliert:

int test (int a)
{
 return a/4;
}

int test2 (int b)
{
 return b >> 2;
}

Und das gibt:

00000000 <test>:
int test (int a)
{
 0: 64 e0 ldi r22, 0x04 ; 4
 2: 70 e0 ldi r23, 0x00 ; 0
 4: 0e 94 00 00 call 0 ; 0x0 <test>
 8: cb 01 movw r24, r22

 return a/4;
}
 a: 08 95 ret

0000000c <test2>:

int test2 (int b)
{
 c: 9c 01 movw r18, r24
 e: 35 95 asr r19
 10: 27 95 ror r18
 12: 35 95 asr r19
 14: 27 95 ror r18

 return b >> 2;
}
 16: c9 01 movw r24, r18
 18: 08 95 ret

also: Bit Shift lohnt Sich
Ich habe auch den "if();if();" vs "if();else if();" Test gemacht. Das lohnt sich nicht weil es gleiche code ergebt.
Wahrscheindlichkeitssortierung: Ich habe die Assembler Code anschaut. Ich glaube Assembler ist sortiert wie in die C Code. Auch sortierung wird lohnen.