ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1746
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von Dirk Fox » 02 Sep 2022, 01:08

Liebe ROBO Pro- und ftDuino-Fans,

vor fast 10 Jahren hat ft-ninja hier im Forum einen genialen Arduino-Parser für ROBO Pro publiziert (aktuelle Version v0.3 in Github). Die Anwendung "litt" unter der Einschränkung, dass ein Arduino keine 9V-Motoren antreiben kann - weder die Last noch die Spannung sind Arduino-kompatibel. Außerdem waren die Eingänge nicht universell nutzbar. Holger Howey (fishfriend) beseitigte die erste Einschränkung bereits 2017, indem er ein Adafruit Motor Shield auf den Arduino setzte. Dennoch blieben starke Einschränkungen: Die vier schnellen Zählereingänge gibt es beim Arduino nicht, da der Arduino (Uno) nur zwei Interrupt-Pins besitzt - und damit waren auch keine erweiterten Motorbefehle möglich (Abstandsbefehl). Auch die Einschränkung der Nutzbarkeit der Input-Pins blieb bestehen; nach Abzug der beiden I2C-Pins, die das Motor Shield belegt, bleiben beim Arduino nur vier analoge Eingänge.

Da erblickte 2018 Tills ftDuino das Licht der Welt: Ein Arduino Leonardo mit Überspannungsschutz, kurzschlussfest, mit einem Layout der Ein- und Ausgangspins wie beim TX - inklusive leistungsfähigen Motorausgängen und vier schnellen Zählereingängen. De facto ein "kleiner TX", der zugleich den Zugang in die gesamte Arduino-Welt eröffnete.

Da lag es nahe, ft-ninjas Parser zu einem ausgewachsenen "ROBO Pro-TX-Simulator" für den ftDuino weiterzuentwickeln, der sich gegenüber ROBO Pro genau wie ein TX verhält - und damit via USB aus ROBO Pro im Online Mode gesteuert werden kann. Holger Howey hatte sich Mitte 2019 darangesetzt, aber der Code ist noch nicht veröffentlicht: wenn ich Holger richtig verstanden habe, "kämpft" er noch mit ein paar Haken und Ösen.

Vor vier Wochen habe ich mir den Code von ftninja und die zahlreichen Dokumentationen des offiziell nicht dokumentierten Fish.X1-Protokolls zwischen ROBO Pro und dem TX endlich einmal genauer angeschaut. ftninja hat da bereits ganze Arbeit geleistet; allerdings fehlte die erweiterte Motorsteuerung von ROBO Pro - wie ich feststellen musste, eine durchaus knifflige Angelegenheit. Mit einem USB-Port-Sniffer habe ich daher erstmal Schritt für Schritt die letzten "Geheimnisse" aus dem Fish.X1-Protokoll herausgepult und konnte einige Inkonsistenzen in den verschiedenen Dokumentationen auflösen.

Gestern hat dann eine erste Version meines "ROBO Pro-TX-Simulators" für den ftDuino alle Tests erfolgreich bestanden.

Version 1.0 des "ROBO Pro-TX-Simulator"-Sketchs, basierend auf einem Fork von ft-ninjas Parser v0.3, liegt seit heute in meinem Github-Repository als Open Source zum Download.

Nachdem ihr den Sketch via Arduino-IDE übersetzt und auf den ftDuino geladen habt, müsst ihr ROBO Pro mit dem ftDuino verbinden. Dazu wählt ihr in ROBO Pro unter "Interface/Schnittstelle" "USB" und "ROBO TX Controller" aus. In der nächsten Maske bei "Verbindungstyp" auf "Bluetooth" klicken und "Alle COM-Schnittstellen anzeigen" lassen, dann könnt ihr aus der Liste die COM-Schnittstelle wählen, die auch eure Arduino-IDE benutzt hat.

Version 1.0 des "TX Simulators" hat gegenüber einem "ausgewachsenen" TX noch die folgenden Einschränkungen:
- Extensionen (beim TX bis zu 8 "Slaves") werden nicht unterstützt
- der Spursensor liefert analoge, nicht digitale Werte
(technische Beschränkung des ftDuino; vielleicht lässt sich das noch korrigieren)
- Motoren werden (bisher) nicht synchronisiert
- der Ultraschall-Abstandssensor wird nicht unterstützt
(der ftDuino unterstützt ihn nur an C1, aber ich brauche die schnellen Zählereingänge für die erweiterten Motorbefehle)
- es gibt (noch) keine BT-Unterstützung (work in progress)
- es gibt (noch) keine I2C-Unterstützung (work in progress)

Ich freue mich über Feedback - und solltet ihr noch einen Fehler finden: bitte gleich melden, ich korrigiere...

Herzliche Grüße und viel Spaß damit,
Dirk

P.S.: Eine umfängliche Dokumentation des Fish.X1-Protokolls unter ROBO Pro ist in der "Mache" - und erscheint spätestens in der (oder zur) nächsten ft:pedia.

Benutzeravatar
MasterOfGizmo
Beiträge: 2674
Registriert: 30 Nov 2014, 07:44

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von MasterOfGizmo » 02 Sep 2022, 07:19

Sehr witzig. Dann installiere ich mir mal RoboPro ...

Wie ft die Motoren synchronisiert findet man in dem TXT-4.0-Repository.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

kräml
Beiträge: 227
Registriert: 14 Aug 2020, 06:47

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von kräml » 02 Sep 2022, 11:38

Hallo,

sehr spannend. Hab hier zwar RoboPro unter Linux/wine (PlayOnLinux) am Laufen, allerdings kann ich nicht auf die USB Schnittstelle zugreifen. Kann dies daher nicht auf die schnell testen. Der FTduino wäre mit der SW bestückt. Eine Windowssystem aufzusetzen und zu verwalten, ist mir der Aufwand zu groß.

Wenn jemand eine Möglichkeit sieht, die USB unter wine rein zu bekommen, immer her damit. Werde auch noch mal schauen, wenn Zeit ist.

Ach ja das mit dem symbolischen Link auf dosdevices funktioniert bei mir leider (noch) nicht.

Aber cooles Projekt.

Gruß Kräml

Benutzeravatar
fishfriend
Beiträge: 1171
Registriert: 26 Nov 2010, 11:45

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von fishfriend » 02 Sep 2022, 13:08

Hallo...
Ja, aufgeräumter als meine Version. Wobei ich mich frage wo die Unterschiede zu meinem Programm sind? Aber OK.
Das Problem das ich hatte ist, das einige Positionen der Daten nicht mit dem Arduino-Parser für ROBO Pro übereinstimmen.
Das wirklich große Problem ist aber, mehrere TAs damit zu bearbeiten. Das hab ich aber nun hin bekommen. Man kann also auf Extensions zugreifen.
Ja dann...
Mit freundlichen Grüßen
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1746
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von Dirk Fox » 02 Sep 2022, 17:55

Hallo Holger,
fishfriend hat geschrieben:
02 Sep 2022, 13:08
Wobei ich mich frage wo die Unterschiede zu meinem Programm sind? Aber OK.
das kann ich Dir nicht sagen - Dein Programm kenne ich nicht; Du hast es bisher nicht veröffentlicht, oder? Ähnlichkeiten sind zudem wahrscheinlich - schließlich haben wir mit ft-ninjas Parser denselben Ausgangscode verwendet. Und so sehr viele verschiedene sinnvolle Möglichkeiten, den ftDuino anzusteuern, gibt es auch nicht.
fishfriend hat geschrieben:
02 Sep 2022, 13:08
Das wirklich große Problem ist aber, mehrere TAs damit zu bearbeiten. Das hab ich aber nun hin bekommen. Man kann also auf Extensions zugreifen.
Mehrere TAs kann man natürlich ansteuern - aber wofür benötigst Du das? Extensionen (also weitere ftDuinos als "Slaves") könnte man am ftDuino höchstens via I2C anbinden, oder wie hast Du das gelöst?

Herzliche Grüße,
Dirk

Benutzeravatar
fishfriend
Beiträge: 1171
Registriert: 26 Nov 2010, 11:45

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von fishfriend » 05 Sep 2022, 11:13

Hallo...
Schau dir mal genau an, wie und wo die Bezeichnungen/Variablen für eine "zweite" TA sind.
Auch die Rückmeldung ob eine oder mehrere Extension vorhanden sind, geht so nicht.
Es ist nicht nur eine Konzeptfrage -wie- man das macht.
Man muss vorher festlegen mit wievielen Extensions man was machen möchte. An- und Abstecken mit Erkennen geht so auch nicht.

Ich hab das Gefühl, dass bei der Programmierung von TX, auch ein Rückschritt in eine vorherige Version gemacht wurde, weil die z.B. die .h-Dateien nicht mit meinen Mittschnitten der Schnittstelle, der neusten Version von RoboPro, übereinstimmen (TX-Modus). Ich hab dann Dummys eingefügt bzw. die Reserve verkleinert, um auf die richtige Stelle der Übertragung zu kommen. Es war nicht der falsche Variablen-Typ, wie ich erst dachte.
---
Momentan sind die Ein- und Ausgänge nur intern in meinen ersten ftduino. Die Anbindung soll mit I2C und zu weiteren ftduinos erfolgen.
Ist halt nett, wenn man Ein- und Ausgänge auf einer Adresse hat und nicht eine/zwei für Eingänge und weitere Treiberkarten für die Ausgänge.
Weil ich gerade die ft-Factory mache, liegt mein Projekt aber erstmal auf Eis. Der Plan war/ist auch die oder Teile der Anlage über so einen ftduino laufen zu lassen. Mein Hauptziel mit den Extension bei RoboPro funktioiert ja. Auch hab ich einen Arduino-Mega da, der halt mehr I/Os hat, mit dem man das ausprobieren kann. Einen zweiten ftduino hab ich nicht.

-Aber- momentan bekommt man teilweise, einen gebrauchten TX günstiger, als einen ftduino. Da ist es die Frage, ob sich der Aufwand wirklich lohnt.
Ist halt wie bei der Mondlandung. Wir machen das, weil wir es können. ;-)
Der wirkliche Unterschied ist aber, dass man auch andere Sachen wie z.B. 8 oder mehr Servos mit RoboPro steuern kann. Da stellt sich mir aber die Frage ob das dann jemand nachbauen würde. Denn die Kosten sind nicht ohne.
Mit freundlichen Grüßen
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

vleeuwen
Beiträge: 1457
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von vleeuwen » 05 Sep 2022, 13:01

Does this include the powerful Robo Pro SLI element?
Will Robo Pro also be maintained by Soegtrof?
Has the bug in the I2C implementation been resolved?
Both seem to me essential whether there is still energy to be invested in them for the future.
=================================================
Beinhaltet dies das leistungsstarke Robo Pro SLI-Element?
Wird Robo Pro auch von Soegtrof gewartet?
Wurde der Fehler in der I2C-Implementierung behoben?
Beides erscheint mir wesentlich, ob in sie noch Energie für die Zukunft investiert werden kann.
software enigineer/teacher/advisor
Google translate
http://tescaweb.nl/Carel/?p=713

Benutzeravatar
MasterOfGizmo
Beiträge: 2674
Registriert: 30 Nov 2014, 07:44

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von MasterOfGizmo » 05 Sep 2022, 18:33

vleeuwen hat geschrieben:
05 Sep 2022, 13:01
Does this include the powerful Robo Pro SLI element?
Will Robo Pro also be maintained by Soegtrof?
Has the bug in the I2C implementation been resolved?
Either you don't know what SLI is and how it works or you are trying to troll Dirk.

Just in case you really don't know SLI: SLI stands for Shared Library Interface. Shared Libraries are a way to share common code between different processes on a Unix system. So SLI requires a Unix like operating system on the target.

The ftDuino on the other hand is an Arduino compatible device. Arduinos run code directly ("bare metal") without any operating system like Unix involved. So SLI and the ftDuino don't have much in common .

Furthermore Dirk is simulating a TX (not a TXT) which IMHO didn't support SLI in the first place.

But I am pretty sure you already knew that and you were just trying to troll Dirk. Please stop that.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1746
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von Dirk Fox » 05 Sep 2022, 22:52

Hi Till, Carel,

there seems to be an acronym "mismatch" - I guess, Carel is talking about the "Shared Library Input" element, which allows to expand the build in ROBO Pro commands by calling C functions from an external library. This element does not affect my "TX simulator": the ftDuino sketch answers to Fish.X1 packets as if it would be a TX. In your ROBO Pro program, you can still call as many external library functions as you wish...

The maintenance of ROBO Pro is an open question - as long as fischertechnik is selling TXTs, I expect continued maintenance, at least because there is no other "official" programming language. On the other hand: there are not so many known open bugs in ROBO Pro anymore... perhaps we will get one final release with some last fixes.

Concerning "the I2C bug": Which one do you mean?

Regards,
Dirk

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1746
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von Dirk Fox » 05 Sep 2022, 23:11

Hallo Holger,
fishfriend hat geschrieben:
05 Sep 2022, 11:13
Schau dir mal genau an, wie und wo die Bezeichnungen/Variablen für eine "zweite" TA sind.
Auch die Rückmeldung ob eine oder mehrere Extension vorhanden sind, geht so nicht.
meine Protokollanalysen habe ich hier mit bis zu vier kaskadierten TXen mit unterschiedlichen Konfigurationen (Reihenfolge, Extension ID) gemacht. Das Konzept erscheint mir sehr simpel: Am Ende des Fish.X1-Frame-Headers des Pakets von ROBO Pro an den TX (ftDuino) steht die Anzahl der Transfer Areas (TAs), dann folgen die TAs jeweils mit der Nummer der Extension davor. (Zwar ist es arg übertrieben, für die Nummerierung der 9 möglichen TAs vier Byte zu spendieren, denn damit lassen sich knapp 4,3 Milliarden TAs durchzählen... aber von der Sorte finden sich einige unsinnige "Aufbläher" in dem Protokoll. Das ginge deutlich effizienter...). Die Datenstrukturen im Headerfile habe ich entsprechend angepasst.

Wenn man die TAs für Extensionen z.B. an via I2C angeschlossene weitere ftDuinos weiterleiten möchte, kann man das ohnehin cleverer machen als der TX (denn die ftDuinos sind ja "unter sich") und jedem angeschlossenen ftDuino nur seine TA via I2C zusenden. Wenn man jeder Extension (so, wie es der TX auch macht) eine eigene Extension-ID zuordnet (primitiv: fest im Sketch), dann kann der "Master ftDuino" die Extensionen auch erkennen - und bei den CMD 007-Paketen, die ROBO Pro regelmäßig schickt, das Ein- und Auschecken von Extensionen abfragen: Wenn ein ftDuino nicht antwortet, ist er eben "weg".

Ob es allerdings lohnt, den "TX Simulator" Extensionen-fähig zu machen, ist tatsächlich die Frage, da gebe ich Dir recht. Viele fischertechnik-Modellbauer verwenden einfach mehrere TXe mit separaten Programmen, ohne sie über die Extensionsschnittstelle zu koppeln. Das geht immer - auch mit dem "TX Simulator".

Beste Grüße,
Dirk

Benutzeravatar
MasterOfGizmo
Beiträge: 2674
Registriert: 30 Nov 2014, 07:44

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von MasterOfGizmo » 06 Sep 2022, 08:00

Dirk Fox hat geschrieben:
05 Sep 2022, 22:52
there seems to be an acronym "mismatch" - I guess, Carel is talking about the "Shared Library Input" element, which allows to expand the build in ROBO Pro commands by calling C functions from an external library.
IMHO Carel refers to this:
The shared library input/output element allows to call functions and return/supply a value from/to shared library modules installed on the TXT controller.
This is from https://github.com/fischertechnik/txt_d ... ter/SLI.md

Those "shared library modules installed on the TXT" obviously don't exist on an Arduino.

Maybe Carel can explain what he expects from the SLI on a device other than the TXT.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1746
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von Dirk Fox » 06 Sep 2022, 08:50

Hi Till,
MasterOfGizmo hat geschrieben:
06 Sep 2022, 08:00
IMHO Carel refers to this:
The shared library input/output element allows to call functions and return/supply a value from/to shared library modules installed on the TXT controller.
This is from https://github.com/fischertechnik/txt_d ... ter/SLI.md
Those "shared library modules installed on the TXT" obviously don't exist on an Arduino.
You are right: If Carel wants to use the shared library element in the offline (download) mode, he is talking about a different setup - the "TX Simulator" is a solution for the online mode of ROBO Pro, and for the TX (and not the TXT, as you observed correctly).

Regards,
Dirk

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1746
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: ROBO Pro ist tot - lang lebe ROBO Pro: Jetzt auch für den ftDuino

Beitrag von Dirk Fox » 07 Sep 2022, 03:20

Hallo zusammen,

Version 1.1 des "TX Simulators" ist gerade online gegangen.
Damit liefert der Spursensor nun auch digitale Werte.
Außerdem enthält die Version eine Unterstützung der I2C-Befehle von ROBO Pro. Da der I2C-Anschluss am ftDuino Pin-kompatibel mit dem des TX ist, können die I2C-Sensoren und -Aktoren direkt "umgesteckt" werden. Getestet habe ich mit den Treibern aus meiner ROBO Pro I2C Treiber Sammlung.

Viel Spaß damit!

Herzliche Grüße,
Dirk

Antworten