einfacher Flugroboter (Drohne) in "Komponentenbauweise&

[moritztheile]

Erstmal das Ziel:

Die Idee die mir als begeisterter Modellbauer und beruflicher Software Architekt schon seit geraumer Zeit in meinem Kopf herumschwirrt, ist es ein Modellflugzeug auf einfache Weise zur Drohne aufzuruesten. Das erwuenschte Scenario sieht folgendermassen aus:

Phase 1: Ein Modellflugzeug wird auf herkoemmliche Weise von einem Pilot mit einer manuellen Fernsteuerung gestarted und auf Hoehe gebracht.

Phase 2: Der Pilot aktiviert den roboter modus des Modells woraufhin eine Mission erfuellt wird (z.B. abfliegen einer bestimmten Stecke und Aufnahme von Fotos).

Phase 3: Der Pilot deaktiviert den Robotermodus und landet das Model manuell.

Wie soll das funktionieren?

Vor allem, wie soll ich dieses Unterfangen in meiner knappen Freizeit realisieren? Das ist der Grund warum ich in diesem Forum poste - ich hoffe einige nuetzliche Informationen von der erfahrenen roboternetz community zu bekommen:)

Eine Liste der logischen Komponenten des Systems die fuer den Betrieb in Robotermodus notwendig sind (hier fehlt mir das roboterspezifische Vokabular, ich hoffe das es trotzdem einigermassen verstaendlich ist) :

Steuerungskomponente: enthaelt die Logik, sozusagen das Gehirn

Effektoren: Antrieb, Hoehen-, Seiten- und Querruderservos

Sensoren: GPS, Traegheitskreisel fuer quer-, laengs- und vertikale Achse


Implementierung der logischen Komponenten:

Als Steuerungskomponente koennte meiner Meinung nach ein java programmierter PDA herhalten. (evtl. mit echtzeit java)

Die Effektoren sind kein Problem da sie standardmaessige Modellbaukomponenten sind.

Ebenso die Traegheitskreisel. Das GPS Modul koennte schon im PDA enthalten sein.

Haha, so jetzt kommt der Punkt an dem mein Wissen aussetzt: Wie kann ich die Steuerungskomponente mit den Effektoren und Sensoren kommunizieren lassen???

Wovon ich Traeume ist folgendes: Eine Steckerleiste mit standard Servo Steckbuchsen. Diese ist wie auch immer mit dem PDA verbunden, von dem ich nun mit einer Java Bibliothek nach belieben angeschlossene Effektoren und Sensoren auslesen und ansteuern kann.

Wenn es so etwas gaebe koennte ich mir vorstellen das eingangs erwaehnte Szenario in meiner Freizeit umzusetzen. Es wuerde dann ja "nur " noch darin bestehen die Steuerungslogik und Intelligenz zu implementieren und auf diesem Gebiet fuehle ich mich zu hause. Nicht jedoch mit allem auf Hardware level.

Ich bin fuer jeden Hinweis auf entsprechende "Verbindungsmoeglichkeiten" von PDA mit Servos oder Kreisel sehr dankbar.

Was mich an diesem Projekt besonders reizt ist es eine Drohne mit minimalen Budget und doch respektablen Faehigkeiten zu kreieren. Wenn man bedenkt wie viel Geld in diesem Bereich investiert wird und wie wenig im Endeffekt hinten heraus kommt ist das doch echt verlockend es mal selbst zu probieren... Insbesondere wenn man Modellbauer ist und einer solchen Drohne auch einKunsfflugprogramm beliebiger Schwierigkeitsstufe eingespeist werden koennte ;)

[Jon]

Steuerungskomponente: enthaelt die Logik, sozusagen das Gehirn
Würde ich persönlich keinen PDA nehmen (mir zu teuer) sondern einen ATMEGA.
Den ATMEGA kannst du frei Programmieren, ist klein und hat viele Anschlüsse für servos etc.
Ich würde gleich einen ATMEGA32 nehmen, bei Reichelt für nur 3,50€.



Effektoren: Antrieb, Hoehen-, Seiten- und Querruderservos
Gut über einen ATMEGA zu steuern. Auch sehr genau.



Sensoren: GPS, Traegheitskreisel fuer quer-, laengs- und vertikale Achse
GPS kann man an einen ATMEGA anschließen, erfahrungen habe ich selbst aber nicht. Es gibt im Forum noch andere, die das schon gemacht haben.
Bei Trägheitskreiseln Informiere ich mich gerade noch selbst.



Als Steuerungskomponente koennte meiner Meinung nach ein java programmierter PDA herhalten. (evtl. mit echtzeit java)
Wie gesaget, mir zu teuer. Wenn der Flieger dann doch mal abschmiert, was ich nicht hoffe, wäre der PDA auch noch hops.


Haha, so jetzt kommt der Punkt an dem mein Wissen aussetzt: Wie kann ich die Steuerungskomponente mit den Effektoren und Sensoren kommunizieren lassen???
Wüsste ich bei einem PDA nicht.


Wenn es so etwas gaebe koennte ich mir vorstellen das eingangs erwaehnte Szenario in meiner Freizeit umzusetzen. Es wuerde dann ja "nur " noch darin bestehen die Steuerungslogik und Intelligenz zu implementieren und auf diesem Gebiet fuehle ich mich zu hause. Nicht jedoch mit allem auf Hardware level.
Das wär mit einem ATMEGA leider nötig. Wobei es nicht alzu viel wäre.


Was mich an diesem Projekt besonders reizt ist es eine Drohne mit minimalen Budget und doch respektablen Faehigkeiten zu kreieren.
In der Robotik ist es normalerweise so, dass alles, was man machen will erstmal billig aussieht und dann immer teurer wird.
soll jetzt nicht sein, um dich von deiner Idee abzubringen.


Wenn man bedenkt wie viel Geld in diesem Bereich investiert wird und wie wenig im Endeffekt hinten heraus kommt ist das doch echt verlockend es mal selbst zu probieren...
Probieren kann man es immer und man lernt auch noch viel dabei.

jon

[dennisstrehl]

Zusätzlich zu den Kreiseln wirst du noch Beschleunigungssensoren brauchen, einerseits damit der Controller es merken kann wenn die Kreisel mit der Zeit wegdriften, andererseits muss es auch irgendwie gemessen werden ob das Flugzeug schiebt (das kann man über die seitliche Beschleunigung machen.) Außerdem bemerken die Beschleunigungssensoren Windböen etc. wahrscheinlich schneller.

Als Controller würde wahrscheinlich irgendein Mikrocontroller reichen, vielleicht kann man die einzelnen Bereiche auch aufteilen in Sensoren und Reglung/Aktoren. Das ist wahrscheinlich einfacher als mit nem PDA, da ein PDA wenig Schnittstellen besitzt.

MfG

[Jon]

Auf einen ATMAGA32 (man kann natürlich auch einen anderen Pic nehmen) sollte alles passen. Da müsste man nichts aufteilen. Im Notfall noch einen PCF... dazu und die Ports reichen dicke aus.

jon

[dieta]

Was auch noch sinvoll wäre: Radar, Ultraschall oder ähnliche Sensoren, die den Boden abtasten und vorne und "aufpassen", dass das Flugzeug nicht in einen Wald reinrasselt oder gegen einen Berg fliegt

[ThSteier]

Ultraschall kann man wohl ausschließen. Damit auf größere Entfernungen (was bei Fluggeschwindigkeiten von 50m/s und mehr sinnvoll sein dürfte) a) ein brauchbares Echo und b) eine vernünftige Auswertung zu realisieren, halte ich für ausgeschlossen. Und ein gewisser Herr Doppler will bei diesen Geschwindigkeiten auch noch mitreden... Wobei ich mich gern vom Gegenteil überzeugen lasse.

Und Radar dürfte von der technischen Seite her noch komplizierter umzusetzen sein. Mal was zum Einlesen: Radar-Grundlagen (http://www.radartutorial.eu/index.html). Bei dem Aufwand, der dafür (falls das überhaupt irgendwie machbar wäre) notwendig wäre, kann man das auch gleich als Fertiglösung (http://www.singer-elektronik.de/stock/750661904.html) kaufen. SCNR... ;)

Viele Grüße,
Thomas

[scales]

Ultraschall kann man wohl ausschließen.

das denk ich auch, zumindest mit den Standardmodulen (SRF oder wie die heisen) ist da wohl nichts zu machen,
sobald der merkt dass vor ihm ein Wald ist hängt er schon im Baum



ATMEGA32 (man kann natürlich auch einen anderen Pic nehmen)

sind die Attinys und Atmegas wirklich PICs?
oder sind AVRs und PICs das Gleiche?


also ich würde das Ganze so machen:
du nimmst einen Controller (erstmal egal welcher) und schliest da deine Sensoren usw. an,
dann seh ich zwei Möglichkeiten:
entweder du programmierst komplett alles auf dem Controller,
oder du nimmst ihn nur als "Übersetzer" für die eigentliche Kontrolleinheit wie einen PDA
(kommt drauf an wie komplex deine Aufgaben werden, für GPS würde ich aufjedenfall was höher leveliges nehmen wie einen Controller)

aber einfach einen PDA direkt an die Elektronik anschliesen wird nicht funktionieren,
die ganzen Daten müssen erst von einem Controller abrufbereit seriell zur verfügung gestellt werden

also ohne Elektrotechnik- und Controllerkenntnisse wird das eher nichts

[mirage]

Ohne Elektronik-Kenntnisse würde ich mich an so ein Projekt nicht heranwagen. Wie will man denn all die Sensoren und Aktoren integrieren, wenn man kaum eine Ahnung hat, wie man sowas schaltet?

Ich glaube kaum, dass es hier käufliche Systeme gibt, die einfach nur zusammengesteckt werden müssen. Und wenn, dann unbezahlbar.

[Jon]

sind die Attinys und Atmegas wirklich PICs?
oder sind AVRs und PICs das Gleiche?
Ich weiß nicht, ob es stimmt:
PICs sind Programmierbare Controler.
Also sind AVRs und PICs das Gleiche.

Ich habe aber keine Ahnung, ob das stimmt.
Angaben ohnen gewähr.

jon

[chr-mt]

PICs sind Programmierbare Controler.
Also sind AVRs und PICs das Gleiche.
Nee, nicht ganz ;)
Klar, beide Typen sind programmierbare Controller.
Sind aber verschiedene Controllertypen von verschiedenen Herstellern.
AVR-Hersteller = Atmel, PIC-Hersteller = Microchip
Sind auch nicht im geringsten kompatibel zueinander.
Ein AVR Programm wird also nicht auf einem PIC laufen und umgekehrt.

Gruß
Christopher

[Jon]

Gut.
Jetzt weiß ich endlich auch mal die Definition von PIC und AVR.

jon

[Benedikt.Seidl]

Ohne Elektronik-Kenntnisse würde ich mich an so ein Projekt nicht heranwagen. Wie will man denn all die Sensoren und Aktoren integrieren, wenn man kaum eine Ahnung hat, wie man sowas schaltet?

das würde ich so nicht sagen. irgendwann muss man ja an irgendwas ohne ahnung rangehen. natürlich ist bei so einem projekt das risiko ein bisschen hoch. aber man kann ja mal mit einem servo steuern anfangen.

ich habe zwar immer noch nicht so den durchblick bei der ganzen elekronik sache, aber ich habe festgestellt, wenn man sich richtig reinhängt und ein bisschen datenblätter liest und sich ein bisschen mit google auskennt, dann geht es schon.

SEIDL.

[moritztheile]

Vielen Dank erstmal fuer die zahlreichen Reaktionen.

Jetzt weiss ich, dass

-es Controller wie den 'ATMEGA' gibt, an den ich meine Effektoren und Sensoren anschliessen kann.

-ein Controller sich mit einer niederen Programmiersprache programmieren laesst.

-ein Controller von einem PC oder vielleicht auch PDA ansprechen laesst und sozusagen als 'Übersetzer' zwischen der Steuerkomponente und den Effektoren und Sensoren dient.

Kommentar an Jon: Danke fuer die ausfuehrlich Antwort. Wie ich die Sache jetzt sehe brauche ich den ATMEGA als Controller, aber nicht als Steuerungsmodul. Es wäre wahrscheinlich fast ein Ding der Unmoeglichkeit die Steuerunglogik fuer den ATMEGA zu programmieren. Mit der Nutzung eines PDAs stehen eine Unmenge von Bibliotheken zur Verfuegung (z.B. Java 3D).

Kommentar an scales: Ich suche genau nach dieser Moeglichkeit einer 'Uebersetzung' von Befehlen einer hoeheren Programmiersprache. Es waere super wenn Du vielleicht noch ein paar genauere oder weiterfuehrende Infos haettest!

Kommentare an dennisstrehl: Kannst Du das genauer begruenden wieso die Drohne Beschleunigungsensoren braucht? Ich denke es reicht die Position alle paar Sekunden zu nehmen und aus dem Vektor eine Kurskorrektur zu errechnen. Aber genauer habe ich mir das noch nicht ueberlegt.
Um eine Primaersteuerung zu ermoeglichen die ein Absinken und Aufsteigen des Modells verhindert waere womoeglich ein Hoehenmesser geeigneter.

Kommentar an dieta: Eine Ultraschallabtastung o. ä. des Bodens halte ich mit meinen Mitteln fuer nicht realisierbar. Ausserdem ist es fuer das angestrebte Szenario ueberfluessig.

Kommentar an mirage: Keine Sorge ich hab schon einige Schaltungen entworfen und geloetet. Es ist nur so, dass ich keine Zeit habe mich zu viel damit auseinander zu setzten. Ich habe meine Hoffnung noch nicht aufgegeben einen Controller zu finden der meinen Anforderungen entspricht. Ansonsten werde ich ihn bauen und als Roboterzubehoer verkaufen. Das waere bestimmt ein Verkaufsschlager :)

[dennisstrehl]

Die Besschleunigungssensoren sind imho für die Driftkompensation und (teilweise) für schnellere Erkennung von Lageänderungen nötig.
Wenn man außer den Kreiseln keine Daten hat, dann wird die errechnete Lage mit der Zeit ungenauer. Der Grund ist, dass man das Signal von den Kreiseln aufsummieren (integrieren) muss, um aus den Drehgeschwindigkeiten die Lage zu berechnen. Durch diverse Ungenauigkeiten weicht das Signal vom Kreisel im Mittel immer ein wenig vom eigentlichen Nullwert ab. Dieser Fehler wird auch aufsummiert, und dadurch driftet der Wert dann mehr oder weniger schnell weg.

Ein anderes Problem ist, dass es auch korrigiert werden muss, wenn das Flugzeug schiebt (= seitlich fliegt). Theoretisch korrigiert sich das zwar nach ner Zeit selber, aber ob das so gut funktioniert...

MfG

[moritztheile]

Durch diverse Ungenauigkeiten weicht das Signal vom Kreisel im Mittel immer ein wenig vom eigentlichen Nullwert ab. Dieser Fehler wird auch aufsummiert...

Haelst Du das GPS fuer eine moeglich Alternative zu den Beschleunigungssensoren um die Posistion zu korrigieren?

[dennisstrehl]

Möglich wäre das wahrscheinlich. Ich wüsste allerdings so aus dem Stegreif nicht, wie man die Rechnerei dann machen müsste.

[Felix G]

-ein Controller sich mit einer niederen Programmiersprache programmieren laesst.Naja, definiere "niedere Programmiersprache"...
falls du damit Assembler meinst: ja damit kannst du einen Controller programmieren.

musst aber nicht :mrgreen:
Die AVR Mikrocontroller (zu denen auch die ATmegas gehören) kann man unter anderem auch in C, C++ und Basic programmieren.


-ein Controller von einem PC oder vielleicht auch PDA ansprechen laesst und sozusagen als 'Übersetzer' zwischen der Steuerkomponente und den Effektoren und Sensoren dient.Das ist eine denkbare Anwendung, mit der ein Controller wie der ATmega32 aber nichtmal ansatzweise ausgelastet wäre.


Wie ich die Sache jetzt sehe brauche ich den ATMEGA als Controller, aber nicht als Steuerungsmodul. Es wäre wahrscheinlich fast ein Ding der Unmoeglichkeit die Steuerunglogik fuer den ATMEGA zu programmieren. Mit der Nutzung eines PDAs stehen eine Unmenge von Bibliotheken zur Verfuegung (z.B. Java 3D).Ich behaupte, daß ein ATmega sämtliche nötigen Steuerungsaufgaben im Flugzeug übernehmen kann. Wenn ein ATmega32 das nicht mehr packt, dann vielleicht ein größerer (oder man verwendet 2-3 kleine Controller).

Einen PDA kannst du natürlich trotzdem noch ins Flugzeug bauen, aber eigentlich ist das nicht nötig (ich würde den stattdessen nur dafür benutzen um den Autopilot zu konfigurieren).

Ich würde vielleicht einen Controller für sämtliche Sensoren, einen für die Aktoren und einen für die "höhere Logik" also die Fluglageregelung verwenden. Prinzipiell kann das zwar auch alles ein einzelner Controller übernehmen, aber ich denke es kann nicht schaden wenn man das in logische Gruppen unterteilt.

Gruß,
Felix

[moritztheile]

Ich halte von der Idee der logischen Unterteilung in Gruppen sehr viel!

Nach etwas Stoebern habe ich diesen Controller gefunden: http://www.acroname.com/robotics/parts/S10-MOTO-BRD.html
Wuerde sich der eventuell als Controller fuer die Effektoren eignen? Die Handhabung und Dokumentation kommt mir sehr leicht bzw. gut vor.

Dann brauechte ich noch einen fuer die Sensoren...

[moritztheile]

Dieser Controller schaut ja auch nicht schlecht aus:

http://www.acroname.com/robotics/parts/S1-GP-BRD.html

[AVRboy]

Hi,

ich habe auch scon mal daran gedacht eine Drohne zu bauen allerdings mit so einen Silverlit X-Ufo von Conrad.

bei der einteilung für die controller gebe ich Felix G recht. es ist gut wenn einer die sensoren macht der andere vieleicht die aktoren und der nächste
ist der hauptcontroller.

man könnte auch noch einen vierten zur kommunikation mit hilfe eines "funkmoduls" benutzten der wie bei den amerikanischen predetaor (oder so ähnlich) der nur höhe,lage und poition etc. überträgt.

allerdings sind meine mcu kenntnisse und fähigkeiten noch etwas wenig für so etwas. aber ich arbeite dran und habe sogar schon eine feste vorstellung wie so etwas aussehen könnte.

mfg

[dennisstrehl]

Das Problem ist, das mehrere Controller auch mehr wiegen, und bei nem Modellflugzeug kann die Zuladung (je nach Größe) ziemlich schnell zu Ende sein.

[squelver]

Ich möchte mal eine Idee einbringen zum Thema "Kollisionsschutz" (obs funzt weiss ich nicht)

Ich denke an eine Digicam, evtl. mit Infrarot/ Laserempfindlichkeit. Die Drohne soll ja eine gewisse Flughöhe haben (durch Höhensensor). Mit Hilfe einer Bildverarbeitungssoftware erkennt die Cam gewisse markante Punkte auf ihrem Flug die, wenn die Drohne fliegt sich aus der Mitte des Bildes nach aussen bewegen. Hier wird ständig der Bildinhalt und seiner Geschwindigeit des aus dem Bild laufenden markanten Punkt mit der Fluggeschwindigkeit und der Höhe der Drohne verglichen. Bewegt sich der markante Punkt garnicht oder nur wenig aus der Mitte fliegt die Drohne wahrscheinlich zu tief und besteht je nach Entfernung darauffolgende Kollisionsgefahr. Die Drohne steigt dann bzw. nimmt an Höhe zu.

Was meint ihr? Zu aufwändig? Machbar?

[Ratte]

wenn die markanten punkte farbig markiert sind könnte es gehen. Ansonsten wirst du die Rechenpower eines PCs brauchen (und viel know-how)
Halte ich für sehr schwer.

[squelver]

Vieleicht kann man von der Idee noch abwandeln und ähnliches realisieren?

[Ratte]

wenn man die strecke vorher einmal abfliegt und dabei aufnahmen von bestimmten punkten macht und dann die strecke nochmal abfliegt, könnte es einfacher sein.

[Felix G]

Ich halte von der Idee der logischen Unterteilung in Gruppen sehr viel!

Nach etwas Stoebern habe ich diesen Controller gefunden: http://www.acroname.com/robotics/parts/S10-MOTO-BRD.html
Wuerde sich der eventuell als Controller fuer die Effektoren eignen? Die Handhabung und Dokumentation kommt mir sehr leicht bzw. gut vor.

Dann brauechte ich noch einen fuer die Sensoren...Also für die Leistung finde ich das Ding zu teuer...


1. auf dem Controller läuft ein Interpreter, was meiner Meinung nach reine Ressourcenverschwendung ist. Ich behaupte mal, daß ein ganz normaler mit 16MHz getakteter (in C oder Assembler programmierter) ATmega schneller sein kann als dieser 40MHz Controller. (man vergleiche mal die "9000 instructions per second" vom teuren Controllerboard, mit den bis zu 16 Millionen Befehlen pro Sekunde die ein normaler ATmega schaffen kann)

2. das Board ist auf eine ganz spezielle Anwendung ausgelegt: die Ansteuerung von 2 Servos. Denn außer den beiden PWM Anschlüssen, gibt es wenn ich das richtig sehe nur einen(!) digitalen Ein-/Ausgang und einen AD-Wandler mit einem Kanal (die meisten ATmegas haben 8 AD-Kanäle)


Falls du damit also nur ein paar Servos ansteuern willst, würde ich doch eher sowas wie das Micro Servoboard (http://www.shop.robotikhardware.de/shop/catalog/product_info.php?products_id=118) von www.robotikhardware.de empfehlen. Das ist ein kleines Board mit dem du 8 Servos ansteuern kannst. Es lässt sich zwar nicht programmieren, aber das ist ja auch nicht wirklich nötig, da du es ja nur über die serielle Schnittstelle mit den gewünschten Servopositionen füttern musst.


Was dann noch fehlen würde wäre ein Controller für sämtliche Sensoren und einer der die eigentlichen Steuerungsaufgaben übernimmt (also das "Gehirn"). Beides erfordert Controller bzw. Controllerboards die flexibel einsetzbar sind, und nicht auf eine bestimmte Anwendung zugeschnitten. Da wäre es natürlich optimal wenn du entweder nur die "rohen" Controller nimmst (die schwarzen Käferchen mit ihren vielen Beinen, die natürlich ohne passende Beschaltung erstmal genau garnichts tun), oder eben universell einsetzbare Controllerboards. (letzteres ist zwar bequemer, aber da ist auch immer überflüssige Hardware mit drauf, wodurch der Flieger schwerer wird)


Gruß,
Felix

[dennisstrehl]

Das könnte übrigens vielleicht noch hilfreich sein:

https://www.roboternetz.de/wissen/index.php/Regelungstechnik

[moritztheile]

Eine kleine Bitte: Ich finde Eure Vorschlaege in Bezug auf moeglich Erweiterungen (Ultraschallbatastung des Bodens, Kollisionsverhuetung mit Bilderkennung, etc.) sehr kreativ. Hauptsaechlich bin ich jedoch erstmal an Informationen interessiert die die Umsetzung des Eingangs erwaehnten Szenarios dienlich sind. Eure Ideen sind komplex genug fuer einen eigenen Thread ;)

Kommentar an dennisstrehl: Das Gesamtgewicht aller Komponenten darf mit dem derzeit geplanten Modell ca. ein halbes Kilo sein. Wenn die Elektronik mehr wiegen sollte wird eben ein groesseres Flugzeug genommen. Das Gesamtgewicht des Flugzeugs darf jedoch die 5kg Grenze nicht ueberschreiten da ansonsten andere rechtliche Bedingungen gelten.

Kommentar an Felix G: Das Micro Servoboard von www.robotikhardware.de ist doch genau das wonach ich gesucht habe :)
Vielleicht noch einen aehnlich guten Tipp fuer den Sensorcontroller?

[moritztheile]

Eine weitere Frage: Um von dem manuellen Modus in den Robotermodus und umgekehrt zu schalten brauch ich eine Vorrichtung die meine Effektoren vom RC-Empfaenge auf den Controller umschalten kann.
Im Endeffekt koennte es dann so aussehen, dass auf den Controller geschaltet wird, sobald kein RC-Signal mehr da ist. Das heisst, umschalten in den Robotermodus erfolg durch ausschalten des Senders.

Hat irgendeiner ein Patentrezept fuer so einen ControllerSwitch? Zuverlaessigkeit ist hier von besonderer Wichtigkeit!!!

[dennisstrehl]

Die Umschaltung würde ich zwecks Zuverlässigkeit nicht im Controller implementieren, sondern in einer Digitalschaltung, die zwischen den Ausgangssignalen vom Controller und den Signalen vom RC-Empfänger umschaltet. Zur Umschaltung würde ich einen Kanal der Fernbedienung nutzen.
Oder willst du das Ding außerhalb der Senderreichweite fliegen lassen? Das würde ich mir gut überlegen.

Das Signal, dass gerade manuell geflogen wird, sollte aber auch an den Controller weitergegeben werden, um eben diesen nicht völlig zu verwirren.

[moritztheile]

Die Umschaltung würde ich (...) in einer Digitalschaltung (...)

irgendeine Idee wie ich diese Digitalschaltung realisieren kann?


Oder willst du das Ding außerhalb der Senderreichweite fliegen lassen? Das würde ich mir gut überlegen.

Schaun wir mal :-)


Das Signal, dass gerade manuell geflogen wird, sollte aber auch an den Controller weitergegeben werden, um eben diesen nicht völlig zu verwirren.

Ich verstehe die Bedenken, aber ich bin der Meinung dass die Steuerungskomponente auf alle Faelle stabil genug sein muss mit so einer Situation zurecht zu kommen. Eine Anforderung sollte sein, dass sie die Steuerung aus einer beliebigen Flugsituation uebernehmen kann (Vielleicht nicht gerade Trudeln...).

[Manf]

Oder willst du das Ding außerhalb der Senderreichweite fliegen lassen? Das würde ich mir gut überlegen.
Da es gerade angesprochen wurde: Im allgemeinen gibt es zu viele Warnungen vor unzulässigen Versuchen, da es hier gar keine gab will ich es nur anmerken. Wenn das Modell für automatischen Flug ausgrüstet ist und außer Kontrolle gerät dann kann es unter anderem Störungen im Straßenverkehr auslösen.

Wenn beispielsweise ein Fahrer eines Gefahrentransports oder eines Reisebusses dadurch beeinträchtigt wird dann wird man kaum noch prüfen ob er 5min später nicht sowieso am Steuer eingeschlafen wäre sondern die Schuldfrage schnell klären.

Vielleicht soll das ganze aber in Australien stattfinden und die Sorge ist völlig unbegründet, dass der Versuch mit der Öffentlichkeit in Kontakt kommt.
Manfred

[dennisstrehl]

Für die Umschaltung bimmt man einen CMOS-Baustein 4019 (Bei Reichelt: "MOS 4019"). Datenblatt: hier (http://www.ortodoxism.ro/datasheets/philips/HEF4019BN.pdf). In der ersten Abbildung sind oben die Eingänge, links sind die Eingänge zum Umschalten (einer der beiden muss jeweils High-Pegel haben), unten sind die Ausgänge. Wenn 4 Kanäle nicht reichen sollten, dann nimmt man halt 2 davon.
Für die Umschalteingänge braucht man also immer entgegengessetzte Spannungen. Der eine Kanal vom Empfänger kommt also an den einen Umschalteingang. Der andere Umschalteingang wird über einen Invertierer (Kann man im Grunde einfach mit nem Transistor und zwei Widerständen aufbauen) an den gleichen EMpfängerkanal angeschlossen.

Vorraussetzung: Das Signal, das am Empfänger rauskommt, müsste dazu ein Digitalsignal mit 0V / 5V-Pegeln sein und kein Servosignal. Wenn das nicht der Fall ist, dann muss zwischen Empfänger und Umschalter noch ne Schaltung zum "dekodieren" der Servosignale.

[moritztheile]

Super!!! Das erinnert mich ja an Zeiten wo ich mit TTL rumgespielt habe. Es ist die perfekte Loesung. So einfach...
Der MOS 4019 in Verbindung mit einem fail save element (http://www.conrad.de/goto.php?artikel=225304) und einem elektronischen Schalter (http://www.conrad.de/goto.php?artikel=225126) sollte genau den erwuenschten Effekt bringen.

Im Falle des Signalverlusts (z.B. Ausschalten der Fernsteuerung) triggert das fail save Element den Schalter, der wiederum den MOS4019 ansteuert...

Ja also ich muss mich herzlich bedanken. Ich sehe die ganze Sache schon um einiges klarer. Das war natuerlich erstmal die nur die Spitze vom Eisberg. Die grossen Herausforderungen wie der Anschluss und Auswertung der Sensorik und die Einbindung in ein Regelsystem kommen ja erst noch. Schaetze da wird es dann ein bisschen schwieriger.
Aber fuer die naechste Zeit bin ich erst mal beschaeftigt die bisherigen Erkenntnisse umzusetzen. Ein Schritt nach dem anderen ;)

[Felix G]

Kommentar an Felix G: Das Micro Servoboard von www.robotikhardware.de ist doch genau das wonach ich gesucht habe :)
Vielleicht noch einen aehnlich guten Tipp fuer den Sensorcontroller?Ich fürchte für die Sensoren wirst du keine Fertiglösung finden, da die einfach zu unterschiedlich sind. Da heisst es dann selbst Hand anlegen, und eine eigene Schaltung (+ die passende Software) entwickeln.

Aber das ist alles kein Hexenwerk...
Die meisten Mikrocontroller kannst du ganz bequem in C programmieren, und schaltungstechnisch sollte es auch nicht so kompliziert werden.

Gruß,
Felix

[wintom]

Wie wäre es mit einem PC104 System (http://www.pc104.org) statt eines PDAs für den Kern? Da gibt es dann jede Menge serielle Schnittstellen in alle Richtungen. Außerdem spart es Gewicht und Kosten. \:D/
Für den "Umschalter" würde sich eventuell ein Blick auf einen fertigen Diversity Empfänger (http://www.acteurope.de/html/dds-10_system.html) lohnen.
Ein Differential GPS würde die Genauigkeit der Positionsbestimmung deutlich erhöhen. Entsprechende Module mit Frequenzen über 1/s gibt es von uBlox (http://www.u-blox.com/products/Data_Sheets/RCB-4H_Data_Sheet(GPS.G4-MS4-06034).pdf) und Novatel (http://www.novatel.com/Documents/Papers/SUPERSTAR.pdf).
Ich kenne mich ja mit der Luftfahrt nicht aus, aber benötigt man für die KI nicht Luftdaten, wie z.B. Anströmwinkel? Da müßte man sich wohl selbst etwas mit Drucksensoren basteln, sonst wirds teuer... Und eine Inertial Measurement Unit?? :-k
Vielleicht sollte man auch ein Funkmodem (http://www.sparkfun.com/datasheets/RF/HAC-LN96.pdf) einplanen, das einem direkt die Daten aus dem Rechner zur Bodenstation schickt (>1500m Reichweite!). Darüber könnte man sich z.B. auch Videobilder senden für das ultimative live Erlebnis :shock:
Meine Idee war ein Flugzeug zu bauen, dass sich über UMTS fernsteuern läßt und das seine Akkus per Solarzellen voll hält. Aber ich bezweifle, dass sich das im zeitlichen und finanziellen Rahmen eines Hobbys realisieren läßt. Außerdem läßt die Rechtslage das Fliegen außer Sichtweite eh nicht zu (was sehr vernünftig ist :!:).
Dir wünsche ich mehr Mut und Durchhaltevermögen. Jedenfalls sind die Dinger so teuer, weil ein paar Mannjahre Arbeit drinstecken.