Fly by Wire in Eigenbauflugzeug Manntragend

[Storchenvogl]

Die Re Zahl wird etwa eine Millionen betragen, das Profil soll ca.10% Dicke haben. Wahrscheinlich ein Clark Y.

Ich bin heute auf diese Seite hingewiesen worden. Ist zwar für Boote aber doch informativ für Fly by Wire und Servos
http://www.tecnautic.com/d/fly_d02.htm#Fly-By-Wire

[oberallgeier]

... Alle meine eigenkonstruierten Flugmodelle (bis 2,2m Spannweite) "kennen keinen Strömungsabriss" ...

Soweit ich die thermodynamischen Vorgänge in Erinnerung habe, ist der theoretisch maximal mögliche cA in der Gegend von 8. Hat wohl mit begrenztem Druckrückgewinn zu tun (aber da kann ich mich irren). Der Sogpeak bei hohen cAs ist ja auch wirklich schrecklich. Leider hat die Thermodynamik immer Recht. Praktisch hatte ich selbst mal im stabilen Flug bei Re=2Mio ein cA knapp 2 erflogen - sehr zur Verwunderung "meines" Luftstuhl-Profs UND des O-ing; beide hatten mit einem Bierkasten auf unter 1,5 - oder waren es 1,4? - gewettet. Da waren auch sicher schon einige aufgeplatze Wirbel im Spiel.

... Das mit dem Generator im Fahrtwind ...

kostet doch 1. Wirkungsgrad, um den Flieger in der Luft zu bewegen - sprich, um Fahrtwind zu erzeugen und 2. Wirkungsgrad, um vom Fahrtwind den Propeller und (3. ... *gggg*) den Generator anzutreiben. Na ja, will ich mal nicht kommentieren.

Die Re Zahl wird etwa eine Millionen betragen ...

Da stell ich mich mal jaaaanz dumm (wie immer): v = 50 m/s, Profiltiefe 0,7 m, dann habe ich ja 2,5 Mio.

... Wahrscheinlich ein Clark Y ...

Ich würde Martin Hepperle fragen, ob er nicht ein hübsches Profil in der Schublade für diese Geschwindigkeit und Flächenbelastung hat, das ein freundliches Überziehverhalten UND eine füllige Druckverteilung in der Art der Laminarprofile hat. Auch Eppler ist ja noch immer wieder im Institut anzutreffen und gibt dazu sicher gerne Auskunft. Und die 10% wirst Du sicher nach dem Vermessen der ersten Modellversion verwünschen.

Im Übrigen finde ich das V-Leitwerk nicht sehr vielversprechend. Bei dem schlechten (etwas sehr eckigen) Rumpfquerschnitt mit der riesigen Haube gibt das wohl schon beim kleinsten Schieben eine deutliche Verschlechterung der Heckumströmung und damit der Leitwerkswirksamkeit, bei V-Leitwerk sicher noch ne drastische Asymmetrie. Ich stell mir dabei ungern die veränderte Steuerwirkung vor. Die markante Seitenwindfläche der Haube - und das soweit vorne - ist ja sicher eines der Probleme der Cricri, insbesondere beim Trudeln.

Sorry, klingt wohl als sei ich heute nicht gut drauf. Aber bei manchen Punkten muss ich meine Argumente vorbringen.

Nachtrag: gerade fällt mir ein prächtiges Argument FÜR das fbw ein: eine erste Flugerprobung könnte man dann als Modellflugzeug, *gggg* scale 1:1, mit einer Fernsteuerung machen.

[Ls4]

Nun da ich für die technische Umsetzung verantwortlich aber nicht gerade der Informatiker bin, meine Fragen!
1. Was sollte man für Rechner nehmen? Ich dachte an Pocketcomputer.
2. Wie kann ich ein Fail-Save hinbekommen?
3. Welche Software wäre sinnvoll?
4. In wie weit muss ich das ganze abschirmen um Störungen durch Funk zu verhindern?
5. Wieviel Strom braucht sowas?
Insgesammt wäre ich für Tipps zur Steuerelektronik dankbar.

Hallo StorchenVogel,

euer ehrgeiziges Projekt in Ehren.
Ich will euch davon auch nicht abbringen.
In welche Gefahr sich jemand begibt oder nicht ist jedes eigenen Entscheidung.

Ich versuche zuerst mal auf deine Fragen einzugehen:
1. das ist eine schlechte Idee.
Auch die Verwendung von normaler PC Hardware ist definitiv nicht zu empfehlen. Alle Geräte haben eins gemeinsam. Sie verkraften die Temperaturen die in Luftsportgeräten auftreten nicht. Leider ziemlich ausnahmslos.
Ich bin selber Segelflieger. Bei einem Wettbewerbsflug ist mir mein PDA im Cockpit abgebrannt. Das war so schon haarig genug. Wenn da die Steuerung dran gehangen wäre, wärs jetzt vorbei.

Viel eher wirst du dich da imm AUtomotive Bereich umsehen müssen. Die Dinger sind für solche Belastungen zugelassen. Viel größere Probleme wirst du aber sicherlich bei der Zulassung bekommen. Du weißt ja selber wie rigoros das LBA auf eine Luftfahrtzulassung der verwendete Komponenten pocht.
Schlagwörter bei der Steuerung werden da auch bei euch ARM und AVR sein...

2. Soweit darfst du es nicht kommen lassen. Redundanz ist das A und O. Die Servos dürfen nicht auf Failsave fahren. Sie müssen jederzeit von einem der mehrfach rdundanten Controller angesteuert werden

3. Berücksichtigt man den Programmieraufwand und dass das ganze zuverlässig und flexibel sein muss würde ich spontan C vorschlagen.

4. Risiko vermutlich eher gering, aber das LBA wird ne Schirmung wollen, wenn mich nicht alles täuscht

5. Das kann man so nicht sagen.... Könnte von wenigen Watt bis zu wirklich großem Stromverbrauch gehen.

Nun noch zu den bedenken meinerseits.

Servos:
Im Modellbaubereich wüsste ich nichts was mir zuverlässig genug wäre um mich selber der Sache anzuvertrauen!
Auch hier ist redundanz angesagt. Wenn eins ausfällt müssen die anderen aber das kaputte Servo auch noch durchziehen können.

Elektronik:
Ohne Erfahrung sehe ich da kaum Chancen sowas zu realisieren. Da sind mehrere Controller erforderlich. Entsprechende Ansteuerungen, Schirmungen, Schnittstellen, Sensorik. Datenblätter lesen studieren. Kompatibilität checken, eventuell herstellen.
Schaltpläne und Layouts entwickeln.
Ich sehe definitiv keine Chance mit erhältlicher Fertighardware sowas aufzubauen

Programmierung:
In Anbetracht der Komplexität sehe ich auch keine Chance, dass unerfahrene sowas in C selber implementieren.
Ich bin studieren Informatik und arbeite mich grade in µC Programmierung ein. Es fällt mir trotz guter Programmierkenntnisse ausgesprochen schwer mich in Die Libraries für die Atmegas einzuarbeiten.
Das ist harter Tobak und nichts was man mal eben lernen könnte.
Der Programmieraufwand ist nahezu gigantisch und durch die notwendige Redundanz wird das definitiv nicht einfacher!

Vermutlich wird euch ein Informatiker alleine nicht helfen können. Ich persönlich würde mich mit so einer Aufgabe hoffnungslos überfordert fühlen. Programmiert bekommen würde ich es mit genug zeit eventuell noch. Die Hardware könnte ich nicht aufbauen.
Dafür braucht es einen versierten Elektroniker mit richtig Ahnung!

Dennoch wünsche ich euch viel Glück für euer Projekt.
Wäre es nicht einfacher eure zu Erwartenden Probleme wie Abrissgefahr und triebwerksausfall durch autonome Systeme zu lösen. Sprich: fällt ein Triebwerks aus, dann schalte anderes auch sofort und automatisch ab.
Das Überziehproblem vielleicht mit ner Überziehwarnung entschärfen?

Ist jetzt sicher nicht die eleganteste Lösung, aber eher möglich zu lösen

Viele Grüße,

Tim

[Storchenvogl]

Im Übrigen finde ich das V-Leitwerk nicht sehr vielversprechend. Bei dem schlechten (etwas sehr eckigen) Rumpfquerschnitt mit der riesigen Haube gibt das wohl schon beim kleinsten Schieben eine deutliche Verschlechterung der Heckumströmung und damit der Leitwerkswirksamkeit, bei V-Leitwerk sicher noch ne drastische Asymmetrie. Ich stell mir dabei ungern die veränderte Steuerwirkung vor. Die markante Seitenwindfläche der Haube - und das soweit vorne - ist ja sicher eines der Probleme der Cricri, insbesondere beim Trudeln.

Der Rumpfquerschnitt ist bei uns eher Oval. Wir lehnen uns nur an die Grille an. Das Trudelproblem der CriCri liegt in der kaum vorhandenen Strömung an Seitenleitwerk. Um die Längsstabilität zu erhöhen soll halt eine Finne unters Heck. Ich hab auch schon über eine Anordnung von zwei Seitenleitwerken F18like nachgedacht. Wird dann aber schwerer hinten.

Sorry, klingt wohl als sei ich heute nicht gut drauf. Aber bei manchen Punkten muss ich meine Argumente vorbringen.

Ich hatte nicht den Eindruck das du schlecht drauf bist! Ich schätze sachkundige Argumente und hab mir auch darüber Gedanken gemacht.
Perfektion ist nur die Angst vor Kritik!

Nachtrag: gerade fällt mir ein prächtiges Argument FÜR das fbw ein: eine erste Flugerprobung könnte man dann als Modellflugzeug, *gggg* scale 1:1, mit einer Fernsteuerung machen.

So haben wir es auch ungefähr geplant. Allerdings muss dabei um das Gewicht zu erhalten ein Dummy ins Cockpit.
Die Reynoldszahl hab ich übrigens so übernommen von meinem Kolegen ohn darüber nachzudenken. Ich hab da noch garnicht nachgerechnet.

Nun noch zu dem Clark Y Profil. Ich selbst tendiere zu NACA 2412 oder was von Eppler. Das NACA ist gutmütig und einfach zu bauen. Die Eppler sind dafür wahrscheinlich bei höheren Geschwindigkeiten besser.

Insgesammt gibt e bishernoch keine konkrete aerodynamische Auslegung.
Erstes Ziel ist die Machbarkeit eines Fly-by-Wire zu prüfen. Der Rest kommt nebenbei dazu.

[Storchenvogl]

Hallo StorchenVogel,

euer ehrgeiziges Projekt in Ehren.
Ich will euch davon auch nicht abbringen.
In welche Gefahr sich jemand begibt oder nicht ist jedes eigenen Entscheidung.

Wir werden uns in keine unmittelbare Gefahr bringen da wir zuerst RC fliegen werden. Das ist bei so einem Winzling mit der geplanten Technologie wohl recht einfach. Ausserdem machen wir uns zur Zeit Gedanken über ein Gesammtrettungssystem wie es in UL´s vorgeschrieben ist. Und wir schliessen auf den Pilot vorher ne hohe Lebensversicherung ab

Ich versuche zuerst mal auf deine Fragen einzugehen:
1. das ist eine schlechte Idee.
Auch die Verwendung von normaler PC Hardware ist definitiv nicht zu empfehlen. Alle Geräte haben eins gemeinsam. Sie verkraften die Temperaturen die in Luftsportgeräten auftreten nicht. Leider ziemlich ausnahmslos.
Ich bin selber Segelflieger. Bei einem Wettbewerbsflug ist mir mein PDA im Cockpit abgebrannt. Das war so schon haarig genug. Wenn da die Steuerung dran gehangen wäre, wärs jetzt vorbei.

Auch deshalb Redunanz! Aber warum brennt z.B. das GPS, das PFD usw. in nem M,K,E..zugelassenen Flugzeug nicht? Wegen entsprechender Auslegung(um die es mir ja hier geht) und Kühlung, denke ich.

Viel größere Probleme wirst du aber sicherlich bei der Zulassung bekommen. Du weißt ja selber wie rigoros das LBA auf eine Luftfahrtzulassung der verwendete Komponenten pocht.

Beim Amateurbau heist die Zulassung ja "Experimentel"
Ich brauche keine zugelassenen Ausrüstungsgegenstände mit Ausnahme des Fahrtmessers, Höhenmessers, Funkgerätes.... soweit mich die OUV da richtig informiert hat.

2. Soweit darfst du es nicht kommen lassen. Redundanz ist das A und O. Die Servos dürfen nicht auf Failsave fahren. Sie müssen jederzeit von einem der mehrfach rdundanten Controller angesteuert werden

Die Ruder in Fail Save fahren währe natürlich fatal. Ich meinte damit sollte ein System defekt sein schaltet automatisch das Backup ein.[/quote]

3. Berücksichtigt man den Programmieraufwand und dass das ganze zuverlässig und flexibel sein muss würde ich spontan C vorschlagen.

Wurde mir auch gesagt. Ich werde mich da wohl mal genauer mit befassen. Nicht nur für dieses Projekt sondern weil es mich interessiert.

4. Risiko vermutlich eher gering, aber das LBA wird ne Schirmung wollen, wenn mich nicht alles täuscht.

Abschirmung muss wegen Funk und Transponder sein!

5. Das kann man so nicht sagen.... Könnte von wenigen Watt bis zu wirklich großem Stromverbrauch gehen.

Eben deshalb möchte ich ja ein kompettes System (Hardware) ausarbeiten.
Damit schon im Vorfeld was überlegt wird und nicht später beim Bau aufeinmal auffällt: "Huch, wo bekommen wir denn den ganzen Strom her?"

Nun noch zu den bedenken meinerseits.

Servos:
Im Modellbaubereich wüsste ich nichts was mir zuverlässig genug wäre um mich selber der Sache anzuvertrauen!
Auch hier ist redundanz angesagt. Wenn eins ausfällt müssen die anderen aber das kaputte Servo auch noch durchziehen können.

Da gibts sehr zuverlässige Servos die man dann entsprechend mechanisch trennen kann damit das Backup nicht noch ein totes Servo mitziehen muss.

Elektronik:
Ohne Erfahrung sehe ich da kaum Chancen sowas zu realisieren. Da sind mehrere Controller erforderlich. Entsprechende Ansteuerungen, Schirmungen, Schnittstellen, Sensorik. Datenblätter lesen studieren. Kompatibilität checken, eventuell herstellen.
Schaltpläne und Layouts entwickeln.
Ich sehe definitiv keine Chance mit erhältlicher Fertighardware sowas aufzubauen

Darüber machen wir uns mittlerweile auch Gedanken. Aber Aufgeben ist nicht. Probleme sind versteckte Möglichkeiten!

Dennoch wünsche ich euch viel Glück für euer Projekt.
Wäre es nicht einfacher eure zu Erwartenden Probleme wie Abrissgefahr und triebwerksausfall durch autonome Systeme zu lösen. Sprich: fällt ein Triebwerks aus, dann schalte anderes auch sofort und automatisch ab.
Das Überziehproblem vielleicht mit ner Überziehwarnung entschärfen?

Ist jetzt sicher nicht die eleganteste Lösung, aber eher möglich zu lösen
Viele Grüße,

Tim

Das wollen wir gerade nicht. Das währe ja zu einfach. Ausserdem ist das Überziehproblem ei der CriCri wohl echt extrem. Auch dieser Bericht befasst sich damit!
http://www.bfu-web.de/nn_41544/DE/Pu...ht_3X225-0.pdf
Gruss zurück Storchenvogel

[SlyD]

Hallo,

Auch deshalb Redunanz! Aber warum brennt z.B. das GPS, das PFD usw. in nem M,K,E..zugelassenen Flugzeug nicht? Wegen entsprechender Auslegung(um die es mir ja hier geht) und Kühlung, denke ich.

Steuergeräte müssen auf Automotive Temperaturbereich ausgelegt sein.
Da braucht man nicht drüber diskutieren.

Standard PC Komponenten - da kann man froh sein wenn die ausserhalb von 0 bis 50 Grad überhaupt noch laufen... die fackeln auch schon mal gerne bei normaler Betriebstemperatur ab wenn ein paar Kondensatoren/Spulen dann doch zu günstig waren


Wenn überhaupt x86, dann ein Industrie Modul das speziell für den angestrebten Temp Bereich ausgelegt ist verwenden - Kontron ( http://de.kontron.com/ ) oder Lippert ( http://www.lippertembedded.com/ ) haben zumindest auf Anfrage auch -40° bis +85° Module. Automotive geht aber eigentlich bis 125°C...


Ihr werdet aber auch nicht drumrum kommen euch da jemanden zu holen der sich mit ARM oder SH4 o.ä. auskennt. Die gibts alle als Automotive Varianten. So ein PC ist für zeitkritische Regelungsaufgaben nämlich nicht gerade 1. Wahl.


MfG,
SlyD

[Ls4]

Hallo nochmal,

Wenn du dir schonmal über die Servos und die mechanische Trenung gedanken gemacht hast, habt ihr ja schonmal ein Problemchen weniger.
Es bleibt aber tatsächlich das mit der Elektronik und der Programmierung.

Mein Tip hierzu wäre:
lade dir mal Eclipse mit CDT herunter http://www.eclipse.org/cdt/
und den passenden MinGW Compiler und arbeite dich ein wenig in die Programmierung ein.
Es reicht vorerst mal PC Progrämmchen für die Console zu entwickeln um sich in die Sprache und Programmierung einzuarbeiten. Ein passendes kurztutorial gibts dann hier:
http://www.cplusplus.com/doc/tutorial/

Wenn dass dann einigermaßen klappt nen kleinen AVR wie den Atmega8 kaufen und beschalten.
Diese Controller sind Vergleichsweise einfach zu Programmieren. Wie gesagt ich arbeite mich da auch gerade ein.
Von dort aus sollte dann ein Umstieg auf andere Controllertypen einfacher erfolgen können.

Ich halte PC-Hardware um es drastisch zu sagen auch für gänzlich ungeeignet. Die komplette X86 Plattform taugt in meinen Augen absolut nicht dafür.

Ihr solltet wenn ihr das wirklich durchziehen wollt Connections zu nem sehr sehr guten Elektroniker, einem Programmierer mit Berufserfahrung im entsprechenden Bereich und vor allem zu jemandem der Platinen ätzen kann aufbauen.

Dann bleibt natürlich auch beim Modellflugvortest ein gewisses Risiko.
Ohne Fehler programmiert niemand.
Manchmal werden Fehler lange nicht aufgedeckt und sind in der Praxis fatal.

Da gibts einge gute Beispiele zu.
Ariane 5 ist abgestürtzt weil die Entwickler dachten eine Integer für die Geschwindigkeitsmessung würde reichen. Ne Integer reicht bis zum Wert 65553. Die Ariane 5 war aber schneller wie die Ariane 4. Also ist die Integer übergelaufen und der Bordcomputer abgestürtzt. Der 2. hatte identische Software und ist ebefalls abgestürtzt. In Folge kam die Rakete vom Kurs ab und drohte zu zerbrechen. Andere Systeme haben das Ding dann automattisch gesprengt.

Mariner 1 (die erste Venus Sonde) ist verlustig gegangen weil ein Programmierer in Fortran anstatt einem Komma einen Punkt geschrieben hat.

Außerdem gab es in der Medizin durch eine falschauslegung der Software für ein Bestrahlungsgerät mehrere Tote.

Der jüngste fatale mir bekannte Fall ist bei BMW aufgetreten.
Da wurde bei einem Steuergerät für den Bremsassistenten die Hardware falsch ausgelegt.
Wenn der Fahrer mit (ich glaube es waren) 90Kg Druck aufs Bremspedal getreten hat hat das Gerät den Geist aufgegeben und auf Notbetrieb geschaltet, was zur Folge hatte dass das Fahrzeug nur noch mit deutlich reduzierter Leistung gebremst hat.

Wie gesagt ich möchte euch nicht abbringen von eurem Vorhaben. Ihr müsst nur genau wissen was ihr das vorhabt.

Ihr begebt euch auf ein Gebiet, dass von anderen Jahrelang studiert wird und in dem noch enorm Forschung betrieben wird.

Bei Fragen könnt ihr euch aber natürlich gerne bei mir melden. Ich finde das Thema wirklich höchst interessant

Viele Grüße,

Tim

[Storchenvogl]

Hallo,

Auch deshalb Redunanz! Aber warum brennt z.B. das GPS, das PFD usw. in nem M,K,E..zugelassenen Flugzeug nicht? Wegen entsprechender Auslegung(um die es mir ja hier geht) und Kühlung, denke ich.

Steuergeräte müssen auf Automotive Temperaturbereich ausgelegt sein.
Da braucht man nicht drüber diskutieren.

Standard PC Komponenten - da kann man froh sein wenn die ausserhalb von 0 bis 50 Grad überhaupt noch laufen... die fackeln auch schon mal gerne bei normaler Betriebstemperatur ab wenn ein paar Kondensatoren/Spulen dann doch zu günstig waren


Wenn überhaupt x86, dann ein Industrie Modul das speziell für den angestrebten Temp Bereich ausgelegt ist verwenden - Kontron ( http://de.kontron.com/ ) oder Lippert ( http://www.lippertembedded.com/ ) haben zumindest auf Anfrage auch -40° bis +85° Module. Automotive geht aber eigentlich bis 125°C...


Ihr werdet aber auch nicht drumrum kommen euch da jemanden zu holen der sich mit ARM oder SH4 o.ä. auskennt. Die gibts alle als Automotive Varianten. So ein PC ist für zeitkritische Regelungsaufgaben nämlich nicht gerade 1. Wahl.


MfG,
SlyD

Danke für die Infos und Links! Das wir die Hardware in der benötigten Qualität nicht im Discounter kaufen können ist uns klar. Wie gesagt die Hardware muss auf die Aufgaben ausgelegt sein. Deshalb ja die "blöden" Fragen.

[Storchenvogl]

Hallo Tim

Hallo nochmal,

Wenn du dir schonmal über die Servos und die mechanische Trenung gedanken gemacht hast, habt ihr ja schonmal ein Problemchen weniger.
Es bleibt aber tatsächlich das mit der Elektronik und der Programmierung.

Mein Tip hierzu wäre:
lade dir mal Eclipse mit CDT herunter http://www.eclipse.org/cdt/
und den passenden MinGW Compiler und arbeite dich ein wenig in die Programmierung ein.
Es reicht vorerst mal PC Progrämmchen für die Console zu entwickeln um sich in die Sprache und Programmierung einzuarbeiten. Ein passendes kurztutorial gibts dann hier:
http://www.cplusplus.com/doc/tutorial/

Wenn dass dann einigermaßen klappt nen kleinen AVR wie den Atmega8 kaufen und beschalten.
Diese Controller sind Vergleichsweise einfach zu Programmieren. Wie gesagt ich arbeite mich da auch gerade ein.
Von dort aus sollte dann ein Umstieg auf andere Controllertypen einfacher erfolgen können.

Ich halte PC-Hardware um es drastisch zu sagen auch für gänzlich ungeeignet. Die komplette X86 Plattform taugt in meinen Augen absolut nicht dafür.

Ihr solltet wenn ihr das wirklich durchziehen wollt Connections zu nem sehr sehr guten Elektroniker, einem Programmierer mit Berufserfahrung im entsprechenden Bereich und vor allem zu jemandem der Platinen ätzen kann aufbauen.

Erst einmal Danke für die Links zu Eclipse und C++!
Ich frage mich was an dem was an Hardware einfach zu beschaffen ist, warum das nicht geeignet sein soll. Ich meine damit nicht billige Massenware aus Fernost. Ich habe SPS Steuerungen an Sondermaschinen gesehen (Ich arbeite im Sondermaschinenbau) die mit Sicherheit komplexer sind wie der Rechner den die Nasa bei den Apollomissionen zur verfügung hatte. Ich könnte mir vorstellen das man sowas durchaus nutzen kann. Ich werde mich nach den Betriebsferien mal mit den bei uns zuständigen Leuten unterhalten. Mal sehen was die sagen. Vieleicht finde ich dort auch Jemand der uns da auch mal mit Rat und Tat zur Seite steht.Servos hab ich mittlerweile sehr Professionelle gesehen. Nichts von Robbbe oder so.
Zum Beispiel sowas
http://www.volz-actuators.com/en/pro...24-30V.php?m=m

Dann bleibt natürlich auch beim Modellflugvortest ein gewisses Risiko.
Ohne Fehler programmiert niemand.
Manchmal werden Fehler lange nicht aufgedeckt und sind in der Praxis fatal.

Da gibts einge gute Beispiele zu.
Ariane 5 ist abgestürtzt weil die Entwickler dachten eine Integer für die Geschwindigkeitsmessung würde reichen. Ne Integer reicht bis zum Wert 65553. Die Ariane 5 war aber schneller wie die Ariane 4. Also ist die Integer übergelaufen und der Bordcomputer abgestürtzt. Der 2. hatte identische Software und ist ebefalls abgestürtzt. In Folge kam die Rakete vom Kurs ab und drohte zu zerbrechen. Andere Systeme haben das Ding dann automattisch gesprengt.

Mariner 1 (die erste Venus Sonde) ist verlustig gegangen weil ein Programmierer in Fortran anstatt einem Komma einen Punkt geschrieben hat.

Außerdem gab es in der Medizin durch eine falschauslegung der Software für ein Bestrahlungsgerät mehrere Tote.

Der jüngste fatale mir bekannte Fall ist bei BMW aufgetreten.
Da wurde bei einem Steuergerät für den Bremsassistenten die Hardware falsch ausgelegt.
Wenn der Fahrer mit (ich glaube es waren) 90Kg Druck aufs Bremspedal getreten hat hat das Gerät den Geist aufgegeben und auf Notbetrieb geschaltet, was zur Folge hatte dass das Fahrzeug nur noch mit deutlich reduzierter Leistung gebremst hat.

Wie gesagt ich möchte euch nicht abbringen von eurem Vorhaben. Ihr müsst nur genau wissen was ihr das vorhabt.

Ihr begebt euch auf ein Gebiet, dass von anderen Jahrelang studiert wird und in dem noch enorm Forschung betrieben wird.

Bei Fragen könnt ihr euch aber natürlich gerne bei mir melden. Ich finde das Thema wirklich höchst interessant

Viele Grüße,

Tim

Ich habe seit heute eine Lichtpausen der CriCri-Baupläne bekommen. Um einen für den Piloten spürbaren Steuerdruck zu simulieren werden da in allen Achsen Expandergummis eingesetzt.
Ich glaube das man das auf elektronischem Weg schon erheblich besser machen kann.
Ich hab da auch eine Idee wie das relativ einfach sein müsste sogar einen Steuerdruck am Stick und den Pedalen aufzubauen. Ich werde Das in Kürze mal beschreiben.
Bei diesem System könnte man auch ohne Computerunterstützung fliegen falls die Software spinnt.
Gruss Storchenvogel

[Storchenvogl]

"Easy Fly by Wire"


Mit dem Poti im Servo wird ja die Servostellung gemessen.
Der Steuerdruck, der beim Force Feedback
aufgebaut wird, wird ja auch von einem Servo aufgebaut.
Also brauche ich, um mit dem Stick das Servo zu bewegen und eine Rückmeldung vom Servo zu bekommen doch nur zwei geeignete "Signalwandler".
Grob gesagt die Schaltung von zwei Servotestern welche gegenseitig arbeiten. Schon hat man doch ein einfaches FBW. Die Signale zum Servo kann man dann mit einem Rechner beeinflussen. Fällt der Rechner aus, ist das FBW in einfachster Form immer noch vorhanden da es ja vom Rechner unabhängig ist. Die Rückmeldung vom Servo zum Stick sollte, um dem Piloten genau das zu vermitteln was gerade am Servo/Ruder passiert nicht vom Computer beeinflusst sein.
Ausserdem hätte im Endeffekt der Pilot immer die Möglichkeit die Einflüsse des Computers zu übersteuern. Ein Aspekt den Airbus-Piloten immer wieder kritisiert haben!
Am Computer währe ja sogar die Option denkbar das jeder Pilot sich verschiedene Setups speichert. Ausserdem könnten Autopilot u.s.w. aufgeschaltet werden.
Irgendwie kann ich nicht glauben das dies alles so kompliziert sein soll wie die meisten, die von unserer Idee hören, einem vermitteln wollen.