Wie gesagt: lieber zu groß als zu klein. Mit Linux bin ich vor 20 Jahre so zu sagen groß geworden - mal sehen, was davon noch übrig ist...Zitat von HaWe
Ich bin mir halt nicht sicher, wie ein Board mit OS bzgl. Echtzeitverarbeitung abschneidet, ob da nicht ein "reiner Controller" ohne OS besser wäre. Gibt es denn echtzeitfähige OS Varianten für den Raspi?
Hat hier jemand Erfahrung mit der Sense Hat? Ist das eine vollwertige IMU?
DANKE für eure Hilfe!!!!
ich habe schon etwas an Erfahrung mit schnellen Pin-Abfragen, und was das angeht: lass die Finger vom Raspi.
Der hat nur 2x Hardware-PWM (allerdings etwas holpriges Software-pwm auf allen Pins), dennoch sind Echtzeit-Encoder-Abfragen direkt nicht möglich (>1000 Flanken pro sec.) - langsame Encoder klappen.
Auch die Kommunikation vom HAT oder Sensor-Shield zum Raspi hin und her ist begrenzt.
Dann also lieber keinen Raspi, sondern eher einen Due, der kann immerhin auch Multitasking.
Fällte der Raspi damit für "kritische" Steuerungen aus? Immerhin gibt es ja einige Quadcopter Implementierungen usw.
Oder gleicht der das durch pure Rechenpower wieder aus?
die Frage ist lediglich, wo "kritisch" anfängt. Vieles kann man outsourcen auf Shields, die komplexe Arbeiten (den "Dreck" halt) autonom erledigen, die nächste Frage ist aber dann, wie schnell die (Zwischen-) Ergebnisse wieder auf dem Raspi sein müssen. Wenn also "sehr" zeitkritisch, dann geht es zumindest mit Linux im Userspace nicht mehr absolut sicher. Ein Kenner der Materie sagte mal sinngemäß im englischen Raspi-Forum:
wenn man was im 200µs-Takt braucht, kann das klappen, vielleicht auch schneller, vielleicht aber auch erst nach 400µs.
Auch ist es mit dem Auslesen der Pins ja vllt noch nicht getan (das geht per pigpio angeblich im 5µs-Takt) - wenn sie dann auch noch im 100µs-Takt weiterverarbeitet werden müssen (wie Quadratur-Encoder), dann geht das eben NICHT mehr in "Echtzeit". Linux hat viel zu viele Parallel-Tasks und Demons und Event-Watcher laufen, auf die du keinen Einfluss hast.
Das Propeller-HAT z.B. ist schon ne gute und schnelle Sache, hat Treiber für Python, aber nicht für C - und Python ist auch nicht gerade für Schnelligkeit und Echtzeitfähigkeit bekannt.
Echtzeitfähigkeit erfordert entweder ein RTOS (wie OSEK) oder ARM-bare-metal-Programmierung: beides geht auf Raspi (oder Arduino), aber eben nicht mit Linux.
(nach meinigem jetzigen Kenntnisstand, aber ohne Gewehr^^)
ps,
ich habe 4 Encoder auf einem B+ getestet, da ging es nicht.
Die Tests auf meinem neuen 2B stehen noch kurz bevor.
Hallo HaWe,
erstmal Merci für die Mühe die du / ihr euch hier gebt!!!
Mein Problem ist (glaub ich), dass man als reiner PC Jünger erstmal bei 84 MHz und ein paar Kilobyte Speicher das Muffensausen bekommt. Sowas kennt man ja gar nicht mehr (gibt es auch Programmlogik mit weniger als 10 Megabyte RAM??) Ich möchte abhängig von einem Joystick und einer Lagekontrolle (IMU) zwei Verbrennungsmotoren regeln. Die sind natürlich sehr träge und müssen via PID Regler o.ä. angesprochen werden. Dabei wäre es auch noch schön, wenn mir ein Display ein paar Daten (z.B Drehzahl) anzeigen würde. Ich muss auch die Drehzahl der beiden Motoren kennen, damit ich richtig reagieren kann. Schön wäre auch noch eine Warnung, falls die EGT (Exhaust Gas Temperature) eines Motors einen kritischen Wert überschreitet - das kann einen Zweitakter schlagartig killen....
Nun ist die kritische Frage, ob ich das mit dem Arduino Due z.B. hinbekomme, oder ob mal dazu die Power des Raspi braucht - bei dem wiederum frag ich mich, wie von dir schon angedeutet, ob ein OS mit den tausend Prozessen drauf das Richtige ist...
Geändert von FlyRider (18.01.2016 um 18:43 Uhr)
der Raspi hat nicht mehr Power, wenn es um Pins geht - und was die nackte Rechnerei angeht, bist du mit einem Due bereits äußerst komfortabel aufgestellt!
Hier habe ich einen Benchmarktest für verschiedene Boards, auch da erkennst du, dass ein Due recht schnell ist.
http://www.mindstormsforum.de/viewto...&t=8095#p64772
Und an die RAM-Grenzen bin ich mit dem Due erst gekommen, als ich autonome mehrschichtige rekurrente Neuronale Netze damit programmiert habe
Was die 9DOF IMUs angeht:
nimm lieber den hier, der macht alles onboard, inkl. Kalman:
http://www.mindstormsforum.de/viewto...tart=15#p67401
Hi HaWe,
ich bin eh schon geplättet
Ne, ernsthaft: Ich denke, ich werd mir mal so ein Board bestellen und mich in die Basics einarbeiten. Zuvor aber noch mal eine (wahrscheinlich?) triviale Frage: wie bekomme ich einen Joystick an den Arduino, geht das komfortabel via USB o.ä oder muss man da basteln??
Was mich wieder zum DigiX bringt. Gleiche Basis wie der DUE, dafür mehr Pins und WLAN bereits onboard. Gut die zusätzlichen Pins fallen jetzt in dem Fall nicht ins Gewicht - aber alleine schon die WLAN Integration reduziert die Komplexität, wenn sie einem schon abgenommen wird. Ein Shield weniger, um das man sich Gedanken machen muss. Aber Vorsicht: sowohl der DUE als auch der pin- und softwarekompatible DigiX laufen auf 3,3Volt. Das muss man bei der Shield- / Peripherie-Auswahl auf alle Fälle berücksichtigen
ein ähnliches Problem wie dein beschriebenes wird auch für die Fischertechnik-Controller TX und TXT berichtet:
Der alte TX (200 MHz ARM9: langsamerer Takt, aber OHNE Linux)
ist bei timer-getriggerten Tests schneller als der
neue TXT (600MHz ARM Cortex A8 + Cortex M3: höherer cpu-Takt, sogar mit ARM Coprozessor, aber MIT Linux) !
Exakt wie ich es auch für Arduino vs. Raspi beschrieben habe!
http://forum.ftcommunity.de/viewtopi...p=22998#p22998
Linux ist eben das Gegenteil von Echtzeit-fähig.
Geändert von HaWe (18.01.2016 um 20:16 Uhr)
das normale linux ist nicht echtzeitfähig, richtig, es gibt aber diverse realtime kernel update für linux. man muß sich da allerdings auskennen.
das leben ist hart, aber wir müssen da durch.
Berechtigungen
Zitieren
Lesezeichen