Quadrocopter Eigenentwicklung

Status
Nicht offen für weitere Antworten.

Vampire

Erfahrener Benutzer
#21
Hi!

Da bin ich auch überfragt. Was ich aber sagen kann ist, dass die Sendeleistung im Rahmen der gesetzlichen Regelung in Deutschland liegt. Ob die Reichweite wirklich so groß ist, werde ich noch testen und hier berichten. Fragt sich nur wie.... ich brauche nen Kumpel und zwei Standorte die so weit auseinander liegen und Sichtverbindung haben ;-). Kann also alles noch etwas dauern :)

In der Zwischenzeit habe ich aber die Centerplates in 3D entworfen. Ein Freund von mir, der sich eine CNC Fräse selbst gebaut hat, wird sie mir fräsen, ich bin schon gespannt auf die Quallität. Hier mal eine stilisierte Perspektivansicht der 3D Daten. Nix Besonders, ganz schlicht für den Anfang. Und ja, ich bau den Rahmen nun doch selbst, anstatt ihn zu kaufen.

Gruß, Markus
 

Anhänge

Zuletzt bearbeitet:

Vampire

Erfahrener Benutzer
#22
Fernsteuerung: Displayeinbau

Hallo Leute!

Da meine heißersehnte Reichelt Bestellung vorgestern endlich angekommen ist, konnte ich gestern das Display einbauen. Doch zuvor ein paar Infos zu dem Display. Es ist von der Firma "ELECTRONIC ASSEMBLY" und hat die Bezeichnung "EA eDIP240J-7LWTP":

* Auflösung 240x128 Pixel
* Touchpanel (analog)
* 5V Betriebsspannung
* Ansteuerung über serieller Schnittstelle (UART, I²C oder SPI)
* Hintergrundbeleuchtung stufenlos einstellbar
* Stromverbrauch ohne Hintergrundbeleuchtung: 75mA
* Stromverbrauch mit Hintergrundbeleuchtung: 210mA

Das hört sich im Handyzeitalter erstmal recht unspektakulär an aber das Besondere an diesem Display ist, dass es bereits Intelligenz an Board hat. Es hat einen integrierten Speicher, in den Grafiken und ganze Bildschirmseiten gespeichert werden und über ein einfaches Protokoll angezeigt werden können. Ebenfalls integriert ist ein Textsatz in verschiedenen größen sowie Grafikfunktionen, sodass man direkt mit Befehlen wie "printf()" oder drawLine(X1, Y1, X2, Y2) arbeiten kann. Der Hersteller bietet zudem eine PC Software an, mit der man diese Inhalte bequem konfigurieren kann. Darüber lassen sich auch Touchflächen und Events dazu definieren, sodass die Entwicklungsarbeit auf dem ATXMega128 bzgl. der Displaydarstellung minimiert wird. Wie genau das Display elektrisch verbunden wird dazu komme ich in einem späteren Beitrag. Heute soll es ausschlißlich um den Einbau in die Fernsteuerung gehen.

Nachdem die besagte Bestellung angekommen war, hatte ich endlich die passende Einbaublende in der Hand. Sie besteht aus edlem schwarz eloxiertem Aluminium wie man auf Bild 1 schön sehen kann. In der Blende wird das Display über eine Lochrasterplatine und vier M3 Schrauben exakt fixiert (Bild 2). Die Blende hat ebenfalls Befestigungsgewinde, um sie am Fernsteuerungsblech zu befestigen.
Das Loch für das Display und Blende habe ich ausgefräst mit einem zylindrischen 2mm Fräser wobei ich das Blech per Hand bewegt habe....recht mühsam möchte man meinen aber es hat gut geklappt (Bild 3). Nachdem ich das Display festgeschraubt hatte, habe ich probehalber mal ans Labornetzteil angeschlossen (5V) und siehe da: Alles klappt. Und das Display enthält sogar noch meine alte Software, welche ich für mein altes RC Car entwickelt hatte :) (Bild 4). Man sieht auch, dass der Kontrast recht ordentlich ist, was für Draußen besonders wichtig ist. Auf Bild 5 sieht man nochmal die Funke in ihrem aktuellen Bauzustand.

Viele Grüße,
Markus
 

Anhänge

Zuletzt bearbeitet:

Vampire

Erfahrener Benutzer
#23
Funkmodule eingelötet

Nochmal ich.

Ich habe soeben die Funkmodule eingelötet (genauer gesagt die Sockel dafür). Leider haben die Funkmodule ein Pin-Rastermaß von 1,27mm, sodass diese nicht einfach so in einer 2,54mm Lochrasterplatine eingelötet werden können. Da sie allerdings genau die Hälfte des Platinenlochrastermaßes haben, konnte ich einfach 0,5mm Löcher genau zwischen die jeweiligen Lochrasterplatinenlöcher bohren, sodass die Sockel nun doch ohne größere Anpassungen bestückt werden konnten (Bild 1 und Bild 2). Ich habe ausserdem jeweils eine Reihe Lotpunkte vom Kumpfer entfernt, um mehr Spiel bei der Leitungsverlegung später zu haben ohne eine Kontaktbrücke zu riskieren.

Bild 3 zeigt das aktuelle Gewicht der Coptersteuerplatine (FlightControl). Bild 4 stellt die Rückseite der Fernsteuerungsarmatur dar. Oben das Display und die Joysticks, unten die Steuerplatine.

Gute Nacht,
Markus
 

Anhänge

Zuletzt bearbeitet:
Erhaltene "Gefällt mir": Toto

kirschi

Händler
Händler
#24
:eek: Wow, das ist mal ein fettes Projekt was du dir da angetan hast! Ich lese schon seit dem ersten Post mit und freu mich immer auf Updates. Weiter so! :)
 

Vampire

Erfahrener Benutzer
#27
Kommunikationsprotokoll Basis (Spezifikation)

Hi!

Das freut mich sehr, dass Ihr dabei seid :)! Hatte am Anfang gedacht, das Hardware und Software für die Meisten eher nichts ist aber ich finde es schön, dass sich hier selbst dafür jemand interessiert :).

OK, also kommen wir auch gleich zum Thema. Ich habe ein Kommunikationsprotokoll spezifiziert als Basis für die Kommunikation zwischen Fernsteurung und Copter und die möchte ich hier dokumentieren.Mit anderen Worten: Jetzt kommt richtig schön trockener theoretischer Stoff :-D.

Normalerweise müsste ich an dieser Stelle zuerst ein wenig auf die Einstellungsmöglichkeiten des DNT24P Funkmoduls eingehen aber dazu hab ich grad keine Lust. Das hole ich in einem anderen Beitrag nach. Wichtig zu wissen ist eigentlich erstmal nur, dass ich die Funkmodule als "Kabelersatz" (Cable Replacement) verwenden möchte. Das bedeutet, die Daten, die man auf der einen Seite (z.B. Fernsteuerung) reinschiebt, bekommt man auf der anderen Seite (z.B. Copter) genauso wieder raus. So als ob man ein RS232 Kabel zwischen zwei Geräten angeschlossen hat und Daten austauscht.

Die kleinste zu Übertragende Dateneinheit bei einem UART (Universal Asynchronouse Receiver Transmitter, über diese Schnittstelle werden die DNT24P Module an dem ATXMega128 angeschlossen) ist ein Byte (8 Bit). Sprich, wenn man ein Byte mit dem Wert 3 in der Funke zum Funkmodul über den UART sendet, wird ein Byte mit dem Wert 3 im Copter über den UART, an den das Funkmodul angeschlossen ist, empfangen. Bild 1 veranschaulicht diese grobe Kommunikation.
Angenommen man ginge naiv an so eine Kommunikation heran und überträgt einfach nacheinander die vier wichtigen Steuerkanäle (Speed [Gas], Rudder [Drehen], Elevator [Pitch] und Aileron [Roll]) zyklisch. In einer Idealen Wert wäre alles in Ordnung, alle Daten kämen perfekt beim Copter an und alles könnte perfekt interpretiert werden. Leider befinden wir uns nicht in einer perfekten Welt, denn:

* Über die Kommunikationsstrecke (sei es Kabel oder Funk) können die Daten verfälscht werden.
* Einzelne Bits können kippen.
* Bits können falsch erfasst werden vom Sender.
* Andere Funksignale können die Übertragung stören und verfälschen.
* Die UARTs könnten wegen ihrer assynchronheit zeitliche Fehler verursachen
* ... usw.

Aus diesen Gründen ist für eine sichere Datenkommunikation ein Übertragungsprotokoll erforderlich. Kommunikatiojnsprotokolle haben üblicherweise eine Startkennung (Zum Erkennen, wann ein Datenpaket anfängt) und eine Checksumme (Checksum, zum Überprüfen, ob der Paketinhalt korrekt empfangen worden ist). Im Falle des Kommunikationsprotokolles für meinen Copter habe ich ein einfaches Basisprotokoll spezifiziert (wie in Bild 2 zu sehen). Dabei habe ich mir überlegt, was für die Steuerung eines Copters am wichtigsten ist: Die vier Steuerwerte:

* Speed
* Rudder
* Eleveator
* Aileron

Daher wollte ich diese vier Werte innerhalb eines einzelnen Paketes übertragen können und zwar mit einer ausreichenden Genauigkeit. Ich wählte den Datentyp "signed short", er ist zwei Byte lang und hat einen Wertebereich von -32768 bis 32767 (2 hoch 16). Das ist mehr als Ausreichend. Mit den ADC des ATXMega128 kann ohnehin nur ein Wertebereich von 12 Bit (2 hoch 12 = 0 bis 4096) erfasst werden. Ein Byte für jeden Wert reicht leider nicht, da dann nur ein Wertebercih von -128 bis 128 möglich wäre (2 hoch 8). Eine weitere wichtige Anfordeung für mich ist, dass ein Paket immer die gleiche Länge hat. Das Problem hier ist, dass wenn die Startkennung eines Paketes innerhab der Datenbytes entahlten ist, würde dies als Paketanfang erkannt werden und das eigentliche Paket wäre verloren. Daher versucht man die Starterkennung innerhalb der Datenbytes während der Übertragung zu vermeiden durch Byte Stuffing. Leider wird ein Paket dadurch größer, was für eine Echtzeitkommunikation für den RC Modellbau nicht praktikabel ist.
Ich habe mir daher ein eigenes Konzept überlegt mit dem kleine Datenmengen ohne Paketverlängerung übertragen werden können und bei dem die Startkennung nicht innerhalb der Datenbytes auftauchen kann.

Dazu definierte ich ein Byte mit dem Wert 01XXXXXX(binär) als Startkennung. Die X stehen dabei für irrelevante Bits. Die sechs X dieser Startkennung können also genutzt werden, um einzelne Datenbytes innerhalb des Paketes zu maskieren (sollten diese in den ersten beiden Bit den Wert "01" haben). Da die vier Steuerwerte + der Checksumme insgesamt 9 Byte sind und nur sechs Byte der Startkennung genutzt werden können habe ich kurzerhand entschieden, zwei Byte mit der Startkennung zu verwenden, im Falle eines Paketes mit den Haupt Steuerdaten. Bild 2 zeigt wie die Bits und Bytes verwendet werden.

Desweiten habe ich einen Pakettyp definiert, welcher nur mit einem Byte Startkennung auskommt, um 0 bis 4 Nutzbytes zu übertragen. Der Identifier spezifiziert dabei den Inhalt des Pakets (z.B. AKKU Spannung, GPS Koordinaten, Befehl zum halten der aktuellen GPS Position, usw.). Die Länge gibt an, wieviele Nutzbytes im Paket enthalten sind. Die genaue Interpretation dieser Werte wird von einer darüberliegenden Schicht übernommen und spielt für das Baisprotokoll keine Rolle. Hier sind sozusagen nur die Haupt Steuer Daten Pakete und Pakete für das Übertragen generelleler Daten spezifiziert. Als spezielles Paket kann das "Acknowledge Paket" betrachtet, werden, welches den Empfang eines generellen Datenpaketes anhand des Identifiers bestätigen soll. Das ist wichtig für Befehle wie "Aktuelle GPS Position halten". Denn stellt man sich vor, man betätigt an der Funke den Knopf für das "Halten der aktuellen GPS Position" und das Paket ist nicht korrekt vom Copter empfangen worden, dann würde weiterhin die Funkensteuerung aktiv sein, der Pilot denkt aber der Copter hält sich nun automatisch. Das wäre fatal. Daher müssen einige Pakettypen bestätigt werden. Die Logik dafür muss allerdings eine übergeordnete Auswertungsschicht übernehmen.

In Bild 2 sind alle Pakettypen beschrieben. Ich hoffe das evtl. der ein oder andere das alles versteht und wenn nicht ist es auch nicht schlimm :). Dann hab ich wenigstens meine Doku hier :p.

Viele Grüße,
Markus


Kleiner Nachtrag:
Sicher fragen sich nun einige: "Was passiert eigentlich, wenn ein wichtiges Datenpaket mit den Hauptsteuerdaten nicht richtig empfangen worden ist?". Das ist eine gute Frage. Also: Ich plane die Hauptsteuertdaten mit 50Hz zu übertragen, sprich: Die Hauptsteuerdaten werden 50 Mal in einer Sekunde übertragen. Das ist etwa doppelt soviel wie es nötig wäre, denn der Mensch ist träge und kann ohnehin nicht mehr als 25 Änderungen in einer Sekunde wahrnehmen (Wie beim TV Bild). Angenommen ein Steuerdatenpaket wird nicht korrekt empfangen, dann gibt es zwei Möglichkeiten.

Erstens: Das Paket könnte neu angefordert werden. Allerdings würde das den Kommunikationsfluss behindern, denn nachfolgende Pakete mit neuen wichtigen Steuerdaten müssten sich hinten anstellen. Ausserdem: Was soll der Copter mit "alten" Daten anfangen. Er könnte sich höchsten sagen: "Tja, vor XXX Millisekunden hätte ich eigentlich in die und die Position fliegen sollen..." aber das Hilft ihm dann auch nicht mehr :p.

Zweitens: Ein nicht korrekt empfangenes Paket wird einfach ignoroert und das nächste aktuelle Paket wird ausgewertet. Diese Möglichkeit macht mehr Sinn, denn alte Pakete sind nicht mehr anzuwenden. Die Copterregelung kann auch ohne Probleme eine geringe Anzahl fehlerhaft empfangener Pakete verkraften. In dieser Zeit wird einfach der zuletzt korrekt empfangene Wert verwendet. Wichtig ist aber, dass ein FailSafe eingebaut wird, sollte die Kommunikation über eine gewisse Zeit nicht mehr gegen sein. In diesem Fall sollte der Copter so intelligent sein und seine aktuelle Position einfach anhand von GPS Daten halten oder besser noch zu seinem Startpunkt automatisch zurückkehren. Aber das ist ein anderes Thema und wird in einem späteren Beitrag behandelt (Jahaaaa, ich glaube das wird mein Lieblingsspruch... "Wird in einem anderen Beitrag behandelt..." :p). Wenn man so darüber nachdenkt wird einem erst klar, was alles in so einem Projekt drin steckt und was beachtet werden muss. Ich denke vielen sind die Hintergründe gar nicht klar, wenn man die Steuerplatinen einfach kauft.
 

Anhänge

Zuletzt bearbeitet:

Vampire

Erfahrener Benutzer
#28
Rahmenbau

Hallihallo ihr Flieger / Schweber!

Nachdem mein letzter Beitrag sehr theoretisch war habe ich heute für Euch 100% Praxis :). Und zwar sind die Centerplates fertig, die mein Kumpel mir gefräst hat (Bild 1). Dafür nochmal herzlichen Dank. Ich finde das ist quallitativ mehr als ausreichend für meine Zwecke und was noch das Tolle daran ist: Die Fräse hat er sich selbst gebaut. Also sind die Centerplates also doppelt selbstgebaut :). Die Maße weichen maximal geschätzte 0,1mm bis 0,2mm an einigen Stellen ab.

Ich habe also den Rahmen testhalber aufbauen können. Dazu zeigen die Bilder 02 bis 11 die einzelnen Bauschritte:

Bild 02: Die Tragarme wurden mit einer Gehrungssäge auf vorläufige 45cm zugeschnitten (Werden wohl nochmal gekürzt, wenn Motoren und Props da sind und ich die Proportionen abschätzen kann.). Ausserdem wurden die Löcher für die Centerplatebefestigung in die Tragarme gebohrt.

Bild 03: Für entsprechende Flachsenkkopfschrauben, habe ich die Löcher ind en Centerplates Kegelförmig ausgebohrt, sodass eine Glatte Oberfläche entsteht, wenn die Schrauben drin sind.

Bild 04: Alle Teile für den Rahmen plus FlightControl Baugruppe (Hier sieht man, dass ich die Baugruppe bereits erweitert habe, das werde ich aber in einem anderen Beitrag dokumentieren :-D). Man sieht auch Gummistücke, welche ich verwendet habe, um die Centerplates von den Tragarmen vibrationstechnisch zu trennen. Das habe ich in einigen Copterforen und Videos gesehen und habe mir dafür eine 1mm starte Gummimatte im sogenannten "Gummishop" bestellt :p. Damit sollen Vibrationen der Motoren, welche auf den regelungsrelevanten Beschleunigungssensor der FlightControl einwirken können, reduziert werden.

Bild 05: Untere Centerplate mit Schrauben und unteren Gummistücken.

Bild 06: Tragarme aufgelegt, sowie die oberen Gummiteile.

Bild 07: Obere Centerplate angebracht und festgeschraubt mit Sicherungsmuttern. Die äußeren Schrauben haben Unterlegscheiben aus Kunststoff bekommen.

Bild 08: Distanzbolzen wurden auf die äußeren Schraiben aufgeschraubt , um die FlightControl Baugrruppe aufzunehmen.

Bild 09 + 10:
Die FlightControl Baugruppe wurde aufgestekt und mit selbstsichernden Muttern fixiert (Metallunterlegscheiben inkl.).

Bild 11: Die Unterseite der Konstruktion. Ich habe die mittleren Schrauben mit Absicht nach unten gehen lassen, so kann man hier später einen Kamerhalter befestigen oder ein Landegestell. Ein AKKU sollte in seiner Breite noch zwischen die jeweils mittleren Schrauben passen.

Auf Bild 12 sieht man die beiden Gummiteile, welche zwischen Tragarmen und Centerplates befindlich sind. Die ganze Sache liegt gut in der Hand und macht einen soliden und stabilen Eindruck. Wichtig ist natürlich das Gewicht des Gesamten Rahmens mit FlightControl, welches mit 326 Gramm (Bild 13) zu Buche steht.

Das wärs erstmal wieder von mir und ich muss Euch vorwarnen, mit dem nächsten Beitrag beginne ich mit der Hardware oder der Software.

Viele Grüße,
Markus
 

Anhänge

Zuletzt bearbeitet:

Vampire

Erfahrener Benutzer
#29
Fernsteurung Gehäuse

Hi!

Vor Hard- und Software kommt nun doch nochmal Praxis: Das Gehäse der Fernsteuerung. Bevor ich mir als umständliche Versuchsaufbauten mit den Platinen mache, dachte ich mir ich machs gleich richtig und baue alles schön sauber in der Fernsteuerung ein.

Ich habe mir also zunächst mit einem 3D Programm alle nötigen Teile und Maße erzeugt. Eine Explositionszeichnung davon findet Ihr auf Bild 1.

Dann ab in den Baumarkt und Material besorgt. Das Oberteil habe ich schon fast fertig. Die Aluplatten habe ich mit den Vierkarntleisten verschraubt. Ich habe auch bereits allerhand Öffnung eingefräst, um beispielsweile einen ON/OFF Schalter und eine Antenne anzubringen. Später sollen die Kanten noch mit Zierleisten (Alu eloxiert bronze) verstehen werden. Die Flächen werde ich airbrushen und mit Lack verseigeln. Ich denke, dann macht das Teil auch optisch was her. Im Moment siehts ja eher einfach nur sehr "roh" aus ;-).

Um das Display und den ARXMega bequem programmieren zu können, habe ich in der Front, unterhalb des linken Steuersticks einen "Servicezugang" mit Programmierschnittstellen verbaut. Hier kann später noch eine kleine Klappe erstellt werden, damit man den Servicezugang verstecken kann. Erstmal bleibt er alleridngs offen, da ich ihn erstmal sehr oft und noch sehr lange brauchen werde.

Gruß,
Markus
 

Anhänge

Vampire

Erfahrener Benutzer
#31
Hi kajot!

Jup, genau diese Baugruppe hab ich im Auge. Ist aber noch nicht bestellt.

Gruß, Markus
 

Jogijo

Erfahrener Benutzer
#33
Hi ReX!

Danke für Deine Antwort und ja, das ist die richtige Idee. Kaufen kann jeder, das ist langweilig. Zudem habe ich bereits im RC Car Bereich Elektronik und Software selbst gebaut bis hin zur Fernsteuerung und das Basteln steht bei mir auch im Vordergrund! Ich möchte mal eine Regelung usw. selbst entwickeln. Ausserdem kann ich dann alle möglichen Erweiterungen selbst einprogrammieren und bin wesentlich flexibler als bei einem Fertigmodell. Mir gings erstmal nur um die Antriebskomponenten und um ein Feedback dazu...

Gruß, Markus
Super, das nenne ich einen richtigen ModellBAUER!
Thema is abonniert!

Das Gehäuse deines Senders erinnert mich sehr stark an die Fernsteuerung die ich mir mal vor länger Zeit gebaut habe, 27Mhz und saftige 4W Sendeleistung.
Das war in einer Zeit wo es noch kein Internet gab!
 

Vampire

Erfahrener Benutzer
#34
Hi!

@kajot: Ich wusste gar nicht, dass es die sogar mit Barometer gibt. Aber ich denke ich nehm dennoch zwei Sensorplatinen, denn es gibt eine Barometerplatine auf der auch gleich noch ein Magnetometer drauf ist. Wenn ich die ganze Baugruppe später als SMD Baugruppe layoute, nehme ich ohnehin die einzelnen ICs direkt, anstatt ganze Sensorplatinen zu verwenden, das spart viel Platz.
Zu Deiner zweiten Frage: Ich programmiere nicht in Arduino auch wenn ich diese Programmierplattform kenne. Ich programmiere in Atmel Studio 6 in C++. Arduino ist zwar ganz nett, wenn man schnell mal was machen will aber man hat auch wenig Übersicht über die Funktionsblöcke (Timer, UART´s, ADC, ...) die im Hintergrund tatsächlich benutzt werden. Daher setze ich meinen Code ganz unten an der Hardware an und nutze lediglich die HAL (Hardware Abstraction Layer) von Atmel. Wenn meine Software in einer ersten Version irgendwann fertg ist, würde ich sie auch hier frei zur Verfügung stellen.

@Jogijo: Danke für die Blumen :). 4W Sendeleistung? War das denn damals noch erlaubt? Das ist ja ungeheuerlich viel ;-).

Gruß, Markus
 

Vampire

Erfahrener Benutzer
#36
Fernsteuerung - Gehäuse funktional fertig

Hi Leute!

Vorm ins Bett gehen wollte ich noch schnell das funktionell fertige Fernsteuerungsgehäuse vorstellen (siehe Bilder). Zudem habe ich bereits eine Menge an der Hard- und Software gemacht:

* Das Display läuft operativ und lässt sich programmieren.
* Die Steuersticks sind an die AD Wandler angeschlossen und liefern korrekte Werte.
* Diverse grundlegende Funktionen wurden programmiert.

Leider habe ich heute weder die Zeit noch die Lust alles im Detail zu dokumentieren, daher mache ich das in einem.... naaaa, genau.... späteren Beitrag :).

Gute Nacht und viele Grüße,
Markus
 

Anhänge

Vampire

Erfahrener Benutzer
#38
Komponenten, Servicezugang, Joystickdemo und Stromverteiler

Hallo Leute!

@Jogijo. Das "leider" nehm ich mir mal nicht so zu Herzen und nehme das als Kompliment auf ;-).

Ich habe nun schon einiges an der Hardware und Software gemacht und muss feststellen, dass es einfach noch keinen Sinn macht, dazu hier was zu dokumentieren, da ich häufig noch Änderungen vornehmen muss und sich mit der Zeit noch einiges ändert. Daher habe ich beschlossen, diese Sachen erst dann hier zu dokumentieren, wenn es eine wirklich verwendbare Version gibt. Sonst würde ich nur alle (einschließlich mich) verwirren ;-P. Ich werde allerdings dann auch auf dei Probleme eingehen, die ich so währned der Entwicklung hatte.

Aus diesem Grund gibts erstmal nur eine Zusammenfassung zur HW und SW:

* Ich habe festgestellt, dass der AD Wandeler des ATXMega mit der internen Refernzspannung dorch recht ungenau arbeitet, daher habe ich viel mit der HW rumgespielt, um akzeptables Rauschverhalten bei der Erfassung der Joystickposition zu erhalten. Ich bin nun an einem Punkt, wo innerhalb eines Wertebereiches von 0 bis 1000 ein maximales Rauschen von 5 auftritt (Das sind 0,5%). Damit kann ich sehr gut leben (Siehe Video). Das Video zeit eine PC Applikation, welche die Joystickdaten anzeigt. Die Daten werden dabei bereits über das DNT24P Funkmodul übertragen. Man sieht also, dass das Delay absolut hervorragend ist. Die Werte werden 50 Mal in einer Sekunde aktualisiert.
* Die Fernsteuerung ist hardwaretechnisch erstmal soweit fertig. Es fehlt nur noch ein Summer für akustische Signale aber das ist kein Problem. Der Servicezugang erfüllt auch wunderbar seinen Zweck (Bild 1).

[video=youtube;oSBVMHExWzM]http://www.youtube.com/watch?v=oSBVMHExWzM&feature=youtu.be[/video]

Die praktischen Arbeiten sind wesentlich einfacher zu beschreiben, da ändert sich nicht mehr viel. Ich habe also einen Stromverteiler gebaut. + und - bestehen dabei aus Sternförmig zusammengelöteten Kabeln. Die Lötstellen sind ordentlich isoliert. Diese Methode sparrt viel Platz dabei werden die Knotenpunkte zusätzlich durch Gummimattenstückchen von den Centerplates zusammengepresst, sodass sie stabil in der Mitte festgehalten werden (Bilder 2 bis 5). Anschlusshülsen habe ich auch schon verlöstet.

Kommen wir zu den Antriebskomponenten. Wie man auf Bild 6 sehen kann, habe ich bereits welche bestellt :). Entgegen meinen ersten Überlegungen habe ich mich nun für folgende Komponenten entschieden:

* Motoren: 2217-800KV Motoren (http://www.xxl-modellbau.de/Motor-2217-800-Arduino-Multiwii-KK-Multicopter-0-3kg-Startgewicht-4x)
* Regler 20A Simon K (http://www.xxl-modellbau.de/20A-SimonK-N-FET-Firmware-Multicopter-Motorregler-ESC-Regler_1)
* Sensorik ist gleichgeblieben.
* 5000mAh AKKU 3s 30C (http://www.alb-modelltechnik.de/Akk...LS-XTRON-5000mAh-3S1P-111V-30C-60C::5385.html)
* 10"x4,5 Propeller für den "Actionbetrieb" (Bild 7 - ecalc 10"x4,5 Props)
* 12"x4,5 Propeller für den "Kamerabetrieb" (Bild 8 - ecalc 12"x4,5 Props)

Bei den 12"x4,5 Props wird zwar die maximale Leistung der Motoren leicht überschritten. Dies allerdings nur bei Vollgas. Zudem sind die Motoren mit einer Leistung von 120 Watt Dauerleistung angegeben. Bei ecalc kann man nur die Leistung für max. 15 Sekunden angeben. Zudem will man mit Kamera ja eher ruhig fliegen, sodass Vollgas in diesem Modus kaum verwendet wird. Das sollte also passen. Vorteil mit den großen Props ist, dass man ein Gesamtgewicht von über 2 kg in die Luft bekommt bei niedrigem Schwebestrom und relativ langer Flugzeit. So kann man einen großzügen Gimbal anbringen. Also sehr viefältig diese Konstelation.

Das wars erstmal.

Viele Grüße,
Markus
 

Anhänge

Zuletzt bearbeitet:

alf-1234

Erfahrener Benutzer
#39
Super Beitrag bis jetzt und mache bitte blos weiter.
Das nenne ich noch richtig echten Modellbau.
Bin ich als Modellbauer mit meiner DSN doch nicht alleine!!

Alf-1234
 

Vampire

Erfahrener Benutzer
#40
Hi alf-1234!

Danke Dir und ja, ich mache auf jeden Fall weiter ;-).
Aber was ist denn eine DSN?

Gruß, Markus
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten