Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Hallo Zusammen!
Ich möchte eine Variable splitten (im Bild).
Dies klappt aber nur einmal und beim 2. Versuch erhalte ich den Error: 'list' object has no attribute 'split'.
Ich möchte die Variable so splitten, dass ich die reine Zahl habe, der nach Distance= angezeigt wird.
Danke für deine Antwort
Werde ich morgen mal ausprobieren.
Die anderen Funktionen braucht ihr nicht beachten. Das richtige Programm ist ein anderes. Dieses ist nur ein kleiner Test. Es geht mir gerade nur um das Splitten.
@AngryJones: Ist trotzdem schwer das zu ignorieren: ``int(1)`` ist sinnlos. Das ist das gleiche wie ``1``. Eine ganze Zahl wird durch `int()` nicht irgendwie noch ganzzahliger.
Wenn man ein `Serial`-Objekt erstellt und dabei die Schnittstelle angibt, dann ist das bereits offen. Da noch mal (zu versuchen) `open()` aufzurufen macht keinen Sinn. Wobei auch dort das gleiche Problem besteht das __deets__ schon angesprochen hat: Man muss so etwas auf *aufrufen*.
Das ``try``/``except KeyboardInterrupt:`` sollte die Funktionsdefinition nicht enthalten. Zudem ist der Inhalt vom ``except`` eher etwas für ein ``finally``, denn Du willst ja nicht nur bei Strg+C die serielle Verbindung schliessen und die Motoren abschalten, sondern wohl eher generell wenn der ``try``-Block verlassen wird, also zum Beispiel auch wenn da irgend eine andere Ausnahme ausgelöst wird.
`s` ist kein guter Name. `serial` oder `connection` wäre wesentlich besser, damit der Leser weiss was das ist.
`Serial`-Objekte sind sowohl Kontextmanager als auch iterierbar. Also sollte man die ``with``-Anweisung beim Erstellen verwenden und kann in einer ``for``-Schleife über die Zeilen iterieren.
Namenskonvention in Python ist kleinbuchstaben_mit_unterstrichen für alles ausser Konstanten (KOMPLETT_GROSS) und Klassen (MixedCase). Und Funktionen werden üblicherweise nach der Tätigkeit benannt die sie durchführen. So etwas wie `Motor_Geschwindigkeit()` geht also gar nicht. Die alten Methoden auf `Serial`-Objekten, die gegen die Konventionen verstossen, sollte man nicht mehr verwenden. Die Getter/Setter für die Leitungen wurden mittlerweile durch Properties ersetzt. Also statt ``ser.setRTS(0)`` schreibt man ``ser.rts = 0`` und statt ``print(ser.getCTS())`` nur noch ``print(ser.cts)``.
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.
Hier noch einmal das ganze Programm (mit die Zeilen die ich in der oberen Version löschen musste, damit es auch auf dem PC funktioniert, statt auf dem Raspberry PI)
Das einzige, was nicht funktioniert ist weiterhin das splitten. Int(s.split(“=“)[-1]) funktioniert nicht. Der Arduino sendet ja über die Seriele Schnittstelle die Werte z.B: b'Distance=15\r\n'
Davon muss ich in diesem Fall die 15 in eine Variable splitten, um im nachfolgenden Programm damit arbeiten zu können.
>>> s = b'Distance=15\r\n'
>>> int(s.split('=')[-1])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: a bytes-like object is required, not 'str'
? Wenn ja, dann ist die Loesung ein simples b vor dem "="
Und wenn nicht, und ganz generell in der Zukunft: konkrete Fehlermeldungen und Beschreibungen, was erwartet wurde, und was nicht passiert. "Geht nicht" kann man nur sagen "schade".
@AngryJones: Funktionen sind nicht so etwas wie Sprungmarken. Funktionen sind in sich abgeschlossene Bereiche, die sich mit ihrer Umgebung per Argumente und Rückgabewerte austauschen. Sie sollten am Anfang einer Datei stehen und nicht innerhalb eines try-Blocks.
Es wäre also sehr überraschend, wenn der neue Code überhaupt funktioniert.
Sirius3 hat geschrieben: Samstag 24. November 2018, 11:54
@AngryJones: Funktionen sind nicht so etwas wie Sprungmarken. Funktionen sind in sich abgeschlossene Bereiche, die sich mit ihrer Umgebung per Argumente und Rückgabewerte austauschen. Sie sollten am Anfang einer Datei stehen und nicht innerhalb eines try-Blocks.
Es wäre also sehr überraschend, wenn der neue Code überhaupt funktioniert.
Und tut er das auch auf dem PI? Oder nur an deinem PC? Denn ausser die serielle Schnittstelle zu bedienen wird dein Code nix tun. "while True" in "Split_Variablen" verhindert, dass danach irgendwas anderes tut.
Wuerde mich ueberraschen. Das einlesen der seriellen Schnittstelle kannst du theoretisch so machen. Einen Effekt hat das uebrigens auch nicht, denn deine Variablen sind lokal zu deiner Funktion.
Spaetestens aber bei den Motoren wird dir das aller Vorraussicht nach auf die Fuesse fallen - mit mehreren Threads auf dem Motor-Hat rumzuhaemmern wird mindestens mal komisches Verhalten erzeugen weil du widerspruechliche Befehle sendest, und im schlimmsten Fall einfach irgendwann abstuerzen, weil der Code des IO-Boards halt nicht thread-safe ist.
Ja, besser programmieren. Indem du deine Aufgaben mit einer gemeinsamen Hauptschleife nacheinander und in Abhaengigkeit der Steuerkommandos, Sensor-Feedback und Ablauf der Zeit abarbeitest.
Ja, nur ich bevorzuge eigentlich immer Threads, da sich diese immer bei den Robotern die ich früher programmiert bewährt haben.
Alle Tasks liefen unabhängig und konnten die anderen starten/ bzw. stoppen. (Hab früher mit NXC programmiert.)
Dies hatte den Vorteil, dass es innerhalb des Programms zu keinen Verzögerungen gekommen ist und man z.B Linienfolgen, während ein anderer Fall eingetreten ist (z.B Rechts Abbiegen),
bequem deaktivieren konnte.
Dann benutz Threads. Die Tage war hier wer mit einem ähnlichen Board, dem ist das auseinander geflogen. Vielleicht hast du Glück, und dir passiert das nicht.
Was ich allerdings bei NXC an “Threads” sehe sind Tasks. Und das ist etwas fundamental anderes. Die laufen immer garantiert exklusiv. Und mit klaren Übergabepunkten. Nicht gleichzeitig wie (in Grenzen) parallel, und an beliebigen stellen unterbrochen, wie bei Python.
Also jetzt rufst du ja nix auf. Es passiert also genau gar nichts. Und deine Funktionen gehören auch nicht verschachtelt, und bei jedem schleifendurchlauf neu definiert, sondern EINMAL auf oberster Modulebene.