• Herzlich willkommen!

    Das Team von »Doctor Brick« heißt Euch herzlich willkommen und wünscht Euch viel Spaß hier!
    »Doctor Brick« ist eine anerkannte Community (RLOC) für erwachsene LEGO Enthusiasten, auch AFOLs (= Adult Fans Of LEGO) genannt.
    Wir können uns hier über alle Belange des LEGO Hobbys austauschen wie z.B. Set- und Teilefragen, Vorstellung und Rezensionen von Legobauten.
    Bitte beachtet die Nutzungsbedingungen und den Verhaltensleitfaden.

Powered up Farbsensor

Lok24

Elektronikbahner
Registriert
11 Sep. 2019
Beiträge
1.450
Ei dann!

ich hab nochmal über die Idee mit dem Stellwerk für die PF-Funktion nachgedacht.

Wenn Du mit einem Farbsensor nur zwei PF-Receiver betreiben kannst, weil sonst der Winkel zu groß wird könntest Du ein technic-Hub mit 4 Sensoren nutzen und die optisch trennen. Das wären dann immerhin 8 PF-Empfänger mit 16 Kanälen.

Dazu schreibst Du Dir dann einen Composite-Block mit den Eingängen
- Nummer (von 1-16)
- Modus (rechts/links/toggle)
- Geschwindigkeit
- Zeit
zum Beispiel

Die ganze Weichen und BÜ-Logik steckt dann da drin, und Dein Programm wird recht übersichtlich.
Wär das nix?
 

Chris77

Stammuser
Registriert
11 Dez. 2015
Beiträge
473
mal sehn ich weis noch nicht, aber ich fürchte das der Technik Hub zu groß ist. 4 Sensor und 4 PF das Stellwerk ist nur max. 16 breit und 32 Steine lang (is im Keller ein gelagert), ok ich hab da schon ein pf Zugfernbedienung drin gehabt...
 

Chris77

Stammuser
Registriert
11 Dez. 2015
Beiträge
473
Hier mal ein Update wie weit die Steuerung schon geht.

Ihr könnte ja mal schauen ob ihr die Fehler findet ;-)

 

ellermaniac

Nebenbahner
Registriert
24 Mai 2019
Beiträge
1.856
Ort
Osnabrück
Hier mein aktueller Stand:

https://www.flickr.com/photos/22158067@N00/50792805191/in/dateposted-public/

Zwei Züge mit Hub No.4 + Sensor, im Schuppen ein Technic-Hub, der auf einem Kanal die Tore, auf zwei Kanälen mit gelöteten PoweredUp-to-9V-Adaptern zwei Weichenstrassen steuert und auf dem vierten noch das Licht im Schuppen anmacht. Somit ist in der Powered-Up App noch ein Hub frei um noch mehr Leben in die Szenerie zu bringen. Und auch der „Lichtschalter“ liesse sich effektiver nutzen.
 

Chris77

Stammuser
Registriert
11 Dez. 2015
Beiträge
473
Farberkennung mit dunklen Untergrund.

Jetzt muss ich dann nur noch die ganzen Programme vereinen, das der Zug fährt, hält und pendelt

 

XCLD

Neumitglied
Registriert
27 Mai 2022
Beiträge
12
Ich habe eine Frage zum Powerd UP Farbsensor im Einsatz mit Pybricks:

Bei einem GBC-Modul möchte ich, dass es nur dann in Aktion tritt, wenn ein Ball vor dem Sensor liegt. Dafür will ich die Entfernungsmessung einsetzen, die sehr gut erkennt, dass da ein Ball ist. Allerdings erkennt sie offenbar nur, wenn ein Ball frisch ankommt und nicht, wenn er dort schon liegt!

Jetzt ist es aber ja so, dass ich im Loop, nach der Erkennung eines Balls die Motoren starten muss. Bis der Mechanismus fertig durchgelaufen ist, und ich das nächste Mal nach dem Sensor fragen kann, sind schon neue Bälle angekommen. Die werden mir dann aber nicht gemeldet: Der Sensor behauptet nichts zu sehen, obwohl der Ball direkt vor seinem Auge liegt.

In der Powerd UP App würde ich das durch Parallelisieren lösen und permanent den Sensor abfragen. Mit Pybricks habe ich noch nicht rausgefunden, wie das geht.

Mache ich was falsch? Wie habt ihr das gelöst?

Viele Grüße,
Christoph
 

Ts__

Eisenbahner
Registriert
6 Jan. 2016
Beiträge
2.520
Ort
Zwickau / Sachsen
Hallo Christoph,

richtige Parallelisierung dürfte PyBricks nicht bieten, ist mir noch nicht unter gekommen.
Es gibt aber Motorfunktionen, denen gibts du eine Aufgabe (also zb fahre auf diesen Winkel) und die halten das Programm nicht an.

Aus der Doku, der Parameter wait ist da interessant:

run_target(speed, target_angle, then=Stop.HOLD, wait=True)
Runs the motor at a constant speed towards a given target angle.

The direction of rotation is automatically selected based on the target angle. It does not matter if speed is positive or negative.

Parameters
  • speed (rotational speed: deg/s) – Speed of the motor.
  • target_angle (angle: deg) – Angle that the motor should rotate to.
  • then (Stop) – What to do after coming to a standstill.
  • wait (bool) – Wait for the motor to reach the target before continuing with the rest of the program.

Wenn man wissen will, ob die Befehle abgeabeitet wurden:

control.done()
Checks if an ongoing command or maneuver is done.

Returns
True if the command is done, False if not.

bool


Oder:

- du hast eine Hauptschleife
- Variante 1: dort machst du Abfragen (also zb Ball da) und dann rufst du eine Funktion auf, die dieAufgabe abarbeitet. Geht aber nur, wenn die Funktion eine sehr kurze Ablaufdauer hat, Sonst blockierst du ja alles andere
- Variante 2: in der Hauptschleife machst die die Abfrage und setzt nur eine Variable, also zb foerdern_aktiv auf 1
- diese Variable fragst du am Ende der Hauptschleife ab und wenn aktiv: lass den Motor laufen, wenn 0, dann Motor aus

Du kannst halt keine Aufgabe programmieren, die Wartezeiten enthält: also Motor an, warte 5 sec, Motor aus funktioniert so nicht, da nichts parallel abgearbeitet wird.
Für sowas musst du einen Zeitgeber laufen lassen und in der Hauptschleife abfragen. Und wenn die 5 sec um sind, wird der Motor gestoppt

Ein Beispiel von deinen aktuellen Code wäre hilfreich.

Thomas
 

Lok24

Elektronikbahner
Registriert
11 Sep. 2019
Beiträge
1.450
Jetzt ist es aber ja so, dass ich im Loop, nach der Erkennung eines Balls die Motoren starten muss. Bis der Mechanismus fertig durchgelaufen ist, und ich das nächste Mal nach dem Sensor fragen kann, sind schon neue Bälle angekommen. Die werden mir dann aber nicht gemeldet: Der Sensor behauptet nichts zu sehen, obwohl der Ball direkt vor seinem Auge liegt.
Du hast aber in der Hauptschleife den Befehl:
sensor.distance()
drin, sodass er jedesmal ausgeführt wird?

Läuft denn das Pybricks-Beispiel? Da sind auch wait() drin.

Ehrlich gesagt verstehe ich das ganze Problem nicht :fngrcrssd:.
Du willst doch haben:

while true
if sensor.distance() < 30
.... mach irgendwas mit Motoren, das 3 sec dauert

Wo ist denn da der Sinn einer Parallelisierung?
Aber wenn Du haben wilst: die habe ich fertig programmiert, gerne als Beispiel hier.
 
Zuletzt bearbeitet:

XCLD

Neumitglied
Registriert
27 Mai 2022
Beiträge
12
Danke Euch beiden für's Mitdenken!

Ich bin einen Schritt weiter: Jetzt läuft die Dauerschleife zur Ballerkennung und die Motoren werden nur getriggert. Wait/control.done hat hier geholfen.

Allerdings: Mein Mechanismus ist so, dass beim Beladen der Bälle der Sensor den Schieber vor der Nase hat. Wenn er fertig ist mit Beladen, hat er dann entweder nichts oder einen Ball vor der Nase. Und den Übergang von Schieber auf Ball zeitlich zu timen scheint mir unmöglich - zumal die Motorlaufzeit ja auch immer vom Batteriestand abhängt.

Mir wäre geholfen, wenn ich den Sensor abfragen könnte, nach dem aktuellen Stand, was er vor der Nase hat aber offenbar reagiert der nur auf eine Flanke, also eine Veränderung der Sicht: Wenn ich ihn nach erfolgter Beladung einfach fragen könnte, ob er noch was vor der Nase sieht - das muss dann ein Ball sein.

Ich meine, mit Powerd UP würde das auch gehen. Daher bin ich so verzweifelt, das Pybricks das offenbar nicht kann - oder ich hab's noch nicht verstanden.

Könnt ihr mir folgen?

Gruß,
Christoph
 

grawuli

Urgestein
Registriert
2 Mai 2018
Beiträge
1.217
Ort
Minga
Vielleicht mit Farberkennung:

- Schieber ist schwarz
- Bälle ≠ schwarz
 

Lok24

Elektronikbahner
Registriert
11 Sep. 2019
Beiträge
1.450
Mir wäre geholfen, wenn ich den Sensor abfragen könnte, nach dem aktuellen Stand, was er vor der Nase hat aber offenbar reagiert der nur auf eine Flanke, also eine Veränderung der Sicht:
Ich hatte drei Fragen gestellt:

Hast Du das if sensor.distance() < 30 in der Hauptschleife?
Hast Du das Beispiel probiert?
Was willst Du mit einer parallelen Verarbeitung?

Könnt ihr mir folgen?
Leider nein.
Was sagt ein Print()?
Wie sieht das Programm aus?
 

gatewalker

Urgestein
Registriert
7 Okt. 2018
Beiträge
1.761
Ort
Niederösterreich Bezirk Zwettl
Wo ist denn da der Sinn einer Parallelisierung?
Aber wenn Du haben wilst: die habe ich fertig programmiert, gerne als Beispiel hier.
hast du ein Beispiel zum Thema parallisieren? Ich such so etwas für meine Tieflader da ich ihn gerne mit pybricks ohne Tablett bedienen will und da muss in dauerschleife die Lenkung laufen und parallel dazu die übersteuerung per Fernbedienung
 

Lok24

Elektronikbahner
Registriert
11 Sep. 2019
Beiträge
1.450
hast du ein Beispiel zum Thema parallisieren?
Nein, da habe ich mich zu weit aus dem Fenster gelehnt......
Aber etwas dass die Timer nutzt und dadurch sowas ähnliches macht.
Ich kann dazu nochmal was schreiben, es erfordert aber eine etwas eigen(willig)e Programmstuktur. (rofl)
Morgen.....
 

Lok24

Elektronikbahner
Registriert
11 Sep. 2019
Beiträge
1.450
Hallo,

ich habe jetzt mal ein kleines Programm getestet, das funktioniert eigentlich .... ?

Python:
from pybricks.pupdevices import  Motor, ColorDistanceSensor
from pybricks.parameters import Port, Stop, Color

sensor = ColorDistanceSensor(Port.B)
motor = Motor(Port.A)

while True:
    if sensor.distance() <= 40:
        motor.run_time(1000, 1000, then=Stop.HOLD, wait=True)
 

XCLD

Neumitglied
Registriert
27 Mai 2022
Beiträge
12
Hallo Werner,

sorry, für die Verwirrung, ich glaube, so langsam lichtet sich der Nebel bei mir:
Hast Du das if sensor.distance() < 30 in der Hauptschleife?
Hast Du das Beispiel probiert?
Was willst Du mit einer parallelen Verarbeitung?

Ja, die Sensor-Abfrage ist in meiner Hauptschleife.

Ja, ich habe das Beispiel (jetzt) ausprobiert und siehe da: Ich konnte das Problem damit näher beleuchten! Leider ist es so, dass der Sensor einen ruhig vor ihm liegenden Ball ziemlich zuverlässig nicht erkennt. Vermutlich streut der Ball wegen seiner runden Form zu sehr. Ich kann Bälle also nur erkennen, wenn sie angerollt kommen, nicht wenn sie ruhig liegen. Und da mein Sensor durch den Schieber nicht permanent freie Sicht hat, kann ich auch nicht klar unterscheiden, ob er grad den Schieber oder einen Ball sich bewegen sieht. Da habe ich mir also insgesamt mit meiner Konstruktion ein Ei gelegt.

An eine parallele Verarbeitung habe ich gedacht, weil die mir bei einem ähnlichen Fall (mit Mindstorms) geholfen hat, wo der Ball am Sensor vorbeirollt, und somit nicht mehr erkennbar ist, wenn ich nicht zur passenden Zeit danach frage. Da hat mir geholfen, dass ich den Sensor in einer eigenen Schleife permanent abfrage und mir merke, ob ein Ball da war, während die Motoren einen Ablauf abfahren. Wenn die Motoren dann fertig sind, habe ich die Information, ob zwischenzeitlich ein Ball vorbei gekommen ist. Das würde mir hier tatsächlich gar nicht helfen, weil der Sensor ja nicht permanent freie Sicht hat.

- Schieber ist schwarz
- Bälle ≠ schwarz
Der Ansatz funktioniert sehr gut. Solange ich hier in meiner Testumgebung nur die orangenen Bälle verwende. Allerdings weiß ich jetzt schon, dass ich bei der nächsten Ausstellung mit Bällen in allen Farben rechnen muss, und dann haut das schon wieder nicht mehr so gut hin.

Ich werde also noch mal den Aufbau meines MOCs grundsätzlich überdenken...

Viele Grüße,
Christoph
 

Lok24

Elektronikbahner
Registriert
11 Sep. 2019
Beiträge
1.450
Und da mein Sensor durch den Schieber nicht permanent freie Sicht hat, kann ich auch nicht klar unterscheiden, ob er grad den Schieber oder einen Ball sich bewegen sieht.
Du willst das voneinander abhängig machen, via Programm.
Aber dann weiß Du doch im Programm an welcher Stelle der Schieber ist (Winkel des Motors auslesen) und brauchst den Ball nur zu detektieren wenn der Schieber nicht stört, oder?
Und: der Schieber müsste doch auch näher am Sensor sein?
Ggf. den Ball auf eine Wippe rollen lassen, dann brauchst Du nur die zu erkennen, das geht (sehr) gut mit einem Neigungssensor.

PS: wenn Du den Sensor woanders einbaust, wo der Schieber nicht im Weg ist?
 
Zuletzt bearbeitet:
Oben