- fchao-Sinus-Wechselrichter AliExpress         
Ergebnis 1 bis 10 von 59

Thema: Universelle Fernsteuerung mit Bluetooth

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Rabenauge Beitrag anzeigen
    von daher lohnt es, ein bisschen mehr Aufwand zu treiben, als aufm Steckbrettl mal nen Joystick an einen Minirechner zu stöpseln.
    Ich nehme mal an, das bezieht sich auf das vom mir gezeigte Bild.

    Zitat Zitat von Rabenauge Beitrag anzeigen
    Schonmal eine Drohne per Handysteuerung geflogen?
    Und anschliessend zu Vergleichszwecken mit nem _richtigen_ Controller?
    Das ist nun nicht mein Ziel. Mir geht es eigentlich nicht darum im klassischen Sinn ein Modell fernzusteuern, sondern einen drahtlosen Zugang zu einem Fahrzeug zu haben. Wenn ich ein Fahrzeug oder auch ganz generell eine Elektronik baue, startet alles auf dem Tisch an Labornetzteil, Scope und Debugger. Da ist ein Zugriff noch leicht, Netzteil abschalten oder SW stoppen. Irgendwann kommt aber der Punkt, wo ein Motor auch mal etwas bewegen soll. Um dafür ein User-Interface zu haben, nehme ich gerne einen Nunchuk. Da ich eigentlich immer den I2C Bus verwende, ist dafür nur ein passender Stecker und etwas SW nötig. So kann man dann mit einer "Drahtfernbedienung" ein Fahrzeug steuern und prüfen, ob man mit seinem Motoren, Getrieben, Rädern und der Stromversorgung richtig liegt.

    Nun will man ja nicht dauernd hinter dem Fahrzeug hinterherrennen. Da kommt jetzt die Fernsteuerung ins Spiel. Wenn es nur darum geht, das Kabel am Joystick durch Funk zu ersetzen, hat man ziemlich freie Auswahl. Da aber mein Ziel nicht vorrangig die manuelle Steuerung ist, habe ich das Fahrzeug in mein LAN via WiFi eingebunden. Mit den ESP ist das am Ende billiger und einfacher als über Ethernet, ich verwende sie auch für stationäre Geräte. Jetzt kann man also das Fahrzeug von jedem Rechner in meinem LAN steuern.

    Wenn es aber ins Freie geht, will ich nicht mit dem Laptop rumrennen. Ich habe daher eine meiner Platinen, die einen ESP und Akku hat um einem Adapter für den Nunchuk erweitert und damit eine Art "Funkfersteuerung" gebaut. Dabei funken Fahrzeug und Fernsteuerung nicht direkt miteinander, sondern alles geht übers LAN. Bei Gelegenheit werd ich für die Wlan-Fernsteuerung eine neue Platine machen. Das Ziel ist, den Hauptteil in die Tasche zu stecken oder an den Gürtel zu klemmen und eine Hand frei zu haben. Dazu ist mir der gezeigte Aufbau zu wacklig. Ich behalte mir gerne die Möglichkeit vor, das Fahrzeug einfach festzuhalten, bevor es sich in den Kellerschacht stürzt. Und dazu hab ich gerne eine Hand frei und dafür ist ein Nunchuk ja gedacht (in der anderen Hand hat man die WiiMote).

    Mir geht es primär nicht darum, ein Fahrzeug fernzusteuern. Das ist nur ein Nebeneffekt. Am Ende geht es darum, daß und wie ein mehr oder weniger autonomes Fahrzeug mit seiner elektronischen Umwelt, und die steckt bei mir im LAN, kommuniziert. Um das an einem Beispiel zu beschreiben, das irgendwann (hoffentlich) autonome Fahrzeug öffnet über Wlan, genau wie ich mit dem Handsender, die Garagentür um dort einzuparken.

    Zitat Zitat von Rabenauge Beitrag anzeigen
    Das Protokoll ist überhaupt kein Problem: die HC-05-Module sprechen seriell.
    Wie oft ich das in meinem Leben schon gehört habe.

    Zitat Zitat von HaWe Beitrag anzeigen
    aber es hakt eben immer an der Plattformunabhängigkeit, Datenübertragungsfehlern, Datenübertragungsabbrüchen, gegenseitiger Störung paralleler Prozesse hoher Prio oder der Nutzerfreundlichkeit und -Verständlichkeit samt einfacher individueller Implementierung.
    Am Ende ist aus dem "einfach asynchron seriell" dann doch ein aufwendiges Protokoll geworden. Das OSI-Modell für die Datenübertragung ist nicht ganz umsonst entwickelt worden.

    Und es muß auch nicht immer in voller Schönheit jede der 7 Schichten implementiert werden. Im LAN muß man es nicht selber machen. Man kann dort auf TCP oder, wie ich es mache, auf UDP aufsetzen. Damit hat man sich schon mal die übelsten Probleme vom Hals geschafft.

    @Rabenauge
    Zusammengefasst ist mein Ziel ein anderes als deins. Daher sind auch die Implementierungen unterschiedlich.

    MfG Klebwax
    Geändert von Klebwax (20.03.2020 um 14:50 Uhr)
    Strom fließt auch durch krumme Drähte !

  2. #2
    HaWe
    Gast
    Ich halte tatsächlich auch Seriell/BT ohne Transport-Control-Protokoll für zu fehleranfällig und nicht ausreichend übertragungssicher, v.a. wenn auf der Zielplattform noch weitere zeitintensive Threads mit hoher Prio laufen.

    Mit ESP WiFi und Webserver Libs habe ich andererseits zwar eine sichere, aber noch nie eine Kommunikation mit Echtzeitfähigkeit hinbekommen.

    Gelänge es, die PS2X_lib für das 2,4GHz Empfangsmodul so umzuschreiben, dass man es direkt an einem ESP32 anschließen kann (ESP32: Dualcore mit std::thread Implementierung), dann hätte man 3 Fliegen mit 1 Klappe erwischt:
    - eine etablierte, gut funktionierende Lib, bei der man sich keine Gedanken machen muss, wie der Empfänger der PS2-Signale der Buttons und Joysticks empfängt + auswertet,
    - eine MT-fähige Plattform, die neben der Echtzeitabfrage und -verarbeitung auch weitere Threads in Echtzeit parallel abarbeiten kann, sogar mit verschiedenen prios, und
    - eine ESP-MCU. die Telemetriedaten per WiFi synchron zurückschicken kann (an einen an den PS2 Controller angeklebten ESP8266 mit Display), zur Visualisierung, und da das synchron zur 2.4GHz Richtung geht, auch ohne gegenseitige Behinderung der Datenübertragung.
    Leider ist die PS2X_lib aber nur für AVRs, nicht für ARMs und nicht für ESPs (wegen vieler AVR-spezifischer low level Befehle oder Registernamen etc., und auch die verwendeten Pins müssten ggf. umbelegt werden).

    Eventuell könnte man statt dem ESP32 auch einen der neuen WiFi-fähigen Arduino MKR-Boards verwenden.

    Eine Alternative wäre auch, deine Fernbedienung Marke Eigenbau mit einer ähnlichen Lib auszustatten wie die PS2X_lib für den PS2 Controller, womit man dann bei identischer Syntax genau so einfach und genau so universell den Zustand aller Buttons+Sticks abfragen kann, wie es die PS2X_lib tut.

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von HaWe Beitrag anzeigen
    Mit ESP WiFi und Webserver Libs habe ich andererseits zwar eine sichere, aber noch nie eine Kommunikation mit Echtzeitfähigkeit hinbekommen.
    Das ist pflichtgemäß so. Ethernet ist nicht echtzeitfähig, WiFi erst recht nicht. Da braucht nur ein Sender, der noch nicht mal zum eigenen Netz gehören muß, einen Kanal zu blockieren und schon hat man ein Delay. Webserver heißt http und das ist Schicht 7 im OSI Modell. Da kommen also zu Ethernet/WiFi noch die Latenzen von den 7 Schichten dazu. Wenn man den http-Overhead, der einem am Ende nichts bringt, wenn man kein Webserver oder Browser ist, weglässt, wirds schon mal besser.

    Eine klassischen Fernsteuerungen hat eine Framerate von ca. 20ms. Wenn man direkt auf Sockets programmiert, kann man mit WiFi ähnliches erreichen. Mit gelegentlichen Überschreitungen der 20ms muß man aber schon rechnen. Der Verlust eines Frames kommt aber auch bei einer Funkfernsteuerung vor und bleibt dort typisch unbemerkt. Für den Menschen mag das Echtzeit sein, das reicht auch für Kunstflug. Von dem, was man technisch bei Echtzeit erwartet, ist das meilenweit entfernt.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.214
    Sodele.
    Das Display läuft.
    Momentan nur ein Test-Beispiel (ne abgewandelte Version vom Graphics-Test der U8g2lib), aber der tut es.
    Und: der Kontrast _lässt_ sich per PWM einstellen- mit Einschränkungen.
    Der Kontrast-Pin hängt erstmal auf Pin D9, und ab etwa PWM 170 werden die Zeichen "sichtbar".
    Allerdings noch sehr schwach, und eher rötlich, als weiss.
    Bei PWM 200 kann man sie schon sehr gut erkennen, aber immernoch rötlich und...flackernd wie ein alter Bildschirm.
    Kurz gesagt: es ist eher unnötig bei meinem, da jemals _irgendwas_ dran rum zu stellen: PWM 255 und gut.
    Das ergibt blitzsaubere, weisse Pixel (eigentlich könnt man sich den Pin auch sparen, und einfach 5V ran legen).
    Ich schaue mir das heute abend im Dunklen noch mal an, aber wenn es dann auch so schön aussieht, kommt der Kontrast-Pin einfach an die 5V-Schiene und fertig.
    Umso mehr bleibt für Erweiterungen übrig, hehe.

    Angeschlossen hab ich das Teil mometan an nem Uno (der ist halt mein Knecht fürs Steckbrett), nach dem Schema der Anleitung von AZ-Delivery.
    Das E-Book gibts gratis bei denen, wer Interesse hat...hier rein werfen möcht ich es nicht.

    Als nächstes teste ich mal, ob es auch mit anderen Pins so gut geht, ich denke aber, schon, da die Pins im Programm definiert werden.
    Dazu gäbs keinen Grund, wenn man sie nicht ändern könnte.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.214
    Sodele.
    Inzwischen habe ich noch ein bisschen mit dem Display gespielt- und es gibt einige Erkenntnisse:

    1.: wenn mans _richtig_ anschliesst, funktioniert die Sache mit dem Kontrast per PWM _besser_.
    Ich hatte doch tatsächlich den 5V der LED-Beleuchtung an den Kontrastpin angeschlossen-daher das Geflackere.

    2.: der Plan geht auf: ich kann im Bedarfsfall die AltSoftSerial-Bibliothek benutzen (die normale SoftSerial ist recht...unzuverlässig), da es kein Problem ist, die Pins 8 und 9 dafür freizuhalten.

    3. man _könnte_ den CS-Pin auch noch frei bekommen, indem man den entsprechenden Pin vom Display einfach auf 5V legt- funktioniert!
    Ob es ne gute Idee ist, weiss ich nicht....
    Das hätte z.B. die Einschränkung, dass man dann den SPI-Bus nicht noch für andere SPI-Geräte benutzen kann. Da es ausreichend freie Pins geben wird, lass ich den CS auf Pin 10, und gut.
    Das Display braucht trotzdem insgesamt nur vier Pins: Kontrast (12), CLk(13), MOSI(11) und CS(10).
    Ist doch ganz erträglich.

    Ich häng mal das Anschlusschema an. Der Übersicht wegen hab ich mal die ganzen Leitungen für die Eingabegeräte und das BT-Modul rausgenommen.

    Klicke auf die Grafik für eine größere Ansicht

Name:	BT-Fernsteuerung_Displayanschluss.jpg
Hits:	10
Größe:	47,5 KB
ID:	34901
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.677
    Blog-Einträge
    1
    Hallo Sly,

    vergiss Software Serial beim Nano am besten. Was damit funktioniert ist das Senden in eine Richtung, Halbduplex. Bei Vollduplex kannst Du Probleme bekommen. Das AltSoftSerial ist da nicht viel besser, habe ich auch ausprobiert. Aber dazu hat man ja den UART, um Daten zuverlässig zu übertragen. Grundsätzlich musst Du aber immer damit rechnen, dass bei einer Seriellen Übertragung der Datenstrom gestört werden kann. Ob der UART da mit Prüfsummen/-bits Abhilfe schafft, weiß ich allerdings nicht. Von UART zu UART seriell zu übertragen, ist auch kein Problem, wenn Du einen DIP-Schalter (oder einen anderen) einsetzt, mit dem Du die serielle Verbindung unterbrechen kannst, um Software auf die Geräte, per USB-Kabel, aufzuspielen.

    MfG

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.214
    Ich habs befürchtet- du hast damit (schlechte) Erfahrungen?
    Getestet hatte ich die Kommunikation neulich zwischen dem XPlorer (der hat ja inzwischen auch ein HC 05 drin) und nem Uno, auf beiden SoftSerial....auf dem UNO lief es tadellos, aber der NANO zickte etwas.
    Allerdings hatte der UNO auch nix weiter zu tun, während auf dem Nano ja "nebenbei" die XP2-Software läuft.

    Schalter einbauen (um USB weiter nutzen zu können) wäre eigentlich Plan B gewesen- aber vielleicht sollte ich _den_ tatsächlich zu Plan A erklären?
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    78
    Beiträge
    2.180
    Hi Sly,

    gratulation! Und wie schon erwähnt, denke ich ersnthaft darüber nach das teil nachzubauen, wenn ich denn Deine ideen nutzen darf
    gruß inka

Ähnliche Themen

  1. Der universelle IR Fernbedienungs-Empfänger
    Von for_ro im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 34
    Letzter Beitrag: 30.08.2015, 11:18
  2. Universelle Fernbedienung über Bluetooth
    Von Trabukh im Forum Vorstellung+Bilder+Ideen zu geplanten eigenen Projekten/Bots
    Antworten: 2
    Letzter Beitrag: 05.01.2013, 21:58
  3. Universelle 16-bit-USB-Messbox
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 1
    Letzter Beitrag: 11.10.2012, 16:57
  4. UNITALK, Die universelle Sprachausgabe
    Von gpsklaus im Forum Eigene fertige Schaltungen und Bauanleitungen
    Antworten: 38
    Letzter Beitrag: 25.11.2006, 20:56
  5. Universelle LCD-Routine für AVR
    Von skyrider im Forum AVR Hardwarethemen
    Antworten: 10
    Letzter Beitrag: 22.05.2005, 16:05

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

12V Akku bauen