Hallo, ich habe heute beim Testen meiner Flugsteuerung für ein Quadrocopter das Problem gehabt, dass sich das Programm aufgehangen hat. Demzufolge konnte ich die Timer-Ausgänge mit den PWM-Signalen für die Motoren nicht mehr beeinflussen. Die Motoren liefen also (glücklicherweise ohne Propeller) und ich konnte nichts anderes tun, außer den Stecker ziehen. Meine Frage ist nun, wie solche Fälle bei kommerziellen Flugsteuerungen gehandhabt werden. Also wie wird in einem solchen undefinierter Zustand vorgegangen? Ich hatte darüber nachgedacht mit einem Watchdog Timer zu arbeiten. Die Zeitdauer für ein Intervall der Main-Loop ist ja bekannt. Wird diese Zeit überschritten kann man davon ausgehen, dass sich das Programm in einem undefinierten Zustand befindet und der Mikrocontroller wird neu gestartet. Was haltet ihr davon? Vielleicht gibt es ja Leute die selbst schon eine Flugsteuerung entwickelt haben und vor dem gleichen Problem standen.
Ein Watchdogreset ist da ungünstig. Alle PWMs gehen aus und das Ding stürzt wie ein Stein zu Boden. Sinnvoll ist eine Aufteilung auf mehrere MCs, wo einer nur für den Flug zuständig ist. Und dessen Programm sollte entsprechend sorgfältig entwickelt werden, daß es sich nicht aufhängen kann.
Servus, redundante Systeme können zwar Leben retten, aber hier bedeutet es: Mehrgewicht, Mehrverbrauch usw. Man könnte vor den Restart wichtige Daten ins eeprom schreiben und wieder laden. Meistens dauern Initialisierungsroutinen etwas Zeit, da z.B Konstanten für PID berechnet werden usw. Mit eeprom könnte man diese Routine etwas schneller machen indem alles im eeprom gespeichert ist. Dann könnte man durch praktische Versuche die Latenz mal bestimmen. Wie groß die Erdbeschleunigung ist, weißt doch jeder, damit kann man berechnen wie Tief der Brunnen ist. mfg
Peter D. schrieb: > Ein Watchdogreset ist da ungünstig. Alle PWMs gehen aus und das Ding > stürzt wie ein Stein zu Boden. Nach Neustart muß nur sehr schnell der reset Grund ausgewertet und ein sicherer Zustand wieder hergestellt werden. Peter D. schrieb: > Und dessen Programm sollte entsprechend sorgfältig > entwickelt werden, daß es sich nicht aufhängen kann. Technisch unmöglich. Durch die großen Störungen einer leistungsstarken (Motor) Stufe können direkt bits kippen. Bei einem von mir gebauten EVG sieht man den Neustart nur als kurzes Flackern der Leuchten. Ein Copter würde auch nur kurz zucken. Das Verteilen auf mehrere MCUs vergrößert das Problem. Statistisch vervielfachen sich die Fehlerquellen und wenn ein einzelner Motor ausfällt schmiert die Kiste auch ab. aSma>> schrieb: > Man könnte vor den Restart wichtige Daten ins eeprom schreiben Das RAM wird durch Reset doch nicht gelöscht. Mit ein wenig Gehirnschmalz ist man nach Watchdogreset extrem schnell wieder funktionsfähig.
Michael K. schrieb: > Das Verteilen auf mehrere MCUs vergrößert das Problem. > Statistisch vervielfachen sich die Fehlerquellen und wenn ein einzelner > Motor ausfällt schmiert die Kiste auch ab. Man macht es bei guten Geräten trotzdem so - und genau so ist es in der Luftfahrtindustrie auch gefordert. Redundanz ist halt alles. Konkret wird beim Systemstart ein unabhängiger uC mit eigener Spannungsversorgung hochgefahren, evtl. noch galvanisch getrennt und manchmal sogar mit eigener Sensorik. Der Hauptprozessor gibt nach jedem Schleifendurchlauf ein "alive"-Signal + aktuelle Daten. Bleibt das Signal aus oder sind die Daten nicht plausibel, übernimmt der zweite Prozessor sofort. Vorteil: Kalibration und alle Werte laufen normal weiter, d.h. auch die Filter müssen sich nicht erneut einschwingen.
Dennis schrieb: > Konkret wird beim Systemstart ein unabhängiger uC mit eigener > Spannungsversorgung hochgefahren, evtl. noch galvanisch getrennt und > manchmal sogar mit eigener Sensorik. Der Hauptprozessor gibt nach jedem > Schleifendurchlauf ein "alive"-Signal + aktuelle Daten. Bleibt das > Signal aus oder sind die Daten nicht plausibel, übernimmt der zweite > Prozessor sofort. Humbug. Mit 2 Einheiten geht das nicht. Woher weiß die eine CPU dass die Werte falsch sind? Vielleicht denkt sie das nur weil sie selber defekt ist? Also würde die defekte CPU die Kontrolle übernehmen und die korrekt arbeitende ablösen. Wenn dann gibt es 3 redundante Einheiten und das ganze läuft per Voting.
Michael K. schrieb: > Peter D. schrieb: >> Und dessen Programm sollte entsprechend sorgfältig >> entwickelt werden, daß es sich nicht aufhängen kann. > > Technisch unmöglich. > Durch die großen Störungen einer leistungsstarken (Motor) Stufe können > direkt bits kippen. Dann muss eben nicht nur die Software besonders sorgfältig entwickelt werden sondern ebenso auch die Hardware! Problem gelöst! Und was war daran jetzt "technisch unmöglich"?
Bernd K. schrieb: > Dann muss eben nicht nur die Software besonders sorgfältig entwickelt > werden sondern ebenso auch die Hardware! Problem gelöst! Und was war > daran jetzt "technisch unmöglich"? Korrekt! Wenn durch Störungen Bits kippen, dann hat man einfach bei der Schaltung oder dem Layout mächtig geschlampt.
aSma>> schrieb: > redundante Systeme können zwar Leben retten, aber hier bedeutet es: > Mehrgewicht, Mehrverbrauch usw. Weder das Mehrgewicht von vielleicht 5 Gramm, noch der Stromverbrauch eines µC im Vergleich zu den Motoren, dürften da kriegsentscheidend sein. Stell mal eine Liste deiner Energieverbräuche auf.
Bernd K. schrieb: > Dann muss eben nicht nur die Software besonders sorgfältig entwickelt > werden sondern ebenso auch die Hardware! Problem gelöst! Und was war > daran jetzt "technisch unmöglich"? Techisch unmöglich ist es eine Fehlerwahrscheinlichkeit von 0,00% zu bekommen. Es gibt eine theoretische Wahrscheinlichkeit von x% das ein Bit kippt. Je wärmer, schneller, gestörter um so wahrscheinlicher. Selbst wenn die Software zu 100% fehlerfrei ist, und glaub mir das mit Testfällen und Review zu beweisen ist der Horror, stürzt eine Software auch ab wenn einfach die Grenzen der Halbleiterphysik bits kippen lassen. Die MCU muß und kann auch mit dem Watchdog Reset Fall umgehen. Die Ansage 'Dann einfach keine Fehler machen und zulassen' hört sich fantastisch an ist aber unrealistisch. Es gibt Fehler die man nicht mehr abfangen kann aber ein Watchdog Reset gehört da definitiv nicht zu. Redundanz mit mindestens drei Entscheidungsinstanzen ist natürlich toll und bei Steuerungen mit möglichem Personenschaden auch angeraten, aber für einen Copter ein wenig hoch gegriffen. Dennis schrieb: > Man macht es bei guten Geräten trotzdem so - und genau so ist es in der > Luftfahrtindustrie auch gefordert. Redundanz ist halt alles. Was in der Luftfahrt gefordert ist und was nicht weiß ich ganz gut. Wir reden hier aber nicht über die fly by wire Steuerung eines Verkehrfliegers mit 400 Seelen an Bord über dicht besiedeltem Gebiet sondert immer noch über einen Quadcopter. Das 'tolle' an ausufernden Schaltungen ist übrigens das mit jedem zusätzlichen Bauteil die Ausfallwahrscheinlichkeit steigt. Mach mal eine MTBF Berechnung nach MIL mit Bewertung der Fehlerfälle. Ein großer Spaß für die ganze Familie.
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.