ftrobopy und ROBOPro auf dem TXT 4.0

[PACMAN]

das würde aber heißen dass der txt 4 zumindest technisch gesehen schlechter ist als der Vorgänger, oder?
oder wird robo pro coding noch geupdated damit man den 4.0er auch fernsteuern kann?
viele Grüße
Leonard

P.S.
was bedeutet eigentlich das hier?
Zitat: "Die folgenden Funktionen werden schon unterstützt: [...] - Kamera-Live streaming über den Port 65001. [...]"
geht die kamera doch, weil bei mir kommt im besten Fall nur ein schwarzer Bildschirm...

[Torsten]

Hallo Leonard,

der TXT 4.0 ist technisch gesehen durchaus etwas besser als der TXT. Immerhin hat er zusätzlich noch 3 Servo Anschlüsse. Ausserdem sind die beiden CPUs etwas moderner und schneller und der TXT 4.0 hat auch mehr Speicher. Insgesamt sind die beiden sich aber durchaus ähnlich.

Der TXT 4.0 und der TXT unterscheiden sich allerdings in der Software und in der Programmierung. ROBO Pro (TXT) und Robo Pro Coding (TXT 4.0) haben zwar einen ähnlichen Namen, haben aber sonst so gut wie keine Gemeinsamkeiten.

ftrobopy_server ist ein Community-Projekt und emuliert auf dem TXT 4.0 den Online-Modus von ROBO Pro und ftrobopy. Für das Auslesen des Bildes von der Kamera verwende ich derzeit noch direkt die Linux V4L2-Library, ich plane jedoch, das in Zukunft mit openCV zu machen und hoffe, dass es damit stabiler wird. ROBO Pro reagiert bei Schwankungen im Timing bei der Bildübertragung recht empfindlich, deshalb funktioniert es derzeit über USB noch besser als über WLAN. Manchmal braucht man noch 2-3 Versuche, bis es läuft.

Hast Du die Kamera-Probleme nur über WLAN oder auch über USB-Kabel ?

Viele Grüße
Torsten

[PACMAN]

Hallo Torsten,
vielen Dank für diese ausführlichen Informationen. :)
also, bei mir funktioniert die Kamera bei einer Verbindung per usb kabel sehr gut, und alles andere per access point auch, allerdings gibt es eben nur dieses eine Problem mit der Kamera:
ich habe bisher immer wieder versucht diesen "Kamera einschalten" knopf zu traktieren(netzfrequenz 50; Auswahl Verfügbare Kamera) bis ich irgendwann ein schwarzes Bild bekommen habe; mehr passiert nicht...
ist das normal oder müsste man statt dem schwarzen Bild trotz remote-Verbindung noch einzelne Bilder sehen?

viele Grüße
Leonard

[Torsten]

Hallo Leonard,

bei mir funktioniert es am besten, wenn der TXT 4.0 nicht im Accesspoint-Modus mit dem PC verbunden ist, sondern über das USB Netzwerkkabel (Micro USB nach USB-A) am PC angeschlossen ist.
In ROBOPro muss dann als USB-Verbindungsadresse die 192.168.7.2 ausgewählt werden.
Die ft-Kamera sollte dann im USB-A Port des TXT 4.0 stecken.

Dann sollte auch bei Aktivierung das Kamerabild im ROBOPro Camera-Tab erscheinen. Es dauert erstmalig ca. 2-3 Sekunden, bis das Bild übertragen wird, da die Kamera zuerst einen Weissabgleich und die Helligkeitseinstellungen vornimmt.

Viele Grüße
Torsten

[PACMAN]

also access point geht nicht?

[Torsten]

also access point geht nicht?

access point geht nur, wenn die Verbindung sehr gut ist. Ich werde mir das mit der Kamera im Access Point Modus nochmal genauer anschauen. Vielleicht lässt sich das noch verbessern.

[mka2022-CM]

Guten Tag,
seit kurzem bin ich Besitzer des TXT4.0-Roboters und möchte mich erst einmal für die tolle Arbeit hier in der Community bedanken.
Mein vierrädriger Roboter funktioniert mit RoboProCoding und Python-Programmierung wie gewünscht.
Mit FTrobopy habe ich aber noch einige Probleme, die ich mit dem Manual nicht gelöst kriege. Vielleicht kann mir jemand helfen:
1. Der Server meldet sich mit Version 0.9.8 - eine 0.9.9 finde ich nicht
2. Die Initialisierung erfolgt mit
ftrob = ftrobopy.ftrobopy(host='192.168.178.140', port=65000,special_connection= '192.168.178.140',use_extension=True)
über WLAN. Leider muss ich dann den Server nach jeder Runde wieder neu starten, auch wenn ich länger warte.
3. Die Sache mit den output-Ausgängen kriege ich nicht hin. Ich definiere:
TXT_M_S1_servomotor = ftrob.output(1) (der Servomotor hängt an S1) und
TXT_M_S4_motosync = ftrob.output(4)
- Verändere ich nun mit TXT_M_S1_servomotor.setLevel(200) den Servomotor, so meldet sich motor1, den ich vorher mit ftrob.motor(1) definiert habe.
- Mit welchen Befehlen kann ich denn nun alle vier Motoren sychronisieren? Da brauche ich einen Hinweis.

Vielen Dank

[Torsten]

1. Der Server meldet sich mit Version 0.9.8 - eine 0.9.9 finde ich nicht

Das ist nur ein Bug in der Versionsanzeige. Die Version auf Github ist aber tatsächlich die Version 0.9.9
(Meine aktuelle Arbeitsversion ist die 0.9.10, die habe ich allerdings noch nicht auf github hochgeladen. Ich experimentiere immer noch mit der Camera. Die läuft mit ftrobopy_server noch nicht so stabil, wie ich mir das wünsche)

2. Die Initialisierung erfolgt mit
ftrob = ftrobopy.ftrobopy(host='192.168.178.140', port=65000,special_connection= '192.168.178.140',use_extension=True)
über WLAN. Leider muss ich dann den Server nach jeder Runde wieder neu starten, auch wenn ich länger warte.

Startest Du den ftrobopy_server über das GUI des TXT 4.0 oder über die Commandozeile des TXT 4.0 (über ssh) ?
Das von Dir beschriebene Verhalten sollte eigentlich nicht auftreten, wenn ftrobopy_server über das TXT 4.0 GUI gestartet wird. Ich werde mir das aber nochmal genauer anschauen.

3. Die Sache mit den output-Ausgängen kriege ich nicht hin. Ich definiere:
TXT_M_S1_servomotor = ftrob.output(1) (der Servomotor hängt an S1) und
TXT_M_S4_motosync = ftrob.output(4)
- Verändere ich nun mit TXT_M_S1_servomotor.setLevel(200) den Servomotor, so meldet sich motor1, den ich vorher mit ftrob.motor(1) definiert habe.
- Mit welchen Befehlen kann ich denn nun alle vier Motoren sychronisieren? Da brauche ich einen Hinweis.

Zur Ansteuerung der Servos des TXT 4.0 mit ftrobopy (oder mit ROBOPro) muss man für die Servo-Anschlüsse die Motor-Outputs der ersten Extension angeben. In Deinem Falle also:

Code: Alles auswählen

TXT_M_S1_servomotor = ftrob.output(1, 1)  # Der zweite Parameter bestimmt die Extension
TXT_M_S4_motosync = ftrob.output(4, 1)

Damit sollte es funktionieren.

Viele Grüße
Torsten

[mka2022-CM]

Hallo Torsten,
vielen Dank für deine schnelle Antwort.
Wegen des vielen Regens habe ich gleich mal probiert.
Das wiederholte Starten des Servers hängt wohl von der Firmware ab. Unter 3.1.0 kann man immer wieder starten, ohne den Server anzutasten, unter 3.1.4. klappt das nicht. Dort muss ich den Server immer stoppen. Er meldet sich dann mit
data =f._sock.recv(512)
ConnectionResetError: [WinError 10054] Eine vorhandene Verbindung wurde vom Remotehost geschlossen

Seltsam eine Fehlermeldung, wenn ich mit 'auto' initialisieren will. Er meldet dann
File "E:\fischertechnik\Python\Class4Wheels - ftrobopro\ftrobopy.py", line 3011, in motor
M, I = self.getConfig(ext)
File "E:\fischertechnik\Python\Class4Wheels - ftrobopro\ftrobopy.py", line 745, in getConfig
m = self._ftX1_motor[4*ext:4*ext+4]
AttributeError: 'ftrobopy' object has no attribute '_ftX1_motor'

Das Problem mit dem Servomotor habe ich auch unter 3.1.0 nicht gelöst bekommen.
Nach
ftrob = ftrobopy.ftrobopy('192.168.178.142',special_connection='192.168.178.142', port=65000,use_extension=True)
ftrob.output(1,1).setLevel(400)
meldet sich immer noch das Rad rechts vorne. Vielleicht habe ich etwas falsch verkabelt. Da werd ich noch mal schauen.

Nochmal vielen Dank für die viele Arbeit und
schöne Grüße
Michael

[Torsten]

Hallo Michael,

der Hinweis auf die Version 3.1.4 der TXT 4.0 Firmware ist gut, vielen Dank! Ich habe meine 4.0er TXTs bisher noch nicht auf diese Version geupdatet. Das werde ich mir mal anschauen.

Viele Grüße
Torsten

[Techum]

Hallo Michael,

auch der TXT (nicht 4.0) mag es nicht, wenn man die Kamera nicht ordentlich abmeldet (andere Fälle sind mir nicht bekannt).

Wenn ich das Beispielprogramm
https://github.com/ftrobopy/ftrobopy/bl ... eraDemo.py
zweimal laufen lasse, kommt beim jeweils zweiten Mal immer:

Connected to TX2013 firmware version 4.7.0
Network error [WinError 10054] Eine vorhandene Verbindung wurde vom Remotehost geschlossen
Network error
Timeout while getting new frame from camera

Dein Fehler ist anders, aber ggf. hilft der Hinweis.

Den Fehler mit der Kamera kann man vermeiden, indem man vor Beendigung des Programms die Kamera stoppt:

Code: Alles auswählen

txt.stopCameraOnline()
while txt.cameraIsOnline() == True:
    time.sleep(1)

Viele Grüße
Techum Frank

[Techum]

Hallo zusammen,

ich bekomme folgendes Problem, wenn ich versuche, den Server zu starten.
Es ist mein erster Versuch mit ftrobopy_server auf TXT 4.0, also ggf. mache ich etwas falsch:

Code: Alles auswählen

ft@txt40-LMLx:~/workspaces/cpp$ ./ftrobopy_server
ftrobopy and ROBOPro Online Server, version 0.9.12, (c) 2022 by Torsten Stuehn
sudo: a password is required
sudo: a password is required
sudo: a password is required
press return to close ftrobopy_server...

File-Berechtigungen sind gesetzt.

Viele Grüße
Frank

[Techum]

Hallo zusammen,

wenn der ft user in der sodoers Gruppe ist, geht es.

Code: Alles auswählen

ft@txt40-LMLx:~/workspaces/ftrobopy_server$ sudo ./ftrobopy_server
ftrobopy and ROBOPro Online Server, version 0.9.12, (c) 2022 by Torsten Stuehn
press return to close ftrobopy_server...

vgl. hierzu 2.4.1 aus David Adams Buch.

update:
Allerdings Probleme mit der Camera sowohl per WLAN (gemäß aktuellem Entwicklungsstand) als auch bei Verbindung mit USB.

Code: Alles auswählen

got: query status
got: start online
got: startCameraOnline
camera thread started
cannot set camsock socket to non blocking ... continuing with blocking communication.
camera streaming started

Manchmal auch:
unknown ACK for camera picture received, cam_m_id = 0 oder auch mit ID z.B.
unknown ACK for camera picture received, cam_m_id = 20544547

Da sich der Server bei mir (kann ggf. jemand versuchen, der den TXT 4.0 auf die aktuelle FIrmware aktualisiert hat und bei dem es früher schon funktioniert hat) nur mit sudo starten lässt, funktioniert freilich auch kein Start über das TXT 4.0 Panel.

Viele Grüße
Techum Frank

[Techum]

Korrektur/Erweiterung zu meiner Frage oben.
Trotz des mehrfachen "sudo: a password is required" läuft der ftrobopy_server normal und lässt sich auch über das Panel starten. Habe nicht richtig gelesen dass "Initializing" bedeutet, dass der Server läuft.

Ein Bild bekomme ich aber ohne den sudo Trick weder unter RoboPro (hier bekomme ich ein Bild wenn ft in der sudoer Gruppe ist und den Server über den PC starte) noch über ftrobopy (da funktioniert es nie - egal ob WLAN oder USB verbunden und egal von wo ich starte).

Wie Torsten in einem anderen Thread richtig ausführt, gibt es andere Möglichkeiten, den Camera-stream abzurufen. Man muss nicht dies nicht unbedingt über ftrobopy - txt.getCameraFrame() - tun.

Unten eine Möglichkeit über die TXT4.0 API - wenn jemand eine schnellere Option kennt und diese als Antwort postet, würde ich mich sehr freuen.
Der Stream läuft zwar flüssig aber mit einer leichten Verzögerung. Definitiv etwas schlechter als mit TXT und ftrobopy. Für meinen Zweck "Qualitätskontrolle in der Bearbeitungsstation" ist es mehr als genug. Der Stream läuft auch sehr schön über WLAN.

Code: Alles auswählen

import ftrobopy
import time
import cv2
import requests
import json
import threading
from collections import deque
import numpy as np

def resize_frame(img,size):
    r = size / img.shape[1]
    dim = (size, int(img.shape[0] * r))
    resized = cv2.resize(img, dim, interpolation=cv2.INTER_AREA)
    return resized

txt = ftrobopy.ftrobopy(host='192.168.7.2', port=65000,special_connection= '192.168.7.2',use_extension=True) #only to show, that it works

# API configurations
base_url = "http://192.168.7.2/api/v1/controller/camera"
start_url = f"{base_url}/start"
stream_url = f"{base_url}/image-stream?X-API-KEY=XXXXXX" #replace XXXXXX with your API key - you find it on Your TXT4.0
api_key = "XXXXXX"

# Start the camera
start_payload = {
    "debug": False,
    "fps": 5,
    "height": 480,
    "rotate": False,
    "width": 640
}
headers = {
    "accept": "*/*",
    "X-API-KEY": api_key,
    "Content-Type": "application/json"
}

headers = {"accept": "*/*", "X-API-KEY": api_key, "Content-Type": "application/json"}

# Function to fetch the stream
def fetch_stream(url, headers, frame_queue):
    response = requests.get(url, headers=headers, stream=True)
    response.raise_for_status()
    byte_data = b""
    for chunk in response.iter_content(chunk_size=8192):
        byte_data += chunk
        start = byte_data.find(b'\xff\xd8')
        end = byte_data.find(b'\xff\xd9')
        if start != -1 and end != -1:
            jpeg_data = byte_data[start:end + 2]
            byte_data = byte_data[end + 2:]
            frame_queue.append(jpeg_data)

# Start the camera
requests.post(start_url, headers=headers, json=start_payload).raise_for_status()

# Queue and threading
frame_queue = deque(maxlen=1)
stream_thread = threading.Thread(target=fetch_stream, args=(stream_url, {"accept": "multipart/x-mixed-replace"}, frame_queue))
stream_thread.daemon = True
stream_thread.start()

# Display frames
while True:
    if frame_queue:
        jpeg_data = frame_queue.pop()
        image = cv2.imdecode(np.frombuffer(jpeg_data, dtype=np.uint8), cv2.IMREAD_COLOR)
        imagefull = resize_frame(image, 800)
        cv2.imshow("Camera Stream", imagefull)
        if cv2.waitKey(1) & 0xFF == ord('q'):
            break

cv2.destroyAllWindows()

Grüße, Techum

[Techum]

Hallo Torsten,

Falls es noch andere interessante Ideen gibt, die man machen könnte: nur her damit

Ich probiere Deine Servo Erweiterung in ftrobopy aus. Dabei ist mir aufgefallen, dass man die aktuelle Einstellung des Servos nicht abfragen kann.
Ok - kann man bei den normalen Outputs auch nicht, aber beim Servo wäre das ggf. schon nützlich.

Freilich kann man den jeweiligen Soll-Stand auch immer mitführen.

Code: Alles auswählen

servo = txt.output(1,200,1)
servo.setLevel(265)
time.sleep(2)
servo_asis = servo.getLevel() #gewünschte Funktion

Irgendwo habe ich gelesen, dass jemand Probleme mit Überschneidungen von M1 und Servo1 hat.
m1 = txt.motor(1,0)
servo1 = txt.output(1,1)
Muss man in einem solchen Fall
Ich kann bestätigen, dass bei mir m1 mitdreht, wenn setSpeed für m1 gesetzt ist:
m1.setSpeed(300)

Wenn man jetzt einen Befehl für den Servo setzt
servo1.setLevel(300)
dann bewegt sich m1 mit.

In den meisten Fällen dürfte sich das nicht groß auswirken, weil die Servobewegung ja sehr flott ist.

Wenn man die Servobewegung analog jedoch verlangsamt - z.B. so:

Code: Alles auswählen

def servo_in_steps(servo,start,end,step,wait):
    if end < start:
        step = -step
    for x in range (start, end, step):
        servo.setLevel(x)
        time.sleep(wait/1000)
    if x != end:
        servo.setLevel(end)
    return end

dann wirkt sich das schon aus.
Setzt man vorher den speed von m1 auf Null, bewegt sich m1 nicht.

Andersherum - Servo bewegt sich bei Motorbewegung - hatte ich das Phänomen glücklicherweise noch nicht.

Viele Grüße
Frank

[Torsten]

Hallo Frank,

vielen Dank für den Hinweis. Das klingt ja ganz nach einem Bug.

Ich werde mir das mal näher Anschauen.

Viele Grüße,
Torsten

[Techum]

Hallo Torsten,

vielleicht sehe ich ja weiße Mäuse, aber versuche bitte mal einen geraden Ausgang als Output zu definieren:
z.B.
valve = txt.output(4,0,ext=0)

Ich habe keine Probleme mit
valve = txt.output(3,0,ext=0)

Habe es auch mit vorheriger Config versucht
M = [txt.C_MOTOR, txt.C_OUTPUT, txt.C_OUTPUT, txt.C_OUTPUT]
nichts zu machen.

firmware ist 3.1.8

Viele Grüße
Frank