Ich habe schon seit einiger Zeit eine IR-Steuerung in Arbeit, welche es erlaubt 4 Modelle mit je 4 Kanälen gleichzeitig im gleichen Raum zu betreiben. Um mir selbst ein wenig 'Druck' zu machen, fange ich einfach schon mal einen Thread dazu an. Das Protokoll (eigentlich das wichtigste für eine solche Steuerung) kommt dabei jedoch nicht von mir, sondern ist eine Idee von Helmut Schweig. Bis jetzt habe ich nur den Sender komplett fertig und eine Art 'Grundgerüst' für den Empfänger, aber da ich in 2 Wochen ein wenig Urlaub habe, denke ich, dass ich die ganze Sache bis Mitte September fertig haben könnte. Der 'Sender' ist ein Modul welches an eine vorhandene PPM Fernsteuerung angeschlossen wird (Somit kann man alle Einstellungen die die FB beherrscht auch für das IR Modell nutzen) und besteht im Wesentlichen aus einer Atmel ATtiny2313, einem FET (IRLML2505) und ein paar Widerständen und Brücken. Der Empfänger wird im ersten Schritt auf einem PIC12F629 basieren (man kann bei dem Empfänger die diversen Platinen vom 'Tanis-Regler' verwenden). Im zweiten Schritt werde ich den Empfänger an einen 12F510 anpassen, was eine Erhöhung der Auflösung und eine Verkleinerung der Platine mit sich bringt.(Den 12F510 gibt es im 2x3x0,8 mm kleinen DFN8 Gehäuse und er läuft mit 8 anstatt 4 Mhz auf dem internen RC-Generator) Morgen poste ich schon mal ein paar Fotos (Vom Sender und vom Oszi (Protokoll) ), die Hex-File und vielleicht den Source dazu gibt es dann, wenn alles fertig ist.
Hier sind schon mal die ersten versprochenen Bilder. Auf dem Ersten Bild ist der 'Sender' zu sehen und auf dem zweiten Photo sieht man einen Frame des Protokoll (ID A, alle Regler in Mittelstellung)
Gruß
--- Lars ---
resitance is futile!
Angefügte Bilder:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden! Hybrid-TX1.jpg Hybrid_Oszi1.jpg
Das Protokoll stammt, wie schon im ersten Post geschrieben, von Helmut Schweig. Es ist ein Hybrid-Protokoll, d.h. es wird erst eine ID (digital bzw. PCM) gesendet, gefolgt von 4 Analogen Kanälen (PPM). Die Framewiederholrate ist abhängig von der ID. ID A hat z.B. eine Wiederholrate von 80 mS, was in etwa 12,5 Wiederholungen in der Sekunde sind. Bei ID C liegt die Wiederholrate bei 104 mS was ungefähr 9,6 Wiederholungen pro Sekunde entspricht. Da es bei den Signalen immer Überschneidungen geben wird, werden diese Werte in der Praxis ein wenig schlechter ausfallen, aber das dürfte sich eigentlich nicht all zu sehr bemerkbar machen. Wenn nur ein Fahrzeug betreiben wird, sind die Werte absolut (wenn es keine Fremdstörungen gibt). Die Reichweite bei dem Im Bild gezeigten Sender liegt bei ~ 6m (Unabhängig von der Sensorposition), kann aber durch mehr IR-LED's bzw. einen Höheren I forward an den LED's (z.Zt. ~ 50 mA) noch erweitert werden.
Gruß
--- Tanis ---
PS: Auch ja, der Empfänger wird so augelegt, das die Servos alle 20 mS einen neuen Impuls bekommen, sodass die Servos genau so 'sanft' laufen sollten, wie an einem normalen RF Empfänger-
danke für die ausführlichen Informationen! Hast Du das System schon mal mit einem Modell ausprobiert? Ich hatte selbst mal ein (PCM-)Protokoll für mehrere Modelle konzipiert, dann aber nicht realisiert, da mir jegliche Wiederholrate < 12/s zu klein erschien. Ob ~10/s tatsächlich ausreichend ist, kann ich aus eigener Erfahrung leider nicht sagen, und bin deshalb an Deinen Erfahrungen (auch bei Flugmodellen!) interessiert.
Viele Grüße
Fred
Time flies like an arrow, fruit flies like a banana. Groucho Marx
Mit Erfahrungen aus der Praxis kann ich leider noch nicht dienen, da ich bis jetzt erst ein 'Grundgerüst' für den Empfänger fertig habe. Der RX erkennt seine ID und gibt diese und den Status ob der Frame gültig (fehlerfrei) war an 3 IO-Pins des PIC aus. Bis hierher ist das alles noch eine recht einfache Sache. Jetzt bin ich dabei die PWM-Routine für den Motor, sowie die PPM Signale für die Servos zu realisieren. Leider ist das bei der begrenzten Rechenleistung des PIC nicht mehr ganz so easy Für Flieger ist auch eine (3-Kanal) Version mit Aktuatorausgängen geplant, was aber noch komplizierter wird und deshalb wird erst die 'Servo-Version' für Autos fertig gemacht. Ob die Framerate und die Auflösung (64 Schritte / Kanal) für ein Modell reichen wird, oder ob alles suboptimal (also Für die Katz) ist, wird sich noch zeigen, aber ich bin da ganz zuversichtlich. Wenn ich mich nicht ganz irre, ist das Protokoll der X-Twins und PicooZ um einiges Träger...
gefällt mir wirklich gut. Bin mal gespannt, ob die 6-bit ausreichen, hatte minimal bisher 7-bit, aber da hat man noch nix gemerkt...in dem Zusammenhang wärs interessant zu erfahren, welche Auflösung die billigen Digitalservos haben... Was ist mit Beleuchtung ? strickt man die dann aus dem 4-ten Kanal ? weiter so !
die 6Bit Auflösung sind schon ziemlich knapp, denn man sieht die 'Schritte' schon sehr bei dem Servo. Wenn man jedoch nicht die vollen 270° des Servos benötigt, kann man die Servopulslänge so anpassen, dass man die 64 Schritte auf den benötigten Servoweg aufteilen kann, dann sollte das alle male reichen. Wenn ich das ganze dann auf den 12F510 portiere, ist sogar eine Auflösung von 128 Schritten drin, was dann 7 Bit entspräche... Für licht fehlt es schlichtweg an IO's, aber man könnte auf 2 Servoausgänge verzichten und diese für z.B. Bremslicht und Fahrlich einsetzten (Rückfahrscheinwerfer würden dann mit nem FET und nem Kondensator gelöst (Signal von der Motorbrücke)). Ich will aber erst mal eine 'normale' Version mit einem Fahrregler und 3 Servo-Ausgängen fertig bekommen, bevor ich mir neue Flausen in den Kopf setze.
Ich habe gerade mal einen Servoausgang 'aktiviert' um die Reaktionsgeschwindigkeit zu testen. Für meinen Geschmack ist das schon gar nicht so schlecht. Das Servo läuft zwar noch langsam und durch die 64 Schritte etwas ruckelig auf ~180°, aber das liegt zum Teil auch noch an der suboptimalen Ansteuerung des Servos. Ich versorge das Servo im Moment nur nach jedem Frame mit einem Signal (80-104 mS), das wird aber im nächsten Schritt mit einer Interrupt-Steuerung geändert... die Übernimmt dann auch die PWM für den Motor..... wenn das mal alles klappt!
jetzt bin ich auf ein Problem mit der Hardware gestoßen. Das Signal vom IR-Sensor scheint nicht ganz sauber zu sein. Auf dem Oszi sehe ich Störimpulse (Der Sensor scheint für den Bruchteil einer Sekunde das Signal zu verlieren was sich in einem Servozittern auf allen 3 Servoausgängen bemerkbar macht. Komischerweise sind die Störungen nicht da, wenn der Ausgang des IR-Sensors offen ist (Keine Verbindung zum PIC hat). Die Störungen sind jedoch nicht periodisch, sondern im 0,5-2 Sek. Abstand (unregelmässig). Als Sensor setzte ich zur Zeit einen 3V Sensor aus einem PiccoZ ein, zu dem ich leider keine weiteren Angaben habe . Der Sensor ist mit 47 Ohm 'entkoppelt' und hat einen 47µF Kondensator zur Spannungsstabilisierung. Die gesendeten Signale sind alle gleich lang (immer 260µS bzw. 10 Perioden 38 kHz) und ich messe zur Auswertung des Protokolls immer nur die Pausen zwischen den 260µS Pulsen (zwischen 150 und 2000µS).
Kann mir jemand einen Tip geben, wie ich diese Störungen eliminieren kann? Ich kann die fehlerhaften Frames zwar per Software raus filtern, aber dadurch geht die Framewiederholrate noch weiter in den Keller und die 10 Hz (bei Id D) sind schon recht knapp bemessen.
mit PICs kenne ich mich nicht aus. Wäre es ein AVR, würde ich überlegen, ob die Software nicht aus irgendwelchen Gründen (z.B. durch Stack-Overflow, Auslösen eines Interrupts, für den keine Adresse in der Vektor-Tabelle vorliegt, oder sonstiges "Weglaufen" des Program Counters) einen Reset auslöst (PC=0), so dass die Port-Initialisierung (Pull-Ups? Ein- oder Ausgangsrichtung?) dann kurzzeitig nicht mehr stimmt.
Ich nehme an, bei abgetrenntem IR-Demodulator ändert sich nichts am zuhörigen PIC-Eingangs-Pin(?). Um zu klären, ob die Problematik durch die Hard- oder die Software ausgelöst wird, könntest Du Dir einen uC programmieren, der das Signal des IR-Demodulators simuliert, und dieses Signal anstelle des "echten" Signals an den Eingangs-Pin geben.
Viel Erfolg bei der Fehlerbeseitigung!
Fred
Time flies like an arrow, fruit flies like a banana. Groucho Marx
Hallo Fred, Danke für die Tipps. Die Idee mit dem Simulieren der Signale ist gut. Ich werde morgen den Code für den Sender so anpassen, das er nicht mit 38 kHz, sondern 'flat' sendet, das sollte in 5 Min. erledigt sein. Damit kann ich dann testen ob es an dem Sensor oder an meinem Programm liegt. Ist alles noch im frühen Alpha-Stadium, deshalb kann sich auch im Programm der eine oder andere Fehler eingeschlichen haben, aber da es bis jetzt noch nichts besonderes ist (keine Fehler Kontrolle/Korrektur und nur bedingte Erkennung von fehlerhaften Frames, kein Interrupt), denke ich das der Code OK ist. Vielleicht mache ich morgen auch ein kurzes Video, das macht meine 'Fehlerbeschreibung' etwas plastischer.... sieht wirklich nach 'Empfangsproblemen' aus. Es steckt auf jeden Fall noch viel Arbeit in diesem Projekt.... schön ist aber schon mal, das ich die Servos überhaupt schon bewegen kann .
auf Deinen "Sender"-Platinen sehe ich keine Treiber-Transistoren für die IR-LEDs. Mit welchem Maximalstrom werden die LEDs betrieben? Im Impulsbetrieb kann man die ja ganz schön belasten; siehe z.B. TSAL6400:
Viele Grüße
Fred
Time flies like an arrow, fruit flies like a banana. Groucho Marx
Die LED's werden von einem IRLML2502 getrieben. Der befindet sich auf der Kupferseite der Platine (SMD). Da ich zu den IR-Sende Dioden auch keine Datenblätter habe, bin ich auf Nummer sicher gegangen und betreibe die LED mit einem If von ~ 50 mA (Je Diode). Ich mache heute Abend eh Fotos von der Platine, da kann ich die dann auch hier im Forum online stellen. Das Hexfile für die ATtiny2313 kann ich auch schon zur Verfügung stellen, nur den Code für den RX gebe ich noch nicht an alle raus (Das muss erst besser funktionieren). Ich versuche auch mal ein vernünftiges Video zu machen, damit man die Reaktionszeit der Lösung besser einschätzen kann. Die Geschwindigkeit sollte aber für die meissten Anwendungen reichen. Sven habe ich schon mal ein 'Vorabvideo' geschickt, er meint auch, das es gar nicht soooo langsam aussieht :)
Erstens kommt es anders und zweitens als man denkt. Ein gutes Video kann ich im Moment leider nicht machen, da ich meine FireWire Karte unter Linux noch nicht zum rennen gekriegt habe. Ich habe trotzdem mal ein Video mit meiner alten Digi Cam gemacht. Viel kann man bei der schlechten Qualität des Videos nicht erkennen, aber ich hoffe das man einen Eindruck davon bekommt, wie gut oder schlecht das Servo auf die Knüppelbewegung reagiert. Die 10 Frames/S sind wohl die Grenze, darunter wird es dann zu schwammig mit der Steuerung. Ich hoffe, dass ich die Framerate vielleicht noch ein wenig erhöhen kann, aber auch so wäre es IMHO schon brauchbar.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Mikromodell-Chat
1
Offline
. Der Sensor ist mit 47 Ohm 'entkoppelt' und hat einen 47µF Kondensator zur Spannungsstabilisierung. Die gesendeten Signale sind alle gleich lang (immer 260µS bzw. 10 Perioden 38 kHz) und ich messe zur Auswertung des Protokolls immer nur die Pausen zwischen den 260µS Pulsen (zwischen 150 und 2000µS).
