Hallo Marvin(s),
Marvin hat geschrieben:Also können tun wir eigentlich gar nichts, wir sind blutige Anfänger in der Hinsicht und beide fast 30.
Der Roboter ist ein mechanisches, elektrotechnisches und schließlich auch ein Softwareproblem. Ihr schreibt weiter unten, daß Euch "richtige Programmierung" eher abschrecke.
Man kann ft oder Lego auch als rein mechanische Lösung begreifen, d.h. man setzt den gewünschten Roboter aus den Teilen dieser Systeme mechanisch zusammen, nutzt auch deren Aktoren und Sensoren, verwendet aber ein anderes Steuerungssystem wie etwa Arduino und Derivate als Controller und dazugehörige Motorshields zur Ansteuerung der jeweiligen Aktoren. Mit dem Arduino und dem erforderlichen Zubehör kann man BTW recht preiswert steuern, muß sich aber auch deutlich mehr einarbeiten - sowohl in elektro- als auch in softwaretechnischer Hinsicht.
Marvin hat geschrieben:Aber bei Lego würde mich schon eher der Mindstorm, anstatt der Boost Roboter interessieren.
Und was noch hinzu kommt ist, dass wir vorher schon immer Lego gesammelt haben, also schon etliche Teile zu Hause rumliegen haben, also warum nicht gleich kombinieren? Die Community wird dort auch einfach viel größer sein.
Rei Vilo hat in
https://reivilofischertechnik.weebly.co ... world.html das "TXT Discovery Set" von ft (Art. 524328) und "Mindstorms EV3" von Lego (Art. 3131) miteinander verglichen. Beide Kästen könnte man wohl als Startsets ihrer jeweiligen Systeme bezeichnen und bieten einen Einstieg in das Thema Robotics allerdings für ältere Kinder und Jugendliche. Ich denke, Rei Vilo hat die Unterschiede zwischen beiden Systemen IMHO recht gut erfaßt.
Die Verwendung alternativer Steuerungen würde bei Lego schon rein anschlußtechnisch betrachtet durchaus eine Fummelei. Für die Konfektionierung von Leitungen mit Westernsteckern benötigt man eine spezielle Crimpzange; bei den Westernsteckern gibt es durchaus noch deutlich mehr Typen als die verbreiteten 4-poligen für Telefone und 6-polige für ISDN-Verkabelungen. Und dann müßte man noch in Erfahrung bringen, ob beispielsweise der verbaute Lego-Aktor oder -Sensor noch verhältnismäßig "normal" aufgebaut ist oder eine Eigenintelligenz mitbringt. In letzterem Fall kann man sie nicht einfach mit einem Shield oder einer H-Brücke betreuen, sondern hat stattdessen einen digitalen Bus anzubinden.
Bei ft ist auch ein Encodermotor noch immer ein (Gleichstrom)motor, zusätzlich versehen mit einem Inkrementalgeber, mit dessen Hilfe der Controller "nachvollziehen" kann, wie weit sich der Läufer des Motors tatsächlich gedreht hat. Alternativ kann man aber auch einen eigenen Inkremetalgeber bauen, etwa wenn man (stärkere oder kleinere) Motore ohne Geber verwenden oder das Spiel einer Kraftübertragung möglichst weitgehend ausschalten möchte. Sowohl Motoren als auch Sensoren (wie etwa Inkrementalgeber) sind ohne Klimmzug Steuerungen auf Arduino-Basis zugänglich.
Nutzt man im ft-System den TXT-Controller etwa der graphischen Programmierung wegen, hat das auch Nachteile: Man hat pro Controller nur 12 Eingänge und 8 Ausgänge und kann dabei je zwei Ausgänge zu einem Motorausgang mit Richtungswechselmöglichkeit zusammenfassen. Wer mehr braucht, kann nur einen weiteren TXT-Controller als Slave anbinden. Allerdings könnte man auch mehrere TXT-Controller mit je eigener Programmierung versehen und deren Koordination durch einfache Signale vom Ausgang des einen zu einem Eingang des anderen realisieren, falls man nicht ohnehin rein sensorisch arbeiten kann.
ft hat die Basis zumindestens einiger seiner Sensoren bekanntgegeben, wie etwa den Typ der Fotodiode, mit der man in ft heute Lichtschranken realisiert; andere haben die Charakteristika der ft-Motoren ermittelt (
https://www.ftcommunity.de/downloads.ph ... ormationen). Der TXT-Controller bietet noch einen I²C-Bus (3,3 V), für den man bei Drittanbietern zahllose Sensortypen und auch Motortreiber findet. Damit kann man die Ein- und Ausgänge des TXT sparsamer verwenden, auch wenn der I²C-Bus nicht für alle Anwendungen schnell genug ist. In technologischer Hinsicht eröffnet das ft-System mit seinen Standards (Linux-tauglicher Controller, I²C-Bus, Ein- und Ausgänge für "plain electrical Devices") IMHO mehr Spielraum als das verschlossenere Lego.
Marvin hat geschrieben:Fischertechnik wirkt halt eher realistisch
Es ist wohl stabiler als Lego, vor allem wenn es um Bewegung oder Fahrzeuge geht.
Generell sorgen Baukastensysteme wie ft oder Lego dafür, daß ein technischer Irrtum nur Zeit, nicht aber Material kostet. Erweist sich ein Mechanismus als untauglich, zerlegt man ihn und verwendet die Einzelteile neu. Das geht mit individuell angefertigten Bauteilen nicht so einfach, zumal deren Erstellung oft teure Maschinen und zumindestens erhebliches handwerkliches Geschick erfordert. Bei der Realisierung selbstentwickelter Elektronik ist der Aufwand überschaubarer, auch weil es heute anscheinend für jeden Zweck bereits einen integrierten Schaltkreis gibt, so daß man kaum noch riesige Layouts mit Hunderten von Bauteilen darstellen muß.
Mit freundlichen Grüßen
Lars