ich möchte mit einer RC Steuerung ein I²C Signal erzeugen.
Das heisst ich habe einen RC Sender und Empfänger, dann kommt ein beliebiger µC und daraus soll ein I²C Signal erzeugt werden.
Hintergrund: Ich möchte mit einer RC Fernsteuerung einen Rasenmähroboter steuern.
Der Rasenmähroboter ist ein open source Projekt und hat eine I²C Schnittstelle.
Gesucht ist nun eine Verbindung von RC Fernsteuerung zur I²C Schnittstelle.
Als RC Fernsteuerung soll eine FrSky Sender+Empfänger und als µC z.B. ein ESP oder Arduino benutzt werden. Falls ein anderer µC besser geeignet ist, kann ich auch den nehmen.
Auch gut, dann gib mal zwei, drei, Tipps wie, wo ich anfangen soll.
Welcher µC ist am besten geeignet?
Bestenfalls gehts mit nem Summensignalempfänger, dann habe ich nur ein Signal und brauche nur einen Eingang am µC.
Wie liest man das dann aus? PulseIn?
Es geht mir nicht um die Funkstrecke. Da ist in dem Projekt schon WLAN und Bluetooth implementiert. Das Problem ist die Haptik, Präzision und Latenz.
Ich komme ais dem Modellbau und habe genug Sender und Empfänger.
Mein Projekt hier fängt also mit dem Summenempfänger an und hört mit dem I²C Ausgangssignal auf.
D.h. ich muss als erdtes das Summensignal vom Empfänger einlesen, dann zerlegen, und dann irgendwas auf dem I²C Bus senden.
Frage 1: Welcher µC ist gut geeignet? Kann ja sein, dass ein Arduino zu lahm ist, oder der ESP8266 eher zum blockieren neigt (yield()) und deswegen ein xyz empfehlenswert ist?!
Frage 2: Wie lese ich das Summensignal ein?
Hast schon alles, die frage was gibt der Empfänger auf den Ausgängen raus, nur 1/0, PWM oder was anderes?
die Signale was kommen über I2C zum Roboter muss du auch können, und endsprechend senden. Zeige mal link zum Projekt.
Hört sich einfach an was aber nicht unbedingt sein muss
I2C ist ein definierter Bus
Frage 1: Ein normaler Uno oder Nano reicht aus.
Frage 2: Du solltest die Zeiten zwischen den Flanken des Signals messen.
Eine Pause größer 2ms ist die Startbedingung, danach kommen die Kanäle.
Siehe auch Summensignal | RC-Network.de
Da hatte ich selber schon ab und an Schwierigkeiten. Manche Libraries funktionieren ais dem Grund nicht mit ESPs. Da sorgt dann der Watchdog immer für reboots. Die Frage ist dann, wenn man WLAN nicht braucht, wozu man sich das antut. Natürlich kann man sich da jahrelang mit beschäftigen, aber es gibt eben aich Leute die Ergebnisorientiert sind und deren Hobby eben nicht das Programmieren ist. Die kennen dann nicht jede Ecke im Detail. Daher die Fragen.
Aus dem RC-Empfänger kann man zylisch (20 ms) jeweils mehrere ("Kanäle") Werte erhalten. Dazu kannst du entweder die Signale, die für die einzelnen Servos gedacht sind, auf jeweils einem Pin mit der normalen RC-Receiver lib ( RC Receiver - Arduino Reference ) einlesen oder das Summensignal an einem einzigen Pin selber auswerten.
Aber danach geht es doch erst los: Was will der Rasenmäher empfangen und wie?
I2C ist eine Schnittstelle die 8Bit Pakete verschickt. Die RC sendet mehrer Kanäle mit einem Signal von 1mS bis 2mS länge. die 50 mal pro Sekunde wiederholt werden.
Ich schaue mir das nachher mit dem Oszi an, was ais dem Empfänger rauskommt.
Dann nehme ich den nano und schaue, wie ich die einzelnen Kanäle auslesen kann.
Und dann kommt erst I²C. Da bin ich aber noch nicht, das kommt erst am Ende.
Ich glaube die I²C Schnittstelle am Mähroboter ist bisher nur physisch da, d.h. dort muss auch noch programmiert werden. Aber nicht von mir.
Also.....meine Güte....war doch ne einfache Frage....aber okay.
Das ist immer wieder lustig, wenn man sich für gegebene Sachen entschuldigen muss und immer alles Begründen muss. Die Aufgabenstellung / Grenzen des Systems sind GANZ KLAR UMRISSEN. Aber okay, ich bin ja auch immer neugierig was drum herum ist, also beschreibe ich das kurz. wieso weshalb und warum. Am Ende braucht man das alles nicht, man kann auch von Hand mähen, ja, ich weiss, aber wir sind ja hier, weil wir alle verschiedene Hobbies betreiben, forschen, entdecken und was neues bauen wollen
Also, ICH habe davon gar nichts gemacht. ICH bin auch nicht "IHR", sondern nur ich
Da haben sich irgendwelche Leute vor Jahren zusammengesetzt und haben einen Ardumower gebastelt ....wie passend im Arduino Forum Letztes Jahr ist daraus Alfred https://alfred.marotronics.de/ geworden, ohne Arduino, dafür mit Linux und einem BananaPi. Es gibt ne App, da steuert man die Kiste mit Bluetooth, aber Bluetooth geht nicht so richtig, es hakelt und mich nervt beim Touchscreen auf dem Handy die unpräzise Haptik und Lenkung im Vergleich zu RC Modellbau. Ich selber fahre Rennboote, Autos, Flugzeuge und Modellhubschrauber und das ist von der Lenkung ein Unterschied wie Tag und Nacht. Also habe ich gegoogelt und auch was für den Ardumower mit RC Fernbedienung gefunden, aber das ist ~8 Jahre alt und nicht kompatibel mit Alfred. Das Basischassis für Alfred ist ein Massenprodukt, das Projekt hat als Schnittstelle zwischen dem BananaPi und dem originalen Motortreiberboard ein IO-Board entwickelt, das wurde gefertigt, es wurden noch einige Kinderkrankheiten aus dem Design rausgenommen und nun ist das Ding seit einem Jahr im Verkauf. Ich habe einen Entwickler gefragt, der mir gesagt hat, dass es noch ein paar I²C Schnittstellen gibt, und dann kam halt die obenstehende Idee...... Ich hoffe, das reicht jetzt, oder?
So, jetzt hab ich den halben Nachmittag damit verbracht den Sender mit dem Empfänger zu binden. Das war nicht so einfach wie gedacht, denn das ging nur indem man die Firmware des Empfängers aktualisiert.
Aber gut, jetzt läufts.
Allerdings wird es doch etwas komplizierter.
Der Empfänger ist ein FrSky X4R. Und der gibt kein Summensignal, sondern ein Sbus Signal mit 16 Kanälen aus. Davon brauche ich 5 Stück.
Sbus aka S.BUS or Serial BUS, is commonly used by Futaba and FrSky. It supports up to 16 channels using only one signal wire. SBUS signal should be connected to the RX pin of an UART.
Hab nur mal kurz in den Link zu Oscar Liang geschaut.
Wenn die einen Hardware-UART zum Dekodieren nehmen, dann trifft der Annahmen über die Pegel für 0 und 1.
Kann sein, daß das nicht mit FrSky zusammenpasst.
Jetzt bin ich doch endlich ein kleines Stückchen weiter gekommen.
Ich habe von unten angefangen die Links abzuklappern, aber davon wollte nichts so richtig auf einem nano, ESP8266 oder ESP32 kompilieren.
.....original nach Murphys Law bin ich dann oben angelangt, bei https://github.com/fdivitto/sbus und da regt sich jetzt doch noch was.
Ein wunderbar kompaktes Sketch, genau sowas hab ich gesucht: