Funksignale mit Microcontroller emulieren.

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    ACHTUNG: In Deutschland muß Deine Drohne per Gesetz mit einem Drohnen-Kennzeichen versehen sein! Diese Plakette muß feuerfest sein und Deinen Namen und Anschrift enthalten. Ein passendes Kennzeichen bekommst Du hier.

    • Funksignale mit Microcontroller emulieren.

      Wir, ein Team aus drei Leuten, besuchen derzeit die HTL in Saalfelden, Österreich.

      Für unser Diplomprojekt haben wir nun vor, eine Drohne für die Suche von Lawinenverunglückten bauen. Dabei werden wir auf einen Bausatz zurückgreifen. Als Steuerung wird vermutlich die NAZA-M-V2 zum Einsatz kommen.

      Nun zu meiner Frage:

      Da wir vorhaben, das Ding autonom fliegen zu lassen, werden wir in die Steuerung eingreifen müssen - also die Signale, die die Fernbedienung an die Drohne senden würde, emulieren. Dafür wollten wir einen Microcontroller einsetzen. Nun sind wir nach einiger Recherche an dem Punkt, wo wir uns überlegen sollten, wie wir das Ganze nun genau angehen wollen. Ist es möglich, die Funksignale, die die Drohne versteht, einfach mit einem 2.4GHz Funkmodul nachzumachen? Oder wird uns da die Verschlüsselung der Signale ein Problem bereiten?

      Unser Plan wäre nämlich folgender: Wir bauen die Drohne aus einem DJI Bausatz, dem dann die NAZA-Steuerung zugeführt wird. Als Steuerung käme dann ein mit Joysticks und Funkmodul ausgestatteter Microcontroller, über den die Drohne ganz normal von Hand gesteuert werden kann. In diesem COntroller würden wir dann auch unser Programm verpacken, dass die Drohne dann, nachdem über GPS eine Fläche eingestellt wurde, die die Drohne abfliegen soll, steuert und sie diese Fläche abfliegen lässt.


      Ein paar Tipps von den Profis wären sehr hilfreich!

      Danke im vorraus!!!
    • Hallo Samuel,

      die NAZA bekommt ihre Steuersignale ja von einem Fernsteuerempfänger und zwar entweder über den SBUS oder über klassische Fernsteuerkanäle über PWM. Das ist ein standardisiertes Protokoll. Ich denke, es wäre sinnvoller, an dieser Stelle anzusetzen, als sich selbst einen Sender zu bauen, der einen Fernsteuerempfänger ansprechen soll. Das wird nämlich - wie von Dir bereits vermutet, höchstwahrscheinlich an der Verschlüsselung/Bindung zwischen Sender und Empfänger scheitern.

      Ein ähnliches System gibt es bereits von DJI selbst: die https://www.dji.com/ipad-ground-station.

      Grüße, Diet
      Mein Hangar:
      DJI Mavic Pro mit iPhone 6s, Parrot Disco, DJI F450 FlameWheel mit Naza-M V2 und FrSky Taranis, diverses "Kleinvieh" mit vier Propellern
    • Ich würde auf jeden Fall auf eine verlässliche Funkverbindung aus dem RC-Bereich setzen, d.h. Sendemodul und Empfänger von z.B. FrSky (z.B. die FrSky XJT Combo).
      Das Sendemodul kann man recht einfach mit den Steuerdaten füttern. Zudem bietet dieses Set auch Telemetriedatenübertragung an, denn ihr wollt ja sicher auch die ein oder andere Info von der Drohne zurück bekommen.

      Wenn ihr die Drohne allerdings Flächen abfliegen lassen wollt, sollte der Flight-Controller Waypoints beherrschen. Die NAZA kann das zwar, DJI setzt dabei aber auf eine proprietären Bluetooth-Verbindung mit geringer Reichweite. Die Drohne aus der Ferne zu füttern ist damit so einfach also nicht möglich.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Chameo ()

    • Ohne mich in die Nesseln zu setzen, einen autonomen Flug durch die Simulation von R/C-Signalen steuern zu wollen, ist mit Verlaub dezent suboptimal. Und eine schon lange abgekündigte Naza einfach nicht der richtige FC.

      Für so etwas nimmt man einen FC, der dafür ausgelegt ist, sei es von DJI einen N3/A3, oder einen Pixhawk mit Arducopter oder auch PX/4-Stack. Da brauche ich weder was zu simulieren noch zu basteln. Da habe ich für so etwas definierte Schnittstellen: bei DJI das API, bei Pixhawk Mavlink. Dokumentation gibt es zu Beidem genügend.

      Viele Grüße,
      Stefan
    • fingadar schrieb:

      Ohne mich in die Nesseln zu setzen, einen autonomen Flug durch die Simulation von R/C-Signalen steuern zu wollen, ist mit Verlaub dezent suboptimal. Und eine schon lange abgekündigte Naza einfach nicht der richtige FC.

      Für so etwas nimmt man einen FC, der dafür ausgelegt ist, sei es von DJI einen N3/A3, oder einen Pixhawk mit Arducopter oder auch PX/4-Stack. Da brauche ich weder was zu simulieren noch zu basteln. Da habe ich für so etwas definierte Schnittstellen: bei DJI das API, bei Pixhawk Mavlink. Dokumentation gibt es zu Beidem genügend.

      Viele Grüße,
      Stefan
      Genau wegen solcher Antworten wollte ich hier fragen, danke!

      Ja, wir haben eben überhaupt keine Ahnung von Drohnen. xD

      Wir werden uns auf jeden Fall die von dir genannten FCs ansehen.
    • Also wir haben unseren Plan jetzt geändert.

      Das Nachfolgende basiert nach wie vor auf der NAZA-M-V2

      Wir werden den Controller zwischen Funkempfänger(Hier würden wir das Funkmodul der NAZA mit einem futaba hitec tauschen und "traditionell" mit dem Flight Controller verkabeln) und dem Flight Controller einbauen. Wir haben acht definierte Kanäle, sechs davon sind von der Steuerung selbst belegt, zwei würden frei bleiben. Die acht Leitungen, die vom Funkempfänger zum Flight Controller gehen, würden dann an den Controller angeschlossen. Danach würden wieder sechs Kabel vom Controller zum Flight Controller gehen. Wenn also die Drohne am Beginn der Aktion vom Bediener manuell über die Fernbedienung gesteuert wird, damit er die Eckpunkte anfliegen kann, gibt der Controller einfach die Steuersignale weiter, die er vom Funkempfänger erhält. Weiters würden wir dann bei der Fernsteuerung einen der zwei freien Kanäle für eine Bestätigung verwenden - der Bediener muss der Drohne ja auch irgendwie sagen können, dass sie gerade an einem Eckpunkt steht. Nach Einstellung der Eckpunkte, errechnet der Controller dann die Flugmanöver und generiert sie selbst. Würde jetzt der Bediener ein Signal an die Drohne senden, würde der Controller das registrieren, das Programm abrechen und den Bediener steuern lassen.

      Auch die Sensoren, die wir an die Drohne noch zusätzlich anbringen würden, wären dann am Controller angeschlossen - fünf Abstandssensoren ( einer auf jeder Seite und einer unten für die Höheneinstellung (der Bediener sollte nämlich am Anfang, also bei der Einstellung der Eckpunkte, auch die Höhe einstellen, in der die Drohne fliegen sollte)) und einen Sensor für das Signal des Lawinensuchgeräts (das er ja suchen soll, weil er ja den Verschütteten suchen soll)

      Die einzige Frage, die ich jetzt noch habe, ist, geht das überhaupt so? Sind die Signale, die dieser Funkempfänger an den Flight Controller sendet, einfach PWM-Signale? Oder steht irgendein BUS-System dahinter? Wir können die Dinge nämlich erst bestellen, wenn wir auch wissen, dass das auch so geht. Wenn die Signale zwischen Funkempfänger und Flight Controller nicht einsehbar und von uns generierbar sind, müssen wir uns etwas anderes überlegen.
    • Kurz gesagt, das funktioniert so nicht... allein schon deswegen nicht, weil ihr so keine Position der Drohne ermitteln und darauf reagieren könnt. Wie schon gesagt wurde, ist es auch ungeschickt zu versuchen, die Drohne mittels emulierter Fernsteuersignale an den nächsten Zielpunkt bringen zu wollen.
      Überlasst die autonomen Manöver dem Flightcontroller und konzentriert euch darauf diesen mit den nötigen Waypoints zu füttern.
    • @SamuelVergeiner Ich weiß nicht was bei euch nun Priorität hat, kommt es in erster Linie auf die Verwirklichung eines Eigenbaus mit diesen Flugeigenschaften an, dann wäre das Vorhaben nachvollziehbar, oder steht das Ergebnis "Suche von Lawinenverunglückten" im Vordergrund? Wenn letzteres im Vordergrund steht, würde ich die Finger von so einem Eigenbauprojekt lassen, denn es gibt mittlerweile genügend ready to fly (RTF)-Multikopter am Markt, die diese Eigenschaften schon durch ihre Firm- und Steuersoftware werksseitig bestizten und perfekter, mit zus. längerer Flugzeit ausführen könnten als jeder Eigenbau. Ich nehme an, dass ein Eigenbau ja nicht unbedingt in Frage kommt um Kosten zu sparen, denn das wäre sowieso eine Milchmädchenrechnung die wahrscheinlich nicht aufgeht.

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von biber ()

    • biber schrieb:

      @SamuelVergeiner Ich weiß nicht was bei euch nun Priorität hat, kommt es in erster Linie auf die Verwirklichung eines Eigenbaus mit diesen Flugeigenschaften an, dann wäre das Vorhaben nachvollziehbar, oder steht das Ergebnis "Suche von Lawinenverunglückten" im Vordergrund? Wenn letzteres im Vordergrund steht, würde ich die Finger von so einem Eigenbauprojekt lassen, denn es gibt mittlerweile genügend ready to fly (RTF)-Multikopter am Markt, die diese Eigenschaften schon durch ihre Firm- und Steuersoftware werksseitig bestizten und perfekter, mit zus. längerer Flugzeit ausführen könnten als jeder Eigenbau. Ich nehme an, dass ein Eigenbau ja nicht unbedingt in Frage kommt um Kosten zu sparen, denn das wäre sowieso eine Milchmädchenrechnung die wahrscheinlich nicht aufgeht.
      Ja, es ist eben eine Abschlussarbeit, also wollen (müssen) wir es selbst bauen.

      Du bist also der Meinung, dass uns dieses Konzept aufgehen wird?
    • Entschuldigt, aber Euer Ansatz ist von sich heraus grundfalsch. Klingt zwar vielleicht jetzt hart, aber ist so.

      Wegpunkt-Navigation legt man über Koordinatenpunkte fest, die auf irgendeine Art und Weise absolut definiert werden. Im üblichen Normalfall über GPS, die Koordinaten werden entweder bestimmt über voriges Abfliegen (inzwischen eher unüblich), oder über eine geeignete GroundControlStation, in der man die Wegpunkte festlegt. Je nach Leistunngsfähigkeit der GCS legt man für Suchrasterflüge ein Begrenzungspolygon fest, die Software errechnet dann entsprechend ein Wegpunktraster.

      Aber niemand kommt ernsthaft auf die Idee, die Flugnavigation so zu realisieren, dass man RC-Singale injected. Das ist völlig ineffizient, fehleranfällig und nicht praktikabel. Wie wollt Ihr denn so eine sichere Flugbewegung zu einem vorher definierten Punkt erreichen? Euer Ansatz wird so definitiv nicht funktionieren.

      Ich hatte vor einier Zeit mal eine Fachaufsatz zum Thema Rehkizsuche geschrieben, das ist eine ähnliche Thematik (prinzipiell eigentlich das Gleiche). Da geht es auch kurz um Missionsplanung, vielleicht schaut Ihr mal da rein: unmanned-technologies.de/wp-co…-Wildtiersuche_Screen.pdf Ihr könnt mich auch gerne zu dem Thema direkt kontaktieren. Und nein, ich verkaufe nichts :)

      Viele Grüße,
      Stefan
    • Es tut mir leid, allen, die dachten, dass wir es so nicht schaffen würden, mitzuteilen, dass tatsächlich alles so funktionierte, wie wir uns das vorstellen. Die Naza wurde nun als Drohnenbausatz eingesetzt, mit einem Raspberry Pi erweitert und die Sache läuft! Einzig allein ein paar Logikgatter und Grundkenntnisse der Elektrotechnik waren dafür nötig. Danke aber an alle, die tatsächlich Konstruktives mitgeteilt haben!!!!


      Manch einer könnte jetzt meinen, dass wir unser Konzept noch nicht ausführlich getestet haben, aber genau das haben wir heute. Per Fernbedienug kann man zwischen Handsteuerung und Automatik umstellen. Die Signale, die der Pi emuliert, werden von der Drohne so verstanden, als wären es ihre eigenen. Es ist im Flugverhalten kein Unterschied zu erkennen; ob Handbetrieb oder Automatik, alles läuft.

      Aber Spaß beiseite, allen großen Dank für den Input!!!
    • Die Dokumentation darf ich nicht veröffentlichen, aber eine ungefähre Erklärung unseres Ansatzes dürfte wohl kein Problem sein.

      Also die Signale der Naza sind einfach PWMs. Wir haben mal ein Osziloskop rangehängt und die Einschaltzeiten für verschiedene Stellungen der Joysticks rausgemessen. Danach wurden diese PWMs einfach via Software mit dem Pi nachgemacht und mal auf die Anschlüsse der Servos geschalten. Als wir vom Flightcontroller über das zugehörige Programm am Laptop auch immer die Werte angezeigt bekamen, die wir mit den PWMs erzeugen wollten, war das erledigt. Danach mussten wir uns nur noch überlegen, wie wir nun von den Signalen des Flightcontrollers und denen des Pis unterbrechungsfrei - oder zumindest annähernd unterbrechungsfrei - umschalten könnten. Dabei kam ein simpler Multiplexer, dessen Schaltung ich mal beigefügt habe, zum Einsatz. Danach wurde das Ganze mal provisorisch zusammengehängt und ein paar Testflüge gemacht. Um nun zwischen Pi und Drohne umzuschalten, haben wir einen freien Kanal der Fernbedienung an einen Kippschalter gehängt, dessen Signal von einem Komperator erfasst wird (Wieder ein PWM), um dem Pi dann zu signalisieren, ob jetzt manuel oder automatisch geflogen werden soll. Zusätzlich dazu haben wir an allen vier Seiten je einen HC-SR04 Ultraschallsensor gehängt, um Hindernisse in der Flugbahn zu erfassen. Den Abstand zum Boden erfassen wir mit einem Lasersensor der Firma Sick, den wir aber noch nicht implementiert haben. Momentan bin ich dabei mit einem seperaten GPS-Modul (Man könnte auch das Onboard-GPS-Modul der Drohne auslesen, aber wir wollten dabei keine Kabel aufschneiden und entschieden uns dann einfach dazu, einen eigenen GPS-Sensor zu kaufen) das automatische Abfliegen einer Fläche zu bewerkstelligen. Tests mit Lawinenpieps wurden auch schon durchgeführt; diese werden aber erst implementiert, wenn ich mit dem GPS fertig bin, was vielleicht noch eine Frage von Tagen ist, da es momentan in der Schule stressig ist.
      Bilder
      • schaltung.png

        67,9 kB, 617×699, 44 mal angesehen