Ich stelle hier ein mein neues Projekt vor. Es ist noch sehr experimentell und ich habe auch leider wenig Zeit dafür, aber es nervt mich, dass Lego eine PlayStore Abfrage in ihre App eingebaut hat, womit die Appp nicht mehr auf meinem Telefon läuft.

Die Idee ist recht einfach: Man nimmt den bereits bekannten M5Stack Nano, bespielt ihn mit der Software und dann kann man den Controler passend per Fernbedienung am Display konfigurieren:

Linke Seite: Motorausgang
Obere Seite: Fernbedienungseingang

Man kann aus folgenden Modi pro Motorausgang und Fernbedienungseingang wählen:

1. Drücken: Drehen, Loslassen: Stop
2. 4 Geschwindigkeiten durchschalten
3. 8 Geschwindigkeiten durchschalten

Alle Funktionen funktionieren jeweils vorwärts (Grün) und rückwärts (Rot).

Der Ablauf geht in etwa so:

1. Mikrokontroller mit Strom verbinden
2. Hub koppeln
3. 1. Fernbedienung koppeln
4. optionnal 2. Fernbedienung koppeln
5. Display M5 drücken

danach kann man zwischen den Modi umschalten:

1. Aktion - betätigt die Funktionen per Fernbedienung
2. Fernbediungseingänge konfigurieren

Mit 2. kann man die einzelnen Einänge der Fernbedienung umschalten. Bisher wird nur eine gekoppelte Fernbedienung unterstützt, es sind aber bis zu zwei angedacht.

Wenn man nun die Fernbediungseingänge konfiguriert, kann man mit der linken Seite die Motorausgänge auswählen und mit der rechten Seite der Fernbedienung die Funktion auswählen. Sie wird rechts vom Eingang grafisch visualisiert.

hier eine kleine Demonstration:

Bisher werden ein Control+ oder ein PoweredHub und für jeden Ausgang einfacher Motor unterstützt. Mit der Zeit sollen mehr Funktionen hinzu kommen. Das nächste Ziel ist die Implementierung eines Servos mit automatischer Kalibrierung und die Unterstützung von bis zu zwei PoweredUp Hubs und zwei Fernbedienungen. Ferner sollen die Einstellungen auch gespeichert werden.

Ziel ist es nicht eine überfachtete Feature vielfalt zu bieten sondern sinnvolle und gut durchdachte Funktionen zu bieten.

Sollte jemand mehr Zeit haben, kann er gerne bei dem Projekt mitwirken:

https://github.com/ElTentakel/OpenPowerBrick

erreichte Meilensteine:

* 2. Fernbedienung wird unterstützt

---

---

Thomas52xxx , Lok24 , Garbage Collector , RobbyRay , Ben® , hassel62 , JuL gefällt das (7 Mitglieder)

---

Hallo,

sehr schön gemacht.

Ich habe für mein (inzwischen eingestelltes) microHub-Projekt folgende Dinge implementiert:
- Verschiedene Profile (= Zusammnenhang zwischen FB und was dann wo passiert, also die eigentliche Funktion)
- Völlige Trennung zwischen den Funktionen des Protokolls (legoino, M5Stack) und der Anwendung
- Speicherung beliebiger Parameter
- Änderung und Parametrisierung via Web-Interface
- Verbindung von bis zu 9 verschiedenen Hubs (egal ob FBs oder SmartHubs)
- Callbacks für Properties und Buttons in einer gekapselten Funktion

Für einfach Steuerungen nutze ich eine adaptive Geschwindigkeitskurve. Geht auch

Das geht ja in die ganz ähnliche Richtung wie Dein Projekt.
Bin sehr gespannt wie es weitergeht.

Grüße

Werner

---

---

Garbage Collector , hassel62 gefällt das

---

Lok24 hat geschrieben:

Danke, wobei die Projekte schon in eine andere Richtung gehen. Mir geht es darum, dass auch Kinder nach Einweisung in der Lage sind das Ding zu benutzen - da fällt das Smartphone raus. Hintergrund für die Wiederaufnahme des Projektes ist, dass Lego die Frechheit besitzt, dass man den 42124 nicht mit Fernbedienung steuern kann. Neben der Tatsache, dass auf meinem Telefon die Control+ App nicht _mehr_ unterstützt, habe ich mich entschlossen weiter zu machen. Ich fand es nebenbei auch beim 42114 ziemlich dämlich, dass man die Gangschaltung nicht direkt steuern konnte. Ich weiß nur noch nicht, wie man das umsetzen könnte. Aber bis dahin ist noch viel zu tun.

Gibt es Gründe für die Einstellung des microHub-Projektes? Ich hab ja das Projekt zwischzeitlich liegen lassen, weil Legoino ja keine Callbacks unterstützt hat, was das dynamische Anmelden von mehreren Fernbedienungen / Hubs unmöglich macht. Nachdem aber die Version 1.0 heraus kam, war der Weg frei. Das ermöglicht dann hoffentlich auch eine automatische Kalibrierung des Servos für eine Lenkung.

---

---

Hallo,

ElTentakel hat geschrieben:

Genau das war der Ansatz: kein Smartphone.
Wobei bei mir auch "(fast)keine Bedienung" am ATOM hinzukam.

ElTentakel hat geschrieben:
Ja, weil LEGO sich weigert, die FB mit dem technic-hub zu verbinden. Niemand weiß warum.

ElTentakel hat geschrieben:
Da brauchst Du eher 2 FBs, denn den "Modus umschalten" während der Fahrt ist irgendwie komisch.

ElTentakel hat geschrieben:
Das ging vorher alles schon ganz genauso, auch ohne Callbacks.
Wie viele andere sehe auch ich die callbacks kritisch, der Overhead ist zu groß, die Programmierung zerfieselt sich komplett. Andere sind zurück auf die 0.8, aus eben dem Grund.
Ich habe eine lauffähige Version, bei der die callbacks gekapselt sind und bei der Anwedung keine Rolle mehr spielen.
Eingestellt habe ich das Ganze weil ich es nicht brauche und das Interesse hier gegen Null ging.

ElTentakel hat geschrieben: Auch das ging schon immer. Die Callbacks liefern ja nur automatisch ein Ereignis, dessen Ergebnis man vorher durch Abfragen genauso erhielt.
Oder habe ich was Grundlegendes übersehen? (bin nicht so der Programmierfuchs)

Grüße

Werner

---

---

Lok24 hat geschrieben:

Hallo Werner

Die Idee hinter Callbacks ist eher, dass man den Overhead verringert, indem man eben nur dann Werte verarbeitet, wenn diese eintreffen. Man kann dann mit kleinen Subroutinen die Werte verarbeiten, wenn sie eintreffen und setzt nur ein Flag oder löst eine andere Funktion aus, die nur darauf wartet ausgelöst zu werden.

Im Beispiel Servo Kalibrierung will ich ja in der Hauptroutine nur wissen, wann der Servo fertig ist und wie die Werte sind. In der Zwischenzeit soll ja alles andere weiter laufen. Also schreibe ich eine Routine, die sich um alles kümmert - wenn man es richtig gestaltet ist alles einfacher.

Kleiner Vergleich aus den Leben wäre: ich prüfe alle 30s die Tür oder ich warte einfach auf die Türklingel. Und wenn man die richtige Türklingel hat, wimmelt sie gleich die ungewünschten Besucher ab, nimmt die Pakete ab, wärend sie nur bei den gewünschten Besuchern klingelt.

Das goldene Ei sind Callbacks auch nicht, man hat damit ja ggf. Zugriffe von zwei verschiedenen Threads. Dann muss man die Daten blockieren (Mutex) - und am Ende blockieren sich zwei Threads gegenseitig. Besser wären Nachrichten, aber damit kann man wirklich überfachtete Software schreiben, das ist definitiv zu viel für einen solch kleinen Mikrokontroller.

Viele Grüße

Richard

---

---

Garbage Collector gefällt das

---

Hallo Richard,

ElTentakel hat geschrieben:

Im Prinzip richtig. Aber: ich will alle Minute testen ob die Batteriespannung noch ausreicht, bekomme aber alle ZehntelSekunden das Callback, weil ja mit der Last (schneller drehender Motor) auch die Batteriespannung schwankt

ElTentakel hat geschrieben:Ich will das vor der Hauproutine nur einmal wissen, ab dann interessieren mich die Winkelwerte nicht mehr, oder?

ElTentakel hat geschrieben:

Vor allem macht der Druck auf de Taste bei mir immer was anderes, je nach Zustand des Programms, dann muss ich das in jedem callback einzeln mit Flags mühsam auseinandernehmen.
Ja, irgendwas ist halt immer.....

Grüße

Werner

---

---

Hallo Werner,

Lok24 hat geschrieben:

Wenn das gewollt ist: Mittelwert bilden und Wert nur jeden n-ten Wert melden / verwenden. Und wenn nicht, spricht was dagegen die Callback wieder kurzzeitig zu deregistrieren?

Lok24 hat geschrieben:

Kommt drauf an was man so alles machen will. Für eine Visualisierung ist es z.B. schon cool, wenn die Anzeige der Realität entspricht. Abgesehen davon: ich will z.B. irgendwann auch wissen, wann sich eine Fernbedienung abmeldet und die automatisch wieder anmelden, weil diese häufiger mal sich von alleine abmelden. Da ist eine Callback sehr praktisch, das will ich nicht jedes mal abfragen.

ElTentakel hat geschrieben:

Einfach mehrere Callbacks registrieren? Ich hatte beisher kein unerwartetes Verhalten. Oder die Programmstruktur (Architektur) passt noch nicht. Wenn man mit Polling anfängt und dann auf Callbacks umschwenkt, ist die bestehende Architektur u.U. einfach nicht mehr die richtige. Daher fange ich mit einem recht unsauberen Prototypen an. Aber im Zweifel merkt man schnell, dass die Architektur nicht passt - und kannn dann mit dem gewonnenen Wissen noch mal anfangen. Gute Projekte fangen mit 0.x Versionen an, damit sie mit der Version 1.0 das Interface noch mal komplett umkrempeln und schick machen können.

/ecit: Falls das alles nicht passt, kann man auch ein struct schaffen, da die Werte Zwischenspeichern und dann in der Main-Loop an der richtigen Stelle pollen.

---

---

Hallo Richard,

ElTentakel hat geschrieben:

s.u.


ElTentakel hat geschrieben:

Ganz genau, es ist eine Frage der Architektur.
Mein Programm ist völlig anders aufgebaut, es ist quasi ein "Add-on" zu legoino, das sich komplett in irgendwelchen .h-Files verstecken ließe.

Das komplette(!) "Anwender"programm in "Loop" sieht dann so aus:

structHubs& Antrieb= Hubs[1];
String f2File = "/P002.parm";

fRead(f2File);
hubConnect(Antrieb);
Antrieb.pHub.setMotorSpeed(portA, fOut[1].toInt());

Es startet einen Motor mit einer eingespeichrten Geschwindigkeit
Die Funktion "hubConnect" macht init, verbinden, prüfen, wiederverbinden, anzeigen, callbacks etc, also bereits das, was in GitHub Issue 38 angedeutet wurde.

Die von Dir erwähnten Structs nutzt es auch, das sieht dann so aus:

getButtons("A", myFB);
if (ButtonStop)
{
Antrieb.pHub.setMotorSpeed(portA, 0);
}

oder auch:

if (Antrieb.recHubType == 3 ) logn("City Hub") ;
if (Antrieb.recHubType == 6 ) logn("Technic Hub") ;
logn(Antrieb.BatVolt) ;

Und: die sind alle vordefiniert, die brauchen den "Anwendungsprogrammierer" nicht zu interessieren.
Das ist alles seit Oktober fix und fertig und läuft.

Aber, wie Du schreibst: jeder hat einen anderen Ansatz zur Architektur.
Ich wollte ein leguino-"enhanced" schreiben
Leider fehlen mir dazu alle weiteren Kenntnisse .

Aber es läuft

---

---