Lok24
26.08.2020, 15:53

Editiert von
Lok24
27.08.2020, 08:42

+17Powered Up mit M5Stack Atom

Hallo zusammen,

heute möchte ich mal eine weitere Lösung für die bekannten Probleme mit Powered Up zeigen:

- kein Smartphone nötig
- Krokodil o.ä. lässt sich mit der FB regeln
- Zwei Motoren gegenläufig mit derselben Taste der FB
- Wenn es heute geht, geht es auch in 10 Jahren noch
- Plug and play (s.u.)

Das „Geheimnis“ ist ein kleiner Microprozessor, nur 3x3 Noppen groß.

Die Hardware

Es ist ein ESP32 „M5Stack ATOM Matrix“. Das Schöne daran: er hat oben eine 5x5 LED Matrix, und diese Fläche ist auch ein Taster.
Außerdem ist er genau 3x3 Noppen groß und grau ...

[image]



[image]



Das Testprogramm

Es handelt sich um ein c++ - Programm und nutzt die legoino-Bibliotheken von Cornelius Munz.
Ich habe das so gestaltet, dass der ATOM das Programm fest eingebaut hat, dennoch aber aus mehreren Optionen (Profilen) gewählt werden kann.



Die Idee

- Man überlegt sich eine Anwendung (z.B. FB mit Regelung für alle Motoren)
- Schreibt das Programm dazu (das gibt es als Beispiel auch zum Download)
- schreibt das fest in den Controller
- fertig

Ab dann macht dieser Prozessor nach dem Einschalten (1 sec) immer genau das und nur das.
(Bis jemand was neues reibschreibt, aber das muss man ja nicht….)

Dazu braucht er nur noch 5V, mehr nicht. Kein PC, kein SmartDevice, nichts von alledem. Vor allem: keine Ahnung was der überhaupt wie macht.

Und erweitert…

Im Video zeige ich wie man auch mehrere „Profile“ anlegen kann, also wie Remote und Hub agieren sollen, bei welchen Tastendrücken was wie passieren soll. Aber man könnte auch ein Profil „Haunted House“ oder „Karussell“ oder irgendwas anderes hinzufügen, in denselben Baustein.

Die Kosten

Die ATOM starten bei ca 6 $ beim Chinamann, der Matrix kostet da um 8$, meiner hat 16 € bei Bezug in D gekostet. Das war‘ schon.

In 10 Jahren …

… läuft das immer noch genauso, wenn nichts kaputtgeht (und man es sich verkneift, das LEGO Hub upzudaten….)

Für Entwickler

Man braucht
- die Arduino IDE
- die legoino-Bibliothek
- die ESP32-Bibliotheken
- einen PC

Das hat man in einer Viertelstunde zusammengesammelt, wenn man sich mittel bis wenig auskennt. Es gibt etliche Tutorials im Netz, da hab ich mein Weisheiten auch her. (habe aber länger gebraucht, da ich gar kein c++ kannte)

Plug and Play

Doch, schon.
Irgendwer (mit Ahnung)
- schreibt ein Programm („2 beliebige Motoren gegenläufig“)
- kauft den ATOM für x €
- schafft das Programm drauf (max. 5 Minuten Arbeit)
- und verkauft das Ganze für x +y € weiter

Der Empfänger steckt es an sein USB-Ladeteil, fertig.

Oder man hat in der Bekanntschaft jemanden der das kann. Wenn die Programme irgendwo vorliegen braucht man das nur zuammenzuklicken.

Ausblick

Was fehlt sind also Ideen, was man überhaupt programmieren kann und will und braucht, und Leute die des Ganzen mächtig sind.

Grüße

Werner

Ps:
Hier als Teaser mal das "Profil1", das ist schon sehr überschaubar....

void control1() {

int sstep = 10;
int sdelay = 400;
int vmax = 75;

if (FB.isLeftRemoteUpButtonPressed()) Speed = min(vmax, oldSpeed + sstep);
if (FB.isLeftRemoteDownButtonPressed()) Speed = max(vmax * -1, oldSpeed - sstep);
if (FB.isLeftRemoteStopButtonPressed()) Speed = 0;

if ( Speed != oldSpeed) {
TrainHub.setMotorSpeed(portA, Speed * 1);
TrainHub.setMotorSpeed(portB, Speed * -1);
oldSpeed = Speed;
disSpeed(Speed);
delay(sdelay);
}
}



Dirk1313 , RobbyRay , asper , hassel62 , cubo , MTM , Legoben4559 , aap134 , SuklaaTalvella , Ben® , Xris , Garbage Collector , tastenmann , freakwave , SirJoghurt , UncleTom , JuL gefällt das (17 Mitglieder)


20 vorhergehende Beiträge sind ausgeblendet

Alle anzeigen Immer alle anzeigen Beitragsbaum

Ruppie
29.08.2020, 17:36

Als Antwort auf den Beitrag von Lok24

Re: Powered Up - Hinweise zur Konfiguration und Abfrage der Sensoren der Ports und intern des HUB

Lok24 hat geschrieben:



Das kann eigentlich nicht richtig sein?


Sagen wir mal so:
Wenn "0" ein ungültiger Farbwert ist kann es ein schlecht abgefangener Lesefehler sein.
Die Frage ist, ob du zwische gültigen und ungültigen Farbwerten ein Muster erkennst, oder ob die "0" Werte zufällig "eingestreut" erscheinen.

Wie der Sensor arbeitet ist ja nicht genau belegt (oder bei Philo schauen) im Zweifel ist eben nicht garantiert, das der Hub die fehlerhaften Werte nicht mitüberträgt
Wie beschrieben, Mal Cornelius fragen oder selber ausfiltern in deinem Programm.

Giancann hat doch eine eigene Implementierung mit dem Farbsensor und ESP32 gemacht, frag den doch mal, er ist doch so hilfsbereit



Ruppie
29.08.2020, 17:43

Als Antwort auf den Beitrag von Lok24

Re: Powered Up mit M5Stack Atom

Lok24 hat geschrieben:

Hallo Marc,

Du könntest mir durchaus helfen, indem Du mir einfach die vier Progammzeilen für dieses "lpf2" hier postest.
Lauffähig, keine verbale Beschreibung. Dann würde ich das mal probieren.



Mal was anderes:

1. achte mal ein wenig auf die Form deiner Ansprache, sei einfach nicht traurig wenn mir schlicht die Zeit fehlt dir den Arsch zu pudern, um es mal deutlich zu sagen.
2. Wie ich dir bereits mehrfach sagte: Derzeit mit anderen Projekten Busy. ESP32 , leguino... sind momentan "out of scope".
3. Wir haben nun genügend oft erörtert das unserer Projekte Verschieden sind, daher gibt es keine Codebasis zum tauschen, du wirst dich also mit den verbalen Hilfestellungen begnügen müssen.


Eine feine Zeit



Lok24
29.08.2020, 17:47

Als Antwort auf den Beitrag von Ruppie

Re: Powered Up - Hinweise zur Konfiguration und Abfrage der Sensoren der Ports und intern des HUB

Hallo,

Ruppie hat geschrieben:

In den Beispielen gibt es ja ein bisschen was zu den Sensoren, hast du ja schon gefunden.

Ja, sicher. Und es funktioniert manchmal, manchmal nicht.

Ruppie hat geschrieben:
Zu deiner Frage: Im Zweifel ein Fehler in der Implementierung in der Bibliothek oder ein Fehler in der Anwendung am Vesten du fragst Cornelius.

Das hatte ich heute vor, komme aber nicht dazu

Ruppie hat geschrieben:
Im Kern das Problem was ich meinte: Mittelfristig wirst du nicht darum herum kommen dir ein eigenen "Framework " aus Funktionen zu erarbeiten.

Nein, das habe ich ja vor Jahren schon auf meinem Raspberry (ohne alle externen Libraries, direkt auf dem LWP3 aufsetzend) getan. Deswegen kenne ich auch das Protokoll und wie man Sensoren entsprechend ansteuert (notifications), damit sie rückmelden, muss man ja für die FB sowieso auch machen.

Und ich muss das nicht nochmal tun, ich kann, wenn das nicht läuft, es einfach sein lassen.
Wie gesagt, ich brauche das überhaupt gar nicht.

Das was ich machen wollte steht im Eingangspost, und das tut es ja.
Eben etwas sehr einfaches.



Lok24
29.08.2020, 17:51

Als Antwort auf den Beitrag von Ruppie

Re: Powered Up - Hinweise zur Konfiguration und Abfrage der Sensoren der Ports und intern des HUB

Ruppie hat geschrieben:

Wenn "0" ein ungültiger Farbwert ist kann es ein schlecht abgefangener Lesefehler sein.
Die Frage ist, ob du zwische gültigen und ungültigen Farbwerten ein Muster erkennst, oder ob die "0" Werte zufällig "eingestreut" erscheinen.

*seufz* Wenn das Programm 0 anzeigt zeigt es immer 0, egal welche Farben man ihm zu fressen gibt.
Wenn es beim Start 255 zeigt zeigt es in der Folge auch die Farben korrekt.

Ruppie hat geschrieben:
Wie der Sensor arbeitet ist ja nicht genau belegt (oder bei Philo schauen) im Zweifel ist eben nicht garantiert, das der Hub die fehlerhaften Werte nicht mitüberträgt
Wie beschrieben, Mal Cornelius fragen oder selber ausfiltern in deinem Programm.

Darum geht es halt gar nicht, er arbeitet manchmal gar nicht.

Ruppie hat geschrieben:
Giancann hat doch eine eigene Implementierung mit dem Farbsensor und ESP32 gemacht, frag den doch mal, er ist doch so hilfsbereit
Das ist er, aber ich wüsste nicht mal wie ich die Frage formulieren sollte.
Ich brauchte ein Beispiel. Aber das schrieb ich schon.



Lok24
29.08.2020, 18:03

Als Antwort auf den Beitrag von Ruppie

Re: Powered Up mit M5Stack Atom

Hallo,

Ruppie hat geschrieben:

1. achte mal ein wenig auf die Form deiner Ansprache, sei einfach nicht traurig wenn mir schlicht die Zeit fehlt dir den Arsch zu pudern, um es mal deutlich zu sagen.

Ich bin nicht traurig. Ich verstehe allerdings nicht warum Du, statt einfach vier(!) Programmzeilen zu tippen, mir seitenlange Tipps gibt was ich alles wie machen könnte.
Das ist sicher gut gemeint, aber für das was ich machen möchte völlg oversized.

Ruppie hat geschrieben:
3. Wir haben nun genügend oft erörtert das unserer Projekte Verschieden sind, daher gibt es keine Codebasis zum tauschen, du wirst dich also mit den verbalen Hilfestellungen begnügen müssen.

Codebasis tauschen? Es war doch nicht mein Vorschlag, irgendeine andere Bibliothek zu nehmen, sondern Deiner?

Nichtdestotrotz vielen Dank für Deine Bemühungen.



Ruppie
29.08.2020, 18:05

Als Antwort auf den Beitrag von Lok24

Re: Powered Up - Hinweise zur Konfiguration und Abfrage der Sensoren der Ports und intern des HUB

Lok24 hat geschrieben:

[
Darum geht es halt gar nicht, er arbeitet manchmal gar nicht.

Ruppie hat geschrieben:
Giancann hat doch eine eigene Implementierung mit dem Farbsensor und ESP32 gemacht, frag den doch mal, er ist doch so hilfsbereit
Das ist er, aber ich wüsste nicht mal wie ich die Frage formulieren sollte.
Ich brauchte ein Beispiel. Aber das schrieb ich schon.



Dann formuliere ich die Frage mal für dich und warum:
Giancann hat, wie im Video gezeigt, ein Beispiel erstellt wie der ESP32 ,it dem Farbsensor arbeitet.

Wichtig:
In seinem Beispiel aber vollständig ohne LEGO und Bluetooth, es geht darum, wie die Farbwerte über die Serielle Schnittstelle übertragen werden
Wenn du so willlst ist das ein Beispiel, wie der Hub mit dem farbsensor interagiert, bevor er die Werte per BLE überträgt.

Das Beispiel ist also im Prinzip "eine Ebene" unter der Leguino Lib.

Aber nach welchem Beispiel suchst du noch wenn es zunächst mal um das Grundverständniss geht.
Hier kannst du dann explizit die Werte sehen,w elche der Sensor überträgt.

Damit hast du ein "low level" Prüfmittel ob der Fehler im Sensor liegt oder in der späteren Übetragung in BLE.


Die Frage für dich an Giancann würde also sinngemäß lauten: "Kannst du mir bitte dein Beispiel aus dem Video geben zur Ansicht"
PS:

Frag ihn ausserdem mal welches ESP32 Board er da verwendet hat, da du den Sensor ja nunmehr an.
Er mag dir einfach das Program geben mit Angaben zum Board und Anschlussbeschreibung, fertig.

Was ist daran nun so schwierig diese frage an ihn zuj stellen ?



Ruppie
29.08.2020, 20:27

Als Antwort auf den Beitrag von Lok24

Re: Powered Up - Hinweise zur Konfiguration und Abfrage der Sensoren der Ports und intern des HUB

Lok24 hat geschrieben:

Hallo Marc,

Das kann eigentlich nicht richtig sein?



Hallo,
Wenn du mal in die *.h Dateien siehst, steht da in den Definitionen zur Farbe; Black =0
0 wäre also schwarz.

Wenn das öfter passiert, obwohl Farbe nicht schwarz ist tippe ich auf einen nicht ordnungsgemäß funktionierenden Sensor ?!
Wie beschrieben; Die Arbeit von Giancarlo ist prima geignet den Sensor zu prüfen



Lok24
29.08.2020, 20:32

Als Antwort auf den Beitrag von Ruppie

Re: Powered Up - Hinweise zur Konfiguration und Abfrage der Sensoren der Ports und intern des HUB

Vielen Dank, wie gesagt, ich muss das nochmal testen.
Aber an meinem Rechner läuft das alles gar nicht, und der andere war heute belegt.

Ich vermute ein Problem mit dem Timing. Der Sensor an dem Hub geht mit allen anderen Programmen einwandfrei.
Evtl braucht das "Notifications" mal länger als erwartet. Das Ganze läuft ja offenbar nicht in Threads.



Ruppie
30.08.2020, 12:01

Als Antwort auf den Beitrag von Lok24

Re: Powered Up - Hinweise zur Konfiguration und Abfrage der Sensoren der Ports und intern des HUB

Lok24 hat geschrieben:



Hallo Werner , kleiner Nachtrag um die zu (entwirren).

Sieh dir hierzu auch mal die Dateien : Lpf2Hub.h,PoweredUpHub.h,BoostHub.h an.


Auszug aus PoweredUpHub.h
class PoweredUpHub : public Lpf2Hub <--- Die Klasse PoweredUpHub "erbt" oder ist Ableitung von der "Basisklasse" :LPf2Hub
{ Solange keine Eigenschaften "überschrieben" werden hat die Klasse alle Eigenschaften von LPf2Hub
public:



//Port definitions specific to PowerdUp Hubs <--- Das ist das "problem", in Lpf2Hub und Boosthub Klasse sind mehrere Ports definiert
enum Port Da die Auflistung hier berschrieben / Angepasst wird, sind in dieser Klasse die urprünglichen
{ Definitionen nicht mehr verwendbar, da eben überschrieben.
A = 0x00,
B = 0x01
};



Vergleiche mit Boosthub

class BoostHub : public Lpf2Hub
{
public:
//Port definitions specific to Boost Hubs
enum Port
{
A = 0x00,
B = 0x01,
AB = 0x10,
C = 0x02,
D = 0x03,
TILT = 0x3A,
CURRENT = 0x3B,
VOLTAGE = 0x3C
};


Eine Lösung: Übernimm doch einfach die Port enum genauso in die PoweredupHub Klasse, wenn es für dich so angenehmer ist.


Mir war unklar warum wir nicht bei einer Klasse bleiben können, da ja stets ähnliche Dinge beschrieben sind.
Tip:


Kopiere Boosthub.cpp und Boosthub.h in Werner.CPP und Werner.h, erstelle also einen Wernerhub wo du einfach die sachen so aus den klassen zusammenkopierst wie du es brauchst.

Einzige Regel:

class WernerHub : public Lpf2Hub

Viel Spass



Lok24
30.08.2020, 14:50

Als Antwort auf den Beitrag von Ruppie

Re: Powered Up - Hinweise zur Konfiguration und Abfrage der Sensoren der Ports und intern des HUB

Hallo, dankeschön.

1.) Boosthub mit MoveHub läuft einwandfrei
2.) Boosthub mit TrainHub läuft garnicht
3.) mit Lpf2Hub läuft gar nichts
4.) die enums für die Ports sind in BoostHub und poweredupHub gleich
5.) das Beispiel TrainColor läuft mal und mal nicht
6.) mein Programm läuft mal und mal nicht

5 und 6 könnten nicht sein, wenn die enums falsch wären.
Meine Folgerung: leguino funktioniert nicht zuverlässig in meiner Umgebung.



31 nachfolgende Beiträge sind ausgeblendet

Alle anzeigen Immer alle anzeigen

Gesamter Thread: