Lok24
01.09.2021, 14:47

+2Programmierung mit Pybricks

Hallo,

hier mal eine Idee zur Programmierung mit Pybricks.
Ich beziehe mich auf
https://github.com/falk12.../MotorControl%202.4.py

Die (gute?) Idee ist folgende:
das Programm zerfällt in mehrere Teile:
- Parameter setzen
- Funktionen (im Beispiel zwei)
- general program routines and classes (ab 147)
- main loop

Alles was nix mit der eigenlichen Anwendung zu tun hat steht im unteren Teil (ab 147), kann also dem der die Anwendung programmiert egal sein, das könnte fertig sein.
In einem richtigen Programm würde man das komplett in irgendwelchen Bibliotheken verstecken.

Die Anwendung ist oben, also was bei welchen Tastendrücken passieren soll. Das "connect", das Erkennen der Motoren, das Betreiben der Motoren etc ist unten.

Natürlich hängt das voneinander ab, hier gibt es nur eine Routine "drive()" die beide Motoren bewegt.
Ob das bei komplexeren Anwendungen überhaupt sinnvoll möglich ist - keine Ahnung.

Letztlich sollte es dazu dienen den Anwendungsteil vom Drumherum zu trennen, um jemanden, der python kennt, das Programmieren zu erleichtern. Man braucht doch nicht immer das Connect/Reconnect neu zu coden, oder?
Ob das jetzt schlau ist oder nicht, genau das ist die Frage.


Grüße

Werner



Thomas52xxx , womo gefällt das


Gimmick
01.09.2021, 16:49

Als Antwort auf den Beitrag von Lok24

Re: Programmierung mit Pybricks

Code bezogene Fragen/Anmerkungen:
- Die Variablen der Tasten "UP", "DOWN",... sind bei Dir strings, obwohl Du in CheckButton() x mit dem enum-member aus 'Button' überschreibst. Hat das einen bestimmten Grund?
- Python kann eigentlich auch "elif" [also 'else if']. Das wird dann bei schon erfüllter Abfrage übersprungen.


Prinzipiell finde ich das gut, habe ich glaube ich ja schon mehrfach gesagt ;)
Ich habe mich aber schon wieder selber dabei ertappt, damit alles möglich konfigurieren und erschlagen zu wollen und ich glaube dann hätte man ein Komplexitätsproblem.

Vordefinierte, wählbare Funktionen? Gute Idee!
Mit Lichtanzeige auf der Fernbedienung? Brilliant
Jede Funktion mit eigenen Parametern im Code konfigurierbar machen? No way! :X

Du initialisierst hier ja den CityHub. Wenn man jetzt auch noch den TechnicHub ansprechen möchte, muss die Initializierung in den MainLoop und dann muss man sich überlegen, was wie passieren soll. Je nach Funktion hätte man dann noch mögliche Variablen, manche Funktionen gehen vielleicht nur mit einem bestimmten Hub,... das kann schnell echt unübersichtlich werden. Und dann ist auch essig mit "man kann hier die Variablen anpassen" da blickt niemand mehr durch.

Beispiel TechnicHub:

- Lenken
- On/off
- Welche Taste
- On/Off auf die selbe Taste?

Und das mal vier, weil 4 Ports, und das Abhandeln der ganzen Settings in eine Funktion? Inklusive Kalibrierung?

Es wäre vielleicht dann doch eher besser, einfache Fälle zur Verfügung zu stellen:

SimpleCar: Port A lenkt, Port B fährt
Car: Port A lenkt, Port B und C fahren (da gehts dann mit dem Invertieren los)...

Zudem müsste man dann z.B. die Konfiguration auslagern und ganz klar voneinander trennen, die Funktionen deutlich benamen und im Zweifel lieber dem "weniger ist mehr" Prinzip folgen.

Die Frage wäre also für mich auch: Was kann man bedenkenlos in eine Funktion packen und was nicht?



Technicmaster0
01.09.2021, 17:22

Als Antwort auf den Beitrag von Gimmick

Re: Programmierung mit Pybricks

Gimmick hat geschrieben:

SimpleCar: Port A lenkt, Port B fährt
Car: Port A lenkt, Port B und C fahren (da gehts dann mit dem Invertieren los)...

Solange beide Motoren fürs Fahren in die gleiche Richtung drehen (gerade aus oder invertiert), kann man sich das mit dem Invertieren sparen. Die Tasten der Fernbedienung lassen sich ja drehen.
Außerdem sollte man zum Fahren koppelbare Ports, also A und B oder C und D nehmen.



Gimmick
01.09.2021, 17:29

Als Antwort auf den Beitrag von Technicmaster0

Re: Programmierung mit Pybricks

Technicmaster0 hat geschrieben:


Solange beide Motoren fürs Fahren in die gleiche Richtung drehen (gerade aus oder invertiert), kann man sich das mit dem Invertieren sparen. Die Tasten der Fernbedienung lassen sich ja drehen.
Außerdem sollte man zum Fahren koppelbare Ports, also A und B oder C und D nehmen.


Dass es extra koppelbare Ports gibt war mir nicht bekannt. Dass man nicht invertieren MUSS ist klar :X Es kann aber sein.



Lok24
01.09.2021, 19:16

Als Antwort auf den Beitrag von Gimmick

Editiert von
Lok24
01.09.2021, 19:18

Re: Programmierung mit Pybricks

Moin,

Gimmick hat geschrieben:

Code bezogene Fragen/Anmerkungen:
- Die Variablen der Tasten "UP", "DOWN",... sind bei Dir strings, obwohl Du in CheckButton() x mit dem enum-member aus 'Button' überschreibst. Hat das einen bestimmten Grund?

Ja, ich weiß es nicht besser.

Gimmick hat geschrieben:
- Python kann eigentlich auch "elif" [also 'else if']. Das wird dann bei schon erfüllter Abfrage übersprungen.

Mag ich nicht

Gimmick hat geschrieben:
Ich habe mich aber schon wieder selber dabei ertappt, damit alles möglich konfigurieren und erschlagen zu wollen

Das ist genau das Problem. Warum machst Du das? Wäre es für den Anfang nicht sinnvoll, nur einige Fälle zu betrachten und zu schauen, wie weit man kommt?

Gimmick hat geschrieben:
Jede Funktion mit eigenen Parametern im Code konfigurierbar machen? No way! :X
Natürlich, was haben den Werte(!) in einem Programm zu suchen? Nix

Gimmick hat geschrieben:
Du initialisierst hier ja den CityHub. Wenn man jetzt auch noch den TechnicHub ansprechen möchte, muss die Initializierung in den MainLoop

Äh... nein wieso, die unterscheiden sich nicht?
Ich kann doch abfragen ob Port C und D da sind.

Gimmick hat geschrieben:
... und dann muss man sich überlegen, was wie passieren soll.

Das gehört alles in den oberen Teil, den ein Programmierer schon selbst schreiben muss.
Aber das connect und reconnect doch nicht wiederkäuen? Das könnte man doch als eine Routine fest vorgeben?
Und wenn man das in Klassen packt kann man auch dort Werte (LED-Farbe) übergeben, statt Parameter zu definieren

Gimmick hat geschrieben:
Und das mal vier, weil 4 Ports, und das Abhandeln der ganzen Settings in eine Funktion? Inklusive Kalibrierung?
man kann doch aus Function1 eine Funktion "cal" ausführen (das sind übrigens nur 4 Zeilen)

Gimmick hat geschrieben:
SimpleCar: Port A lenkt, Port B fährt
Car: Port A lenkt, Port B und C fahren (da gehts dann mit dem Invertieren los)...
das ist der obere Teil, mir geht es um den unteren.

Gimmick hat geschrieben:
Zudem müsste man dann z.B. die Konfiguration auslagern und ganz klar voneinander trennen, die Funktionen deutlich benamen und im Zweifel lieber dem "weniger ist mehr" Prinzip folgen. Die Frage wäre also für mich auch: Was kann man bedenkenlos in eine Funktion packen und was nicht?


Genau!



GELÖSCHT

Dieser Beitrag wurde gelöscht.


Gimmick
01.09.2021, 20:42

Als Antwort auf den Beitrag von Lok24

Re: Programmierung mit Pybricks

Lok24 hat geschrieben:

Moin,




Tja, warum mache ich das? Weil sich alles auch in gewisser ähnelt ohne gleich zu sein, das verlockend ist und ich ja überlegen muss, was man zusammenpacken kann und was nicht


Das andere habe ich nicht so recht verstanden:

Laut Doku gibt es für jeden Hub eine Klasse und der City-Hub scheint keine Abfrage für die Beschleunigungssensoren zu haben?
https://github.com/pybric...aa47f4bc/doc/main/hubs

Ja, man kann eine extra Funktion für die Kalibrierung machen. Ich meine aber, so wie das jetzt ist, hast du oben Parameter, die für die Funktionen gebraucht werden. Wenn man jetzt mehrere Funktionen anbietet und jede Funktion ihre Parameter hat, bräuchte man eine unübersichtliche Anzahl an Parametern - alleine eben schon für eine Funktion, die Lenken, On/Off und Vollgas pro Port anbieten würde, sehr viele. Und die muss man in der Funktion prüfen, damit man überhaupt weiß, ob kalibriert werden muss. So wie Du jetzt auch die Profile in der function1() prüfst.

Möchte man das nicht, sondern man möchte nur, dass zwischen Funktionen gewählt werden kann und jede Funktion soll ein eigenständiger Block sein, der getauscht werden kann, müssten die Parameter von oben ja eigentlich weg ;)

Wenn es hauptsächlich um die Konnektivität geht, hätte man natürlich mehr Spielraum, aber auch mehr Redundanz und Arbeit pro Programm. Das kann man pauschal sicher nicht beantworten, man ist beim Programmieren ja nicht ohne Grund ständig am Umstricken xD.

Vielleicht habe das aber auch falsch verstanden und es geht nicht darum Funktionen im Sinne von function1(), function2() zu ergänzen, sondern darum alles außer der Konnektivität auszutauschen. Dann hätten wir intensiv aneinander vorbei geredet



Technicmaster0
01.09.2021, 22:11

Als Antwort auf den Beitrag von Gimmick

Editiert von
Navigation
02.09.2021, 07:57

Re: Programmierung mit Pybricks

Gimmick hat geschrieben:

Laut Doku gibt es für jeden Hub eine Klasse und der City-Hub scheint keine Abfrage für die Beschleunigungssensoren zu haben?
https://github.com/pybric...aa47f4bc/doc/main/hubs

Der City Hub hat keinen Beschleunigungssensor, jo



Lok24
02.09.2021, 16:07

Als Antwort auf den Beitrag von Gimmick

Editiert von
Lok24
02.09.2021, 16:27

Re: Programmierung mit Pybricks

Gimmick hat geschrieben:


Laut Doku gibt es für jeden Hub eine Klasse und der City-Hub

ja natürlich, das war Unfug was ich schrub.

Gimmick hat geschrieben:
Vielleicht habe das aber auch falsch verstanden und es geht nicht darum Funktionen im Sinne von function1(), function2() zu ergänzen, sondern darum alles außer der Konnektivität auszutauschen. Dann hätten wir intensiv aneinander vorbei geredet


So ähnlich.
Vielleicht mal einfach denken:
a.) 1 City Hub -> Train, einfaches Fahrzeug, auch Zugmotor
b.) 1 Technic Hub -> Fahrzeug mit erweiterten Möglichkeiten, kein Zugmotor

Programmstruktur für Anwendung "Zug"

Parameter "Zug"
Parameter für Hub / main loop
Funktion "Zug"
----------------
diverse Funktionen und Klassen
----------------
Init Variablen
Hub definieren
Andere Variablen für main
main loop

Das ist das, was ich jetzt habe.
Und jetzt soll es ein Auto werden.
Dann tauschen wir nur
Parameter "Zug"
Funktion "Zug"

gegen

Parameter "Auto"
Funktion "Auto"

Und das kann man doch aus 2-3 Textdateien immer maschinell zusammendübeln?

Also nicht etwa "Auto" auch zu "Zug" hinzupacken

Parameter "Zug"
Parameter "Auto"
Funktion "Zug"
Funktion "Auto"


Wieviele Programme wären das? Nun,
- ein Grundgerüst City Hub / technic Hub via Parameter einstellbar
- Auto / City Hub
- Zug City Hub
- Karussell City Hub
- Achterbahn City Hub
- Volvo Hauler technic Hab
- CAT City Hub

and so on

Andersrum: für n Funktionen mit n+1 Programmen, die sich aber nur noch drum kümmern, bei welchen Tasten was passiert.

Wo ist der Sinn?
Vergleiche
----------------------

def portcheck(i):

port = motor[i].getPort()
# Try to get the device, if it is attached.
try:
device = PUPDevice(port)
except OSError as ex:
if ex.args[0] == ENODEV:
# No device found on this port.
motor[i].setType("---")
print(port, ": not connected")
return ("---")
else:
raise
------------------------

mit

------------------------
if CheckButton(UP) and not CheckButton(STOP) :
for x in range (1, step + 1):
v = v + 1
if v > vmax :
v = vmax
if v > 0 and v < vmin:
v = vmin
if abs(v) < vmin:
v = 0
drive()
--------------------------

Die Komplexität, neue "Anwendungen" zu programmieren wird deutlich geringer.
Dachte ich.



Gimmick
02.09.2021, 17:20

Als Antwort auf den Beitrag von Lok24

Re: Programmierung mit Pybricks

Lok24 hat geschrieben:


Die Komplexität, neue "Anwendungen" zu programmieren wird deutlich geringer.
Dachte ich.


Ja, ok. Dann hatte ich das falsch verstanden.
Insbesondere, wenn man einzelne Modelle, wie z.B. den 42114 oder 42131, berücksichtigen möchte, wird es so schon erheblich einfacher, denke ich.

Der Nachteil wäre, dass es dann in Arbeit ausarten kann, weil der eine PortA als Servo möchte, der nächste PortA+B, usw... Denn ich glaube, wie in dem anderen Thread schon gesagt, nicht, dass viele Programmieren wollen, auch nicht wenn man es noch so vereinfacht.

Interessierte werden für so ein Grundgerüst aber sicher dankbar sein.

In der Summe würde man so nicht um feste Programme für Einzelanwendungen UND einigermaßen konfigurierbare Programme herum kommen.
Bei letztem müsste man dann schauen, wie man sich das Leben maximal vereinfacht, also welche Optionen man wirklich anbieten möchte. Wenn man immer zwei Remotes für den Technic-Hub vorsieht bleibt ja fast nurnoch für jeden Port "ist Servo?" übrig und "kombiniere A+B/C+D". Das ist ja dann soviel nicht mehr glaube ich. Dann hätte man das Wesentliche von PF nachgebildet.



Lok24
05.09.2021, 14:29

Als Antwort auf den Beitrag von Gimmick

Editiert von
Lok24
05.09.2021, 15:03

Re: Programmierung mit Pybricks

Hallo,

sorry für die späte Antwort.

Gimmick hat geschrieben:

Der Nachteil wäre, dass es dann in Arbeit ausarten kann, weil der eine PortA als Servo möchte, der nächste PortA+B, usw... Denn ich glaube, wie in dem anderen Thread schon gesagt, nicht, dass viele Programmieren wollen, auch nicht wenn man es noch so vereinfacht.

Das sind zwei Thesen.
Wenn wir mal von "vorgefertigten" Profilen für bestehende Sets ausgehen (wie sie technicmaster0 schon bereitgestellt hat) haben wir schon mal Problem 1 nicht, und wenn wir bei dem Beispiel bleiben braucht es genau einen, der das programmiert (hat).
PyBricks und legoino zeigen auch, dass es durchaus eine Menge Leute gibt die damit programmieren.

Gimmick hat geschrieben:
Interessierte werden für so ein Grundgerüst aber sicher dankbar sein.
Sind sie, ich nutze ja auch die beiden oben erwähnten gerne. Sonst könnte ich ja einfach auf dem LWP 3.0 aufsetzen (habe ich auch hier schon mal gezeigt).
Das was mir hier vorschwebt würde man eigentlich als Bibliothek zum Nutzen bereitstellen, aber das erlaubt Pybricks nicht.

Gimmick hat geschrieben:
In der Summe würde man so nicht um feste Programme für Einzelanwendungen UND einigermaßen konfigurierbare Programme herum kommen.


Ja, es sind verschiedene Personengruppen und Programmqualitäten.

- End-User - kann/soll nicht programmieren
- Wir hier gerade - überlegen, wie man
a.) für Sets passende Progs zusammenbekommen
b.) Eine Befehlserweiterung für Pybricks hinbekommt
c.) für a.) die Konfigurierbarkeit für End-User herstellt.
- "Progammierer", die aber, basierend auf der Befehlserweiterung in einer Viertelstunde ein bestehendes Programm angepasst haben und nicht drei Stunden von Grund auf neu schreiben müssen.

Und daher gibt es auch auch drei Arten von Programmen:
- Standard für Sets
- Alternativen / Abwandlungen für Sets auf "Kundenwunsch"
- ganz neue Funktionalitäten für eigene MOCs

Zahlenmäßig habe wir aber, dem gegenübergestellt:
0 End-User (Stichwort Resonanz 0)
2-3 die sich aktiv mit der Sache befassen
0 die es nutzen könnten und sich darob gemeldet haben

Grüße

Werner



Lok24
05.09.2021, 16:30

Als Antwort auf den Beitrag von Lok24

Re: Programmierung mit Pybricks

Lok24 hat geschrieben:

0 die es nutzen könnten und sich darob gemeldet haben

Jetzt sind es schon drei....



Gesamter Thread: