FiliusRucilo
28.03.2020, 11:36

Editiert von
FiliusRucilo
28.03.2020, 11:38

+6Der MiniDominator -

Seit etwa Weihnachten setze ich mich intensiver mit PoweredUp! auf Protokollebene auseinander um das neue System in meine bestehende Infrastruktur zu integrieren. Auf meiner Weltbeherrschungskonsole dem Entwicklungssystem habe ich mich schon so tief reingebohrt, das ich über die Umsetzungsqualität seitens LEGO nur noch den Kopf schütteln kann. "Only the best is good enough"? Au weia!
Da veröffentlicht LEGO einen Protokollstandard und dann halten die sich selbst nicht dran. Man merkt DEUTLICH, das es keine Übergeordnete Instanz gibt, die bei solchen Basisplattformen (und PF2 ist eine solche!) für ausreichende Qualität und Standardisierung sorgt. Bei Steinen bekommen die das doch auch hin - wieso nicht bei Software?! Egal. Das ist heute nicht das Thema...

Nach "nur" 3 Monaten rumgebastelt gibt es so was wie ein erstes "MOC". Den MiniDominator. Ja, ich weiß: Bautechnisch sicher kein geistiger Höhenflug, dafür kann das kleine Maschinchen ein paar nette "Zirkuskunststückchen" mit LEGO Hubs machen.

Das Arbeitsthema war: "Wie bediene ich einen einen PoweredUp! Hub mit dem grünen Knopf" wahlweise auch "Ich will meine Powerfunctions Batteriebox zurück!"

Dazu habe ich ein Video gemacht, weil bewegte Sachen auf Bildern zeigen ist irgendwie blöd.
Wie das bei Videos auf Flickr so ist, müsst ihr das Bild unten anklicken um nach Flickr zu wechseln. Ich habs halt nicht so mit youTube. Trotzdem viel Spaß!

[image]

Smart battery box by Filius Rucilo, auf Flickr

Der MiniDominator kann SmartHub, BoostHub, TechnicHub (Control+) sowie 6 Sorten Motoren (eigentlich alle bekannten: M-Motor, Train-Motor, Interner Boost Motor, Externer Boost Motor, Kleiner Technic Motor, Großer Technic Motor... Gibts noch welche, die ich noch nicht kenne?) und die LED Lichter. Alles in jeglicher Kombination und Portanzahl.
WeDo Hub? Achtung Wortwitz: Hub ich! Den aber in mein System zu integrieren - Siehe erster Satz dieses Posts. Da ist alles irgendwie von innen nach aussen gedreht?! Wenn man sich im LEGO WiFi Protokoll 3.0 zurechtfindet, spricht der WeDo Hub irgendwie "polnisch Rückwärts".

Technisch wäre Raspberry Pi sogar in der Lage mehrere Hubs gleichzeitig zu bedienen. 3 Stück gehen, dann läuft der Raspberry auf 100% Systemauslastung. Es ist halt nur der "kleine" mit einem CPU Kern.
Mehrere Hubs Gleichzeitig scheitert in diesem Kontext aber am Unvermögen der Programmierer, die den Python Bluetooth Wrapper gemacht haben: Immer wenn man einen Bluetooth Scan startet, werden erstmal alle bestehenden Verbindungen gekappt. Man kann also durchaus mehrere Hubs gleichzeitig anschließen, wenn man VORHER deren Adressen kennt und diese ohne Scan direkt verbindet. Es ist halt wie immer: Eiiiiinmal mit Profis arbeiten, eiiiinmal nur... Na, vielleicht wird der Bug ja irgendwann mal noch behoben und dann geht das auch mit scannen und mehreren Hubs auf einmal.


Born2Brick e.V. | Brick-Fans Rhein-Main | snottingen.de | Filius Rucilo auf Flickr


jopiek , aap134 , Ben® , Lok24 , Mylenium , JuL gefällt das (6 Mitglieder)


Lok24
28.03.2020, 14:18

Als Antwort auf den Beitrag von FiliusRucilo

Re: Der MiniDominator -

Moin Erek,

very nice.

Zum Verständnis:
am Hub kann ich x Farben durchklimpern, wobei x = Anzahl Ports des verbundenen Hubs.
Innerhalb einer Farbe (=port) gibt es dann vor-zurück-stop, jeweils 100%

Soweit richtig?

Frage:
Warum gehen nicht mehr als 3 Verbindungen? Das hängt doch sicher von der Frquenz ab, mit der Du die Befehle
schickst?

Idee zur Erweiterung:
Mit einem WLAN könnte man noch sehr viel mehr daraus machen.
(als AddOn, nicht als Ersatz)

Welcher Raspberry ist das genau?

Grüße

Werner



FiliusRucilo
28.03.2020, 17:56

Als Antwort auf den Beitrag von Lok24

Re: Der MiniDominator -

Lok24 hat geschrieben:


...am Hub kann ich x Farben durchklimpern, wobei x = Anzahl Ports des verbundenen Hubs.
Innerhalb einer Farbe (=port) gibt es dann vor-zurück-stop, jeweils 100%

Soweit richtig?


Fast. Du klimperst aktive Ports durch und die LED wird passend illuminiert. Das Ergebnis ist allerdings das selbe. Bei den LED Lights halt an/aus unter ignorieren der Drehrichtung. (Links- oder Rechtsdrehendes LED Licht. Witziger Gedanke...)
x kann sich während der Laufzeit durch an und abstecken von Hardware auch ändern. Die LED Farben 1-x laufen analog zu den externen Portnummern (1 - x)-1 einfach durch.

Lok24 hat geschrieben:

Warum gehen nicht mehr als 3 Verbindungen? Das hängt doch sicher von der Frquenz ab, mit der Du die Befehle
schickst?


Äh nööö wenn man es drauf anlegt geht da auch mehr. Bis der Pi "quietscht" Dieser spezielle Pi, ein Pi Zero W Rev. 1.1, läuft mit rund 30% Prozessorlast, wenn a ein Technic-Hub aktiv dranhängt. Das liegt an der Art und weise wie meine Multi-Hub-Multi-Trhead-Library so arbeitet und an Alter, Taktfrequenz und Speicherausbau des Geräts. Die Library macht für jedes IO einen eigenen Thread auf und überwacht die Aktionen der Hardware bzw. bildet eine API Richtung Hauptprogramm. Mit einem Leistungsfähigeren Pi Kannst Du da auch viel mehr Hubs laufen lassen. Mein Entwicklungssystem langweilt sich mit einem Hub bei 2,5% Last und legt abhängig von Hub-Typ und angeschlossener Hardware um 1-2% nach.

Lok24 hat geschrieben:

Idee zur Erweiterung:
Mit einem WLAN könnte man noch sehr viel mehr daraus machen.
(als AddOn, nicht als Ersatz)


Genau das war ja nicht der Plan... Das Maschinchen soll ja gerade eine Batterie-Box simulieren. Eigentlich sollte das Gerät gar nicht "sein". Das Beste wäre wenn LEGO diese Funktionalität in die Hub Firmware einbauen würde damit die Hubs genau so eingeschränkt funktionieren, wenn sie mit nichts gekoppelt sind. Das wäre gut. Alles weitere und bessere erledigt dann die Software auf dem Tablett oder Smartphone. Dazu müsste LEGO ja nur den grünen Knopf mal als IO definieren. Ich kann mir nicht erklären warum sie das bei den inneren Sensoren "Spannung", "Strom" und "LED" tun, beim Knopf aber nicht. Der schickt keine Meldungen von "Hub attached IO", sondern setzt "Hub Properties". Das ist befremdlich was die da gemacht haben. "Konsequent" und "System" ist jedenfalls anders...

Am Ende ist der MiniDominator die erste Payload für meine Library, die vorzeigbar deren Leistungsfähigkeit und Flexibilität aufzeigt. Der steuernde Programmteil hat gerade mal 200 Zeilen Code und damit ist alles abgefackelt. Von Scannen über "Knöpfchen drücken", Drehrichtung ändern bis Ein-, Aus- und Ports durchschalten.


Born2Brick e.V. | Brick-Fans Rhein-Main | snottingen.de | Filius Rucilo auf Flickr


Lok24
28.03.2020, 18:46

Als Antwort auf den Beitrag von FiliusRucilo

Re: Der MiniDominator -

Hallo Erek,

I see.

Ganz klar ist mir aber die Vorgehensweise dann nicht.
Würde es nicht genügen, für die max 4 ports einmal je einen Motor-Befehl zu schicken?
(ist aber auch egal, wenn es so konzipiert ist, dass es immer genau ein Hub bedient)

Und das "User Interface" in die Box zu legen statt in das Hub?

Die 200 Zeilen sind aber ohne die eigentliche Library die drunter liegt?

Grüße

Werner



FiliusRucilo
28.03.2020, 20:18

Als Antwort auf den Beitrag von Lok24

Editiert von
FiliusRucilo
28.03.2020, 20:29

Re: Der MiniDominator -

Lok24 hat geschrieben:

Hallo Erek,

I see.

Ganz klar ist mir aber die Vorgehensweise dann nicht.
Würde es nicht genügen, für die max 4 ports einmal je einen Motor-Befehl zu schicken?
(ist aber auch egal, wenn es so konzipiert ist, dass es immer genau ein Hub bedient)

Und das "User Interface" in die Box zu legen statt in das Hub?

Die 200 Zeilen sind aber ohne die eigentliche Library die drunter liegt?

Grüße

Werner


Bei Spike sind wir ja mittlerweile schon bei 6 Ports...
Ich bin kein Freund der Try-and-Error-Methode. Klar kann ich den Hub einfach mit Kommandos beschießen und hoffen, das er dabei nicht abstürzt. (Oder sich vor Verzweiflung in den disconnect stürzt)
Meine Library weiss welche Hardware "Online" ist, so kann ich immer das passende Kommando schicken.

Das UI in den Controller zu legen war nicht der Sinn der Fingerübung. Das Stichwort ist "Batterie-Box-Verhalten" und aufzeigen was LEGO tun könnte um diejenigen einzufangen, die kein Smart-Device einsetzen oder nicht programmieren können/wollen.

Die Library hat im Augenblick 3454 Zeilen Code. ...und es ist bei weitem nicht alles Implementiert. Das ist deshalb so viel, weil ich mittlerweile die Hardware exakt auslesen kann, das bei Bedarf auch tue, und damit sehen kann welche Parameter an einen Sensor/Aktor geschickt werden können (sollten)

Im Screenshot schön zu sehen: Der IO RGB Light meldet einen Mode1, aber leider hat irgendwer in Billund vergessen den Code dafür zu implementieren. Der Smarthub quittiert ein entsprechendes Kommando zur Ansteuerung des RGB Modus mit einer Fehlermeldung, (Illegal Command) die anderen Hubs (Technic, Boost) schweigen sich galant aus und kehren den entgegengenommenen Befehl unter den Teppich. (Immerhin kein beleidigtes disconnect als ACK)
Auch interessant: Laut Parameterliste sind die gültigen Werte für Mode 0 -> 0-10. Interessanterweise kann man aber auch noch die 11 beschicken und erst bei 12 kommen dann Fehlermeldungen zurück. Das wiederum ist ein Fehler im Aktor, denn lt. Protokoll wird die 11 genutzt um darin die zuletzt genutzte Farbe vor dem Busy-Blinken zu speichern. Im Klartext ist die Farbe 11 die "aktuelle" Farbe. Der Hub braucht das wohl um nach dem Blinken wieder auf die vorher eingestellte Farbe zu schalten. Warum so etwas aber wieder auf einem von aussen zugänglichen Register gemacht werden muss bleibt eines der vielen ungelösten Rätsel...

[image]


Born2Brick e.V. | Brick-Fans Rhein-Main | snottingen.de | Filius Rucilo auf Flickr


FiliusRucilo
28.03.2020, 20:43

Als Antwort auf den Beitrag von FiliusRucilo

Re: Der MiniDominator -

Hier findet ihr noch ein paar Bilder des Entwicklungssystems, meiner mobilen "Weltbeherrschungskonsole V2" kurz auch WDC2 (World Domination Console)

[image]

World Domination Console by Filius Rucilo, auf Flickr


Born2Brick e.V. | Brick-Fans Rhein-Main | snottingen.de | Filius Rucilo auf Flickr


Lok24
29.03.2020, 09:55

Als Antwort auf den Beitrag von FiliusRucilo

Re: Der MiniDominator -

Moin Erek,

FiliusRucilo hat geschrieben:

Das UI in den Controller zu legen war nicht der Sinn der Fingerübung.

Du hast zwei Taster (einen im Hub, einen im MD) und ich verstehe nicht warum man dann zum Bedienen
nicht den anderen nehmen könnte, denn das ist ja Dein UI: Taste und LED.
Aber gut, wenn es genau so sein soll dann ist natürlich jede Diskussion darüber sinnlos.

FiliusRucilo hat geschrieben:
Das Stichwort ist "Batterie-Box-Verhalten" und aufzeigen was LEGO tun könnte um diejenigen einzufangen, die kein Smart-Device einsetzen oder nicht programmieren können/wollen.


1.) der Weg den LEGO gehen will (und hoffentlich wird) ist ein anderer
2.) ja, das hatten wir hier schon mal diskutiert und waren bei 5-6 bei Tastern gelandet, finde es gerade nicht mehr.
Das wäre das "universelle UI"

Grüße über den Main

Werner



Gesamter Thread: