Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

61

Montag, 20. Juli 2009, 15:25

Zitat

mit 6DOF und Inertialmesssytem meinst du aber nicht das Selbe, oder?


? ? ?. Es ist ein Inertial-Messsystem, da es nur aus den Eigenbewegungs-Sensoren (3 Drehratensensoren und 3 Beschleunigungssensoren) die absoluten (zu einem Erd-Referenzsystem) 6 Freiheitsgrade berechnet. Da dies eben nur indirekt erfolgt, schleichen sich mit der Zeit eben Fehler ein.
Ist ähnlich wie bei integrierten GPS-Systemen im Auto, die mit Hilfe von Odometrie berechen, wo das Auto ist, auch wenn kein GPS-Signal vorhanden ist (z.B. im Tunnel). Dies wird einfach aus Fahrgeschwindigkeit und Lenkungsausschlag berechnet.

Zitat

aber wenn du weisst wo die Erde ist dann weisst du doch schon 3DOF... die sollen also "doppelt" gemessen werden?


Ich glaub du verwechselst das oft gesagte 3D mit 3DoF. In einem 3D-Raum hat ein Objekt 6 Freiheitsgrade (DoF=Degree of Freedom). Wenn man also wie üblich nur 3 Drehratensensoren hat, kann man zwar theoretisch berechnen wo die Erde ist, wenn man weiss wo Sie zu Beginn war. Mit der Zeit wird der akkumulierte Fehler jedoch so gross, dass das keinen Sinn mehr macht. Wenn man hingegen mit Hilfe der 3 Beschleunigungssensoren auch noch die Gravitation misst, dann kann sich das System immer wieder angleichen und so den Fehler wieder minimieren. Zumindest den Fehler der Rollachsen im Bezug zur Erde, was wohl am wichtigsten ist.


Zitat

es geht also nicht (nur) darum zu stabilisieren, sondern "autonom" zu fliegen? Ich meine, kein Gerät kann vorher wissen welchen Knüppel ich wann wie bewege, ob in der nächsten Sekunde eine Windböhe auszugleichen ist, oder wie der Pitch wirklich stehen muss um die von mir gewünschte Bewegung hinzubekommen... oder kurz:


Nein es geht nicht darum autonom zu fliegen, sondern dass man eben noch weiter gehen könnte als heutige Stabi-Systeme. Ob man's dann benutzen will, hängt vom jeweiligen User ab.
Natürlich kann das System nicht wissen, welche Ausschläge du machen willst. Es kann jedoch bestimmte Annahmen machen und diesbezüglich optimieren. Sicherlich wäre das ein im Flug zuschaltbares Feature. Z.B. Höhe halten. Dann kann man eben z.B. Rollen machen oder anderes und das System würde so gut wie möglich versuchen die Höhe stabil zu halten.
Auch wäre dann möglich, auch z.B. den Pitch so zu steuern wie das Tail oder die Rollachsen. D.h. man bestimmt per Pitch-Hebel die Steig und Sink-Rate und nicht direkt den Pitch...
Sagen wir es einmal so: Es gäbe Unmengen an Möglichkeiten, was man damit alles machen könnte. Ob man's dann programmiert und ob's dann zufriedenstellend funktioniert und ob man's dann auch benutzt ist eine andere Frage. Aber ich finde, wenn es fast ohne Zusatz-Aufwand auf's Board passt, wieso sich nicht diese Möglichkeit offen lassen.

BTW: Es lässt einem auch die Möglichkeit offen, endlich Mal ein 6DoF Fluggerät zu bauen und fliegen. Wollte ich schon immer mal machen.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Hui« (20. Juli 2009, 15:57)


haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

62

Montag, 20. Juli 2009, 16:09

Hallo Hui,

leider ist das nicht ganz so einfach...

Ein Heli hat selbstverständlich mindestens die üblichen 6 Freiheitsgrade; dazu können/müssen -je nach Tiefe und Komplexität der Behandlung- noch weitere kommen (vor allem die Blattbewegungen). Die Bewegungen/Bewegungsgleichungen in den Freiheitsgraden sind im allgemeinen verkoppelt und nichtlinear; recht unschön...

Zum Glück kann man diese Modellierung des Helis in vielen Fällen mit hinreichender Genauigkeit vereinfachen , z.B. bei (mehr oder weniger) symmetrischen Bauformen, bei geringer Verkoppelung (Translation in der z-Achse kann man z.B. "abspalten"), im Schwebeflug und bei geringen Fortschrittsgraden; und/oder man kann die "Seitenbewegung" (Rollen, Gieren, y-Translation) getrennt von der "Längsbewegung" betrachten.

Aber schon die allereinfachste Modellierung des Helis (symmetrische Längsbewegung im Schweben und bei kleinen Fortschrittsgraden) erfordert 3 Freiheitsgrade in der Längs-/Vertikalebene; üblicherweise verwendet man dafür Bahngeschwindigkeit, Bahnwinkel und Anstellwinkel. Ohne diese 3 (oder äquivalente) Freiheitsgrade ist die Längsbewegung garnicht physikalisch sinnvoll darstellbar.

Das o.g. betrifft nur die Modellierung des Helis und hat mit einer Flugregelung selbst noch nichts zu tun. Bei der Wahl eines Reglertyps, der Sensoren bzw. Aufschaltgrößen hat man noch ziemliche Freiheiten (die dann zu mehr oder weniger guten Regelungen führen). Insbesondere braucht man nicht für jeden Freiheitsgrad einen Sensor.

Ich sage das jetzt vor allem deshalb, weil du weiter oben im thread die Ansprüche an deinen Regler sehr hoch gesteckt hast und auch (so ist mein Eindruck...) regeltechnisch/mathematisch ziemlich tief einsteigen willst.


Es dürfte sehr hilfreich und letztlich zeitsparend für dich sein, wenn du dich erstmal etwas mit der Flugmechanik der Helis beschäftigen würdest, wenigstens mit den Grundlagen. Das ist alles etwas anders, als es sich die Modellbauer meistens vorstellen.

Im Rahmen eines Forums kann man das nicht vermitteln. Falls du Interesse hast, kann ich dir ein paar Bücher nennen, die für´s "Einlesen" geeignet sind (Kenntnisse in höherer Mathematik sind aber nötig). Die sind allesamt nicht mehr oder nur sehr teuer zu kaufen; aber in jeder technisch orientierten Bibliothek sollten sie auszuleihen sein. Melde dich gfls. dazu.


Und noch was:
Ich stolpere (nicht nur hier) regelmäßig über den geplanten Einsatz von Beschleunigungs-Sensoren, egal für wie viele Achsen; vor allem auch zur Ermittelung der Lotrichtung.
Dabei wird idR vergessen, daß diese grundsätzlich nur den resultierenden Beschleunigungsvektor bzw. dessen Komponenten im flugzeugfesten Koordinatensystem messen können. Ohne zusätzliche Hilfsmittel (z.B. Kreisel, spezielle Pendel, und/oder Kombinationen davon) kann man mit Beschleunigungssensoren nicht die Lage des Fluggeräts feststellen. Darüber bin ich vor vielen Jahren selbst mal bei einem speziellen Flugregler (nicht für Helis, es ging um die "Phygoiden"-Bewegung von Starrflüglern) gestolpert...


Gruß,
Helmut

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »haschenk« (20. Juli 2009, 16:14)


63

Montag, 20. Juli 2009, 16:32

Auch diesesmal Danke an deine Antwortbereitschaft.

Die Frage mit den 6DOF und IMS musste ich stellen um sicherzugehen, dass ich dich nicht nur falsch verstehe. :)

Zitat

Ich glaub du verwechselst das oft gesagte 3D mit 3DoF.
ne, ganz sicher nicht :)

Zitat

Wenn man also wie üblich nur 3 Drehratensensoren hat, kann man zwar theoretisch berechnen wo die Erde ist, wenn man weiss wo Sie zu Beginn war. ... Wenn man hingegen mit Hilfe der 3 Beschleunigungssensoren auch noch die Gravitation misst,
du hast 6 Sensoren, 3 davon für die Beschleunigung, mit diesen 6 willst du die 6Dof bekommen PLUS die Gravitation? Wie willst du mit den Beschleunigungssensoren zwischen Beschleunigung des Helis und Gravitation unterscheiden?

Zitat

Sagen wir es einmal so: Es gäbe Unmengen an Möglichkeiten, was man damit alles machen könnte. Ob man's dann programmiert und ob's dann zufriedenstellend funktioniert und ob man's dann auch benutzt ist eine andere Frage. Aber ich finde, wenn es fast ohne Zusatz-Aufwand auf's Board passt, wieso sich nicht diese Möglichkeit offen lassen.
ich bin mir noch nicht sicher ob ich dir da zustimmen will. Ich kann akzeptieren dass es Sinn macht mehrere Sensoren zu benutzen um z.B. die Genauigkeit zu erhöhen oder Fehler auszugleichen, aber diesen Aspekt klammern wir mal aus weil es da nicht um 6DOF geht sondern um Details der Messtechnik. Meine Logik ist ganz einfach: ich habe nur 4 Steuerknüppel um dem Heli Info darüber zu geben was er tun soll, d.h., jedes System kann nur bzgl 4 Freiheitsgraden stabilisieren. Wenn es das bzgl mehr tun soll dann muss das System irgendeine zusätzliche Info haben, aber dann tut's nicht nur stabilisieren sondern auch bestimmen, in der Art, fliege auf einer Höhe egal was der Meister sagt. Das mit dem Vorausschauen ist so eine Sache, in der Physik gibt es weitreichende Einschränkungen aufgrund der Kausalität, und die werden manchmal sehr unterschätzt, und lassen sich vorallem nur "schwer" aushebeln... (klassisches Beispiel Filter: will man das vorrauschauend machen, dann gibt man die Gleichzeitigkeit auf).

Würdest du dieser Formulierung zustimmen: mit 6DOF bekommt man ein Stabilisierungssystem nicht stabiler, aber man kann Dinge damit tun die über eine Stabilisierung hinausgehen?

Olli

64

Montag, 20. Juli 2009, 16:45

mal wieder eine Antwort über dem Verfassen einer Antwort verpasst... :)

Zitat

Die Bewegungen/Bewegungsgleichungen in den Freiheitsgraden sind im allgemeinen verkoppelt und nichtlinear; recht unschön...
aber wenn ich meine 4DOFs (bzw. 4 Sensoren) gerade so wählen würde dass Sie genau das wiederspiegeln (bzw messen) was die 4 SteuerKanäle bewirken, wäre dann die Stabilisierung nicht doch "einfach" zu machen? Deine Antwort interessiert mich, Helmut. :)

Olli

65

Montag, 20. Juli 2009, 17:21

lol. Heute ist scheinbar eine Diskussionrunde angesagt...

@Helmut:

Zitat

Ich sage das jetzt vor allem deshalb, weil du weiter oben im thread die Ansprüche an deinen Regler sehr hoch gesteckt hast und auch (so ist mein Eindruck...) regeltechnisch/mathematisch ziemlich tief einsteigen willst.


Ja das ist schon so. Sicherlich wird zuerst ein ganz simples PID-System implementiert, damit man mal was hat. Danach kann dann experimentiert werden.
Ich selbst hatte sehr viel Mathe/Algebra/... im Studium und bzgl. ähnlicher Systeme doch einiges in meinen 3 Semestern Robotik gelernt. Bin also sicherlich nicht jungfräulich und weiss schon, um was es hier geht. Ob, und wie gut das dann umsetzbar ist, ist eine andere Frage. Aber etwa Motivation hat noch nie geschadet :D

Zitat

Dabei wird idR vergessen, daß diese grundsätzlich nur den resultierenden Beschleunigungsvektor bzw. dessen Komponenten im flugzeugfesten Koordinatensystem messen können. Ohne zusätzliche Hilfsmittel (z.B. Kreisel, spezielle Pendel, und/oder Kombinationen davon) kann man mit Beschleunigungssensoren nicht die Lage des Fluggeräts feststellen.


Das ist mir selbstversändlich klar. Aber ich habe ja die 3 Drehratensensoren. Und damit kann ich vorausberechnen, welche Beschleunigungen ich wegen den Drehungen bekomme. Der Rest sind dann die translatorischen Beschleunigungen des Helikopters und die Gravitation. Sicherlich ist das eine mathematisch aufwändige Aufbereitung. Aber eigentlich ein bekanntes Problem mit bekannten Algorithmen und schlussendlich nicht viel mehr als eine gehörige Portion Matrizenrechnungen... :D

Zitat

Wie willst du mit den Beschleunigungssensoren zwischen Beschleunigung des Helis und Gravitation unterscheiden?

Da kommen dann eben die mathematischen Modelle zum Zug. Man hat immer einen vorhergesagten Gravitationsvektor. Gleichzeitig hat man eben auch vorhergesagte Beschleunigungen. Über mathematische Fehlerminimierung kann nun geschätzt werden, wo genau sich zurzeit nun der Gravitationsvektor befindet.
Sicherlich wird diese Schätzung schlechter sein, wenn man ständig wild rumfliegt. Aber nur Mal kurz am Himmel stehenbleiben, und schon ist das System wieder geeicht.
Ist wie bereits erwähnt ein bekanntes Problem. Gibt deshalb auch viele bekannte Lösungen dazu.

Zitat

Wenn es das bzgl mehr tun soll dann muss das System irgendeine zusätzliche Info haben, aber dann tut's nicht nur stabilisieren sondern auch bestimmen, in der Art, fliege auf einer Höhe egal was der Meister sagt.


Ja, das ist ja der Witz!. Ich sehe das so, dass es dann eben z.B. statt des Gyro-Switches ein Switch gibt für Höhe halten. Wenn man nun kurz ein paar Loops/Rolls und Co auf gleicher Höhe drehen möchte, schaltet man kurz den Switch ein. Danach wieder aus. Ist jetzt nur ein Beispiel. Man könnte sich eben auch z.B. ein Switch für die Pitch-Regelung denken. Oder eben ein Switch um auf einen Horizontal-Modus zu schalten, wo man mit den Knüppeln direkt den absolut Winkel vorgibt, etc...

Zitat

ich habe nur 4 Steuerknüppel um dem Heli Info darüber zu geben was er tun soll, d.h., jedes System kann nur bzgl 4 Freiheitsgraden stabilisieren


Es ist richtig, man hat nur 4 Hebel. Aber was man genau mit diesen Hebeln steuert kann man eben umdefinieren. Ob man mit den Hebeln z.B. absolute Rollwinkel ansteuert, oder eben Drehraten. Ob der Pitch direkt die Blätter ansteuern soll, oder die Steig und Sink-Rate. Auch andere Modi sind vorstellbar. Z.B. dass man mit den Hebeln die absoluten X/Y/Z Koordinaten vorgibt in der sich der Heli bewegen soll, usw. Auch beliebige Mischkombinationen sind prinzipiell vorstellbar...
Falls das System die 6DoF tatsächlich einigermassen zuverlässig schätzen kann, dann wäre es vielleicht sogar dann an der Zeit andere Fernsteuerungen zu benutzen.
Auch ist klar, dass ein Heli immer nur in 4 Freiheitsgraden steuern kann. D.h. gewisse Manöver sind nicht möglich. Das System muss das dann eben erkennen und den Gesamtfehler versuchen zu minimieren.

Zitat

Würdest du dieser Formulierung zustimmen: mit 6DOF bekommt man ein Stabilisierungssystem nicht stabiler, aber man kann Dinge damit tun die über eine Stabilisierung hinausgehen?

Fast. Die Frage ist, wie Du stabil definierst?
Wenn Du z.B. den Heli einfach so in der Luft stehen lässt, akkumuliert sich eben bei einem konventionellen Stabi-System der Fehler und der Heli wird mit der Zeit immer mehr wegdriften. Bei einem 6DoF-System kann man eben immer wieder die Gravitation berücksichtigen und so diesen Fehler korrigieren.
Also einen kleinen Vorteil bringt es auch bzgl Stabilität, aber sonst hast Du recht.

PS:
Aber das sind wirklich nur Spielereien. Zuerst wird ein ganz normales Stabi-System implementiert. Danach kann jeder (da offen) seinen Fantasien freien Lauf lassen...Mal schauen was rauskommt...
Mein Hauptaugenmerk liegt zurzeit darauf, eine Stabi-HW-Basis zur Verfügung zu stellen für extrem kleine Helis. Schlicht, weil es das im Moment nicht gibt. Für grössere Helis würde ich zurzeit jedem zu den käuflichen Lösungen, oder den bekannten andere offenen Stabi-Projekten raten.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Hui« (20. Juli 2009, 17:35)


haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

66

Montag, 20. Juli 2009, 17:33

Hallo Olli,

ohne mich jetzt bis ins Letzte festzulegen, würde ich "Nein" sagen.

Die Dinge (Bewegungen und deren physikalisch/mathematische Beschreibung....) sind einfach zu komplex, um da eine einfache Aussage zu machen. Und die Parameter, die darin eingehen (z.B. Abmessungen, Massen, aerodynamische Eigenschaften) können stark unterschiedlich sein.

Natürlich könnte man sagen, daß ein "Hyper-Super-Pilot" (egal ob er drinsitzt, oder nur ein Modell sieht) über die Steuerknüppel alles das machen, was ein Regler macht. Den gibt´s aber nicht...

Ein gängiger und bewährter Weg ist, zuerst mal das Fluggerät ohne Regler flugmechanisch/mathematisch zu simulieren, d.h. seine Eigenbewegungen zu studieren. Bei einem Heli hat man da (ganz grob verkürzt gesagt) meistens statische Stabilität, aber dynamische Instabilität (oszillatorisch oder aperiodisch).

Und anschließend kann man Sensoren verschiedenster Art (zweckmäßigerweise immer mit der Gedanken der möglichen Realisierung im Hinterkopf) in die Bewegungsgleichungen einführen, d.h. an einer "passenden" Stelle eine "Aufschaltung" des Sensorsignals vornehmen. D.h. letztlich, daß man Abhängigkeiten einführt, die "natürlich" nicht gibt. Daß "gerätetechnisch" dann schon vorhandene Stellglieder (z.B. Höhenruder- oder Heli-Nickservo) verwendet werden, ist selbstverständlich.

Hierbei kann man - wenn man nicht schon einschlägige Erfahrung hat- in der Auswirkung oft Überraschungen erleben. Hinterher zu erklären, warum das so ist, ist dann idR einfach...
Beispielsweise kommt oft die Aufschaltung einer Geschwindigkeit physikalisch gesehen "zu spät"; man müsste schon die Beschleunigung aufschalten...

Bei meinem o.e. Beispiel der "Phygoiden-Regelung" (mehr zur Phygoide z.B. in Wikipedia) hat sich in einer rel. einfachen Simulation (die aber auch schon numerisches Rechnen erfordert) gezeigt, daß die Aufschaltung der Beschleunigung in Bahnrichtung die besten Ergebnisse (Unterdrückung der Phygoide) bringt. Dazu kann man aber i.a. wegen des Mit-Messens der Gravitations-Komponente keinen Beschleunigungsmesser verwenden. Mein Ausweg war damals Messung der Bahngeschwindigkeit und Differenzierung des Messwert nach der Zeit. Hat funktioniert..

Beim Heli ist die Simulation erheblich komplexer, aber machbar.


Gruß,
Helmut

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »haschenk« (20. Juli 2009, 17:48)


haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

67

Montag, 20. Juli 2009, 17:42

Hallo Hui,

Zitat

Es ist richtig, man hat nur 4 Hebel. Aber was man genau mit diesen Hebeln steuert kann man eben umdefinieren. Ob man mit den Hebeln z.B. absolute Rollwinkel ansteuert, oder eben Drehraten.


Nur damit du das Rad nicht nochmal erfindest:
Mit solchen Fragen und den Antworten dazu haben sich die "professionellen manntragenden" Flugregler-Entwickler schon ausgiebigst beschäftigt...

Anwendungen reichen von Boden-Boden-Raketen bis zu Vertikalstartern.


Gruß,
Helmut

68

Montag, 20. Juli 2009, 17:46

Zitat

aber wenn ich meine 4DOFs (bzw. 4 Sensoren) gerade so wählen würde dass Sie genau das wiederspiegeln (bzw messen) was die 4 SteuerKanäle bewirken, wäre dann die Stabilisierung nicht doch "einfach" zu machen?


Ich sage dazu auch Nein.
3DoF sind rel "einfach" zu machen. Nämlich eben die 3 Rollachsen (ein konventionelles Stabi-System). Wie man in bisherigen Implementationen sehen kann, kann man diese sogar unabhängig voneinander modellieren. D.h. theoretisch könntest Du 3 GY401 nehmen und hättest ein Stabi-System. Nicht das Beste, aber es sollte funktionieren.
Der 4erte Freiheitsgrad (Pitch) ist aber eben nicht "einfach" zu machen, da ein Beschleunigungssensor immer alle Beschleunigungen in diese Richtung misst, also auch die Gravitation, der Wind, ...
Hier brauchts Du dann unbedingt ein 6DoF-System, da man die Position des Helis inkl aller Zusatzparameter modellieren muss, um wirklich herausfinden zu können mit welcher translatorischen Beschleunigung der Heli im Moment sich auf der Z-Achse bewegt...

Zitat

Natürlich könnte man sagen, daß ein "Hyper-Super-Pilot" (egal ob er drinsitzt, oder nur ein Modell sieht) über die Steuerknüppel alles das kann, was ein Regler macht. Den gibt´s aber nicht...


Lol. Im heutigen RC-Bereich gilt sogar tatsächlich, dass selbst der allergeilste Pilot, nie so gut ist, wie ein System auf dem Heli. Ganz einfach, weil die Funk-Update-Rate von 22ms sehr grob ist im Vergleich zu der Update-Rate des Regel-Systems (GY401 z.B. 270Hz=3.7ms).

Zitat

Nur damit du das Rad nicht nochmal erfindest: Mit solchen Fragen und den Antworten dazu haben sich die "professionellen manntragenden" Flugregler-Entwickler schon ausgiebigst beschäftigt...

Interessant. Und zu was für einem Fazit ist man gekommen? Ich denke ist halt immer sehr abhängig davon, was man gerade will.
Für eine Überwachungsdrone wäre z.B. IMHO eine absolute XYZ translatorische Steuerung am besten.

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »Hui« (20. Juli 2009, 17:56)


69

Montag, 20. Juli 2009, 19:00

Zitat

Heute ist scheinbar eine Diskussionrunde angesagt...
hast du das nicht ein kleines bischen vermisst? :D

Zitat

Aber nur Mal kurz am Himmel stehenbleiben, und schon ist das System wieder geeicht.
Ok, das verstehe ich.

Und beim Rest sehe ich nun auch klarer, und fasse es so zusammen: 4DOF reichen für ein Stabilisierungssystem im Prinzip völlig aus, mit 6DOF kann man allerdings Fehler von Standard-Systemen auskorrigieren, und darüber hinaus noch Dinge tun die über eine Stabilisierung hinausgehen...

... und ich habe noch zusätzlich gelernt dass es auch mit 4 geschickt gewählte Sensoren bzw DOFs nicht notwednigerweise einfacher wird...

DANKE für die Diskussion :prost:

Olli

70

Montag, 20. Juli 2009, 19:18

Zitat

4DOF reichen für ein Stabilisierungssystem im Prinzip völlig aus


Lol, nicht ganz! 3DoF reichen aus.
Die meisten Stabi-Systemen haben auch nur 3DoF, nämlich die 3 Drehraten.

Hmm, falls irgendjemand anderes sich tatsächlich hier durchliest :D , versuche ich zum besseren Verständnis nochmals kurz zu erläutern um was es prinzipiell geht.

Ein Stabi System hat eigentlich 2 Hauptpunkte.

1) Das Inertial-Mess-System.
Es misst mit Hilfe von Sensoren gewisse Bewegungen des Helis und berechnet daraus seine aktuellen Bewegungen und oder Lage.

2) Das Regel-System.
Es vergleicht die angeforderten User-Eingaben (Knüppel-Stellungen) mit den aktuellen Bewegungen/Lage und steuert die Servos so an, dass die Eingaben erreicht werden.

Bzgl. Vorausberechnung/Simulation.
Um im 2. Punkt besser Regeln zu können ist es von Vorteil ein Simulations-Modell des Helis zu haben um zu berechnen wie am optimalsten die Servos angesteuert werden um schnellstmöglich die User-Eingaben zu erreichen.
Wenn der Heli sich z.B. gerade schnell um die Hoch-Achse dreht, und man dann den Stick zentriert, man also keine Drehung mehr will, so bringt es nichts, wenn der Tail-Pitch auf die Stellung für keine Drehung mehr geht, da der Heli eine Rotationsträgheit besitzt wird er überschiessen. Wenn man aber ein Simulationsmodell des Helis hat, so kann man sehen, dass man jetzt halt voll Pitch dagegen halten muss, um den Heli so schnell wie möglich zum Stillstand zu bringen.
Ich vermute stark, dass die billigen Stabi-Systeme und auch alle offenen die ich bisher gesehen habe keine Simulationskomponente beinhalten!
D.h. die Simulationskomponente kann einfach die Regelung verbessern, ist aber nicht zwingend notwendig.
Je besser die Simulation, je besser die Regelung.

@Helmut:
Hier sehe ich eben auch das Limit. Es bringt wahscheinlich nichts eine allzu komplexe Simulation zu integrieren, da die Rohdaten auf denen das Regelsystem aufbaut (Mess-System) eh ungenau sind. D.h. irgendwann macht das Verhältnis keinen Sinn mehr.
Ich persönlich würde jetzt Mal aus'm Bauch raus schätzen, dass es sicherlich was bringt die Trägheitsmatrix zu berechnen. Auch das Tail bedingte Drehmoment und der Tail bedingte Drift. Zusätzlich dann noch die Präzession des Hauptrotorkreises. Ich glaube das wird eine für ein Stabi-System genügend genaue Simulationsbasis. Ob das wirklich so ist, das könnte man sehen, in einer Simulation :D :D :D

BTW: Die vorhergesagte Bewegung des Regelsystems kann man wieder benutzen um die Fehlerschätzungen des Mess-Systems zu optimieren...

OK, ist jetzt nicht alles erklärt worden. Aber ich hoffe es wurde jetzt etwas klarer.

haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

71

Montag, 20. Juli 2009, 20:29

Hallo Hui,

Zitat

Und zu was für einem Fazit ist man gekommen?


Wie soll ich das in Kürzestform sagen ?
Man sollte den Pilot auf "höchster dynamischer Ebene" (Lage) eingreifen lassen.
Also nicht auf "Beschleunigungsebene" ("Kraft-Steuerung"; das wären z.B. Quadros ohne jedes Gyro); unfliegbar. Besser ist schon "Geschwindigkeits-Steuerung" (z.B. Drehrate, Quadros mit Gyros, aber noch ohne Integration zur Lage). Bei frühen Panzerabwehrraketen z.B. hat man noch mit "Beschleunigungs-Steuerung" gearbeitet; deren Steuerung war sehr schwierig zu erlernen; obwohl nur 2-dimensional (Zieldeckungsverfahren). Die Einführung eines "Vorhalts" (regeltechnisch gemeint) war eine erhebliche Verbesserung. Mehr dazu findest du in der Literatur.

Zitat


Ich persönlich würde jetzt Mal aus'm Bauch raus schätzen, dass es sicherlich was bringt die Trägheitsmatrix zu berechnen. Auch das Tail bedingte Drehmoment und der Tail bedingte Drift. Zusätzlich dann noch die Präzession des Hauptrotorkreises. Ich glaube das wird eine für ein Stabi-System genügend genaue Simulationsbasis.


Wie schon mal gesagt, so einfach ist das nicht. Du hast imho bislang eine ziemlich vage Vorstellung von der Dynamik/Aerodynamik eines Helis. Mag sein, daß du damit irgendwann (vielleicht in Grenzen ?) auch zum Ziel kommst.

Am Heli treten (aerodynamische) Kräfte und Momente auf, die dir noch fremd sind. Der Heli ist die *Regelstrecke*, und deren Verhalten sollte man schon (wenigstens qualitativ) kennen, wenn man einen Regler dafür bauen will.
Der Rotor eines "üblichen" Helis ist kein Kreisel, damit treffen auch die Vorstellungen von einer Kreiselpräzession nicht zu. Die Quadros etc. sind ähnlich, aber nicht gleich.

Daher nochmals (und letztmals) mein Rat, dich da etwas einzulesen, um wenigstens eine qualitative Vorstellung zu bekommen. Auf Forumsebene geht das nicht; die Nennung von relevanter Literatur hab ich dir ja schon angedroht.


Gruß,
Helmut

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »haschenk« (20. Juli 2009, 20:35)


72

Dienstag, 21. Juli 2009, 13:44

Zitat

Am Heli treten (aerodynamische) Kräfte und Momente auf, die dir noch fremd sind.


Lol, die Frage wäre eben wie gross diese sind im Vergleich zu den offensicthlichen Momenten. Wie bereits vorhin erwähnt grundsätzlich geht es auch ganz ohne Simulation, was wohl auch viele Stabis so machen. Wenn Die Simulation nicht perfekt ist, gibt es einfach mehr Fehler, der korrigiert werden muss. Je besser die Simulation, desto weniger Fehler tritt auf, der korrigiert werden muss.
Wie gesagt, zuerst wird sicher ein plumperes Modell eingebaut. Wenn dann Zeit und Lust besteht komm ich gerne auf deine Literatur zurück. Ist aber alles halt immer ein Zeit-Frage...

Das weitere Hauptproblem, welches ich bei komplexen Simulationen sehe sind die Parameter dazu. Irgendwie müssen diese ermittelt werden, und mit der Komplexität, nehmen auch die Anzahl Parameter zu. Adaptive Regelungen nur für die Trägheitsmatrix sind ja standard. Aber schon einige weitere Parameter machen das Modell sehr komplex und es bleibt dann meiner Meinung nach fragwürdig, ob das System diese alle noch selbst lernen kann. Denn wenn vom User verlangt wird selbst grossartig Messungen zu machen wird es bald nicht mehr zumutbar für viele.
Schlussendlich wird es deshalb wahrscheinlich auf ein vereinfachtes "Kompromiss"-Modell hinauslaufen, welches noch selbst erlernt werden kann, aber trotzdem die wichtigsten Eigenschaften abdeckt. Da ist dann wohl wieder probieren angesagt...
Aber "First Things First". Jetzt erstmal das Grundboard herstellen und zum Laufen bekommen.

BTW: Für diejenigen die es interessiert:
Das hier ist die Bestückungsliste der Boards, welche sich jetzt in Produktion befinden:

Part Value Package Library Position (mm) Orientation

AIL MOLEX - 53047-0310 53047-03 con-molex (28 13.2) R0
BOOT-PIN TP10SQ testpad (18.2878 13.3707) R0
C1 100nF 0402 wuerth-elektronik (16.2878 13.6292) R0
C2 100nF 0402 wuerth-elektronik (21.2707 7.7707) R180
C3 100nF 0402 wuerth-elektronik (17.9294 4.3707) R180
C4 100nF 0402 wuerth-elektronik (11.7878 12.9292) R0
C5 10uF C0603K rcl (21 16.4) R90
C6 10nF C0603K rcl (14.1 17.2) R0
C7 4.7uF C0603K rcl (14.1 15.8) R0
C8 10uF C0603K rcl (11.8 16.4) R90
C9 10nF C0603K rcl (4.6 17.2) R0
C10 4.7uF C0603K rcl (4.6 15.8) R0
C11 10uF C0603K rcl (33.8 15.15) R0
C12 100nF C0603K rcl (33.8 13.35) R180
C13 100nF 0402 wuerth-elektronik (8 5) R0
C14 100nF 0402 wuerth-elektronik (4.4 9.9) R270
C15 100nF 0402 wuerth-elektronik (8.6 3.6) R0
C16 100nF 0402 wuerth-elektronik (7 13) R90
C17 220nF 0402 wuerth-elektronik (6 13) R270
C18 220nF 0402 wuerth-elektronik (6 4.3) R90
C19 100nF 0402 wuerth-elektronik (4.4 7.5) R90
ELE MOLEX - 53047-0310 53047-03 con-molex (28 10) R0
I2C MOLEX - 53047-0310 53047-02 con-molex (21.2 11.7) R180
IC1 STM32F103T8U QFN-36 SparkFun (15.6585 8.7171) R225
IC2 IDG500 QFN-28 74ttl-din (7.5 8.7) R270
IC3 74HCT245PW TSSOP20 maxim (34.2 9.4) R270
L1 MPZ1608R391ATA00 C0603K rcl (22.5 16.4) R270
L2 MPZ1608R391ATA00 C0603K rcl (12.7 14.2) R180
L3 MPZ1608R391ATA00 C0603K rcl (36.45 16) R90
PIT MOLEX - 53047-0310 53047-03 con-molex (28 16.4) R0
R1 10k 0402 wuerth-elektronik (21.5877 13.6705) R0
R2 56 0402 wuerth-elektronik (20.3292 6.6292) R0
R3 3k9 0402 wuerth-elektronik (21.2206 4.3793) R0
R4 3k9 0402 wuerth-elektronik (23.7706 4.3793) R0
R5 750 0402 wuerth-elektronik (10.7 4.8) R90
R6 750 0402 wuerth-elektronik (8.6 12.4) R0
SAT_GND TP10SQ testpad (15 3.7) MR0
SAT_RX TP10SQ testpad (12 3.7) SMR0
SAT_VCC TP10SQ testpad (13.5 3.7) MR0
TAIL MOLEX - 53047-0310 53047-03 con-molex (28 6.8) R0
THR MOLEX - 53047-0310 53047-03 con-molex (28 3.6) R0
U1 LP3985IM5-3.1 SOT23-5 linear (17.7 16.5) R90
U2 LP3985IM5-3.0 SOT23-5 linear (8.2 16.5) R90
V1 LED 2.0V 20mA 0402 wuerth-elektronik (22.7292 6.6292) R0
X1 MA03-2 con-lstb (41.51 15.6) R0
X2 MA03-2 con-lstb (41.51 10.52) R0
X3 MA03-2 con-lstb (41.51 5.44) R0


Blöd ist, das Farnell keine 0402er LEDs hat. Nur ein Typ, aber das sind so Hochleistungs-LEDs für 160mA. 160mA durch eine LED in einem 0402...
Lustigerweise hat ausgerechnet Conrad tatsächlich 0402er LEDs. Muss ich wohl trotzdem mal was dort bestellen, auch wenn die Versandkosten hier in der Schweiz exorbitant sind.

haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

73

Dienstag, 21. Juli 2009, 18:30

Hallo Hui,

Zitat

Lol, die Frage wäre eben wie gross diese sind im Vergleich zu den offensicthlichen Momenten. Wie bereits vorhin erwähnt grundsätzlich geht es auch ganz ohne Simulation, was wohl auch viele Stabis so machen.


Sie sind so groß, daß ein Teil von ihnen die Eigenbewegung dominiert...
Wenn du eine Simulation machen willst, dann musst du die Wichtigsten davon berücksichtigen. Am allerwichtigsten ist das (nicht ganz unbekannte...) "Pitch-Up"-Moment mit der Fahrt; das lässt z.B. die Koaxe so eigenstabil und unwillig im Vorwärtsflug werden. Art und Position der Schlaggelenke, Trägheitsmomente der Blätter u.a.m. spielen dabei eine große Rolle.

Aber -wie du richtig ahnst- wird die Geschichte dann richtig aufwändig, weil man diese Parameter ja kennen muß. Es gibt dafür Näherungsformeln, die vermutlich genügen würden, aber auch da ist der Aufwand zu deren Verwendung schon beträchtlich.

Ich würde daher sagen, lass´ die Simulation erst mal ganz bleiben. Mit den "offensichtlichen" Kräften/Momenten würdest du imho arg daneben liegen. Wahrscheinlich wurde bei den bestehenden Systemen auch eher pragmatisch vorgegangen. Obwohl, bei einem System (V-Stabi ?) ist/war auch eine Aufschaltung der Fluggeschwindigkeit vorgesehen; das geht in die erwähnte Richtung.

Zitat

Das weitere Hauptproblem, welches ich bei komplexen Simulationen sehe sind die Parameter dazu. Irgendwie müssen diese ermittelt werden, und mit der Komplexität, nehmen auch die Anzahl Parameter zu.

Aber schon einige weitere Parameter machen das Modell sehr komplex und es bleibt dann meiner Meinung nach fragwürdig, ob das System diese alle noch selbst lernen kann.
.
Siehe oben.

Zitat

Schlussendlich wird es deshalb wahrscheinlich auf ein vereinfachtes "Kompromiss"-Modell hinauslaufen, welches noch selbst erlernt werden kann, aber trotzdem die wichtigsten Eigenschaften abdeckt. Da ist dann wohl wieder probieren angesagt...

Könnte ich mir vorstellen...

Persönlich werde ich bei meiner Arbeit wahrscheinlich mehr in Richtung "Multicopter" gehen; die sind aerodynamisch/flugmechanisch etwas anders und (vermutlich, soweit ich es überblicke) einfacher. Aber auch da stellt sich natürlich das Problem der zugrunde zu legenden Parameterwerte.


Noch was Anderes:
Ich hab´s jetzt endlich geschafft, den DSM2-Satelliten-Rx ohne Haupt-Rx zu binden. Die Angaben dazu im microcopter-Forum waren wenig brauchbar, aber hier hab´ ich die Lösung (d.h. das notwendige Timing auf der Signalleitung) gefunden, ganz am Ende des threads:
http://www.rcgroups.com/forums/showthrea…tellite+binding

Ein Mini-Einfachst-Progrämmchen für Tiny15 o.ä. dafür, und schon geht´s.
Das Ausgangssignal des Sat-Rx hat dasselbe Format wie das "Meta-Signal" im (DX5e-) Sender, jedoch mit anderer Reihenfolge und Numerierung der Kanäle; sollte leicht zu decodieren und weiter zu verarbeiten sein.

Falls Interesse besteht, stelle ich die Info dazu natürlich zur Verfügung.


Gruß,
Helmut

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »haschenk« (21. Juli 2009, 18:32)


74

Dienstag, 21. Juli 2009, 20:06

Zitat

ch hab´s jetzt endlich geschafft, den DSM2-Satelliten-Rx ohne Haupt-Rx zu binden.

Zitat

Falls Interesse besteht, stelle ich die Info dazu natürlich zur Verfügung.
auch wenn ich gerade DSM2-mässig wenig unterwegs bin würde mich das SEHR interessieren, deswegen, bitte schreib es doch irgendwo auffindbar ins Forum... :):)

Olli

JPOP

RCLine User

Wohnort: Saarbrücken

  • Nachricht senden

75

Dienstag, 21. Juli 2009, 22:22

_________________________________
Against gravity

Spanky

RCLine User

Wohnort: BW

Beruf: Studiere Medieninformatik

  • Nachricht senden

76

Dienstag, 21. Juli 2009, 22:49

Super das mit dem Binding, vielleicht könntest du ein eigenen Beitrag aufmachen und dein Programm anhängen, dann finden das andere auch leichter. :ok: :ok: :ok:
Gruß Flo

www.Xtreme-RC.de

77

Mittwoch, 22. Juli 2009, 09:46

@Helmut: Gratulation und Vielen Dank.

Also hat das bei Dir so funktioniert, wie dort geschrieben, ohne Probleme?

Was mich interessiert ist, was macht das Ding bei einer DX7se?
Diese hat ja 11Bit Auflösung und 11ms Frames. Ich kann mir kaum vorstellen, dass der Satellit dies einfach so an den Empfänger weitergibt, da dann ja sonst der Empfänger speziell wissen muss, dass das Daten einer DX7se sind.
Dann müssten Sie jedoch bereits gewusst haben bei den ersten DSM2 Empfängern, dass Sie Mal eine Spezialvariante rausbringen möchten.

Ich werd's wohl dann einfach Mal ausprobieren. Wenn ich endlich wieder etwas Zeit finde...

haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

78

Mittwoch, 22. Juli 2009, 11:35

Hallo,

im Anhang und nächsten post die Info, wie ich es gemacht habe (gem. den Angaben im RCgroups-thread).

Olli:
Ich hab dir den source-code und das hex-file p. Email geschickt. Ist nicht viel dran (49 words), nach den vorhergegangenen Fehlversuchen auf die Schnelle gestrickt; Timer anwerfen lohnt eigentlich nicht.
Wer den Source-Code sonst noch will, bitte mir Email-Adresse per PN zukommen lassen.

Betrieb: Einfach Sat-Binder und Sat-Rx zusammenstecken und dann Stromquelle (1s-Lipo) an Sat-Binder anschließen. Der Rx blinkt dann im Bind-mode. Rest wie üblich.

Hui:
Ja, hat so auf Anhieb geklappt. Wichtig ist der Transistor zum Einschalten der Sat-Rx-Betriebsspannung. Ich hab versucht, Tiny15 - I/Os (auch parallel geschaltete) dazu zu mißbrauchen, geht aber nicht. Vermutlich können die I/Os nicht genug Strom liefern, der Sat-Rx zieht immerhin ca. 28 mA. Hab´s nicht weiter untersucht.

Wie´s mit DX7se geht, weiß ich nicht. Aber es kann schon sein, daß jeder Tx den Telegrammen eine eigene Kennung mitgibt; s. u. Byte 1. Beim DX5e im "Meta-Signal" steht da noch $00, am Sat-Rx-Ausgang ist es $18.

---------------------------------------------------------------------------------------
Belegung der Kanäle am Sat-Rx-Ausgang mit
Sender DX5e
Byte 1 $18 (immer, Sender-Kennung ?)
Byte 2 $00 (immer)

Weitere Bytes Funktion Adressbits
3,4 Roll 01
5,6 Tastschalter 05
7,8 Nick 02
9,10 Gier 03
11,12 Motor 00
13,14 Kippschalter 04

115,2 kb/s; 23,5 ms frame rate
Man kann hier einfach den "LCD-Monitor" (s. thread bei den Koaxen) dranhängen.
»haschenk« hat folgendes Bild angehängt:
  • Bild1.jpg

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »haschenk« (22. Juli 2009, 11:37)


haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

79

Mittwoch, 22. Juli 2009, 11:46

Und jetzt noch der hex-Code:

:020000020000FC
:1000000008C018951895189518951895189518956D
:10001000189507E801BFBA9AC398C298BB9A17D03F
:10002000C39A1AD0C3980BD0C39A09D0C39807D0EB
:10003000C39A05D0C39803D0C39ABB98FFCF1CE3E3
:100040001A95F1F708951FEF1A95F1F7089527E132
:10005000FADF2A95E9F708952BE7F5DF2A95E9F706
:02006000089501
:00000001FF

Den Source-Code kann ich hier nicht direkt einfügen, da er durch die versaute Formatierung fast unlesbar wird. Der Editor vom AVR-Studio hat eh seine Eigenheiten. Ihr werdet ja wohl auch in C oder BASCOM programmieren.

Aber zur Übersicht noch als Bild im Anhang; ich hab da nur Standard-Header/Deklarationen weggelassen.

Gruß,
Helmut
»haschenk« hat folgendes Bild angehängt:
  • Source.gif

80

Mittwoch, 22. Juli 2009, 12:24

Vielen Dank

Zitat

Wichtig ist der Transistor zum Einschalten der Sat-Rx-Betriebsspannung.


Wieso muss die Betriebsspannung überhaupt schaltbar sein? Geht es nicht den RX einfach normal zusammen mit dem AVR zu speisen?
Das mit dem Speisen aus den IO ist seltsam, 2 parallel müssten eigentlich reichen für 28mA ohne zuviel Spannungsverlust.

Interessant wäre noch, was genau ausgegeben wird, bei einer Empfangsstörung.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Hui« (22. Juli 2009, 12:27)