-         
Seite 4 von 6 ErsteErste ... 23456 LetzteLetzte
Ergebnis 31 bis 40 von 59

Thema: Universelle Fernsteuerung mit Bluetooth

  1. #31
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    09.10.2014
    Beiträge
    5.071
    Anzeige

    Zitat Zitat von Rabenauge Beitrag anzeigen
    ...weil ich den Nano hier habe.
    Und weil ich nichts davon halte, mit Kanonen auf Spatzen zu schiessen.
    das Problem ist nicht, mit "Kanonen" auf Spatzen zu schießen, sondern der Glaube, unbedingt mit Wasserpistolen oder Blasrohren auf Strohhalmbasis das Ziel erreichen zu müssen
    ein SAMD21=M0/Zero ist IMO der ggT zur Problemlösung, oder ein ESP8266 mit ADS1115.
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  2. #32
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.653
    Blasrohre sind halt zuverlässiger...
    Mal im Ernst: wenn wir uns nicht angewöhnt hätten, jedes Problem einfach mit geballter Rechenpower zu erschlagen, wären uns Seuchen wie Java erspart geblieben...und Windows inzwischen auch.

    Ich find es durchaus interessanter, aus so nem schwachbrüstigen Rechner rauszuholen, was geht.
    Die können mehr, als man oft meint- wenn man gescheit programmiert (naja....ich benutz ja auch nur die Arduino-IDE, insofern wäre da noch ne Menge Luft...)
    Wenn sich rausstellen sollte, dass das Ding instabil läuft (woran ich _noch_ nicht glaube), dann wird sich ziemlich sicher ein Teensy finden, der das Problem aus der Welt schaffen kann.

    Wie gesagt:vom ESP halte ich nicht viel- ich weiss zwar die Vorzüge durchaus auch zu schätzen (ein paar von hab ich auch schon verbaut)- aber ich trau den Chinesen einfach nicht. Wenn die nicht mit der Sprache rausrücken wollen, was der in Wirklichkeit noch alles treibt (deutlich mehr als man ihm sagt, das steht fest)-werden sie ihre Gründe haben...auf solche (möglichen) Sicherheitsprobleme reagier ich bisschen allergisch.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  3. #33
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    09.10.2014
    Beiträge
    5.071
    was die ESPs gundsätzlich angeht, hast du ntl Recht. Die ESP-cores und -libs für Arduino werden ja auch nur von einer Community privat "oben drauf" entwickelt, nicht von den Chinesen selber, und daher ist vieles noch komplett unfertig. Aber für "nicht trauen" besteht IMO bei denen kein Anlass, man baut sie ja nicht in sicherheitsrelevante IT Systeme mit Datenverschlüsselung ein.

    Hätten die Nanos mehr RAM (8? 16kB?), wäre ja auch nichts gegen solche AVRs einzuwenden, aber 2 oder 2,5k sind einfach lächerlich, die werden ja schon von SPI+I2C fast komplett aufgebraucht, sodass kaum noch was für ein Programm übrig bleibt.
    Wenn du den aber nur deshalb nimmst, weil er gerade da ist und du nichts besseres hast: klar, dann würde ich es auch erstmal damit versuchen.

    Deinen Seitenhieb auf Windows etc verstehe ich aber nicht, cpus müssen mit den Sofwareanforderungen mitwachsen, genau wie hier, und die Preise dafür sinken ja zusehends - kein Grund also, in der IT-Steinzeit zu verweilen. Oder wolltest du ernsthaft auch noch mit CP/M und MSDOS auf deinem Homecomputer herumwerkeln?
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  4. #34
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.653
    Hm -ich benutz einfach Linux.
    Schon seit Jahren... unproblematisch, zuverlässig, sicher und mit _weit_ moderateren Hardwareanforderungen.
    Tatsächlich hatte ich mal ein Ubuntu (ich glaub, das war noch das 14er) auf nen "Sperrmüll-Rechner" (sah jedenfalls so aus..) ans laufen gebracht, der nicht mal mit XP flüssig lief- das Ding war so schwachbrüstig, dass ich die LXDE nachinstallieren musste, weil nicht mal Unity auf die Beine kam.
    Lief dann aber völlig problemlos und überraschend schnell.
    Aber lassen wir das- wird nur wieder ein Glaubenskrieg, und ich muss nix glauben.

    Inzwischen hat es noch nen netten Rahmen ums Display gegeben (der den überschüssigen, anders-blau leuchtenden Rand fast komplett verdeckt), einen Einbau-Adapter für den letzten Button und nen neuen Drehknopf auch (den mache ich noch mal neu, der ist zu gross).
    Wie ich die Joysticks verblenden soll, grüble ich noch...Klicke auf die Grafik für eine größere Ansicht

Name:	20200406_153430.jpg
Hits:	10
Größe:	49,5 KB
ID:	34933

    Sieht doch schon ganz nett aus (ich weiss, die Farben..... aber ich nehm, was grade da ist).
    Muss mal wieder ein paar Rollen Filament besorgen.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  5. #35
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.653

    Beitrag

    Sodele.
    Die Hardware dürfte fertig sein (es sei denn, mir fällt noch irgendwas ein).

    Heute hab ich endlich mal die letzte Komponente noch verkabelt-der einzelnen Button.
    Der ist mehr als ein simpler Knopf: er hat zusätzlich nen roten Ring eingelegt, der leuchten kann.
    Den kann man auch separat steuern- ich werde den also als zusätzliche Anzeige benutzen (z.B. kann man ihn aufleuchten lassen, wenn das BT-Modul sich mit irgendwas verbunden hat).
    Sehr praktisch- und sehr hübsch.
    Damit ich später auch weiss, ob das BT-Modul sich mit _irgendwas_ koppeln konnte, habe ich die State-Leitung vom HC 05 auch noch an nen Digitalpin getüdelt.

    Davon sind jetzt noch zwei Stück frei, hehe:

    Code:
    #define clockPin 13                  // SPI Clock
    #define csPin 12                      // Chip-Select Display
    #define mosiPin 11                  // SPI-MOSI
    
    #define statusPin 8                     // High, wenn gekoppelt
    #define bluetoothPin 7                // schaltet BT-Modul ein oder aus
    #define ledPin  6                        // die rote LED im Button
    #define buttonPin 5                    // der Button
    #define encoderButton 4            // Button Encoder
    #define encoderPinB 3               // zweiter Pin Encoder
    #define encoderPinA 2               // erster Pin Rotationsencoder
    
    #define lX A0                         // X-Achse linker Stick
    #define lY A1                         // Y-Achse linker Stick
    #define lB A2                         // Button linker Stick
    #define rX A7                         // X-Achse rechter Stick
    #define rY A6                         // Y-Achse rechter Stick
    #define rB A5                         // Button rechter Stick
    Aber ein paar analoge wären auch noch da, wenn sie gebraucht würden...

    Ein bisschen ärgere ich mich jetzt, dass ich den Button nicht mit blauer Beleuchtung genommen hatte- das rot fällt ziemlich auf, hehe- aber man kanns auch sportlich nehmen und sagen "soll es ja auch".

    Die Gehäuseteile sind inzwischen auch alle fertig gedruckt- die Abdeckungen für die Sticks waren grausam: bis die leidlich passten, hab ich sechs oder sieben Probeteile gedruckt...aber nun gehts.

    Die kleinen Teile hab ich dann mit dem 3D-Stift kurzerhand von innen ins Gehäuse geschweisst.
    Die hatte ich bewusst einzeln gezeichnet, und zwar so, dass man sie einsetzen, aber ein wenig hin und herschieben kann- so kann man alles schön anpassen, ohne die gesamte Abdeckplatte 15x zu drucken.
    Dadurch, dass sie ihre Öffnungen aussen überlappen, sieht man davon jetzt nichts mehr.

    Als nächstes muss jetzt der neue Button auch noch ne Anzeige im Display bekommen, keine grosse Sache: halt nen Kreis, der gefüllt dargestellt wird, wenn man den Button drückt- so ähnlich wie beim Encoder, nur ohne Wert in der Mitte eben.

    Wenn die da ist, mach ich wiedermal ein Foto.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  6. #36
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.653
    Hab eben mal eine Art kleines Video gemacht, von den bisherigen Funktionen.

    Klick

    Inzwischen bin ich noch ein kleines Stück weiter:
    nach dem Einschalten werden die Sticks, nach einer kurzen Wartezeit, kalibriert (Wartezeit, damit man die Pfoten weg nehmen kann, das steht auch im Display), so weit waren wir schon.
    Anschliessend fängt der Button an, zu blinken...solange er das macht (einige Sekunden) kann man ihn drücken, und damit die Fernsteuerung in den USB-Modus versetzen: das Bluetooth-Modul wird dann abgeschalten (genauer gesagt, gar nicht erst an), und man kann flashen, oder die seriellen Ausgaben im Monitor verfolgen. Dort kommt dann genau das an, was normal auch per Bluetooth gesendet würde...

    Drückt man den Button nicht, wird ganz normal durchgestartet und das BT-Modul eingeschaltet.
    Ich denke,das ist so ausreichend praxistauglich: wenn ich das Ding einfach nur benutzen will, schalte ich sie ein und muss mich nicht weiter drum kümmern.
    Will ich in den USB-Modus, drücke ich halt mal den Button....

    Insgesamt haben wir jetzt also vier analoge Kanäle, drei völlig frei verwendbare Buttons, zusätzlich nen Encoder, der quasi-analog arbeitet (tut er nicht, aber er kann, genau wie die Sticks, Werte zwischen 0 und 255 erzeugen), und den Button des Encoders, der allerdings den Encoder-Wert wieder auf 0 stellt. Daher ist der als Button nur eingeschränkt zu verwenden (wenn man den Encoderwert nich braucht, ist es kein Problem).
    Ich denke, damit kann man erst mal eine ganze Menge anfangen...
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  7. #37
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.653
    Ein bisschen hab ich mal weiter codiert:
    Es werden jetzt alle Werte tatsächlich auch per BT gesendet, in der Form:
    lX128-> X-Achse links hat den Wert 128.
    Auf die Weise geht das mit relativ wenigen Daten von statten-es werden _nur_ Änderungen gesendet.
    Wenn man nix tut, dann nicht....
    Die Auswertung auf der Gegenseite steht noch aus....ich denke aber, sehr schwierig wird das nicht.

    Inzwischen merkt die Fernsteuerung auch, wenn sie sich mit irgendwem verbinden konnte (so lange sie das nicht hat, gibts ne Art "Fortschrittsbalken" im Display.
    Ermittelt wird das über den STATE-Pin des HC-Moduls.

    Das Nächste wird jetzt sein, dass sie, nach erfolgter Koppelung, die Gegenstelle fragt "wer bist du"- ich möchte den Namen des verbundenen Roboters dann im Display stehn haben.
    Dazu brauch ich dann aber auch für den "Roboter" erst mal ein Software- Grundgerüst- momentan besteht der lediglich aus nem, neben das Steckbrett gespaxten Uno und einem weiteren HC 05-Modul, was lediglich per AT-Befehle passend konfiguriert ist.

    Verbinden klappt-aber mehr kann das noch gar nich...allerdings hab ich die Tage schonmal einen kleinen Parser gebastelt, der Kommandos, die von der seriellen Schnittstelle kommen, auswertet-der muss aber noch aufgebohrt werden, um z.B. die Zahlen aus den eintreffenden Strings extrahieren zu können.

    So nebenbei steigen meine Skills im RAM-Sparen, hehe: um diesen Fortschritts-Balken realisieren zu können (es werden einfach 1,2,3,4 Sternchen gezeichnet, und dann fängts von vorne an), brauchte ich ne Variable als Zähler-da hab ich kurzerhand eine der globalen, die an _dieser_ Stelle nicht gebraucht wird, mal eben ausgeliehen.
    Somit _kein_ zusätzlicher Speicherverbrauch *freu
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  8. #38
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    09.10.2014
    Beiträge
    5.071
    Zitat Zitat von Rabenauge Beitrag anzeigen
    Ein bisschen hab ich mal weiter codiert:
    Es werden jetzt alle Werte tatsächlich auch per BT gesendet, in der Form:
    lX128-> X-Achse links hat den Wert 128.
    Auf die Weise geht das mit relativ wenigen Daten von statten-es werden _nur_ Änderungen gesendet.
    Wenn man nix tut, dann nicht....
    Die Auswertung auf der Gegenseite steht noch aus....ich denke aber, sehr schwierig wird das nicht.
    hallo,
    ich halte das für u.U. bedenklich bzw. gefährlich:
    Folgender Fall:
    wert lX128 gesendet und empfangen => alles ok, Empfänger führt entspr. Befehl aus (z.B. Motor links auf pwm128 )
    danach
    wert lX0 gesendet aber wegen Unterbrechung oder Block (Serial stream/buffer hardware/software sync/async wire/wireless) nicht empfangen => Empfänger führt immer noch entspr. alten Befehl aus (Motor links auf pwm128 statt 0), da sich für ihn nichts geändert hat.

    Ganz abgesehen davon ist es ebenfalls denkbar, dass einzelne Bytes (l,X,1,2,8 ) durch Datenkorruption falsch übertragen bzw. empfangen werden - wie prüfst du auf Datenintegrität und korrekten Empfang? z.B.
    wert lX128 gesendet aber wegen Datenkorruption falsch empfangen => Empfänger liest lY128 (anderer Motor auf pwm128 ) oder noch was ganz anderes
    (edit: das müsste dann auf heartbeat und timeouts gecheckt und nach Rückmeldung auf Richtigkeit und Vollständigkeit überprüft werden; weitere Stichworte sind message-Startsignal, Ende-Signal, msg-Länge, checksum)
    Geändert von HaWe (15.04.2020 um 12:24 Uhr)
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  9. #39
    Erfahrener Benutzer Robotik Einstein Avatar von Moppi
    Registriert seit
    18.03.2018
    Beiträge
    1.900
    Blog-Einträge
    12
    Zur Not kann er noch ein Paritätsbit mitsenden und auf der Gegenseite prüfen. Sehr genau beschrieben ist das hier: https://de.wikipedia.org/wiki/Parit%C3%A4tsbit
    Eventuell kann das einfach so umgesetzt werden, dass man nur halbe Wertebereiche überträgt und das höchstwertige Bit als Paritätsbit verwendet.
    Sollte kein Problem sein.


    MfG

  10. #40
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    51
    Beiträge
    1.653
    Heartbeat ist schon vorbereitet.
    Ich habe schon einen Timer drin, der alle halbe Sekunde einen Tick erzeugt (den setze ich wahrscheinlich noch deutlich runter, in der Zeit), denn es stimmt: wenn das Stop-Signal nicht ankommt, fährt er endlos weiter.
    Die HC 05 merken auch erst nach ungefähr zehn Sekunden, wenn die Verbindung weg ist-> zu lange.
    Ich will also (wie gesagt, vermutlich wirds am Ende mindestens viermal pro Sekunde passieren) ein "alive" senden, und wenn das, sagen wir, zweimal, nicht kommt, weiss der Empfänger, dass da was faul ist, und kann sein fail-save aktivieren.

    Auch richtig: gegen verstümmelte Signale hab ich noch nix...hat aber nicht das BT-Protokoll da sowieso was eingebaut?

    Aber gut, dass der Einwand kam, ich werd das beim ausprobieren (vorerst sowieso nur trocken, mit dem UNO als Prügelknaben) mal im Auge behalten.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

Seite 4 von 6 ErsteErste ... 23456 LetzteLetzte

Ä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
  •