Failsave-Pflicht!

    • Offizieller Beitrag

    Hier eine Ankündigung, die ich aus den Erfahrungen nach MMM3 mitteilen / zur Diskussion stellen möchte.

    Es hat sich bei einem Teilnehmenden Featherweight Bot mit Hochdruckpneumatik gezeigt, dass der eingebaute Failsave-Mechanismus nicht zuverlässig funktioniert hat. Der Erbauer der Maschine wurde sogar leicht verletzt (indirekt). Ich nenne deswegen keine Namen, weil es kein personenbezogenens Problem ist sondern eine aus dem Vorfall zu ziehende Konsequens ist.

    Eingesetzt war eine normale FM Fernbedienung (ohne PCM) mit einem externen Failsavemodul, welches in der Art von verschiedenen Firmen vertrieben wird (z.B. Robbe, Graupner, Conrad.....). Der Flipper löste aus, obwohl per Fernbedienung kein bewustes Signal dazu gegeben wurde. Die Fernbedienung war an! Es sind nun zwei Dinge denkbar, zum einem eine Fehlfunktion der Fernbedienung, die ein gültiges Signal ausgesendet hat und den Flipper ohne menschliches dazutun auslöste. Oder es hat eine externe Störung geben, die der Empfänger verarbeitet und weiter gegeben hat und nicht vom Failsavemodul als Fehler erkannt wurde. Da wir kein Log vom Scanner haben, ist es schwer den vorfall Funktechnisch aufzudröseln.

    Ich halte aber das verwendetet Failsavemodul für den Übeltäter (bitte hier mal den Failsavethread(s) durchlesen). Ich gedenke (solang ich dafür verantwortlich bin) keinen Roboter mit einer schnell auslösenden Waffe mehr in die Arena zu lassen, der nur über ein "Standart" Failsavemodul üblicher Hersteller abgesichert ist.

    Die nach meiner Auffassung aus sicherheitstechnischer Sicht derzeit allein möglichen Systeme wären:

    PCM Fernbedienungen
    MS Failsave Decoder
    Failsave Decoder von Bugs (DRG)
    Trifailsave Decoder vom Normen, insoweit durchgetestet.
    oder andere Systeme die eine "intelligente" Signalauswertung durchführen.

    Die meisten handelsüblichen Dekoder scheinen nur dann in den Failsavemodus zu schalten, wenn sie kein Signal mehr bekommen, aber nicht wenn sie kein "logisches" Signal (sprich Störung) bekommen. Ich gebe zu bedenken, das z.B. Magnetventile im millisekunden Bereich auslösen, da zuckt noch kein Servo. Ein Servo an ein solches Failsavemodul anzuschließen und damit zu testen, sagt also nichts darüber aus, ob das Modul sicher funktioniert oder nicht.

    Wer ein "handelsübliches" Modul verwenden will, muss mir hieb und stichfest nachweisen, ob eine intelligente Signalauswertung vorgenommen wird.

    Beim Techcheck mit dem o.g. Roboter funktionierte übrigens alles prima, aber nicht als es darauf ankam.

    Gruß Dirk

    • Offizieller Beitrag
    Zitat

    Original von bat_boy
    Hier eine Ankündigung, die ich aus den Erfahrungen nach MMM3 mitteilen / zur Diskussion stellen möchte.

    Ich glaube darüber muß nicht wirklich diskutiert werden,
    Sicherheit ist oberstes Gebot.
    Welche Systeme als Failsafe in Frage kommen ist natürlich Sache der Experten

    Dirk

    • Offizieller Beitrag

    tja... die sache mit den failsafes ist wirklich ein heisses eisen...
    wer hier öfter mitliest, erinnert sich wohl noch an meine postings zu dem thema... :engel:
    ich hoffe mal, dass jeder, der die fehlauslösung(en) gesehen hat nun versteht, warum ich da (auch und gerade für mich selber) so einen aufstand darum mache...
    mir ist es in den versuchsphasen öfter passiert, dass die waffe spontan ausgelöst hat... einige gründe (störungen, nicht entstörte motoren, main handy...) konnte ich finden, andere nicht...
    die erste lehre, die ich daraus gezogen habe ist:
    failsafe hin oder her,
    störungen und ein damit verbundenes auslösen der waffe lassen sich nie wirklich ausschliessen!!!!!!!!!!!

    die zweite lehre ist:
    ich halte meine waffe IMMER in einer stellung, in der ein versehentliches auslösen der waffe keinen schaden anrichtet... bei mir bedeutet das: der flipparm ist immer OBEN (und wird durch eine mechanische, fernauslösbare (leine) sicherung dort gehalten) wenn der RL gesteckt ist... wenn mein zylinder dann doch auslösen sollte, bewegt sich der fliparm nicht, es kann also wesentlich weniger passieren...
    nach dem kampf wird es etwas schwieriger, die waffe in eine 'sichere' position zu bringen... ich werde versuchen, den bot mit 'ausgefahrenem' fliparm und der an einer stange befestigten sicherung zu entschärfen, bevor ich den link ziehe... ob sich das bewährt, muss sich noch zeigen... :engel:
    jemand hält das für übertrieben??? ich jedenfalls nicht... ich weiss aus eigener erfahrung, dass man absolut keine möglichkeit hat, einer schnellauslösenden waffe (flipper, hammer, allgemein alles was pneumatisch betrieben oder über vorgespannte systeme betrieben wird) zu entgehen... die reaktionszeiten sind einfach zu gering...

    die dritte lehre:
    es gibt keine absolut sicheren failsafe module!!!
    jeder muss sich darüber im klaren sein, dass eine aktive waffe jederzeit auslösen kann, wenn der RL aktiv ist und auch, wenn der RL inaktiv ist, aber eine energiequelle für die waffe vorhanden ist!!!
    ein pneumatisches system ist erst nach dem deaktivieren des RL und NACH dem kompletten ablassen des druckes sicher!!!


    ich hoffe, nun wird auch klar, warum ich auf die peinliche einhaltung der motorentstörung gedrängt habe... es sind teilweise nicht nur die eigenen störungen, die eine waffenfehlauslösung verursachen können...!!! wenn einer der (drei) teilnehmer seinen bot aus der arena nehmen möchte, und ein anderer teilnehmer seinen bot schon mal in die nähe des ausgangs fährt kann der eventuell auch eine waffenauslösung bei dem bot verursachen, an dem gerade der RL gezogen werden soll...


    für die nächsten events (wenn es hoffentlich mehr 'aktive' waffen geben wird) sollten wir (der 'veranstalter') darüber nachdenken, wie wir die sicherheit besser gewährleisten können...

    -funktionierende failsafe module für aktive waffen vorschreiben (über den nachweis darüber und die erlaubten failsafe-module müssen wir noch reden!!!)

    -aktive waffen dürfen nur in gesicherter stellung IN die arena hineingestzt werden und mit gesicherter waffe AUS der arena herausgenommen werden (das herausnehmen dürfte hier das grösste problem werden)

    -aktive waffensysteme sollten ALS LETZTE aus der arena genommen werden (schliesst störungen durch die anderen teilnehmer weitgehend aus)

    -die IN der arana befindlichen bots sollten in die am weitesten vom ausgang entfernte ecke gefahren werden, BEVOR jemand in die nähe des zu 'entschärfenden' bots am ausgang geht (bei mehreren aktiven waffen in der arena)

    -jeder roboteer (NICHT der arenameister!!!) ist für das sichern und entschärfen seines bots selbst verantworlich, wenn er eine aktive waffe besitzt!!! der arenameister gibt anleitungen und übt kontrollfunktion aus, entschärft aktive waffen aber nicht selber!!! (hintergrund: der botbesitzer kennt (oder sollte kennen) selbst am besten die reihenfolge der entschärfung und die sicherste vorgehensweise!!!)


    soweit erstmal 'kurz' meine meinung dazu...
    lest bitte etwas zwischen den zeilen und macht euch ein paar gedanken zu der thematik...
    in zukunft werden wir mehr aktive waffen sehen und uns intensiver mit den sicherheitsaspekten auseinandesetzen müssen ... lieber etwas 'zu sicher' sein, als verletzungen riskieren... :engel:

    • Offizieller Beitrag

    Danke Jungs, dass ihr das Thema angeht und vor allem gleich die ganzen Tipps dazu kommen. Wenn man das so durchliest, ist eigentlich alles ganz logisch. Aber beim Tag X ist man wahrscheinlich einfach zu sehr in Hektik, um alle Gesichtspunkte automatisch zu berücksichtigen. Darum muss das irgendwie in Fleisch und Blut übergehen. (Ich weis, ich rede mich leicht....)

    Frage zu einer möglichen Störquelle:
    In meiner Elektronikpraxis hatte ich öfters schon das Problem, dass Mikrocontroller beim Einschalten irgendwas auslösen, bevor der Reset im Controller beendet ist und das Programm alle Portausgänge ordnungsgemäß initialisiert. Heißt: Die angeschlossene Peripherie hat für ein paar Millisekunden was getan, was ich eigentlich nicht wollte. Meistens ungefährlich. Wenn eine Kontrollleuchte mal kurz aufblitzt, dann macht das nichts. Aber die anderen Sachen, wo Power dahintersteckt, habe ich durch Hardware zusätzlich abgesichert. (Details für Insider: Ich nehme zwei Portausgänge her und hänge ein paar Logikgatter dahinter. Ein Portausgang muss logisch 1 und der andere logisch 0 sein. Dann erst gibt die Logik den Schaltausgang frei. Beim Initialisieren ist der Port entweder gemeinsam 1 oder gemeinsam 0. Aber niemals als Schachbrett geschaltet, somit kann nichts mehr passieren...)

    Jetzt wieder publik: Ich hab' das Maleur auch zufällig beobachtet. Kann es sein, dass der Flip-Up beim Einstecken/Freigeben der Spannungsversorgung ausgelöst hat? Also dass praktisch der Empfänger schon eher bereit war als der Fail-Save (oder umgekehrt)? Das wäre eine Erklärung.... darum hats beim Tech-Check wunderbar funktioniert und jetzt beim Einschalten mal für ein paar Millisekunden nicht....
    Wenn alle drei Komponenten an einer Spannungsversorgung dranhängen, dann sollte man es so machen, wie in der Bühnentechnik: zuerst die Mikrofone einschalten, dann das Mischpult, dann die Endstufe. Umgekehrt hat man den vollen Einschaltknacks des Mikrofons durch die Endstufe an die Lautsprecher weitergegeben.
    Auf unser Problem gemüntzt: Was haltet ihr davon, auch die anderen Komponenten zeitversetzt einzuschalten? Also praktisch erst mal den Empfänger hochlaufen lassen, dann Failsave, dann den Regler?

    Noch ein Aspekt: Mirist aufgefallen, dass mein Fahrtregler mit den "neuen" Robbe-Empfängern nicht funktioniert. Mit den alten Schinken schon. Liegt vielleicht daran, dass ich am Reglereingang einen Pull-Down-Widerstand gesetzt habe, der bei offenen Eingängen (oder Störungen) nicht irgendeinen Unsinn an die Endstufe weitergibt. Ich kombiniere mal, dass die käuflichen Regler nicht so niederohmig sind und deshalb empfindlicher für Störungen. (?) =Y das untersuche ich noch, vielleicht gibts eine technische Lösung zwischen Empfänger und Failsave.

    • Offizieller Beitrag

    Um ganz ehrlich zu sein weiß ich garnicht mehr wann der Flip bei der Aktivierung des Bots ausgelöst wurde.
    Ist aber auch wurscht, denn genausoschlimm war der Auslöser bei der Deaktivierung.
    Wenn ich mir die Videos so anschaue, dann war da noch mindestens ein Flip der nicht beabsichtigt war.

    • Offizieller Beitrag
    Zitat

    Frage zu einer möglichen Störquelle:
    In meiner Elektronikpraxis hatte ich öfters schon das Problem, dass Mikrocontroller beim Einschalten irgendwas auslösen, bevor der Reset im Controller beendet ist und das Programm alle Portausgänge ordnungsgemäß initialisiert. Heißt: Die angeschlossene Peripherie hat für ein paar Millisekunden was getan, was ich eigentlich nicht wollte. Meistens ungefährlich. Wenn eine Kontrollleuchte mal kurz aufblitzt, dann macht das nichts.

    Um das zu verhindern gibt es Erfindungen wie Power-On-Reset Controller...


    Zitat

    (Details für Insider: Ich nehme zwei Portausgänge her und hänge ein paar Logikgatter dahinter. Ein Portausgang muss logisch 1 und der andere logisch 0 sein. Dann erst gibt die Logik den Schaltausgang frei. Beim Initialisieren ist der Port entweder gemeinsam 1 oder gemeinsam 0. Aber niemals als Schachbrett geschaltet, somit kann nichts mehr passieren...)

    Und wozu nun der extra Hardware Umstand? Es gibt gescheite Controller mit eben besagten integrierten Power-On-Reset Controllern, sogar gleich zusammen mit Watchdog und Brown Out Wächtern. Ich hatte noch nie ein Problem beim Power Up, weder bei uCs von Atmel noch von Freescale...

    • Offizieller Beitrag

    Wir sollten auch die Verwendeten RC-Schalter nicht aus den Augen verlieren. Was die beim Einschalten und Ausschalten machen ist nicht sicher. Die Dinger sind im Modellbau für irgendwelche Spezieleffekte, wenn da bei ferngesteuerten Polizeiwagen beim anschalten mal kurz das Blaulicht angeht ist das egal.

    • Offizieller Beitrag
    Zitat

    Der Robotoer war aktiviert (Link gesteckt), als Dirk Druck auf das System gegeben hat. Kann also keine Störung durch das "Power-up" gewesen sein.


    Aha. Damit scheidet meine o.g. Theorie von verschiedenen Anlaufzeiten der Komponenten aus.
    => weiter suchen.

    • Offizieller Beitrag
    Zitat

    Mirist aufgefallen, dass mein Fahrtregler mit den "neuen" Robbe-Empfängern nicht funktioniert. Mit den alten Schinken schon. Liegt vielleicht daran, dass ich am Reglereingang einen Pull-Down-Widerstand gesetzt habe, der bei offenen Eingängen (oder Störungen) nicht irgendeinen Unsinn an die Endstufe weitergibt. Ich kombiniere mal, dass die käuflichen Regler nicht so niederohmig sind und deshalb empfindlicher für Störungen.

    manche empfänger sind etwas "schwach" in ihren ausgangssignalen... musste ich auch schon feststellen...
    schau dir mit dem oszilloskop die empfängersignale an... dann siehst du, ob der signalpegel ausreichend ist...
    die schaltschwelle deiner eingänge kennst du (datenblatt :engel: ), das ausgangssignal des empfängers kannst du messen...

    ich sags nochmal:
    manche empfänger geben keine 5V-signale ab, sondern nur 3-3,5V (rex, pico) bei einer 6V-versorgung (z.b. pro-regler mit 6V-BEC) der regler passt das teilweise nicht zusammen (für die insider: 'störabstand' ist das zauberwort... =) )

    Zitat

    Wir sollten auch die Verwendeten RC-Schalter nicht aus den Augen verlieren.

    wohl wahr!!! das ein/ausschaltverhalten ist leider recht 'undefiniert'...


    noch mal eine generelle anmerkung:
    die verwendung eines failsafe-moduls sollte einen nicht in falscher sicherheit wiegen... gerade der 'normale' benutzer sollte sich darüber im klaren sein, dass es NICHT ausreicht, einfach ein failsafe-modul einzubauen und 'alles ist gut'... jeder sollte sich etwas mit der materie beschäftigen und versuchen zu verstehen, wie die komponenten funktionieren... nur dann kann man abschätzen, ob und wie 'sicher' die jeweilige anordnung ist...

    Zitat

    Auf unser Problem gemüntzt: Was haltet ihr davon, auch die anderen Komponenten zeitversetzt einzuschalten? Also praktisch erst mal den Empfänger hochlaufen lassen, dann Failsave, dann den Regler?

    erst der failsafe, dann der elektronische schalter, dann der empfänger (ist auch nicht immer sicher, kommt wirklich auf die verwendeten einzelkomponenten an)... der regler ist erstmal egal... man kann den bot immer etwas hochbocken, um die räder beim einschalten vom boden zu haben... der antrieb ist die ungefährlichste stelle bei der ganzen angelegenheit... :-O

    • Offizieller Beitrag
    Zitat

    die verwendung eines failsafe-moduls sollte einen nicht in falscher sicherheit wiegen... gerade der 'normale' benutzer sollte sich darüber im klaren sein, dass es NICHT ausreicht, einfach ein failsafe-modul einzubauen und 'alles ist gut'... jeder sollte sich etwas mit der materie beschäftigen und versuchen zu verstehen, wie die komponenten funktionieren...


    ohne Irgendjemandem zu nahe treten zu wollen, befürchte ich, dass da hin zu kommen recht schwierig wird. Wir brauchen ein für unsere Zwecke optimiertes und getestets Failsave-Modul, am besten mit integriertem RC-Schalter. Ich hab ja sowas schonmal probiert, das Teil braucht aber noch deutliche Verbesserungen.

    • Offizieller Beitrag
    Zitat

    Ich hab ja sowas schonmal probiert, das Teil braucht aber noch deutliche Verbesserungen.


    Ups... Normen: ich dachte, das dreikanalige Failsave-Modul von Dir wäre fertig und serienreif?
    (Nur aus Neugierde: woran scheiterts?)
    Wenn Flatliner es schafft, den Fehler zu reproduzieren, dann hätte ich gehofft, dass mit diesem Modul ein Präsidenzfall für die erfolgreiche Abhilfe von Fehlauslösungen geschaffen wird. :engel:

    Ich bohre mal bei dem Problem weiter:
    - Das ganze System stand schon unter elektrischer Power
    - Die CO2-Pulle wurde aufgedreht und dann kam die Auslösung.
    ??? Kann es sein, dass das Ventil durch den kontinuierlich steigenden Druck eine "Zwischenstellung" eingenommen hat und deshalb mal etwas durchgepfiffen hat ???
    (Ich weis, dass viele Ideen u.U. Blödsinn sein können, aber vielleicht ist doch mal irgendwas wahres dran, das uns auf eine weitere Spur bringt.)

    • Offizieller Beitrag
    Zitat

    Original von IBF
    - Die CO2-Pulle wurde aufgedreht und dann kam die Auslösung.
    ??? Kann es sein, dass das Ventil durch den kontinuierlich steigenden Druck eine "Zwischenstellung" eingenommen hat und deshalb mal etwas durchgepfiffen hat ???

    Da hat nichts durchgepfiffen, das war nahezu voller Flaschendruck.
    Wie ich die Fehlauslösung reproduzieren soll ist mir ein Rätsel, bei allen Versuchen vor dem Event ist das nicht vorgekommen.
    Verwendet wurde auch kein RC-Switch sondern eine Kombination aus Servo und Microschalter.
    Der Microschalter ist auch nicht so sensibel daß er durch Erschütterungen ansprechen würde.

    Wie wird das Ausgangssignal des Empfängers gemessen? zwischen GND und Signalleitung bei vollem Knüppelausschlag?
    Läßt sich da was mit einem einfachen Multimeter messen ?

    • Offizieller Beitrag

    Zu Messtechnik kann ich nichts sagen, nur ein Punkt der mir am MS Failsavedekoder gefällt (keine Sorge ich bin nicht an der Vermarktung des Decoders beteiligt)

    Der Decoder hat eine zusätzliche Referenzleitung, sprich es kann ein nicht benutzter Kanal des Empfängers mit abgefragt werden um Störungen zu erkennen. Wenn dieser Kanal nach der Aktivierung der gesamten Fernsteuerung betägtigt würde (oder ein unlogisches Signal abgibt) dann geht ebenso der Decoder in Failsave. Mann kann diesen Kanal also gezielt dazu verwenden die Waffe in "Failsave" zu stellen oder "Scharf" zu machen. Das heißt man könnte nach der Aktivierung des bots die Arena schließen und dann erst die Waffe freigeben. Das Failsavemodul von Bugs (DRG) kann das wohl auch (bin mir jetzt aber nicht mehr ganz sicher, Leo hat mir das Modul kurz erklärt). Durch die freischaltung durch den Referenzkanal erhöht sich aus meiner Sicht die Sicherheit erheblich. Dieses verhindert natürlich nicht eine fehlfunktion des RC-Switches .

    Gruß Dirk

    • Offizieller Beitrag
    Zitat

    Wie wird das Ausgangssignal des Empfängers gemessen? zwischen GND und Signalleitung bei vollem Knüppelausschlag?


    Im Prinzip zwischen dem "Hot" Ausgangssignal des Empfängers und GND. ABER: Es handelt sich nur um kurze Pulse zwischen 1ms und 2ms, dann ist Pause bis zu 20ms. Dann kommt der Puls erst wieder. Das heißt, dass das Multimeter keine richtige kontinuierliche Gleichspannung kriegt. Es wird irgendeinen Käse anzeigen. (Schätzungsweise um die 0.5V).
    Wenn der Knüppel in Nullstellung ist, dann sollte das Signal eine Länge von 1.5ms haben. Wenn der Knüppel nach unten gezogen wird, sinkt die Pulsweite auf 1ms. Wird der Knüppel nach oben gelegt, dann steigt sie auf 2ms.
    Auch wenn am Multimeter Käse angezeigt wird, durch das Bewegen am Knüppel müßte sich dieser Wert ebenfalls ändern.

    Zur Anzeige bzw. Messung des Ausgangssignals verwendet man ein Oszilloskop. Damit kriegst Du sowohl die Pulsweiten-Änderung raus (ich hatte anfangs eine Fernsteuerung, die konnte nur 1.2ms bis 1.8ms => kein Vollgas beim Rapi möglich), also auch die Höhe des Ausgangssignals.

    @All Electronics: Es hat mal irgendwo eine Schaltung und entsprechende Software gegeben, da konnte man den PC als Oszilloskop mißbrauchen. Das wäre doch was für unsere Truppe, nachdem das Vermessen von Empfängern bei mehr Leuten anstehen dürfte?

    • Offizieller Beitrag
    Zitat

    @All Electronics: Es hat mal irgendwo eine Schaltung und entsprechende Software gegeben, da konnte man den PC als Oszilloskop mißbrauchen. Das wäre doch was für unsere Truppe, nachdem das Vermessen von Empfängern bei mehr Leuten anstehen dürfte?

    Da sind andere schon seit Jahren dran un haben immer noch nix brauchbares...

    Was du meinst könnte das Oszi mit dem Mic Eingang der Soundkarte sein...

    • Offizieller Beitrag
    Zitat

    Was du meinst könnte das Oszi mit dem Mic Eingang der Soundkarte sein...


    Hm...ja... könnte sein, ich erinnere mich nicht mehr genau. Oder wurde der Eingang von den Spiel-Padels (Joystick-Eingang) benutzt.... ?

    Um mal wieder den Gedanken freien Lauf zu lassen: Ich habe mal ein Geräte entwickelt, um die Prellzeiten von Relais herauszumessen. Automatisiert, also auch von Siemens-Messdamen in der Hausfrauenschicht zu bedienen. Wäre in der Gemeinde Interesse und Bedarf an einem kleinen Gerät, um den Fernsteuer-Empfänger zu vermessen? Ich würde dabei nur auf die übliche Pulsweite der Empfänger losgehen und die gelieferte Spannung anzeigen. (Danke Heiko für den Hinweis auf die Low-Voltage-Empfänger). Ankopplung über RS232.
    Wenn mehrere Leute Interesse haben, würde ich so eine Schaltung mit zugehöriger PC-Software stricken. Für mich selbst ist das uninteressant, da ich ja ein Oszi mein Eigen nenne.... =)

    • Offizieller Beitrag
    Zitat

    Ups... Normen: ich dachte, das dreikanalige Failsave-Modul von Dir wäre fertig und serienreif?


    Prinzipiell funktionierts, die Abtastrate war nur zu gering, so dass es zu Ungenauigkeiten kommt, die z.B. dafür sorgten, dass im Failsave-Fall Konters Räder nicht komplett standen, sondern ganz langsam in eine Richtung liefen.
    Sollte mit etwas größerem µC und mehr Takt (20MHz) in den Griff zu kriegen sein.
    Ich hab aber auch noch ne Idee für ne bessere Fehlererkennung im Kopf.

    Zitat


    Der Decoder hat eine zusätzliche Referenzleitung, sprich es kann ein nicht benutzter Kanal des Empfängers mit abgefragt werden um Störungen zu erkennen.


    Genau, darum hatte mein Modul ja alle drei Kanäle betrachtet und auch nur alle freigeschaltet wenn alle OK waren.