-         
Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 19 von 19

Thema: Universelle Fernsteuerung mit Bluetooth

  1. #11
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.807
    Anzeige

    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 13:50 Uhr)
    Strom fließt auch durch krumme Drähte !

  2. #12
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    4.967
    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.
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  3. #13
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.807
    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. #14
    Erfahrener Benutzer Roboter Genie Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.596
    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. #15
    Erfahrener Benutzer Roboter Genie Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.596
    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:	5
Größe:	47,5 KB
ID:	34901
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  6. #16
    Erfahrener Benutzer Robotik Einstein Avatar von Moppi
    Registriert seit
    18.03.2018
    Beiträge
    1.757
    Blog-Einträge
    9
    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. #17
    Erfahrener Benutzer Roboter Genie Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.596
    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. #18
    Erfahrener Benutzer Robotik Einstein Avatar von Moppi
    Registriert seit
    18.03.2018
    Beiträge
    1.757
    Blog-Einträge
    9
    auf dem UNO lief es tadellos, aber der NANO zickte etwas
    Da haben wir dieselben Erfahrungen gesammelt. Mit dem 328P vom UNO hatte ich nie Probleme, aber mit dem vom NANO. Deswegen habe ich das dann bleiben lassen, mit SoftwareSerial. Allerdings, Halbduplex scheint damit auch auf dem NANO gut zu funktionieren. Also erst in eine Richtung senden und danach in die Gegenrichtung. Per UART und Schalter dazwischen ist die beste Lösung - jedenfalls für meine Bedürfnisse. ZUmal Du dadurch Pins freihältst, für was anderes.

    MfG

  9. #19
    Erfahrener Benutzer Roboter Genie Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.596
    Hm- hab das heute morgen mit nem Kumpel mal diskutiert, und es scheint sich ne noch cleverere Lösung aufzutun, zum abschalten:

    Das Modul kommt an Rx1/Tx1, aber die Stromversorgung des HC 05 läuft über nen Transistor.
    Der wiederum liegt an einem freien Pin- ich muss noch mal genauer in den Schaltplan gucken, aber da dürften noch einige frei sein.
    Das wäre-wenns funktioniert-die eleganteste Lösung: man kann dann einfach per Software (z.B. beim Einschalten) zwischen USB-und BT-Betrieb wählen.

    Ich werd aufm Steckbrett mal testen, was das HC 05 macht, wenn es "abgeschalten" ist aber auf den Logik-Leitungen Signale anliegen....mit etwas Glück funktioniert das.
    Ein Transistor sollte reichen, so hoch ist ja die Stromaufnahme der BT-Module nicht..mit nem ESP würd ich das so nicht versuchen..

    Aktueller Stand: das Display ist in die Fernsteuerung eingebaut und an den Nano angeschlossen, läuft.
    Grad drucke ich mir ne kleine Halterung, mit der ich nen USB-Stecker (mit nem bisschen Kabel dran) in die Fernsteuerung schweissen kann, damit ich das Ding schonmal per Powerbank versorgen kann.

    Nachtrag: Die Powerbank ist angeschlossen.
    Den USB-Stecker zu verkleben, war gar nicht nötig, wenn man genau genug misst und druckt, passt der Stecker fest genug in den Halter.
    Das Ding läuft nun auch standalone.
    Ein-und ausgeschalten wird einfach, indem man die Powerbank rauszieht-oder reinschiebt.

    Inzwischen gibt es auch ein Boot-Logo auf dem Display...frisst abartig Speicher, aber notfalls kann ich es noch ein paar Byte eindampfen. Wenn es ganz schlimm komt, kann ich _das_ auch noch aus Linien zusammencoden, das dürfte den Verbrauch auch senken, aber evtl ist das auch gar nicht nötig, mal sehn.

    Etwas Ärger hat mir noch der Kontrast gemacht: erst klappte es gar nicht, den zu verstellen, bis ich drauf kam, dass Pin 12 bei den Nanos gar keine PWM kann.
    Umgebaut auf Pin10 (12 ist nun CS, dem isses Wurst)...und ein schönes Flimmern *grummel
    Hab dann Timer1 auf irgendwas mit 30KHz eingestellt, nun gehts- flimmern sieht man nur noch bei recht niedrigen Kontrasteinstellungen, aber da ist die Anzeige schon braun, statt weiss...

    Die Betriebsdauer mit der kleinen Powerbank beträgt locker 1-2 Stunden (so lange lief die schon mit der einen, die hat inzwischen abgeschalten, aber ich weiss nicht, wie voll die vorher war) , und da ich von den Dingern zwei hab, halte ich das allemal für ausreichend.

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

Name:	XPControl_foddo.jpg
Hits:	4
Größe:	54,2 KB
ID:	34911
    Geändert von Rabenauge (23.03.2020 um 22:08 Uhr)
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

Seite 2 von 2 ErsteErste 12

Ä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, 10: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, 20:58
  3. Universelle 16-bit-USB-Messbox
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 1
    Letzter Beitrag: 11.10.2012, 15:57
  4. UNITALK, Die universelle Sprachausgabe
    Von gpsklaus im Forum Eigene fertige Schaltungen und Bauanleitungen
    Antworten: 38
    Letzter Beitrag: 25.11.2006, 19:56
  5. Universelle LCD-Routine für AVR
    Von skyrider im Forum AVR Hardwarethemen
    Antworten: 10
    Letzter Beitrag: 22.05.2005, 15:05

Berechtigungen

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