Ich habe einen STM32F4 als Drohnenflugkontroller. Leider reicht die Performance dessen selbst mit OC auf 240MHz nicht aus um den PID loop mit 32kHz laufen zu lassen. Obs der F7 bringt ist auch fraglich. Da die Anwendung nicht besonders kosten/energieverbrauchsensitiv ist, wäre ein A53 den zu gehenden weg. Kennt jemanden einen einfachen A53, bei welchem Betafligh (die SW) auch relativ einfach portabel wäre?
Das Problem mit Cortex-A ist, daß sie für Applikationen vorgesehen sind. Soweit mir bekannt, sind sie daher bare metal praktisch nicht nutzbar, wenn Du nicht extremen Aufwand treiben willst. Das ist zum Betrieb mit Linux gedacht. Das ist aber nicht echtzeitfähig, und eine variable Totzeit wäre für einen Regler fatal. Also müßte man schauen, wie man eine RT-Erweiterung von Linux auf dem Board zum Laufen bekommt.
Die A Serie sind keine Mikrocontroller. Da bist du eher in dem Umfeld von Linux oder Raspberry Pi. Ohne Betriebssystem kannst du damit nur sehr mühsam arbeiten. Und mit Betriebssystem wird das Timing kompliziert. Hast du mal erwägt einen Raspberry Pi Zero mit einem kleinen STM32 zu kombinieren?
>PID loop mit 32kHz
Ein normaler PID Regler braucht auf dem STM32F4 etwa 1µs.
Ist das so viel mehr?
snapdragon flight nutzt einen Quadcore: https://www.intrinsyc.com/vertical-development-platforms/qualcomm-snapdragon-flight/
Hast Du den Flash Instruction Cache/Prefetch aktiv? Oder läuft die Regelung im RAM?
Schlechten Code mit mit Hardware kompensieren: Nimm einen STM32H7.. mit 400 MHz Oder einen Cortex R Und ja, es gibt Profiler ;-)
STM32 schrieb im Beitrag #5281067: > Leider reicht die > Performance dessen selbst mit OC auf 240MHz nicht aus um den PID loop > mit 32kHz laufen zu lassen. 32k Durchläufe/Sekunde für den PID loop? Möchtest du dir nicht nocheinmal überlegen ob das Sinn macht? Bekommst du von den Sensoren überhaupt so schnell die Werte? Hab da irgendwas im Kopf as 1k/Sekunde reichen sollte. STM32 schrieb im Beitrag #5281067: > Obs der F7 bringt ist auch fraglich. Davon wird dein Code auch nicht besser. Manche schaffen es auch auf 8MHZ/16MHZ ATMegas...
STM32 schrieb im Beitrag #5281067: > Leider reicht die Performance dessen selbst mit OC auf 240MHz nicht aus > um den PID loop mit 32kHz laufen zu lassen. > Obs der F7 bringt ist auch fraglich. Was ist das für ein Board und wie schnell läuft es momentan auf dem F4?
Wie schnell fliegt denn diese Drohne, dass da eine zeitliche Auflösung mit 32 kHz nötig ist? Und die zweite Frage wäre, wie schon einige Leute hier angesprochen haben, was ist denn mit Codeoptimierung? Ich habe grad vor ein paar Monaten mit den STM32 angefangen und musste erst mal feststellen, dass die Libraries enorm schlecht sind. Das ist von Leuten programmiert worden die Angst vor Microcontrollern haben und die darum mehrere unnütze Abstraktionsebenen eingebaut haben wo bestenfalls eine ausreichend wäre.
Guido Körber schrieb: > Das ist von Leuten programmiert worden die Angst vor Microcontrollern > haben und die darum mehrere unnütze Abstraktionsebenen eingebaut > haben Es gibt halt kein Problem, das nicht mit einer weiteren Abstraktionsschicht zu lösen wäre. Mit Ausnahme des Problems "zuviele Schichten" natürlich. ;-)
Ich habe mal einen fahrenden Modell-Roboter mit 100Hz Regelschleife gesteuert. Ich erwähne das, damit klar wird wie extrem die 32kHz sind.
und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren? Wie ihr hier schon wieder drauf seid, glaubt ihr in der Szene gibts nur Stümper? Schaut euch mal nur als Beispiel https://github.com/betaflight/betaflight an, >10k commits, >260 contributors. Ich habe letztes Jahr zwei ESC mit SimonK Software gekauft und noch wollte noch zwei nachordern. Gibts nicht mehr, kalter Kaffee. SingleShot, ProShot, DShot, jeden Monat ein neues schnelleres Protokoll um den ESC schneller mit Steuerbefehlen zu versorgen. Mit 100 Hz wirst du da herzlich ausgelacht, die sind bei wenigen µs für die Ansteuerung.
32KHz halte ich auch für übertrieben. Alles über 1K sollte keinen Unterschied mehr machen. Welcher Motor schafft innerhalb 1ms eine nennenswerte Drehzahländerung? Andere Leute schaffen das mit einem 16 MHz AVR (Wobei man das jetzt auch nicht direkt vergleichen kann). Dein Ansatzpunkt sollte erstmal die Optimierung von Code sein und die Update Rate zu überdenken. mfg
Felix F. schrieb: > ndere Leute schaffen das mit einem 16 MHz AVR (Wobei man das jetzt auch > nicht direkt vergleichen kann). und die machen nebenbei noch ein OSD, Datenlogging mit 8 kHz, AutoPID, die ganzen Berechnungen mit dem IMU? Nicht mal die STM32F1 möchte man dafür noch haben.
Johannes S. schrieb: > Felix F. schrieb: >> ndere Leute schaffen das mit einem 16 MHz AVR (Wobei man das jetzt auch >> nicht direkt vergleichen kann). > > und die machen nebenbei noch ein OSD, Datenlogging mit 8 kHz, AutoPID, > die ganzen Berechnungen mit dem IMU? Nicht mal die STM32F1 möchte man > dafür noch haben. Klar, die nehmen dann einfach einen Coprozessor, der für diese Aufgaben ausgelegt ist :) mfg
> Welcher Motor schafft innerhalb 1ms eine > nennenswerte Drehzahländerung? Dazu kommt die Massenträgheit des ganzen Gerätes. Ich möchte mal eine Drohne sehen, die 30 tausend mal (oder lass es mal nur ein zehntel davon sein) pro Sekunde ihre Flugrichtung ändern kann. > und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren? Gegenfrage: Muss deiner bei 100km/h in einer 30tel Millisekunde reagieren? Vermutlich denkst du das, aber warum? > Mit 100 Hz wirst du da herzlich ausgelacht Von Leuten die auf große Mhz Zahlen stehen und keine Ahnung haben. Kleine Anekdote: Die Navigation einer bemannten Raumfähre wurde mit einem C64 gemacht, da hatte etwa 1Mhz Taktfrequenz! Wenn man für solche Sachen hunderte Mhz bräuchte, dann frage ich mich, wie die Menschen denn in den 70er Jahren ihre digitalen Regelungen konstruiert haben.
Felix F. schrieb: > 32KHz halte ich auch für übertrieben Ist es natürlich auch. Mich interessiert total mit welchem Beschleunigungssensor und mit welchem Gyro der TO arbeitet. 32kHz sind ja schon beachtlich. Deshalb nochmal die Frage: Was ist das für ein Board?
Bei den 32 kHz gehe ich mal davon aus das die Summenrate gemeint ist, damit verteilt sich das beim Quad auf 8 kHz oder Octo auf 4 kHz. Ich bin zu langsam für solche Extrem Racer aber guckt euch die höher schneller weiter Videos auf YT an wie die richtigen Cracks fliegen. Mich stört es nur wie hier alle anderen wieder für blöd gehalten werden.
Hmmm.... eine merkwürdige Diskussion ist das. Der TO schreibt noch nicht einmal, welche Regelschleife mit 32 kHz abgetastet wird (ich gehe mal davon aus, daß ein Quadkopter durchaus mehrere kaskadierte Regelschleifen hat). Vom Reglermodell ist auch nichts zu lesen. "Der" PID ist ein Eingrößenregler und selbst in seinen kompliziertesten Ausprägungen in float problemlos mit 100 kHz auf einem STM32F446 mit 176 MHz zum Laufen zu bekommen, wobei die Auslastung des Gesamtsystems noch vertretbar bleibt. BTDT. Die Gegenseite vergleicht die Dynamik eines Quadcopters mit einem Bodenfahrzeug. Auch Unsinn. Als ob man einen Lageregler nur einmal pro Umdrehung abtasten müßte. Oder pro "erlaubtem" Bereich.
:
Bearbeitet durch User
Einen F4/F7 wird man nicht mal eben durch einen Quadcore A53 ersetzen, da bin ich auch skeptisch aber es gibt eben schon z.B. einen Snapdragon Controller. Das Bessere ist des Guten Feind in dem Markt und wenn morgen so ein Controller am Markt ist stürzen sich alle drauf. Ein halbwegs aktueller Controller mit F4 kostet 35-40€, das ist spottbillig wenn man bedenkt was da alles drauf ist auf einer Multilayer Platine mit teilweise dicken Layern und >90 Keramik Cs für die >150 A die da kurzzeitig fliessen. Das reicht schon für viel Spass aber die Entwicklung wird da von den richtigen Freaks getrieben.
>Kennt jemanden einen einfachen A53, bei welchem Betafligh >die SW) auch relativ einfach portabel wäre? download DS5 Community Edition, unterstützte CPUs auswählen, Bare Metal programmieren https://developer.arm.com/products/software-development-tools/ds-5-development-studio/editions/community-edition
STM32 schrieb im Beitrag #5281067: > Obs der F7 bringt ist auch fraglich. Der ist deutlich schneller als die F4, u.A. dank superskalarer Architektur und Instruction RAM. Kann man also mal drüber nachdenken. PS: 8 kHz Daten Logging ist ein Witz selbst für den F4 ;-)
Wenn's nicht an der Software liegt, dann hätten NXP und Renesas u.U. was passenderes im Angebot: NXP den i.MX RT1050 Cortex-M7 mit bis zu 600 MHz oder Renesas die RZ/T1 Cortex-R4 mit bis zu 600 MHz
Dr. Sommer schrieb: > PS: 8 kHz Daten Logging ist ein Witz selbst für den F4 ;-) Vlt wäre das schon mal der erste Ansatzpunkt für Optimierungen? Was genau muss man den 8000! mal pro Sekunde loggen? Selbst wenn sich das Ding 10 pro Sekunde um seine eigene Achse dreht, könntest du mit 4k immer noch die Position auf über 1° genau messen. Vor allem wenn du auf non-volatile Speicher schreibst gewinnst du hier deutlich an Geschwindigkeit. mfg
Arc N. schrieb: > Wenn's nicht an der Software liegt, dann hätten NXP und Renesas u.U. was > passenderes im Angebot: NXP den i.MX RT1050 Cortex-M7 mit bis zu 600 MHz > oder Renesas die RZ/T1 Cortex-R4 mit bis zu 600 MHz wollte ich auch gerade vorschlagen, wenn es nicht ein STM32 sein muss würde ich mir die M7 von NXP anschauen.
Die Seite von Oscar Liang ist Top und bringt alles auf den Punkt: https://oscarliang.com/best-looptime-flight-controller/ https://oscarliang.com/f1-f3-f4-flight-controller/ Danach gibt es durchaus F4 Controller die eine 32 kHz PID looptime schaffen. Aber wie gesagt, meine Reaktionszeit liegt deutlich über 125µs und ich selber brauche es nicht :-)
> meine Reaktionszeit liegt deutlich über 125µs
Meine liegt laut Doktrin der Fahrschule bei 1s. Meine bescheidenen
Erfolge in Videospielen scheinen das zu untermauern.
Johannes S. schrieb: > Die Seite von Oscar Liang ist Top und bringt alles auf den Punkt: By making looptime faster, you are now also open to a broader spectrum of noise frequency. This broader noise spectrum can manifest as, what is known as “D-Term” oscillation in blackbox data. D-Term oscillation can make your quad harder to tune as well as causing excessive heat in your motors. Some quadcopters actually run better at slower looptime because a faster looptime generates so much vibration, it is almost impossible to tune out. Gyro running a 32KHz sampling rate can be susceptible to noise Just remember that setting looptime faster isn’t going to make you a better pilot I tried KISS flight controller which was running at just 1KHz looptime, and the quad was flying just as “locked in” as my other quads running Betaflight at 8KHz. Mmhhh, ja stimmt. Wirklich gute Seite. Dieser Oscar bestätigt alles, was hier im Forum schon gesagt wurde. Johannes S. schrieb: > Danach gibt es durchaus F4 Controller die eine 32 kHz PID looptime > schaffen. Das hat auch niemand gesagt. Im Gegenteil, man hat dir sogar noch Tipps gegeben um deine absurden 32Khz zu erreichen. mfg
Felix F. schrieb: > man hat dir sogar noch Tipps > gegeben um deine absurden 32Khz zu erreichen. nö, der TO wollte das und mit seinem Controller gehts nicht, not me. Und es wird trotzdem Freaks geben die sagen das man mit 32 kHz viel besser fliegen kann...
> es wird trotzdem Freaks geben die sagen das man mit 32 kHz viel > besser fliegen kann... Ja, so wie Akkuschrauber mit mehr Volt grundsätzlich stärker sind und Staubsauger mit mehr Watt besser saugen und USB Sticks mit mehr GB öfter gefälscht sind ... upps
Der Code wird wohl unheimlich verfrimelt sein... aber soll mir nix angehen... Wenn ich ein CortexA einsetzen würde wollen, würde ich wohl bei FreeRTOS vorbei gucken und mir einen mit passendem FreeRTOS-Port als Grundlage raussuchen. Mit viel Glück gibts vom Hersteller noch ne passende HAL, sonst wirds "lustig".
STM32 könnte einer unserer Kunden sein. Dem war unser F4 auch viel zu langsam, weil "die PWM ja mit 20kHz laufen muss". Er hat wegen der hohen Frequenz auch Litzendraht für die Spule vorgeschlagen... Aber immerhin wurde ich so nach ein paar Konferenzen zum Bullshi-Bingo-Meister... Zum Thread: was genau ist zu machen? Ich vermute deshalb etwas Skepsis, weil es so klingt als ob MEMS (Beschleunigung, Gyro), die üblicherweise Grenzfrequenzen von wenigen kHz haben, mit 32kHz abgetastet werden. 4 Brushless-Motoren zu regeln wäre schon plausibler. Je nach Anforderung: wie wäre es mit einem Mehrkerner? Evtl. auch ein asymmetrischer Aufbau?
Johannes S. schrieb: > Die Seite von Oscar Liang ist Top und bringt alles auf den Punkt: > > https://oscarliang.com/best-looptime-flight-controller/ > https://oscarliang.com/f1-f3-f4-flight-controller/ Sehr schöne Übersicht. Wie absurd das ganze ist, beschreibt folgendes ganz gut: > Gyro running a 32KHz sampling rate can be susceptible to noise, > a good example would be flight controllers like the Raceflight Revolt > which requires soft-mounting. > [Link zu "soft-mounting": https://oscarliang.com/soft-mounting-fc-motors/ Und dann weiter: > Soft mounting had been a hot topics in 2017 because vibration became a real > problem due to more powerful mini quad motors, and faster PID algorithm and > Gyro sampling rates. Da lach ich mich schief. Erst versucht man mit aller Gewalt die Abtastrate des Gyros hochzudrehen, nur um den dann gewissermaßen durch einen mechanischen Tiefpass wieder zu limitieren, weil man feststellt, dass 32kHz ganz viel Müll mit sich bringen :D Was kommt als nächstes? Der elektronische Bang-Bang-Regler für die Herdplatte mit 1MHz? Manche Leute werden es trotzdem kaufen, weil die meinen, dass damit die Nudeln schneller gar werden.
Höher, schneller, weiter… Die Diskussion kenne ich nur zu gut von Input-Devices (mein Business). Den Chip für die RTR-720 Mk I haben wir damals gemacht, eine Gaming Mouse, noch mechanisch. Da wurde mir auch erst erzählt man brauche für eine Gaming-Mouse auf jeden Fall Full Speed USB, weil dann 1000 Reports pro Sekunde durch gehen, die 125 bei Low Speed gingen garnicht. Wir haben dann einfach 16 Bit pro Achse statt der üblichen 8 Bit genommen und die Routinen zum Auslesen der Drehgeber optimiert bis zum Anschlag. Auf diese Weise ging die Maus bei schnellen Bewegungen nicht an den Anschlag und im direkten Vergleich kam sie bei den Gamern besser weg als die Full Speed Teile, es wollte keiner glauben, dass die nur mit 125 Hz Datenpaketrate läuft. Vielleicht gibt es kein zu schnell, aber ist gibt ein schneller als sinnvoll. Das erreicht man in dem Moment wo die Regelschleife deutlich schneller als das ist was sie regeln soll. Falls ein Mensch in der Schleife drin ist, dann ist alles über 100 Hz reine Esoterik. Wir haben grad einen neuen Beschleunigungs-/Drehratensensor fertig, der läuft bei maximal 6,6 kHz Abtastrate. Da mag man dann aber schon noch einen Tiefpass dahinter haben, denn das Rauschen wächst mit der Abtastfrequenz deutlich an.
egal obs noch wichtig ist: M4 hat aus dem flash waitstates ... also aufpasse!! ebenso der RAM hat diverse busse .. ( DTCM ... ) hier gibts auch performanceunterschiede zum M7 jedenfalls : bei solchen aktionen immer den ITCM RAM nutzen Fuktionen im RAM benötiogen keine waitstates und werden durch den cache unterstützt. Das erfordert jedoch etwas aufmerksamkeit beim programmieren. also nur wirklich zeitkritische funktionen in den ITCM legen und schon rennt der µC Ich konnte so einen SW JPEG decoder von 5-7fps auf über 25fps beschleunigen
Johannes S. schrieb: > und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren? Bei 1Hz sind das 27,78m/s = 27,78mm/ms = 2,7cm/ms. Bei 32kHz sind das dann <1mm Bewegung. Macht das Sinn?? rgds
6a66 schrieb: > Johannes S. schrieb: >> und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren? > > Bei 1Hz sind das 27,78m/s = 27,78mm/ms = 2,7cm/ms. > Bei 32kHz sind das dann <1mm Bewegung. > > Macht das Sinn?? > > rgds da bedeutet 0,868 mm/ Cycle - wenn du mit 1cm an nem Aobjekt vorbeifliegst hat das vielleicht schon seine Berechtigung. Das Problem ist wohl eher die Entstörung mittels mechanischem oder SW technischem Tiefpasses
Als Einsteiger mit noch halbfertigem Copter weiss ich das ich keine 32 kHz Loopfrequenz brauche. In der Messtechnik ist Oversampling aber nicht ungewöhnlich und man kann die 'überflüssigen' Messwerte mit schlauen Filtern bearbeiten oder die Zukunft vorhersagen. In den Copterforen wird das Feature jedenfalls auch kontrovers diskutiert und in vielen FC sind sowieso noch IMU mit max. 8 kHz drin. Es gibt mittlerweile sehr viele FC und da sind die 32 kHz natürlich ein zugkräftiges Schlagwort für das Marketing. Die meisten die so Dinger kaufen sind sicher mehr Flieger als Techniker und da zählen die PS :-)
Markus H. schrieb: > da bedeutet 0,868 mm/ Cycle - wenn du mit 1cm an nem Aobjekt Bei 100km/h an einem Objekt mit 1cm Abstand vorbeifliegen? Ich sehe ich bin noch lernfähig :) rgds
Danke erstmal für die vielen Beiträge. Stefan U. schrieb: >> und musste der Robbi auch bei 100 km/h millisekundenschnell reagieren? > Gegenfrage: Muss deiner bei 100km/h in einer 30tel Millisekunde > reagieren? Vermutlich denkst du das, aber warum? Es geht hier nicht direkt um die menschliche Interaktion. Ein Quad ist ein hochdynamisches mechatronisches system welches unteranderem über den MEMS Gyro (>> schneller als Mensch) geregelt wird. Anyway die Mechanik ist klar der Tiefpass. Das bestreben ist daher diesen Pol irgendwie zu Kompensieren und der PID mit möglichst grossem D Anteil zu betreiben. Wichtig ist eine möglichst geringe Latenz im Regelkreis. Hierfür ist einerseits ein schnellerere Flight controller aber auch insbesondere bessere ESCs von möten. Weiter ist das Protokoll zum ESC eine eigentlich unnötige verzögerung. Dshot1200 generiert mindestens 1.3e-5 s delay. Weiter sind die PWM frequenzen der ESC oft recht tief (40-50kHz) und die ESC selbst nicht über die nichtliniarität des Moments bezüglich der aktuellen Motorposition kompensiert. Deadtime hoch etc... Grob gesagt sind die aktuell verfügbaren ESCs nicht besonders befriedigend und eigentlich eine grosse Baustelle. Um das Delay der kommunikation zum ESC zu eliminieren, wäre es am besten, die ESC steuerung in den Flight controller zu integrieren und direkt die 6 Gatesignale pro ESC auszugeben. Somit sind wir am ursprünglichen Problem, dass es der STM32F4 mit 240 MHz nicht bringt... >> Mit 100 Hz wirst du da herzlich ausgelacht > Von Leuten die auf große Mhz Zahlen stehen und keine Ahnung haben. Nun evtl. würde man den Quad auch mit einem 4004 irgendiwie zum Fliegen kriegen :-). Arc N. schrieb: > NXP den i.MX RT1050 Cortex-M7 mit bis zu 600 MHz > oder Renesas die RZ/T1 Cortex-R4 mit bis zu 600 MHz Danke Christopher J. schrieb: >> Gyro running a 32KHz sampling rate can be susceptible to noise, >> a good example would be flight controllers like the Raceflight Revolt >> which requires soft-mounting. Noise der Gyros ist ein Problem. Glücklicherweise scheinen die MEMS entwickler einige Fortschritte zu machen :-). Mit 8 ICM20602 kann der SNR um gut 10dB zu erhöht werden. Vibrationen kriegt man mit dem Auswuchten der Propeller eigentlich relativ gut in den Griff.
Beitrag #5284303 wurde vom Autor gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.