Fischertechnik mit Raspberry Pi steuern - Erfahrungen und Projekte.

[jayalpha93]

Hallo zusammen,
ich bin neu hier im Forum und begeistere mich seit kurzem für die Kombination aus fischertechnik und Raspberry Pi. Ich habe bereits einige kleinere Projekte realisiert, wie z.B. die Steuerung eines einfachen Förderbandes mit Python und einer Relaiskarte.
Ich würde gerne von euren Erfahrungen profitieren und mich austauschen. Welche Projekte habt ihr bereits umgesetzt? Welche Herausforderungen gab es dabei? Welche Libraries oder Tools könnt ihr empfehlen?
Ich bin besonders interessiert an:
* Steuerung komplexerer fischertechnik Modelle (z.B. Roboter) mit ROS (Robot Operating System)
* Bildverarbeitung mit OpenCV zur Objekterkennung und -sortierung
* Anbindung von Sensoren (z.B. Ultraschall, Farbsensoren)
* Web-Interface zur Steuerung und Überwachung
Gibt es vielleicht auch eine Art "Best Practices

[PHabermehl]

Schau mal unter

www.tx-pi.de

Man kann libroboint und ftrobopy auch ohne den Rest des Tx-Pi Setup nutzen, ähnliches gilt für das HAT.

Schau auch mal in die aktuelle ft:pedia.

Gruß
Peter

[Defiant]

Wenn du mit ROS noch nicht vertraut sein solltest, würde ich empfehlen zuerst mit einer Hardwaresimulation zu starten, z.B. Turtlebot 3 für mobile Roboter, Openmanipulator für Roboterarme, so lernst du zuerst das Framework kennen und brauchst dich nicht am Anfang gleich parallel mit den unzulänglichkeiten der Hardware auseinanderzusetzen. ROS erwartet z.B. eine funktionierende Geschwindigkeitsregelung und exakte Positionserkennung die erfahrungsgenäß etwas Zeit und Erfahrung brauchen bis diese in der echten Welt funktionieren, mit und ohne ft.

[kräml]

Hallo erst a.,

coole Ideen. Mit Fischertechnik und ROS2 finde ich auch sehr spannend. Ich denke, mit Raspberry Pi und Fischertechnik hat dir Peter schon den richtigen Tipp gegeben.

Bin hier auch mit ROS2 auf dem Pi beschäftigt - noch nicht mit Fischertechnik - und wenn wir Zeit und Lust haben, können wir uns hier im Forum gerne austauschen. Bin aber auch noch ganz am Anfang mit ROS2.

Woher kommst du? Ich komme aus dem Raum Nordbayern. Evtl. auch face to face.

Gruß Kräml

[PHabermehl]

ROS ist halt ein ganz anderer Level. Sehr spannend, das interessiert mich natürlich auch alles, was so läuft.
Wenn es primär erstmal um die Steuerung von ft Modellen geht, würde ich tatsächlich aber erstmal Python unter Raspberry OS empfehlen, damit man nicht auch noch den ganzen Stress auf Systemseite hat.
Aber wie gesagt, ROS für ft fände ich auch sehr spannend...

[kräml]

Hallo,

ja ROS ist schon eine Baustelle, aber wenn ich mir die Wunschliste anschaue und der Wunsch mit Fischertechnik, das kann ich nur unterstützen bzw. will ich gerne mit dabei sein. Einfach machen, es könnte ja gut werden.

Daher die Frage @jayalpha93, wie Sattelfest bist du unter Linux und Python? Das wäre die Grundlage von deiner Wunschliste. Also meiner Meinung nach, wenn der TX-PI schon gewollt wird, dann macht es Sinn, mit Linux zu arbeiten.

Gruß Kräml

[kräml]

Noch mal Hallo,

man sollte hier noch erwähnen, dass der TX-PI auf Debian und nicht auf Ubuntu aufsetzt. Daher würde ich, wie in meinem anderen Projekt, auf Docker setzen. JA ich weiß noch ein Techterminus mehr hier auf der Liste. Aber zusammen werden wir das schon schaukeln.

Gruß Kräml

[Techum]

Wenn du mit ROS noch nicht vertraut sein solltest, würde ich empfehlen zuerst mit einer Hardwaresimulation zu starten, ... ROS erwartet z.B. eine funktionierende Geschwindigkeitsregelung und exakte Positionserkennung die erfahrungsgenäß etwas Zeit und Erfahrung brauchen bis diese in der echten Welt funktionieren, mit und ohne ft.

Das klingt nach Erfahrung... Hast Du ggf. schon ROS mit fischertechnik gekoppelt? Wenn man sich auf den Weg einigen würde, könnte man sich ggf. die Arbeit an den Packages für Services und besonders den Actions teilen...

[Defiant]

Das klingt nach Erfahrung... Hast Du ggf. schon ROS mit fischertechnik gekoppelt? Wenn man sich auf den Weg einigen würde, könnte man sich ggf. die Arbeit an den Packages für Services und besonders den Actions teilen...

Ich habe mehrere meiner Spielzeuge an ROS (1+2) angebunden, darunter auch ft-Modelle, allerdings normalerweise nicht mit ft-Interface, sondern Fremdelektronik. Ausnahme ist der Robo-Explorer den ich per libroboint angesteuert hatte.

Was das Teilen der Arbeit bei der Anbindung an ft angeht. Meiner bescheidenen Erfahrung nach ist die reine Anpassung von ROS an Hardwaretreiber schnell geschrieben, ROS-Control kann hier unterstützen. Nehmen wir als Beispiel mal einen mobilen Roboter. Hier erwartet ROS die aktuelle Position und Geschwindigkeit von der Hardware als Eingabe. Im Gegenzug muss die Sollgeschwindigkeit umgesetzt werden. Jetzt nehmen wir mal die drei unterschiedlichen Maker-Plattformen, sie verarbeiten sowohl die Geschwindigkeit, als auch die Rotation unterschiedlich. Und hier steckt der größte Aufwand der ROS-Adaption. Wenn sich die Plattform mit 10cm/s bewegen soll, dann bedeutet das nicht bergauf 5cm/s und bergab 15cm/s, dann sind nämlich die vorrausschauenden Berechnungen der Algorithmen unbrauchbar und der Roboter fährt direkt in den Stuhl rein, obwohl ein Kurs knapp vorbei geplant wurde. Hab ich alles schon gehabt, mehr als einmal..

Hier sind zum einen die Parameter für die Geschwingdigkeitsregelung, als auch die Fehlerkovarianzen zu ermitteln. Gefühlt sind bei der Inbetriebnahme in der Parametrisierung 40% des Aufwands, weitere 50% sind das ROS-Ökosystem zu verstehen, die restlichen 10% ist dann die Kopplung von ROS an das ft-Modell.

Bezogen auf Services und Actions, die habe ich bisher sehr wenig implementieren müssen. Ein Service könnte z.B. sein "Licht anmachen", hier wird einfach nur eine Callback benötigt die den Hardwareaufruf ausführt, also etwa zwei Zeilen code, wieder sehr individuell per Roboter, einige haben Licht, andere Mähmotoren. ;)

Actionserver werden von ROS weitesgehend zur Verfügung gestellt, z.B. für Navigation, hier entsteht auch der Aufwand an das Tuning (max. Geschwindigkeit, Beschleinung etc) für das eigene Modell, je nach Aktoren, Sensoren und was der Roboter machen soll, z.B. von der Küche ins Wohnzimmer fahren oder Pfadabdeckung wie z.B. bei Staubsaugerrobotern oder Rasenmähern.

Arbeitsteilung lohnt sich mMn. eher bei der generellen Architektur und mit Fragen und Antworten kann man viel voneinander lernen.

[Techum]

Ich habe mehrere meiner Spielzeuge an ROS (1+2) angebunden, darunter auch ft-Modelle, ... verarbeiten sowohl die Geschwindigkeit, als auch die Rotation unterschiedlich. Und hier steckt der größte Aufwand der ROS-Adaption. ...
Arbeitsteilung lohnt sich mMn. eher bei der generellen Architektur und mit Fragen und Antworten kann man viel voneinander lernen.

Super vielen Dank für die ausführliche Antwort und Deine Einschätzungen. Dein "Spielzeug" mit Greifer ist schon ein mächtiges Kaliber. Hut ab!
Ich hätte genau das Gegenteil von dem gehofft, was Du schreibst. Also dass sie Kalibrierung keine so große Rolle spielt, weil man z.B. "relativ einfach" Beobachtung von außen oder eine (Re)Kalibrierung des Systems anhand von Fixpunkten einsetzen kann.

Klingt nach etwas Größerem und vor allem nicht danach, als könne man gut arbeitsteilig vorgehen.
Vielleicht ein schönes Thema für die Convention...

Schönen Abend!
Techum

[Defiant]

Ich hoffe ich habe hier niemanden entmutig, aber es sollte klar sein, dass man sich ganze nicht "an einem Abend" durchführen lässt. Wie gesagt, ich würde, wen ich neu anfangen würde ROS anhand einer Simulation lernen wollen, auch wenn reale Hardware mehr Spaß macht. Aber so lässt sich leichter erkennen wie ROS funktioniert und welche Probleme eine falsche ROS Konfiguration oder unzulänglichkeiten der Hardware sind.

[kräml]

Hallo,

vielen Dank an Defiant für den inspirierenden Beitrag und die wirklich tollen Modelle.

Ich hoffe ich habe hier niemanden entmutig, aber es sollte klar sein, dass man sich ganze nicht "an einem Abend" durchführen lässt. Wie gesagt, ich würde, wen ich neu anfangen würde ROS anhand einer Simulation lernen wollen, auch wenn reale Hardware mehr Spaß macht. Aber so lässt sich leichter erkennen wie ROS funktioniert und welche Probleme eine falsche ROS Konfiguration oder unzulänglichkeiten der Hardware sind.

Das klingt für mich nicht entmutigend, sondern sehr spannend. Hier steckt viel Erfahrung drin. Daher meine Fragen:

1. Wie würde dein Einstieg denn jetzt aussehen?
2. Wie würde eine reale Hardware nach der Simulation aussehen?
3. Ist FT eine unzulängliche Hardware? (Nicht falsch verstehen)

Zu 1.: Die ROS2-Dokumentation geht, soweit ich mich erinnere, von der Turtle-Simulation aus. Dabei werden die wichtigsten Konzepte und Methoden von ROS2 vorgestellt. Es wäre schön, wenn man jetzt mit einem Joystick die Schildkröte steuern könnte. Damit wären wir dann schon bei Punkt 2. Man könnte einen einfachen FT-Roboter (Maker-Modell) einführen. Joystick und FT mit ROS2 verbinden.

Zu Punkt 3: Die FT-Maker sind bestimmt eine gute Sache. Oder wie wäre es mit einem FT-Community-Turtlebot? Das wäre dann was.

Gruß Kräml

[Defiant]

Ich bringe mal ein Beispiel für unzulängliche Hardware: Ich habe mit ROS mit einem mobilen Roboter mit Kettenantrieb gestartet (Avatar). Aufgrund des Schlupfes bei der Drehung war die Ermittlung der Orientierung für eine Odometrie viel zu schlecht. Die Lösung war dann die Verwendung einer IMU, die damals in der bezahlbaren Version aber nicht so genau arbeitete wie moderne Sensoren, z.B. BNO055. Das hat also nicht direkt mit ft zu tun.

Bei der "Turtle-Simulation" sind zwei zu unterscheiden. Die Simulation in den Einsteigertutorials ist nur dafür gedacht das fundamentale ROS-Konzepte (Publish/Subscripbe) zu verstehen, danach kann man diese Simulation vergessen. Sie hat nichts mit der späteren Verwendung zu tun, das Datenformat passt nichtmal zu dem, was per Konvention zur Steuerrung verwendet wird.

Die Navigation-Anleitungen verwenden den Turtlebot 3, das sind die spannenden Anleitungen. Für den einfachen ft-Roboter würde ich als Chassis dem Omniwheel nehmen. Der Bionic ist zu kompliziert für den Einstieg, da komplex in der Ansteuerung und der Car eignet sich mehr als ein Modell für selbstfarende Autos.

Für die Steuerung per Joystick wird "nur" ein Hardware-Controller (Interface?) benötigt und dieser sollte dann den Geschwindigkeitsbefehl für Translation (x,y) und Rotation bearbeiten. Also eine Geschwigkeitsregelung sollte vorhanden sein..

Lass uns unten anfangen, welches Chassis und welche Elektronik zur Ansteuerrung habt ihr schon, bzw wollt ihr verwenden? Der Turtlebot 3 ist iirc ein 2wd Fahrzeug, also ein linker und ein rechter Motor sowie ein nachlaufendes Rad ähnlich Mobile Robots.

[kräml]

Hallo,

denke, das Maker Omniwheel wäre eine gute und einfache Ausgangsbasis. Hab ich zwar nicht, sollte aber mit den Teilen hier machbar sein. Da hier der Thread schon mit Raspberry Pi gestartet wurde, gerne den TX-PI. Zu überlegen wäre auch, mit einem esp32 zu arbeiten. Da Dirk Fox ja was in der Maker vorgestellt. Das könnte man evtl. auch noch aufmotzen.

Gerne auch Maker Kit Car mit TX-PI. Ob man gleich mit einem TurtlBot3 in FT anfangen möchte, weiß ich nicht, wäre aber auch denkbar.

Cool wäre es, wenn man aus dem FT-Designer die URDF raus bekommen könnte.

Gruß Kräml

[Defiant]

Den Maker Artikel muss ich mir noch besorgen, ist das die aktuelle Ausgabe?

Guter Punkt mit der URDF, da bräuchten wir ein austauschformat, was sich in Freecad einlesen lässt.

Für den ESP32 gibt es natürlich auch was. Vorteil eines TX-PI ist denke ich die Möglichkeit der Verwendung von USB-Geräten, z.B. (3D-)Kameras. Ja, auch hier gibt es Lösungen für den ESP32 hat aber mehr Bastelaufwand. Turtlebot 3 arbeitet auch mit dem Rpi.

[kräml]

Hallo,

ja ist die aktuelle Ausgabe:

Make 2/2025 S. 74

Die FT-Makerkästen wurden hier vorgestellt:

Make 5/2024 S. 128 Fischertechnik Bausätze für erfahrene Maker

Gruß Kräml

[kräml]

Hallo,

die Frage nach dem Modell lässt mir keine Ruhe. Ich möchte die Frage daher noch etwas abändern:

Ein FT-Modell für ROS, das u. a. nach folgenden Kriterien untersucht werden kann:

- Gewicht
- Energieträger
- Antriebstechnik
- 100 % Fischertechnik (was hier im Thread „Fischertechnik mit Raspberry Pi steuern” eigentlich nicht gegeben ist).



Der Turtlebot3 ist ein typischer ROS1-Roboter. Er ist schwer, hat starke Motoren und eine große Rechenleistung.
Der Buggy oder Flitzer von Dirk Fox. Das sind typische FT-Modelle, aber nicht 100 %.

Einen Turtlebot wird man nicht aus 100 % Fischertechnik bauen. Dafür sind große Akkus und große Motoren notwendig. Das werden die Fischertechnik-Teile nicht hergeben.

Da der Pi recht viel Energie benötigt, würde ich dennoch den ESP32-Ansatz verfolgen. Das spart Gewicht und Akkuleistung, sodass der Antrieb leichter zu realisieren wäre. Allerdings würde ich den Pi zur Verarbeitung der Informationen vom ESP32 verwenden. ROS2 bietet mit seinen leicht- und gleichgewichtigen Nodes ja diese Möglichkeit, wenn ich das richtig verstanden habe.

- Steuerung komplexerer fischertechnik-Modelle (z. B. Roboter) mit ROS (Robot Operating System)
* Bildverarbeitung mit OpenCV zur Objekterkennung und -sortierung
* Anbindung von Sensoren (z. B. Ultraschall-, Farbsensoren)
* Web-Interface zur Steuerung und Überwachung
Gibt es vielleicht auch eine Art „Best Practices”?

Daher mein Vorschlag:
- ESP32-FT-Modell für mobile Anwendungen
- Stationär den TXT-PI für OpenCV usw.
ROS2 (Pi) mit Microros (ESP32) verbinden.

Dirks Modell liegt als FT-Designer-Modell vor. Mit FreeCAD kannst du es dann in URDF wandeln. Wenn das geht, super, ich freue mich.

Gruß Kräml

[Defiant]

Der Turtlebot3 ist ein typischer ROS1-Roboter. Er ist schwer, hat starke Motoren und eine große Rechenleistung.

Einen Turtlebot wird man nicht aus 100 % Fischertechnik bauen. Dafür sind große Akkus und große Motoren notwendig. Das werden die Fischertechnik-Teile nicht hergeben.

Das Gewicht des Turtlebot 3 wird je nach Version mit 1kg bzw 1,8kg angegeben. Mein Maker 4wd Nachbau wiegt laut meiner Küchwaage 1,8kg, das Gewicht ist also in derselben Größenordnung. Aber zugegeben, 30kg Payload sind mit ft schon eine Herausforderung, halte ich bei dem Turtlebot allerdings auch für optimistisch. Die schwarzen Encoder Competition sind auch nicht ganz so schwach wie die roten Encodermotoren oder sogar S-Motoren und können schon was bewegen.

Hier noch ein Tip: Mach es im ersten Ansatz nicht zu kompliziert.