Raspberry Pi powered Wii-Quadrocopter

[rossi]

Das ist nicht ganz richtig. In jedem Rechner gibt es eine absolut präzise Zeitbasis, einen Counter der in Hardware die Takte des Haupttaktgebers zählt. Und mit genau diesem Counter ist es möglich die Ungenauigkeiten die durch den Task-Scheduler entstehen auszugleichen. Diese Zeitbasis ist absolut präzise und das Verfahren funktioniert tadellos. Und die 700MHz Takt (von den 32-Bit Registern mal ganz abgesehen, Mathematischer Coprozessor usw.) sorgen halt nicht nur dafür, dass mehr Rechenpower zur Verfügung steht sondern dass sie auch "öfter" zur Verfügung steht.
Selbst grob überschlagen durchläuft ein 700MHz Prozessor die gleiche Regelschleife rund 40 mal öfter als ein 16MHz Prozessor. Wahrscheinlich ist das Ergebnis schon genau genug, wenn man einfach die 40 Zyklen mittelt. Mit ein paar Tricks (wie oben angedeutet) ist das Ergebnis garantiert mindestens so gut wie bei einem kleinen 8-bit Atmel!

 

[schnellmaleben]

Richtig, aber an die Hardware-Timer des Cores kommst Du wohl kaum mit Python ran (schon PWM für die ESCs erzeugen ist ein Krampf auf dem Raspberry...), also, fröhlich Kernelmodul schreiben ist angesagt. Einfach und elegant geht anders

 

[rossi]

Zu Python hab ich meine Meinung ja schon Kundgetan. Da bin ich mit euch einer Meinung. Das ist Murks. Dass die Aufgabenstellung nicht einfach ist habe ich auch nicht in Abrede gestellt. Wenn man sich aufgrund der mangelnden Echtzeitfähigkeit des Betriebssystems eine unabhängige Zeitbasis zur Korrektur von Fehlern bei der Zeitmessung heranziehen muss klingt das nicht nach einfach. Elegant kann es trotzdem sein.
Ich wollte halt nur den Threadstarter nicht mit einem plumpen "das kannste vergessen, das klappt eh nie" direkt jeden Elan nehmen. Wenn er das gerne so machen möchte soll er es versuchen. Ich halte das Unterfangen nicht für grundsätzlich unmöglich. Und ich glaube auch nicht, dass man auf Kernel-Eben runter muss um ein lächerliches 400Hz "PWM" zu erzeugen. Er will ja nicht direkt die FETs auf den Reglern ansteuern sondern nur "relativ" schnelle Servo-Signale erzeugen.

Edit: Bzgl HW Counter in Python: http://stackoverflow.com/questions/156330/get-timer-ticks-in-python/157423#157423
Man kommt schon an die CPU-Ticks ran. Zumindest unter Linux. Trotzdem ist Python ein absolutes no-go.

 

[schnellmaleben]

Ich wollte halt nur den Threadstarter nicht mit einem plumpen "das kannste vergessen, das klappt eh nie" nicht direkt jeden Elan nehmen. Wenn er das gerne so machen möchte soll er es versuchen. Ich halte das Unterfangen nicht für grundsätzlich unmöglich.

Sehr schön gesagt. Ich halte es, bei richtigem Ansatz, auch für durchaus möglich.

Übrigens lohnt ein Blick auf die Architektur anderer Systeme: Bei der AR.Drohne (1.0 hatte ich mal in den Händen) fliegt ein Linux auf ARM-Kern mit. Ich hab leider grad keine zur Hand, sonst würd ich mal reinschauen ob noch andere Prozessoren drauf sind.

Edit: ARM9 mit 468Mhz, ein PIC für I/O ist mit drauf, und Echtzeit-Linux, Regelung im Hauptprozessor. Hier sind Details: http://cas.ensmp.fr/~petit/papers/ifac11/pjb.pdf

 

[rossi]

Und wenn wir schon beim Unterstützen sind - denn dafür sind Foren ja da - hier ein wenig Lektüre zum Thema Realtime Kernel + Raspberry:

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=2376

http://elinux.org/RPi_Kernel_Compilation

https://rt.wiki.kernel.org/

Und der Ansicht "but its fairly easy to rebuild the kernel with the right options to make it a bit more real time. " kann ich mich nur anschließen. Einen eigenen Kernel bauen ist keine Raketenwissenschaft.

 

[harlix]

...ich glaube nicht, dass das Projekt mit einer RPi-Standard-Linuxdistribution zum Erfolg wird.

Grundsätzlich ist es schon möglich, mit Echtzeit-Linux eine schnelle, hochdynamische Regelung zu realisieren. Aber es erfordert einiges an Arbeit und Wissen über das Scheduling und die Strukturen der verwendeten Kernelmodule. Ich würde die Arbeit halt an eine externe CPU delegieren, da ich das für einfacher halte.

Die Häufigkeit der Berechnungen pro Zeiteinheit sind bei einer Regelung nicht so relevant wie die Stabilität der Periodendauer. Ein Regler, der genau alle 5 ms seine Werte neu berechnet, ist besser, als ein Regler, der im Mittel zehnmal so häufig seine Berechnungen durchführt, aber dafür die Periodendauer zwischen beispielsweise 0,1 ms und 0,8 ms schwankt. Das führt zwangsläufig zu falschen I- und D- Werten.

viele Grüße,

Felix

 

[Giga]

Hi Neroburner, lass Dich nicht entmutigen, es funktioniert:
hier hat es schonmal jemand erfolgreich probiert: http://www.botched.co.uk/picopters-maiden-flight/
vielleicht könnt Ihr ja mal Ideen austauschen.

Übergens gefunden über:
http://hackaday.com/2012/12/01/raspberry-pi-quadcopter/

 

[Roberto]

Auf jeden Fall ein geiles Projekt. Vielleicht kann man noch eine billige Crius AIO unterschnallen für die Sensorik und I/O und SPI anbinden. Das dürfte dann eine zündfähige Mischung ergeben.

 

[axmen]

Der Ansatz der hier im Thread weiter oben von jemandem vorgeschlagen wurde, die "nackte" Steuerung den üblichen FCs zu überlassen und mit dem Raspberry PI "andere" lustige Sachen am Copter zu machen wird ja dort:
http://fpv-community.de/showthread.php?25594-MultiGCS-f%FCr-Linux-und-Raspberry-PI
recht eindrucksvoll gezeigt.

Falls der TE etwas mit dem PI UND Coptern machen mag.

LG
Axel