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.

JPOP

RCLine User

Wohnort: Saarbrücken

  • Nachricht senden

121

Freitag, 7. August 2009, 12:53

Hi,

Zitat

Original von Flippo
nur damit wir uns richtig verstehen: HH heißt bei mir (regelungstechnisch gesehen) die Vorgabe eines Winkels. Damit ist die Regelgröße der Heckwinkel. In 'Normalmodus' ist ein Kreisel dagegeb bestrebt, die Winkelgeschwindigkeit zu Null zu setzen.. right?

Da sind wir uns nicht einig.
Was Du sagst ist, das die Regelung auf der Winkelgeschwindigkeit läuft. Das ist nicht HH!
HH ist ein Integrator, ja. Der steuert das Heck in die Ursprungsposition zurück nach einer Störung.
So ist mal mein Verständnis.
Unabhängig davon würde ich die Regelug auch auf der Winkelgeschwndigkeit laufen lassen für gleichmässige Piruetten im Vorwärtsflug.

-JP
_________________________________
Against gravity

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »JPOP« (7. August 2009, 13:23)


122

Freitag, 7. August 2009, 16:06

Hallo Philippe,

nein - ich sage, HH ist die Vorgabe eines Winkels. Der I-Anteil im PID alleine macht noch kein HH, das war ein Irrtum. Zugegeben,

Je nachdem, was angestrebt wird, kann die Stabilisierung (und damit die Regelung) Winkel oder Winkelgeschwindigkeit betreffen. Oder, wenn man es weiter ausführt, könnte man einen Zustandsregler mit den Ausgängen Winkelbeschleunigung, Winkelgeschwindigkeit und Winkel implementieren. Auch wenn wir nich alle Größen messen können, können wir den Rest schätzen (Beobachter) und die Regelung auf mehreren Größen laufen lassen. Je nach gewünschtem Verhalten.... Für ein 6-DoF-System würd ich, wie Helmut auch, den Regler auf der höchsten Ebene arbeiten lassen. Sonst wird es für die Erfassung der Translationen noch komplizierter.

Das heißt aber nicht, dass wir uns nicht der Winkelgeschwindigkeit als einer der Reglerausgänge bedienen können...
;-)

Prinzipiell müssen wir uns bei dem Thema über die Frage unterhalten, was das System soll.
Ein V-Stabi (AC-3X, etc.) für Mikrohelis regelt NICHT die Lagewinkel, sondern die Winkelgeschwindigkeiten. Wenn wir das haben möchten, müssen wir die Regelgrößen entsprechend wählen.
Wenn wir einen echten Lage-/Positionsregler wollen, sollten wir, wie oben beschrieben, auf der höchsten Ebene eingreifen, und uns aber der Winkelgeschwindigkeiten als Zustandsgröße bedienen...
Umfangreiches Thema....


Ich lasse mir von Matlab immer die Anteile des Reglers mitschreiben und plotte sie dann.


Gruß

Philip
Misslingt dir voll der Tagesplan, so sei zum Troste dir bekräftigt: Du hast zwar heute nichts getan, doch warst den ganzen Tag beschäftigt!

haschenk

RCLine User

Beruf: Dipl. Ing.

  • Nachricht senden

123

Samstag, 8. August 2009, 00:57

Hallo,

@Hui
Danke für deine Erläuterungen.
Ganz so nieder wäre aber nicht nötig gewesen... Ich stelle (vor allem mir selbst) hauptsächlich die Frage, ob Beschleunigungsmesser -gfls. in Verbindung mit Kalman-Filtern- notwendig und/oder sinnvoll sind. Und mit dem Kalman-Filter tue ich mich noch schwer, trotz Literaturstudium.
Wir verfolgen unterschiedliche Ansätze; bei mir steht die Aerodynamik/Flugmechanik mehr im Vordergrund.


@All
Prakt. jedes Rotor-getragene Fluggerät hat ein mehr oder weniger großes aerodynamisches "pitch-up"-Moment vs. Fluggeschwindigkeit (Eigenschaft des schräg angeströmten Propellers/Rotors); das hat idR statische Stabilität "hinsichtlich der Fluggeschwindigkeit" zur Folge. Leider auch dynamische Instabilität...
Leider ist auch die Kippdämpfung der Rotoren zu klein- aber das ist ein Punkt, an dem ansetzen kann (Stabistange, Aufschaltung von Drehraten-Sensoren u.ä. ).
Beim Heli (eigentlich auch bei Starrflüglern, aber da hat das das keine so große Bedeutung) gibt´s nicht nur "eine", sondern mehrere Stabilitäten, und die sind alle (je nach Flugzustand) von Bedeutung. Hinsichtlich der Bahngeschwindigkeit, hinsichtlich des Lagewinkels, hinsichtlich des Anstellwinkels... wenn wir mal nur die (symmetrische) Längsbewegung betrachten.

Ich nehme mal an, daß in diesem Kreis die "Quaduino"-threads bei RCgroups bekannt sind (da geht es aber nur um Quadrokopter u.ä.); die Jungs sind schon ganz schön weit...
Aber wenn ich mir die Videos so anschaue, dann fällt auf, daß die Teile im Schwebeflug prakt. alle mehr oder weniger "hin- und herschaukeln". Jeder einfache Blade mCX o.ä. kann das viel besser. Am Pilot kann´s eigentlich nicht liegen; ich würde für´s erste auf "nicht passende" v_punkt-Behandlung tippen.

Zum Regel/Steuer-Modus habe ich weiter oben ja schon was gesagt. Das ist halt die Frage, was sich realisieren lässt bzw. unbedingt nötig ist. "Beschleunigungs-Steuerung" ist unfliegbar, "Geschwindigkeis-Steuerung" geht, braucht aber viel Übung, "Lage-Steuerung" ist rel. leicht erlernbar.

Hierbei spielen aber auch Details wie Dämpfung/Anfachung und Frequenz der Schwingungen eine große Rolle. Beispielsweise ist bei Starrflüglern die Nicksteuerung stets eine Lagesteuerung, die Rollsteuerung aber eine Geschwindigkeits-Steuerung. Eine aperiodische ("Divergenz") oder auch oszillatorische Anfachung wird von Piloten idR toleriert und weggesteuert, wenn sie nur "langsam" genug (Halbwertszeit) ist. Aber auch eine hinreichend große Steuer-Autorität (Steuerwirkung) ist sehr wichtig.

Wer sich für solche Dinge interessiert, wird z.B. hier fündig:
K. Kracheel, "Flugführungssysteme- Blindfluginstrumente, Autopiloten, Flugsteuerungen"; Bernard & Graefe-Verlag 1993

X. Hafer, G. Sachs, "Senkrechtstart-Technik"; Springer-Verlag 1982


Gruß,
Helmut

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »haschenk« (8. August 2009, 00:58)


124

Freitag, 14. August 2009, 22:03

Hallo Hui,


Gibt es was neues auf der IME3000 front ? hast du es schon irgendwo zu kaufen gefunden ?

gruss

Marcel

125

Montag, 17. August 2009, 12:30

Sorry für die lange Pause. Gehe diese Woche in die Ferien. Und hatte/habe deshalb viel Vorarbeit zu leisten im Geschäft...
Deshalb bin ich leider auch nicht dazu gekommen, die Boards zu löten. Wird dann wohl erst gemacht, wenn ich wieder da bin (1.September).
Sorry!

Zitat

Ich stelle (vor allem mir selbst) hauptsächlich die Frage, ob Beschleunigungsmesser -gfls. in Verbindung mit Kalman-Filtern- notwendig und/oder sinnvoll sind.


Tja, die Frage stelle ich mir auch. Aber da es eben preislich und "platzlich" :D keine grosse Rolle spielt, kann man ihn problemlos Mal aufs PCB pappen. Falls sich dann zeigt, dass man in der Praxis bei dieser Applikation nichts reisst mit den Sensoren, ist ja dann auch egal. Aber zumindest hat man die Möglichkeit das Mal zu testen.

Zitat

Aber wenn ich mir die Videos so anschaue, dann fällt auf, daß die Teile im Schwebeflug prakt. alle mehr oder weniger "hin- und herschaukeln"

Da ja alle Quadrokopter direkt Motorgetrieben sind, könnte ich mir vorstellen, dass die Trägheiten der Motoren auch nie so eine schnelle Korrektur zulassen, wie ein Pitch-Rotor und deshalb Fehler nicht so schnell korrigiert werden können, wie bei einem Heli. Oder eben die Regelung ist nicht gut. Oder beides :D

Zitat

Gibt es was neues auf der IME3000 front ? hast du es schon irgendwo zu kaufen gefunden ?


Nein, aber zurzeit stehen eh erstmals die Tests der Boards hier an. Und bis wir damit rumflliegen, wird wohl auch der IME3000 lieferbar sein.

Interessant ist, dass mittlerweile die Preise für die ISZ bekannt sind $11.
D.h. IDG+ISZ kommen zusammen auf $31.
Ich schätze nochmals etwa $10 für den IME dann $10 für den Prozessor etwas für den Rest macht dann in etwa $60-$70 Bauteilekosten für das volle System.

BTW:
Nochmals bzgl AD-Auflösung. Hab gerade gesehen, dass der AC3X auch nur 12-Bit AD wandelt und das bei einer 32Bit ARM CPU bei 72MHz...Da würde ich glatt meine rechte Hand und meinen linken Fuss verwetten, dass das dieselbe CPU ist, wie bei diesem Projekt (Bis auf's package).
So gesehen müssten die 12-Bit also reichen, selbst ohne die zusätzliche Mittenverstärkung.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Hui« (17. August 2009, 12:46)


o.dippel

RCLine User

Wohnort: Büdingen / Hessen

Beruf: Software-Developer

  • Nachricht senden

126

Mittwoch, 19. August 2009, 13:03

Wii MotionPlus

Hi Leute,
nochmal kurz zum Thema 'Wii MotionPlus'
Hat jemand ahnung wo ich das Teil ohne Software in DE bekomme

Danke
Olli

127

Mittwoch, 19. August 2009, 13:41

Zitat

Original von Hui

Zitat

Aber wenn ich mir die Videos so anschaue, dann fällt auf, daß die Teile im Schwebeflug prakt. alle mehr oder weniger "hin- und herschaukeln"

Da ja alle Quadrokopter direkt Motorgetrieben sind, könnte ich mir vorstellen, dass die Trägheiten der Motoren auch nie so eine schnelle Korrektur zulassen, wie ein Pitch-Rotor und deshalb Fehler nicht so schnell korrigiert werden können, wie bei einem Heli. Oder eben die Regelung ist nicht gut. Oder beides :D


was ja auch beim Vierdrei & 4G3 am Heck zu beobachten ist...
es muss alles stimmen und selbst dann ist das System meist noch dem Tailpitch System unterlegen
letzteres läßt sich halt schneller und genauer dosieren sofern die Auflösung stimmt
Gruß Phil

128

Mittwoch, 19. August 2009, 17:09

Zitat

Hat jemand ahnung wo ich das Teil ohne Software in DE bekomme


Eigentlich fast überall! Aber schau Mal z:B. bei Amazon nach...

Bzgl Tail-Motoren.
Das wird halt schon so sein, dass ein Tail Motor niemals so korrigieren kann, wie ein Pitch-Heck. D.h. wenn man das ausbrechen verhindern will bei einem 4G3 muss die SW die Pitch-Stell-Geschwindigkeit so verringern, dass der Tail-Motor gerade noch mithalten kann.
Entweder das, oder das Heck dreht sich weg. Da gibt's nicht viel Luft...
D.h. entweder man erlaubt schnelles "Pitch-Pumpen", dann wird sich jedoch das Heck jeweils wegdrehen, oder man begrenzt das "Pitch-Pumpen", dafür hält das Heck.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Hui« (19. August 2009, 17:13)


JPOP

RCLine User

Wohnort: Saarbrücken

  • Nachricht senden

129

Donnerstag, 20. August 2009, 14:12

Hi,

das gehört jetzt nur in sofern hierher als das man so ne Fnktion ja in die SW reinbringen kann:
Beim 4G3 habe ich wg. dem HH Kreisel keine Heck-Mischkurve, sondern ne Grade.
Für den Normal mode stelle ich über diese Kurve den Heckmotor ab. Wenn der Hauptmotor steht.
Im Idle up geht die Kurve ganz außen etwas hoch, um eben etwas Gas zu geben. Das Steuersignal kommt ja doch früher an als das Korrektursignal vom Kreisel. Dadurch, das ich in dem Pitchbereich normal nie Rumfliege geht das ganz OK.. habs halt probiert und finds ganz gut. Er hält bei maxpitch besser.

-JP
_________________________________
Against gravity

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »JPOP« (20. August 2009, 14:14)


130

Sonntag, 23. August 2009, 19:38

Zitat

das gehört jetzt nur in sofern hierher als das man so ne Fnktion ja in die SW reinbringen kann:


...das wird es sowieso geben. Nennt sich z.B. Störgrößenaufschaltung bzw. Feed Forward.

In einem (ideal) identifizierten System ist der Zustandsregler ohnehin 'allwissend', bekommt also Information über sämtliche Stellsignale, Zustandsgrößen, Reglerausgänge etc.


Daher weiß der Regler auch, wann und wie viel das Heck aufgrund von Kollektivsteueranteilen ausbrechen wird und kann entsprechend gegensteuern. Begrenzendes Element ist hier die Dynamik des Steller/Heckmotor-Gliedes und die Steifheit des Hauptantriebsstranges. Wenn der Hauptmotor ein stark nichtlineares Drehzahleinbruchverhalten bei Pitchstößen zeigt, wird es schwierig....

Gruß

Philip
Misslingt dir voll der Tagesplan, so sei zum Troste dir bekräftigt: Du hast zwar heute nichts getan, doch warst den ganzen Tag beschäftigt!

131

Dienstag, 1. September 2009, 16:48

So, bin zurück aus den Ferien...
Wer in den nächsten Tagen sicherlich endlich Mal einen Prototyp in den Reflow-Ofen schieben und die Grund SW machen...

132

Sonntag, 6. September 2009, 18:47

So nun ist der erste Prototyp gelötet. Hab da noch ein paar Sachen gesehen, die ich am Design verändern muss. Die 0603er Kondensatoren sind zu nah beieinander und ziehen sich beim Reflow zusammen. Gab dann ein bissl ein gefrickele mit dem Kolben um das zu korrigieren. Ebenso die beiden 0402er Cs die parallel nebeneinander neben dem IDG sind...

Alles in allem kein Vorzeigestück, aber sollte zumindest (hoffentlich) funzen.

Den zweiten Prototypen für Philip werde ich löten sobald ich vom C die 0402er LED bekomme.

So sieht das Teil nun aus:
»Hui« hat folgendes Bild angehängt:
  • P1030132_klein.jpg

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Hui« (6. September 2009, 18:48)


133

Sonntag, 6. September 2009, 18:51

Das Teil wiegt zurzeit 2.4g. Wiegt aber natürlich mehr, weil ich für's billige Prototyping ja eine ganz normale Platinendicke genommen habe. Der Finale soll dann ja 0.8mm PCB-Dicke haben. Das wird das Gewicht fast halbieren.

Hier sieht man schön die Platinendickenunterschiede zwischen dem Spektrum Sat-RX (mit 0.8er Dicke) und dem Stabi-Board:
»Hui« hat folgendes Bild angehängt:
  • P1030129.jpg

134

Sonntag, 6. September 2009, 18:53

Und hier ein weiteres Bild vom Board zusammengesteckt mit dem Spektrum Sat-RX:
»Hui« hat folgendes Bild angehängt:
  • P1030124_klein.jpg

o.dippel

RCLine User

Wohnort: Büdingen / Hessen

Beruf: Software-Developer

  • Nachricht senden

135

Sonntag, 6. September 2009, 18:59

Super Geil :ok: :ok: :ok: :ok: :ok: :ok: :ok:

Wo bekomme ich denn diese Sat-Empfänger ???

:w

136

Sonntag, 6. September 2009, 19:07

Ja wirklich super!

sat's gibt es hier zB http://www.helidirect.com/spektrum-remot…iver-p-6032.hdx

gruss

Marcel

137

Mittwoch, 16. September 2009, 20:16

So hab heute endlich Zeit gefunden, noch die Adapterplatinen zu machen.
Später würde man es dann wohl so machen, dass man die, jetzt noch unbenutzten USB Pins des uC wohl benutzen würde, um das Ding auch ohne zusätzliche Elektronik an den PC hängen zu können, und auch um keine "alte" RS232 Schnittstelle mehr zu benötigen.
Aber sicherlich muss dann trotzdem kurz zumindest ein Bootloader per RS232 geflsht werden, dass man dann nachher per USB flashen kann!

Für's Prototyping geht's so sicherlich.

Jetzt kann ich endlich programmieren. Wenn da nur nicht wieder das Zeit Problem wäre...
»Hui« hat folgendes Bild angehängt:
  • RS232 Adapter.jpg

138

Samstag, 26. September 2009, 15:52

Selbstbau-Projekt Flybarless-System

Hallo Hui,

ich verfolge Dein 6DOF seit Anfang an, aber ich konnte mich 4 Monate bei RCLine nicht einloggen, dank UMTS...
Im Internet habe ich eine Interessantes Selbstbau-Projekt eines Flybarless-Systems von Dirk Schmidt gefunden. http://3digi.wikidot.com
Bitte schau Dir die HP mal an, vielleicht findest Du einige Interessante Tipps und Lösungen für Dein 6DOF. Das Wiki ist sehr professionell gemacht, mit allen Daten und Anleitungen.

Hoffentlich konnte ich einen kleinen Beitrag zu Deinem "genialen" mini Projekt beitragen

Mfg Steffen
Gruß Frank

139

Dienstag, 13. Oktober 2009, 09:44

Hab jetzt nicht alles gelesen, und hab jetzt nicht 100% rausgefunden welche Gyros ihr nehmen wollt.

Ein Freund ist auf die hier gestoßen: http://www.st.com/stonline/products/fami…/gyroscopes.htm

unter 6€ das Stück hier http://de.mouser.com/Home.aspx
Meine Homepage:
verleihnix.webege.com

140

Mittwoch, 14. Oktober 2009, 09:37

Erstmals, sorry das es nicht vorwärts geht, bin aber im Moment voll ausgelastet privat wie geschäftlich, da unbedingt vor der Kälte unser neuer Wintergarten fertig werden muss...

Zu den neuen ST hab ich schonmal einen Kommentar geschrieben. Falls sie denselben Aufbau wie die Lysis von ST haben, dann sind Sie für diese Anwendung völlig untauglich, da Sie eine sehr tiefe Sensorfrequenz benutzen und deshalb extrem anfällig auf Vibrationen sind.
Ob das bei den neuen auch zutrifft weiss ich nicht, ist aber IMHO sehr wahrscheinlich.

Zum 3digi Projekt: Kannte ich. Aber da ist wieder das für mich unverständliche Problem, dass Sie es nicht OpenSource gemacht haben...

Ich hoffe wirklich diese Woche wird der Wintergarten fertig. Dann muss ich etwas Nacharbeiten geschäftlich und dann kann ich endlich weitermachen. Nochmals Sorry.

EDIT: Hab mir jetzt kurz Mal ein Datenblatt der neuen Gyros von ST angesehen. Leider schreiben Sie nirgends die Sensorfrequenz...(Absicht?)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Hui« (14. Oktober 2009, 09:45)