RC-Framework mit XBees

RC-Framework mit XBees

Einführung

Wenn man schon länger →RC-Modellbau betreibt, kennt man die alten FM-Fernsteuersysteme oder hat sogar noch eines zu Hause. Typischerweise hatte man einen Sender, der auf einem Frequenzband von 35 oder 40MHz lief, dazu ein Sender-Kanalquarz. Ferner mindestens einen, bei mehreren Modellen vielleicht auch mehrere Empfänger. Diese benötigten in der Regel auch Empfängerquarze; später gab es auch quarzlose Systeme. Bedingt durch das Frequenzband und die entsprechende Technik hatten sowohl Sender als auch Empfänger ziemlich lange Antennen. Dafür war die Reichweite mit über 1km ziemlich hoch, damit auch Flugmodelle gesteuert werden konnten.

klassischer Sender mit Teleskopantenne (Multiplex Profi mc3010, 40 MHz)

Aus der Sicht des Indoor-Modellbaus für Fahrzeuge im Maßstab 1:32 ergaben sich allerdings folgende Nachteile:

  • 1 Modell brauchte 1 Kanal, also 1 Empfänger und 1 Quarz. Sowohl Empfänger als auch Quarze hatten (haben) ihren Preis. Meistens musste man vor dem Betrieb die Empfänger/Quarze wechseln, da man nicht für jedes (vielleicht seltener genutzte?) Modell einen zur Verfügung hatte
  • manche (günstige) Empfänger benötigten relativ viel Bauraum
  • Die Antennen waren sehr lang. Insbesondere auf Empfängerseite waren bis zu 90cm normal. Das führte zwangsläufig zu sehr spielzeughaften “Riesenantennen”
  • Die Empfangseigenschaften in Innenräumen waren wegen vieler Interferenzen bescheiden. Je nach Qualität der Systeme (teuer!) waren aber zufriedenstellende Ergebnisse möglich
  • Digitalkanäle wurden nicht übertragen (Pulse-Pause-Modulation: PPM)
  • Für umfangreiche bzw. Funktionsmodell gab es manchmal zu wenige Proportional-Kanäle
  • Manche Eigenschaft ist nicht mehr zeitgemäß. Sender vor dem Empfänger abschalten war früher nicht gut, denn die Servos im Modell bzw. der Fahrmotor fing wild an zu “zucken”. Gute Empfänger hatten aber schon ein Failsafe

Vor ca. 15 Jahren kamen dann die ersten Systeme im 2,4GHz-Band heraus. Diese überwinden die oben genannten Nachteile… doch sie sind bis heute ziemlich teuer. Außerdem gibt es keine Austauschbarkeit zwischen den Systemen mehr. Die Hersteller haben die Gelegenheit genutzt und eigene, nicht kompatible Systeme herausgebracht. Falls man sich für ein System bzw. einen Hersteller entscheidet, ist man dann sehr lange darauf festlegt.

Daher war ich vor einigen Jahren auf der Suche nach einer flexiblen, aber auch günstigen Lösung für die zunehmende Zahl an ferngesteuerten 1:32-Modellen. Ausgangspunkt war hier der →Lexion.

Das Ziel

Sehr einfache Systeme wie Ultraschall- oder Infrarotsteuerungen habe ich wegen der hohen Störanfälligkeit gleich verworfen. Die folgenden Eigenschaften sollten (und sollen) im Vordergrund stehen:

  • preisgünstige Steuerung für viele/mehrere Modelle
  • kleiner Bauraum (zumindest empfangsseitig)
  • zuverlässig & störungssicher, auch bei mehreren WLANs etc. in der Nähe
  • zulassungsfrei (z.B. 2,4GHz)
  • ausreichend Bandbreite bzw. Übertragungskapazität
  • Reichweite: mind. 10m Indoor, Outdoor gerne mehr (falls man mit dem landwirtschaftlichen Gerät mal eine Tour durch den sommerlichen Garten machen möchte)
  • möglichst bidirektionale Übertragung (z.B. für eine Rückmeldung der Akkuspannung)
  • komfortable Bedienung (automatische Konfiguration, wenig Einrichtungsaufwand)
  • flexibel (verschiedene Sender möglich; freie Programmierbarkeit auf Modellseite)
  • einfach zu parametrierende Funktionsbausteine (Servoverzögerung, Blinkfunktionen)
  • gut verfügbare Hardware
  • Integration möglichst in meinen vorhandenen profi3010-Sender (siehe Bild oben)

ZigBee-Module (XBees von Digikey)

Seit vielen Jahren gibt es den →ZigBee-Standard. Dieser regelt den Datenaustausch für kleinere Netzwerke (klein = mittlere bis geringe Reichweite, eher geringe Datenrate).

Die Firma →Digikey produziert wiederum Module, die auf diesem Standard aufbauen. Diese tragen den Markennamen “XBee”. Die Module sind ca. 20x25x5mm groß. Eine optionale externe Antenne (on-board Chip-Antennen sind auch möglich) kann mit einem Spezialstecker verbunden werden:

Umsetzung & Architektur

Nutzung von AVRs zur Datenverarbeitung

Die Grundidee zum neuen RC-System ist der Aufbau eines Minimal-XBee-Netzwerks mit einem XBee im Sender und einem im Modell. Das Sender-XBee fungiert als sogenannter Coordinator und sendet in Modellbau-üblichen Zeitabständen die Eingabebefehle (Proportional- und Digitalkanäle) an das definierte Empfänger-XBee. Theoretisch könnten die XBees dies alleine übernehmen; sie verfügen über diverse Aus- und Eingänge, sogar inklusive PWM-Signalgeneratoren. Auch das Aufspielen eigener Software ist bedingt möglich. Jedoch empfinde ich es als komfortabler, diverse Einstellungen und Auswertungen via separatem Mikrocontroller vorzunehmen. So gibt es zu jedem XBee noch einen →AVR, welcher passende Datenpakete zusammenstellt und schickt bzw. selbige auswertet und LEDs und Motoren ansteuert:

Senderseitiger Aufbau

Das Bild zeigt eine kleine Zusatzplatine in meinem Sender mit dem XBee und dem dazugehörigen AVR:

Der AVR ist mit dem XBee nur über die serielle Schnittstelle (UART) verbunden (RX und TX-Seite). Das reicht aus, um alle Funktionen des XBees bzw. des zugrunde liegenden Funknetzwerks nutzen zu können. Die Sendersignale werden dem AVR hier als PPM-Summensignal zugeführt. Das hat den Vorteil, dass die Funktionen des Senders wie z.B. elektronische Trimmung weiter genutzt werden können. Zudem erleichtert es die Verkabelung. Über einen speziell definierten Proportionalkanal wechselt das XBee auch die Modelladresse, an welche Befehle gesendet werden sollen. So kann ich die Modellspeicher im ursprünglichen Sender beibehalten. Natürlich sorgt die kleine Platine mit ein paar Zusatzbauteilen auch für die Stromversorgung von AVR und XBee aus dem Senderakku. Die drei Steckbuchsen in der Platinenmitte sind Abgriffe für die serielle Schnittstelle plus Masse. So kann für Diagnosezwecke per FTDI-Kabel in die Kommunikation zwischen AVR und XBee “hineingehört” werden.

Modellseitiger Aufbau

Der modellseitige Aufbau ist praktisch gleich: Ein XBee ist per serieller Schnittstelle mit einem AVR verbunden:

Hierbei hat der AVR vor allem die Aufgabe, die empfangenen Befehle zu decodieren und den LEDs, Servos bzw. Motoren in geeigneter Form zu übermitteln. Dazu werden z.B. Soft-PWMs generiert. Durch die Flexibilität der AVRs ist man hier sehr frei, was die Anzahl der Servos/Motoren usw. angeht. Praktisch alles ist möglich; angefangen von ein- und ausfadenden LEDs bis hin zu Servowegbegrenzungen und Trägheitssimulation, wie beim →Lexion zu sehen.

Aufbau RC-Telegramm

Die vom Sender gelesenen Stellungen der Knüppel bzw. Schalter liegen im Sender-AVR als Analog- und Digitalwerte vor. Diese gilt es nun in ein kompaktes Format zu bringen. Ich habe den Wert 2000 als Mittelwert definiert, bei dem ein Knüppelausschlag 1023 entspricht. Das bedeutet, ein Proportionalkanal wird durch eine Zahl zwischen 977 und 3023 dargestellt. So reichen für die Darstellung eines Wertes 12 Bit aus. Um mit möglichst wenig Speicherplatz auszukommen und das Telegramm klein zu halten, wird nun aus jeweils zwei Proportionalwerten ein Block mit drei Bytes generiert. Dann sehen die “RC-Data” wie folgt aus:

  • Datenbyte 1 (Prop-Kanal 0 & 1)
  • Datenbyte 2
  • Datenbyte 3
  • Datenbyte 1 (Prop-Kanal 2 & 3)
  • Datenbyte 2
  • Datenbyte 3
  • Datenbyte 1 (Prop-Kanal 4 & 5)
  • Datenbyte 2
  • Datenbyte 3
  • Datenbyte 1 (Prop-Kanal 6 & 7)
  • Datenbyte 2
  • Datenbyte 3
  • Datenbyte 1 (Prop-Kanal 8)
  • Datenbyte 2 1. Hälfte
  • Datenbyte 2 2. Hälfte (4 Digitalkanäle)
  • Datenbyte 3 (nochmal 8 Digitalkanäle)

Es ist leicht zu sehen, dass hier 9 Proportional und 12 Digitalkanäle übertragen werden. Damit lässt sich schon einiges umsetzen.

Die XBees: Einstellungen und Betriebsart

Die XBees werden im sogenannten API2-Mode betrieben. Das heisst, jegliche Befehle über UART ans XBee müssen in einem bestimmten Format, dem API-Frame, übermittelt werden. Da diese Art der Kommunikation eine Checksumme einschließt, ist dies die sicherste Methode. Die Geschwindigkeit der UART-Schnittstelle wird vorher auf 250kBd erhöht. Das verringert die Latenz und ist aufgrund der kurzen Leitungslängen zwischen AVR und XBee unproblematisch.

Der API2-Mode ist eine Erweiterung des API-Modes, bei dem bestimmte Zeichen “escaped” werden müssen, da sie vom XBee als Steuerzeichen misinterpretiert werden würden. Das bedeutet, nach dem Zusammenstellen des Paketes muss dieses auf “Escape-Zeichen” geprüft und diesen Zeichen müssen bestimmte Vorsatzzeichen vorangestellt werden.

Die umgekehrte Prozedur läuft auf der Empfangsseite ab: Die Datenbytes werden wieder zu Proportionaldaten decodiert und auf einen Proportionalwert, also z.B. auf eine Servoposition, gemapped. Alles das erledigt das zugehörige Software-Framework (welches später auch hier bei Doktorrail vorgestellt wird).

Erfahrungen & Fazit

Das beschriebene Framework ist mittlerweile seit fünf Jahren im Einsatz und es funktioniert sehr zufriedenstellend. Einige der angedeuteten Funktionen sind bis heute aus Zeitgründen nicht implementiert (z.B. Rückmeldung der Akkuspannung oder Reichweitenwarnung). Für das “normale” Steuern von RC-Modellen möchte ich aber schon jetzt auf dieses System nicht mehr verzichten.

Darüber hinaus bietet es noch unzählige Möglichkeiten und ist damit sehr zukunftssicher.



Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.