Ist ein Arduino als Servo-Signalverteiler betriebssicher?

ta-uli

User
Hallo zusammen,

Ich habe mit einem Arduino Nano das SUMD-Signal eines Empfängers (Hott GR-12L von Graupner) aufbereitet,
und an die Servos im Flugmodell weitergeleitet.
Damit hat der Arduino in etwa die Funktion eines Flightcontrollers, wenn auch mit weniger Funktionalität.
Leider hab ich keine Erfahrung mit der Betriebssicherheit eines Arduino im Flugmodell.
Gibt es eurerseits derartige Erfahrungen, ob damit das Modell wieder sicher gelandet werden kann, oder
sollte man es sein lassen, weil das Ausfallrisiko zu groß ist.

Der Arduino wird natürlich mit den üblichen Mitteln (Kondensatoren, Abschirmung,...) von Störungen elektrischer Art ferngehalten.

Bei der Recherche sind mit dem Arduino meistens Beleuchtungsanwendungen erstellt worden, die aber nicht lebensnotwendig für ein Flugmodell sind, daher sind Infos zur Betriebssicherheit nicht so aufgefallen.
Bei den Koptern bin ich mir auch nicht so sicher, ob dort Arduinos in der direkten Steuerung wichtige Rollen spielen.

Daher nochmal die Bitte um Infos bzw. Tips zur Verlässlichkeit.

Danke
Uli
 

Sepp62

User
Generell kannst Du die Betriebssicherheit eine Mikroprozessor-Systems durch folgende Maßnahmen erhöhen:

1. Programmierung
a) Ordentliche Fehlerbehandlung, damit der Prozessor nicht "abstürzt" (Pointer-Fehler, Division by Zero, etc.)
b) So weit wie möglich Verzicht auf "asynchrone Programmierung" (Interrupts). Stattdessen "Mainloop" (wie sie beim Arduino üblich ist) und synchrone Ausführung aller Funktionen. Vermeiden von "blockierenden Routinen". Hier gibt es ein hohes Risiko, wenn I2C-Hardware über die Arduino Standard-I2C-Libraries angebunden ist. Fällt die I2C-Busverbindung oder das Bus-Gerät aus, steht die Main-Loop und das war's dann mit dem Programm.
Ansonsten siehe auch 5.

2. Stromversorgung
Das ist ein Thema für sich. Hier entstehen, neben Programmierfehlern, die meisten Probleme.

3. "EMV" (bei Dir Abschirmung genannt)
Wenn man nicht krasse Fehler macht und gewisse Sicherheitsabstände zu anderen Systemen einhält, passiert hier nach meiner Erfahrung eigentlich nichts. Ich hatte hier noch niemals ein Problem. Natürlich hängt dieser Punkt auch mit der Stromversorgung zusammen.

4. Schutz der Ports vor Überspannung/Transienten
Schließt man seinen Prozessor an andere Systeme an, die den zulässigen Eingangsspanungsbereich des Prozessorsystems überschreiten, hat man schnell ein Problem. Schutzschaltungen. Level-Shifter und ggf. galvanische Trennung helfen dagegen.

5. Nutzen von Hardware-Sicherheitsmechanismen des Prozessors
Hier sind zu erwähnen:
- Brown-Out-Detection und
- Watchdog
Diese Mechanismen sind nicht bei allen Arduino-Prozessoren verfügbar. Wenn die Hardware sie hergibt, ist die Aktivierung teilweise recht kompliziert (Stichwort "Fuses").
Gute "Produkte" verwenden diese Mechanismen. Sie sind eine sehr gute Versicherung für ein bereits gut designtes System (Punkte 1-4).

Es ist also weniger die Plattform "Arduino", die die Betriebssicherheit bestimmt, sondern die Ausführung Deines Gesamtsystems.

Das ist nun alles sehr theoretisch und am Ende hängt es von Deinem Sicherheitsempfinden ab, ob Du mit Deiner Lösung fliegen willst.

Wenn ich von mir ausgehe: Ich habe in einigen großen Modellen Arduinos verbaut. Die Programme habe ich größtenteils selbst erstellt, auch die verwendeten Libraries kenne ich meist recht genau.

Keiner dieser Arduinos übernimmt Funktionen, die bei Fehlfunktion zum Absturz führen würden.

In leichten Schaummodellen würde ich mich das allerdings schon trauen, wenn ich wüsste, dass das Programm (gemäß Punkt 1) stabil läuft...

VG Bernd
 

ta-uli

User
Danke Bernd für die Infos.
So ähnlich dachte ich es mir schon...
Dann werd ich mal mit einer Schaumwaffel das Seitenruder versuchsweise über den Arduino steuern, und Paketverluste und erkennbare Fehler mitprotokollieren.
Mal sehen, ob das Vertrauen wächst... ;)

Uli
 

Ay3.14

User
Hallo Uli,

ich habe auch nur positive Erfahrungen damit gemacht und den vielen guten Tipps vom Bernd ist nichts hinzuzufügen. :)

Das Testen mit einer leichten Schaumwaffel kann ich nur empfehlen, da mit Programmierfehlern stets zu "rechnen" ist. Eine stabile "fail-safe" Logik ist sehr wichtig, spätestens dann wenn dein Arduino Steuerfunktionen anhand von Sensoren übernimmt.

Viel Spaß und Erfolg damit.

Holm- und Rippenbruch
Albert
 
Den Hinweisen von Bernd kann ich nur beipflichten, danke @Sepp62 für diese gute Zusammenfassung.

Keiner dieser Arduinos übernimmt Funktionen, die bei Fehlfunktion zum Absturz führen würden.
Handhabe ich in meinen Fliegern genau so. Ich lesen den Futaba SBUS2 aus und steuere damit nur Licht, Sound, Fahrwerk und lese/schreibe Sensorwerte. Die komplette Flugsteuerung besteht aus originalen Rx/Servos. Timing und Logic Fehler beim SBUS2 Telemetrie schreiben habe ich simuliert: der Empfänger R7008SB versorgt alle Servos und den SBUS in solchen Fällen normal weiter. Andere Rx verwende ich nicht bzw. würde sie vorher auch testen.

Anmerkung zu Bernds 1b): Meine SBUS2 Lib lief erst stabil, nach dem ich das Lesen nicht mehr im Mainloop durchführe, sondern in den dafür schon vorhandenen Interrupt Routinen verschoben haben. Damit will ich die Aussage nicht aufweichen sondern nur unterstreichen, dass man in solchen Fällen genau wissen sollte, warum und wieso man sich für Interrupts entscheidet.

Zu Bernds 5): Mein Atmel SAM D21 hat laut Datenblatt beide Hardware-Sicherheitsmechanismen, danke für den Impuls von dir, mich damit mal zu beschäftigen.

Was ich noch anfügen möchte: Fehlerbehandlungen vertraue ich erst, wenn sie auch mal einen Fehler behandelt haben ;). Das wird normalerweise auf HIL Prüfständen gemacht aber auch ohne kann man einiges simulieren
  • I/O Signale mal auf GND oder + ziehen (hier sollte man wissen was man macht, nicht das die HW raucht)
  • Buskabel/SD Karte/Sensoren mal ab und wieder an stecken
  • einen Fehler bewusst einprogrammieren - zum Auslösen habe ich auf meinen Board einen Testpin
  • einen SelfTest einprogrammieren, hat sich aber bei mir nicht 100% bewährt
Was dabei hilft, ist sich vorher ein Testplan zu erstellen, dann hat mein beim Testen den Kopf frei für das "wie teste ich das?".
Und ja, Fehlerbahandlungen und Testen ist unsexy und kostet oft mehr Zeit als das Programmieren, da muss man durch.

Grüße Rony
 
Ansicht hell / dunkel umschalten
Oben Unten