text: 5 Zoll unter 250g - möglich?
  veröffentlicht am : Di, 04. 12. 2018 geändert am: Di, 04. 12. 2018
  Schlagworte: drohne drone sub250g
  Dank der neuen bzw. nicht mehr ganz so neuen Drohnenverordnung und den Reglementierungen in den meisten Ländern zur Zeit, ist es erlaubt mit Drohnen unter 250g ohne sonstige Einschränkungen zu fliegen - insbesondere auch FPV.
  (bei mehr als 250g ist in Deutschland ein Spotter vorgeschrieben, also jemand, der die Drohne im Blick behält und bei Gefahr... ähm.. Ruft, schreit oder sonst was tut... )
  Auch Versicherungstechnisch sind die Drohnen unter 250g besser gestellt.
  bisher war es nur schwer möglich, "echte" Racing Quads damit hinzubekommen. Die meisten sub-250g-Drohnen haben "nur" 3 Zoll, die "königsklasse" der Racer haben jedoch 5 Zoll.
  Da die Motoren schwerer sind und die Rahmen, da sie ja größer sein müssen, auch, war es quasi unmöglich mit 5 Zoll unter 250g Abfluggewicht zu bleiben. Bis jetzt!
  Druckbär Ultralight
  Schaut mal bei Druckbär vorbei. Dort gibt es den Ultralight 3, welcher in der 5Zoll Variante ganze 30,7g(!) wiegt!
  Mit einem 20x20 Flightcontroller-Stack ist es wirklich möglich, den Quad auf ein Abfluggewicht unter 250g zu bringen. Und das sogar inkl. einer Runcam Split mini - mit der kann man dann nämlich sogar Full-HD aufnahmen machen.
  Die Verbauten Einzelteile:
  Druckbär Ultralight 3
  HGLRC XJB F440 Stack inkl. VTX
  XNOVA 1804 Motoren - 15g jeder!
  Alles in Allem wiegt der Kleine Racer ja nach Props ohne Lipo ca. 160g. Mit passendem Lipo (650mAh oder 850mAh müssen es schon sein) sind wir ziemlich genau bei den anvisierten 250g.
  Der Stack ist eigentlich recht einfach aufzubauen, allerdings haben wir ein paar besonderheiten, die es zu berücksichtigen gilt. Ich wollte in meinem Build so einiges erreichen:
  es sollte unter 250g bleiben (klar)
  ich wollte die Runcam Split Mini über den FC bzw. die Fersteuerung steuern (an und ausschalten reicht mir erst mal)
  ich wollte SmartPort Telemetry an der Taranis, so dass ich nicht nur über das OSD über nen leeren Lipo gewart werde, sondern auch von der Funke
  der VTX sollte sich über das OSD steuern lassen.
  Spoiler-Alarm: Ich hab alle Punkte erfüllt, nur punkt 4 klappt (noch) nicht.
  Wie hab ich das gebaut?
  Der FC hat noch 2 "freie" UARTs (also serielle Anschlüsse für irgendwelche Peripherie). Einer davon wird Laut Handbuch für die ESC-Telemetry genutzt (darüber kann der FC die Temperatur der ESCs auslesen) der andere für die Steuerung des VTX. Das ist etwas blöde, denn wir brauchen ja eigentlich 4 UARTS: ESC-Telemetry, RuncamSplit Mini, VTX und SmartPort.
  FrSky SmartPort Telemetry
  Das einfachste zuerst: SmartPort lässt sich wunderbar über den LED-Ausgang steuern, einen LED-Port hat der FC und ich hab keine LEDs an meinem Quad. Wunderbar. Recht einfach: SmartPort-Telemtry vom FrSky-Receiver an den LED ausgang anlöten.
  in Betaflight dann die Resourcen ummappen, bei mir war es in etwa so:
  resource SERIAL_TX 11 A01
  damit das geht, muss in den Betaflight-Settings unter Configuration das Häckchen bei "Softserial" gesetzt sein. Und dann kann man unter Port den neuen "virtuellen" Uart dann auf SmartPort stellen.
  Mehr musste ich nicht tun. Falls es nicht funktionieren sollte, versucht mal die settings für tlm_inverted umzustellen (on oder off). Auf jeden Fall muss tlm_halfduplex auf on stehen.
  (Anmerkung: eigentlich ist der Smartport von FrSky invertiert, aber genau das erwartet der FC nämlich, deswegen muss man tlm_inverted eben nicht auf ON stellen - ist etwas dämlich gedacht, aber ok)
  Runcam Split Mini steuerung
  Das war hardwaretechnisch recht simpel, ich habe UART6 für die Runcam genutzt. Dabei wird RX auf TX gelötet. D.h. ein Kabel von dem RX-Pad auf dem Board der Runcam geht zum TX6-Pad auf dem HGLRC - und umgekehrt. Dann noch Masse (Gnd) irgendwohin löten - voila!
  Nicht vergessen, den Video-Out der Runcam an den CAM-Port des FC zu löten.
  Theoretisch hätte das klappen sollen. Tat es aber nicht so wirklich. Es gab wohl da ein paar Firmware-Probleme mit Betaflight und Runcam, weshalb das ganze nicht so sauber geklappt hat.
  Mit Betaflight 3.4 wurden neue settings hinzugefügt, die das ganze beheben sollten:
  set rcdevice_init_dev_attempts = 8
  set rcdevice_init_dev_attempt_interval = 2000
  Das Problem war anscheinend, dass die Runcam zu lange für die Initialisierung benötigt hat, d.h. der FC war up, die Runcam nicht und er hat sie quasi nicht "gefunden". Mit den Settings kann man nun die Anzahl der Versuche, die Runcam zu finden, also die attempts, einstellen und die Pause zwischen je zwei Versuchen. In meinem Fall hat die Runcam 16s Zeit sich zu initialisieren.
  (Anmerkung: ich bin mir nicht 100%ig sicher, dass man das Interval wirklich überall ändern kann, ich habe einen anderen FC hier, bei dem geht das nicht)
  Jetzt kann man in Betaflight unter Modes einen Modus vergeben, mit dem man dann die Runcam z.B. Aufnehmen lassen bzw. Stoppen lassen kann...
  Das ist ja noch einfach. Die ESC-Telemetry legt man einfach auf UART3 und gut ist. Naja, fast... Die ESC-Telemetry wird ja quasi nur empfangen, d.h. man lötet das entsprechende Kabel an das RX-Pad des UART (in unserem Fall UART3). Das ist soweit gut. Und damit funktioniert das ganze auch schon... fast...
  VTX Steuerung
  das ist das einzige, was noch klemmt. Die Steuerung des VTX wird zunächst an das TX-Pad des UART3 gelötet. Denn darüber soll ja ausschließlich gesendet werden. jetzt muss man via Softserial und Resourcen-Mapping einen neuen "Virtuellen" UART-Port anlegen, über den man das dann steuern kann. Bei mir war das mit:
  resource SERIAL_TX 12 B10
  erledigt. Jetzt konnte ich die VTX-Steuerung in den Port-Settings einstellen. Nur leider funktioniert das nicht. Und das werde ich in den nächsten Wochen noch rausfinden, denke ich 😉
  die Umgekehrte Konfiguration, also die ESC-Telemetry auf den "Softserial"-Port zu legen, klappt leider auch nicht. Dann funktioniert beides nicht...