Motor richtig entstören

moinsen

störungen im stand und bei laufenden motoren sind zwei unterschiedliche paar schuhe...

1. die kondensatoren bzw jede entstörmaßnahme an den motoren wirkt nur, wenn die motoren DREHEN!!!
sinn der sache ist die unterdrückung der durch die funken am kollektor des motors entstehenden störimpulse... und das weniger, um die anderen bots nicht zu stören, sondern eher aus gründen des selbstschutzes... die störungen wirken sich nämlich weit mehr auf den eigenen empfänger aus als auf die 'nachbarn', da sich die eigene empfangs-antennne wesentlich! näher an der störquelle (motor) befindet als die des gegners...
die motoren sollten GRUNDSÄTZLICH entstört werden...
...ansonsten bezahlt man die einsparung mit verringerter reichweite (die antennenkonstruktionen sind bei den meisten bots sowieso schon nicht optimal für grosse reichweiten) und teilweise völlig unkontrolliertem fahrverhalten... =)

2. wenn die motoren im stand 'zucken' kann das mehrere gründe haben:
(das hat aber als ursache erstmal nichts mit der entstörung der motoren zu tun!!! allerdings zuckt ein nicht entstörter motor mehr, denn wenn der motor kurz anläuft, produziert er wieder störungen, die das zucken noch verstärken)

- die 'totzone' (wenn der regler eine hat) ist zu gering
(die totzone ist der kleine bereich um den nullpunkt des steuerknüppels, in dem der regler garnicht auf den knüppelausschlag reagiert... normalerweise 1-5% des knüppelweges... wie gesagt, wenn überhaupt vorhanden...)

- die federrückstellung des steuerknüppels funktioniert bei manchen anlagen um den nullpunkt herum nicht richtig... die rückstellung wirkt erst, wenn der knüppel aus der nullstellung heraus bewegt wird... man kann den knüppel dann fast 1mm ohne gegenkraft vor und zurück bewegen... sollte bei neueren fernsteuerungen (auch bei billigen) eigentlich nicht mehr auftreten...

- es kann störquellen in der umgebung geben, (handy, DECT-telefone oder andere starke sender, die den empfang stören... (die müssen allerdings recht nah am empfänger liegen...)

- die empfangs-antenne ist zu kurz, berührt das gehäuse (natürlich nicht mit der isolierung, sondern mit dem innenliegenden kupfer...) --> extrem verringerte reichweite, höhere störanfälligkeit

- ein grossteil des antennenkabels liegt direkt auf einer metallfläche (strecke im bot vom empfänger zur aussenantenne)--> extrem verringerte reichweite, höhere störanfälligkeit

- elektrische verbraucher verursachen störungen auf dem empfänger-spannung... (das können auch servos sein!!!)

- der BEC-regler hat nen schlag weg und die spannung bricht ein... oder er wird durch angeschlossene geräte überlastet...

- die batteriespannung ist zu niedrig... manche regler schalten dann kurzzeitig ab... das tritt aber eher beim fahren auf, (wenn durch den stromfluss in den motoren die batteriespannung zusammenbricht) und macht sich dur starkes 'ruckeln' bemerkbar...

das sind nur einige mögliche ursachen für störungen...
meiner erfahrung nach sind die meisten störungen auf eine schlechte verlegung und/oder eine unzureichende länge der antenne zurückzuführen... :engel:

tja ist keine einfache frage, wir müssen zwischen den GRA-Regeln und dem Techcheck am Event unterscheiden. Die Regeln sind eindeutig, ein failsave muss für jede potentiell gefährliche aktive Komponente des Raptors vorhanden sein und zur zufriedenheit des Eventveranstalters funktionieren.

Von jedem Teilnehmer wird erwartet, dass er sich an die Regeln hält und eine Regelgerechte Konstruktion vorgenommen hat.

Beim techcheck werde ich aber nicht die Bedinungsanleitungen der einzelnen verbauten Komponenten durchlesen oder kontrolieren. Es wird eine Sicht- und Funktionsprüfung geben (motoren voll vorwärts / rückwärts stellen und dann fernsteuerung aus - motoren müssen in den Failsave d.h. stillstand kommen) und wenn diese bestanden ist, so ist der Raptor (bezogen auf diesem Punkt) zum Event zugelassen. Wenn sich aber während des events zeigt, dass das diese Sicherheitsfunktion nicht zuverlässig funktioniert biste drausen.

bei starken Zweifeln ob hier eine regelgerechte konstruktion vorliegt, wird zwar besonders genau hingesehen, aber wenn der techcheck bestanden wird, müssen schon sehr gravierende Zweifel vorliegen um einen teilnehmer auszuschließen.

Der Failsave dient in erster Sicherheit der Crew, die die Raptoren in der Arena handhaben müssen. Insgesamt muss natürlich gesagt werden, das mit dem Ansprechen der Failsavefuntion der roboter nicht sicher ist, sondern nur das schlimmste verhindert wird. Ein roboter in failsave ist eigentlich der unsicherste zustand den ein roboter haben sollte. Es ist der letzte notanker.

Ich gebe hier aber schon mal zu protokoll, dass ich einem Raptor bei dem erhebliche zweifel hinsichtlich der failsave funktion vorliegen sehr sehr genau prüfen werde. Unter Umständen kann dieser Raptor nur unter Auflagen an den start gehen.

Gruß Dirk

Gruß Dirk

hm... failsafe ist doch immer wieder ein lustiges thema... =)

mal überlegen... der regler verarbeitet das PWM-signal der fernsteuerung (also die pulsbreite)
um daraus die information für die aussteuerung der endstufe zu generieren...
die PWM-high-phase liegt im bereich von 1ms('voll zurück') - 2ms('voll vorwärts'), in nullstellung bei 1.5ms...
jeder halbwegs vernünftige regler (mit microprozessor drin) blendet PWM-signale <1ms und >2ms aus...
(dummerweise kann man das aber für seinen regler nicht genau sagen, ohne einen blick in die software des reglers geworfen zu haben...
also im normalfall bei gekauften reglern aussichtslos... =) )

was passiert also, wenn man den sender ausschaltet?
der empfänger gibt bei ausbleiben des sendersignals (von störimpulsen die NICHT vom sender kommen!!!abgesehen) keine PWM aus...
das signal (in dem fall ist ausser den störungen eben kein signal vorhanden) liegt ausserhalb des gültigen bereichs (>1ms, <2ms)...
der regler steuert die endstufen nicht aus... (glücklicherweise ist genau das für einen regler die 'sichere' stellung)
wenn allerdings ein störimpuls vom empfänger als gültiges signal erkannt wird, wird der regler dieses an die endstufen weitergeben...
und der motor läuft an...
das ganze ist natürlich wieder von der art und dauer der störimpulse und der verarbeitung durch den empfänger abhängig...

überlegen wir mal weiter:
woher kommt der failsave eigentlich? ich mutmaße jetzt mal, von den flugmodellbauern, die bei einem ausbleiben des sendesignals keine
bruchlandung im sturzflug machen wollen (anders als wir roboteers lieben die ihre modelle und wollen beschädigungen vermeiden...)
wünschenswert ist für ein flugmodell also ein automatischer, langsamer sinkflug...
es werden dort failsafes verwendet, die bei ausfall des sendesignals einen einstellbaren steuerimpuls generieren und an regler oder servos weitergeben...
diese steuerimpulse sind aber im normalfall nicht gleich der steuerknüppel-nullstellung (dann würde das modell einfach mit gleicher geschwindigkeit und
in gleicher richtung weiterfliegen... also werden steuerimpulse eingestellt, die zb den motor drosseln, bremsklappen ausfahren, das höhenruder auf leichten
sinkflug stellen und eventuell für einen leichten kurvenflug des modells sorgen, damit es nicht bis nach kleinasien segelt...

die bekannten nachrüstmodule zb von conrad arbeiten genau auf diese weise...

nun kann man natürlich sagen:
ein failsafe ist irgendwas, dass bei ausbleiben des sendesignals die angeschlossenen 'geräte' in eine sichere stellung fährt.'
eine durchaus sinnige forderung, die dann allerdings auch von reglern ohne wirklichen failsafe
(die also beim versuch 'bei-vollgas-sender-ausschalten' nicht weiterlaufen) erfüllt wird...

der für unsere anwendung eigentlich wünschenswerte nebeneffekt von störsignalunterdrückung und auswertung des empfangssignals auf gültigkeit
wird allerdings von keinem der module erfüllt...
gut, die failsave module blenden extrem kurze störimpulse aus... aber eben keine längeren... bei der motorsteuerung ist das eventuell noch tragbar...
es ruckelt etwas, aber der bot wird durch kurze störimpulse nicht sehr weit fahren...
anders sieht die geschichte bei einer aktiven waffe aus... einem pneumatikventil reichen kurze impulse, um eine waffe
(fliparm, axt, usw) auszulösen...

also bräuchte man eigentlich einen failsave, der nicht nur ein ausbleiben des sendesignals erkennt, sondern auch das empfangene signal auf gültigkeit
überprüft... das einzige, was das meiner meinung nach einigermaßen sicherstellt, ist ein PCM-empfänger mit eingebautem failsave oder ein selbstgebauter
regler (oder eine steuerplatine), die eine vernünftige filterung der signale vom empfänger vornimmt ... viel spass beim bauen
fakt ist: es ist einfach ein höllenaufwand, gültige signale von störungen zu trennen... also werden wir wohl mit dem leben müssen, was auf dem
markt erhältlich ist...
ausserdem sollten wir trotz aller failsaves eine gesunde vorsichtigkeit, sorgfalt und vor allem einen gewissen respekt vor unseren 'waffen'
an den tag legen... denn eigentlich ist keine unserer maschinen gegen absolut jede fehlfunktion gesichert...

Zustimmung. Nur als Ergänzung möchte ich kurz die Funktion unserer Waffenelektronik und der bisherigen Speedo-Software erläutern, da ich während der Entwicklungsphase bei den empfangenen Signalen auch stellenweise Fehlfunktionen hatte.

- Neutralstellung (Waffe, Zylinder, Licht,...) ist bei 1,5ms (=> bekannt)
- Pulse zwischen 0.5ms und 1ms werden ignoriert, der bisherige Zustand wird aber beibehalten. D.h. dass bei einem langsamen Ziehen des Knüppels die Geschwindigkeit beim Motor steigt. Sollte die Fernbedienung jetzt zufällig 0.9ms (statt Minimum 1ms) produzieren, so wird der Motor nicht abgeschaltet, sondern läuft weiter, als ob das Signal weiterhin 1ms hätte.
- Signale zwischen 2ms und 2,5ms weden ebenso auf 2ms korrigiert. Der Motor läuft weiter
- Signale kleiner 0.5ms (aber größer 0ms) oder größer 2,5ms werden ignoriert. Dabei wird so getan, als ob das Signal 1,5ms hätte (Nullstellung, keine Aktion)
- Jeder Signalzustand (ausser 1,5ms) muss dreimal korrekt eintreffen, bevor er als gültig zu einer Aktion führen darf. (Gerade beim Auslösen von Waffenfunktionen wichtig)
- Das Ausbleiben von Signalen (z.B. Abstecken vom Empfänger) führt zum Zustand "1.5ms", also "keine Aktion".

Mit diesem System sind wir bisher ganz gut gefahren. Nach meiner Ansicht habe ich damit indirekt eine Fail-Safe-Funktion integriert. Die Überprüfung, ob eine Schalthandlung dreimal hintereinander korrekt eingetroffen ist, führt zu einer Verzögerung von 60ms. Damit läßt sich aber leben.

Ciao
Reiner

yepp... hört sich echt klasse an...

das ist so in etwa das optimum, was ohne grossrechner mit signalvorhersage und rechenmodell machbar ist...

die dreifachauswertung hat eventuell einen kleinen nachteil:

wenn von drei gemessenen impulsen einer durch 'rauschen' (ganz genau 'gleich' sind 'gleiche' impulse leider nicht immer...) beim vergleich der impulse aus der auswertung fällt werden alle drei impulse verworfen und die messung beginnt von vorne (wieder 60ms verschenkt )
das gleiche passiert eventuell auch bei bewegung des steuerknüppels... jenachdem, wie 'genau' der vergleich der drei impulse durchgeführt wird...

effektiver ist eventuell, ein kleines 'rauschen' von 1-2% der Signalvariation als gültigen wert zuzulassen... :engel:

und ein ringpuffer könnte auch helfen:

3 (bis 5) werte in einen ringpuffer (oder FIFO speicher (First-In-First-Out)) schreiben, und bei einem fehlerhaften vergleich nicht alle werte, sondern nur den letzten verwerfen... das ergibt dann eine raktionszeit von 20ms (PWM-zeitintervall)
bei gültigem wert den wert in den puffer schreiben und den ältesten wert aus dem puffer entfernen...

...allerdings muss so ein puffer nach mehreren aufeinanderfolgenden fehlern kontrolliert gelöscht werden... ist auch wieder schwierig... :-O

örgs... ich hoffe ihr versteht, was ich meine... ist schwierig etwas vernünftiges zu schreiben, wenn einem die leute im büro fast auf dem schoß sitzen... *grummel*