Universelle Fernsteuerung mit Bluetooth

[Rabenauge]

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:

#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.

[Rabenauge]

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...

[Rabenauge]

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

[HaWe]

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)

[Moppi]

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

[Rabenauge]

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.

[HaWe]

der Fehler kann v.a. in der verkabelten Serial TX/RX-Kette vorkommen, also außerhalb von BT.
Meine Serial messages (hin/zurück) laufen immer per handshake, bei dem die Fernsteuerung und das Mobil msgs wechselweise in der Art versenden:

0 0xff Start
1 msg_len // (<=255)
2 timer-byte für heartbeat (in 100ms), auch für timeout
3 uint8_t(chksum) // summe über alle Datenbytes, die ab hier folgen, davon das low byte
4 ack
5 daten
6 daten
7 daten
8 daten
...
0xfe Ende

so kann gecheckt werden, ob
- alle bytes gelesen wurden (Anzahl inkl. Start und Ende)
- ob dabei auch alle Einzel-Bytes korrekt sind über chksum (nur geringe Fehlerwahrschl. bei weggelassenem chksum- highbyte)
- ob timeout und heartbeat im Rahmen sind
- ob die zuletzt empfangene Nachricht korrekt war

nach dem Senden wartet die Fernsteuerung, ob alle 4 checks korrekt waren beim Empfänger (Senden von ack plus Werte des Mobils an Fernsteuerung) - dann wartet wieder das Mobil, bis die Fernsteuerung neue Daten sendet.

PS
auch hier müsste evt. besser sichergestellt werden, dass immer alles gesendet wird, nicht nur bei Änderung eines Wertes.
Ändert sich nämlich ein Wert sehr schnell (255-->0), kann es sein, dass der Empfänger nur eine msg mit einem Zwischenwert liest (z.B. 50), aber die 0 verpasst: trotzdem wird er die chksum etc. als korrekt prüfen (auf 50) ohne wegen der Zeitverzögerung jemals die 0 in der Folge-Message zu bekommen, und der Sender kann u.U. der Meinung sein, er hätte die letzte Änderung schon gesendet und sendet die 0 nicht nochmal: also macht das Mobil mit Wert 50 weiter, nicht mit 0.