Arduino, ftduino mit RoboPro steuern und Betatester gesucht
Verfasst: 05 Apr 2020, 01:26
Hallo...
Also es funktioniert. Man kann einen Arduino oder ftduino mit RoboPro steuern.
Ja, ich werde nun mal ein paar Tester hiermit suchen.
-Aber- erst noch mal ein paar Fragen an euch:
Counter<> Genauigkeit
Die Frage ist: Wie genau soll ein "Counter" sein?
Hintergrund: Man kann im ftduino einen Encodermotor eine Strecke (Impulse) fahren lassen.
Nun läuft der Motor jedoch nach, egal ob mit oder ohne Bremse. Die ftduino.h macht leider keinen Unterschied bei Countern und Distanz.
Ich vermute das es ehr von der Arduino-Programmierung kommt als von ft.
Nun hab ich das Problem, wenn ich von RoboPro eine Distanz vom ftduino fahren lasse, wird scheinbar beim ftduino Counter
der zufahrende Wert (z.B. 10) von Null abgezogen und dann der Counter bis 0 gefahren und dann gestoppt (+ ein paar Impulse).
Somit steht er dann z.B. auf 11.
Somit driftet die wirkliche Position, weil ja beim nächsten fahren der Wert ja wieder von Null aus gemessen.
Auch geht der "mitzählende" Counter verloren.
Es ist die Frage ob ich mir die Arbeit machen soll, einen extra mitzählenden Counter zu programmieren.
Wie oft braucht man so etwas bei einem ft-Modell, wo sowieso ein Nullpunkt-Taster da ist?
Der Aufwand ist momentan gerade etwas hoch. Oder doch? (11 zu 190 bei einer Motor Umdrehung)
Art der Eingänge
Es ist die Frage ob man "Anfängern" zumuten kann, die Eingänge per Arduino IDE umzustellen.
Hintergrund: Man hat 8 Eingänge die einen (digitalen) Taster oder ein Widerstand einlesen und mit:
ftduino.input_set_mode(Ftduino::I1, Ftduino:: SWITCH);
ftduino.input_set_mode(Ftduino::I1, Ftduino:: RESISTANCE);
umgestellt werden.
Die Auswertung der Umschaltung ist bisher nicht drin. Für -mich- ist das nun kein großes Problem.
Ich hatte zwischenzeitlich einfach die letzten beiden Eingänge beiden als Widerstand laufen lassen.
Nur tauchen dann bei dem Interfacetest von RoboPro bei unbeschalteten Eingängen manchmal Werte auf und die Taster sind auf 1.
Alles in allem ist es ja nur ein TX "Light" Interface. Somit laufen nur die überwiegende Sachen.
Ich denke das so 95% der "normalen" ft Modelle laufen (wenn nicht noch mehr).
Ich habe aber nicht alle fertigen Programme getestet - auch weil ich nicht die CDs von allen Kästen und damit die Programme habe
bzw. weil ich nicht alle Modelle aufbauen und testen kann.
Die nächste Sache ist die Anleitung. Ich muss die noch mal überarbeiten.
Es sind momentan zwei (und die noch gemischt), wobei ich mehrere Bereiche habe u.a.:
Arduino Uno
Arduino Uno; ohne alles weitere; Steuerung "nur" von z.B. LEDs... über RoboPro (sehr Gut zum Lernen mit Elektronik) (kleine Sachen auch ohne Netzteil)
Arduino Uno; mit Motortreiber (H-Brücken); (teilweise mit ft nutzbar)
Arduino Uno; mit Adafruit Motortreiber Shield 2.0; (Motor, Lampen,... auch fremde Motoren mit viel höherer Spannung nutzbar)
Arduino Uno; mit Adafruit Motortreiber Shield 2.0; mit Eingangsbeschaltung (Eigentlich erst ab hier voll mit ft nutzbar) -- ("Umbau" genannt)
Arduino Uno; mit Seeed Grove - Baseborad und den "normalen" Sensoren und Actoren und dem OLED-Display (Anzeige der Zustände der Ein- und Ausgänge)
Sondermodell Arduino Uno mit Adafruit Motortreiber Shield 2.0 und HC05 Bluetooth für mobile Roboter.
Die Funktion beim Uno ist jedoch eingeschränkt, z.B. die Counter. Der Uno hat nur einen Mega hat drei. "Man" könnte die noch dazu dichten, hab ich aber bisher nicht. Der "Umbau" bezieht sich auf Widerstände für die Eingänge. Meine Erfahrungen ist, dass das ft-Modell nahe beim Monitor steht und der Stört sehr stark. Deswegen muss man Widerstände "dazu zuschalten". Entweder man schraubt sie in die ft-Stecker oder halt eleganter man lötet die auf das Adafruit Motortreiber Shield 2.0 mit drauf. Ich hab zusätzlich eine 20pol. Buchse drauf gelötet und kann so das Kabel mit der Buchsenleiste vom alten parallelen PC/C64/Atari... Interface nutzen. Auch hab ich die Bezeichnung so gelassen. M1 ist auch M1, I1 ist E1 usw. .
Ich hab auch eine Anleitung dazu gemacht und ein paar Modelle beschrieben die bisher eingesetzt habe z.B. Ampel mit Auto-Sensor...
Die Modelle laufen nun schon einige Zeit im "Schulbetrieb" (Schulpausenbetrieb) und haben auch schon ein paar Modellschauen, wo Besucher selber programmieren konnten überlebt. Somit sollte das auch bei anderen laufen.
ftduino der eigentliche TX Light.
Ist am weitesten mit der Programmierung.
Jedoch (bisher) kein: I2C, Display, Umschaltung der Eingänge, Counter Reset, Ultraschallsensor (hier nur die fehlende Umschaltung der Eingänge, sollte laufen, habe es aber nicht ausprobiert, weil ich meinen Sensor nicht finde )
Ansonsten sollte der TX Light auf dem ftduino laufen.
Der Arduino / ftduino simuliert einen TX Controller am PC und dem RoboPro.
Hinweise:
Die Steuerung geht über RoboPro - über USB Kabel und eine Spannungsversorgung.
Einmaliges Aufspielen der Software über die Arduino IDE.
Speziell Arduino Uno:
-Einschalten: 1. Spannungsversorgung, dann 2. der USB Anschluss
-Ausschalten 1. der USB Anschluss dann 2. die Spannungsversorgung
Bisher getestet unter der RoboPro Version 3.1.2. (CD-TX Explorer) oder der neusten, Stand 5.4.20.
Mein Projekt habe ich von:
https://github.com/mr-kubikus/fx1-arduino-parser
übernommen. Ich habe also nicht alles neu gemacht.
Die ftduino - Variante hat eigentlich nur noch die Kommunikation mit dem PC gemeinsam.
Insgesamt ist es immer noch nicht 100% fehlerfrei, aber so -ohne- Abstürze (bei mir) lauffähig.
Ich denke es ist nun sinnvoll, wenn ein paar Leute das mal bei sich testen würde. Insgesammt währe es Schade wenn es mit mir einschlafen würde.
Da steckt ja viel Arbeit drin.
Ich denke das wir mal mit der ftduino - Version anfangen. Oder doch lieber mit der Arduino - Variante?
Es soll zumindest so sein, dass ich nicht mit so vielen Meldungen bombardiert werde.
Bei dem ftduino TX Light Programm ist meine Beschreibung im Programm besser und man hat halt keinen weiteren Umbau.
Zudem sollte es am besten erst mal über E-Mail laufen. Danach kann es ja über das Forum laufen.
Hier nun sofort alles online zustellen und auch Anfängerfragen bis ins letzte Detail hinien zu klären, geht (denke ich) über meine Möglichkeiten hinaus. Deswegen besser diesen Weg.
Also wer hätte Interesse und einen ftduino?
Mit freundlichen Grüßen
fishfriend
Holger Howey
PS Bitte RoboPro Version angeben. Etwas Erfahrung bei der Arduino IDE sollte auch vorhanden sein.
PPS
Um es noch mal klarzustellen. Der TX-Light ist kein 100% Ersatz für einen fischertechnik TX oder TXT Controller.
Es ist auch -nicht- als Konkurrenz gedacht. Es sollten die vorhandenen Arduino Unos, an der Schule, für die nicht mehr
vorhandenen ft Interfaces genutzt werden. Auch als Grund war fischertechnik als DIE Alternative zu Scratch, Arduino IDE und ("Baller-") Spielen einzusetzen. Das Ganze dann ab Klasse 5. Ziel war es erst nur Eingänge und Ausgänge zu steuern und damals "vorhandene" ft Modell anzusteuern.
Ich habe dann nur noch meine ft Modelle benutzt.
PPPS
Es kann ja sein, dass z.B. 4 Counter bei der und der RoboPro Version nicht laufen. Das kann es ja dazu führen, dass z.B. Counter rausgenommen
werden. Ob und wie weit nun z.B. I2C Unterstützung mit reinkommt, kann das ja dann auch von anderen Programmieren kommen. Mal schauen.
Also es funktioniert. Man kann einen Arduino oder ftduino mit RoboPro steuern.
Ja, ich werde nun mal ein paar Tester hiermit suchen.
-Aber- erst noch mal ein paar Fragen an euch:
Counter<> Genauigkeit
Die Frage ist: Wie genau soll ein "Counter" sein?
Hintergrund: Man kann im ftduino einen Encodermotor eine Strecke (Impulse) fahren lassen.
Nun läuft der Motor jedoch nach, egal ob mit oder ohne Bremse. Die ftduino.h macht leider keinen Unterschied bei Countern und Distanz.
Ich vermute das es ehr von der Arduino-Programmierung kommt als von ft.
Nun hab ich das Problem, wenn ich von RoboPro eine Distanz vom ftduino fahren lasse, wird scheinbar beim ftduino Counter
der zufahrende Wert (z.B. 10) von Null abgezogen und dann der Counter bis 0 gefahren und dann gestoppt (+ ein paar Impulse).
Somit steht er dann z.B. auf 11.
Somit driftet die wirkliche Position, weil ja beim nächsten fahren der Wert ja wieder von Null aus gemessen.
Auch geht der "mitzählende" Counter verloren.
Es ist die Frage ob ich mir die Arbeit machen soll, einen extra mitzählenden Counter zu programmieren.
Wie oft braucht man so etwas bei einem ft-Modell, wo sowieso ein Nullpunkt-Taster da ist?
Der Aufwand ist momentan gerade etwas hoch. Oder doch? (11 zu 190 bei einer Motor Umdrehung)
Art der Eingänge
Es ist die Frage ob man "Anfängern" zumuten kann, die Eingänge per Arduino IDE umzustellen.
Hintergrund: Man hat 8 Eingänge die einen (digitalen) Taster oder ein Widerstand einlesen und mit:
ftduino.input_set_mode(Ftduino::I1, Ftduino:: SWITCH);
ftduino.input_set_mode(Ftduino::I1, Ftduino:: RESISTANCE);
umgestellt werden.
Die Auswertung der Umschaltung ist bisher nicht drin. Für -mich- ist das nun kein großes Problem.
Ich hatte zwischenzeitlich einfach die letzten beiden Eingänge beiden als Widerstand laufen lassen.
Nur tauchen dann bei dem Interfacetest von RoboPro bei unbeschalteten Eingängen manchmal Werte auf und die Taster sind auf 1.
Alles in allem ist es ja nur ein TX "Light" Interface. Somit laufen nur die überwiegende Sachen.
Ich denke das so 95% der "normalen" ft Modelle laufen (wenn nicht noch mehr).
Ich habe aber nicht alle fertigen Programme getestet - auch weil ich nicht die CDs von allen Kästen und damit die Programme habe
bzw. weil ich nicht alle Modelle aufbauen und testen kann.
Die nächste Sache ist die Anleitung. Ich muss die noch mal überarbeiten.
Es sind momentan zwei (und die noch gemischt), wobei ich mehrere Bereiche habe u.a.:
Arduino Uno
Arduino Uno; ohne alles weitere; Steuerung "nur" von z.B. LEDs... über RoboPro (sehr Gut zum Lernen mit Elektronik) (kleine Sachen auch ohne Netzteil)
Arduino Uno; mit Motortreiber (H-Brücken); (teilweise mit ft nutzbar)
Arduino Uno; mit Adafruit Motortreiber Shield 2.0; (Motor, Lampen,... auch fremde Motoren mit viel höherer Spannung nutzbar)
Arduino Uno; mit Adafruit Motortreiber Shield 2.0; mit Eingangsbeschaltung (Eigentlich erst ab hier voll mit ft nutzbar) -- ("Umbau" genannt)
Arduino Uno; mit Seeed Grove - Baseborad und den "normalen" Sensoren und Actoren und dem OLED-Display (Anzeige der Zustände der Ein- und Ausgänge)
Sondermodell Arduino Uno mit Adafruit Motortreiber Shield 2.0 und HC05 Bluetooth für mobile Roboter.
Die Funktion beim Uno ist jedoch eingeschränkt, z.B. die Counter. Der Uno hat nur einen Mega hat drei. "Man" könnte die noch dazu dichten, hab ich aber bisher nicht. Der "Umbau" bezieht sich auf Widerstände für die Eingänge. Meine Erfahrungen ist, dass das ft-Modell nahe beim Monitor steht und der Stört sehr stark. Deswegen muss man Widerstände "dazu zuschalten". Entweder man schraubt sie in die ft-Stecker oder halt eleganter man lötet die auf das Adafruit Motortreiber Shield 2.0 mit drauf. Ich hab zusätzlich eine 20pol. Buchse drauf gelötet und kann so das Kabel mit der Buchsenleiste vom alten parallelen PC/C64/Atari... Interface nutzen. Auch hab ich die Bezeichnung so gelassen. M1 ist auch M1, I1 ist E1 usw. .
Ich hab auch eine Anleitung dazu gemacht und ein paar Modelle beschrieben die bisher eingesetzt habe z.B. Ampel mit Auto-Sensor...
Die Modelle laufen nun schon einige Zeit im "Schulbetrieb" (Schulpausenbetrieb) und haben auch schon ein paar Modellschauen, wo Besucher selber programmieren konnten überlebt. Somit sollte das auch bei anderen laufen.
ftduino der eigentliche TX Light.
Ist am weitesten mit der Programmierung.
Jedoch (bisher) kein: I2C, Display, Umschaltung der Eingänge, Counter Reset, Ultraschallsensor (hier nur die fehlende Umschaltung der Eingänge, sollte laufen, habe es aber nicht ausprobiert, weil ich meinen Sensor nicht finde )
Ansonsten sollte der TX Light auf dem ftduino laufen.
Der Arduino / ftduino simuliert einen TX Controller am PC und dem RoboPro.
Hinweise:
Die Steuerung geht über RoboPro - über USB Kabel und eine Spannungsversorgung.
Einmaliges Aufspielen der Software über die Arduino IDE.
Speziell Arduino Uno:
-Einschalten: 1. Spannungsversorgung, dann 2. der USB Anschluss
-Ausschalten 1. der USB Anschluss dann 2. die Spannungsversorgung
Bisher getestet unter der RoboPro Version 3.1.2. (CD-TX Explorer) oder der neusten, Stand 5.4.20.
Mein Projekt habe ich von:
https://github.com/mr-kubikus/fx1-arduino-parser
übernommen. Ich habe also nicht alles neu gemacht.
Die ftduino - Variante hat eigentlich nur noch die Kommunikation mit dem PC gemeinsam.
Insgesamt ist es immer noch nicht 100% fehlerfrei, aber so -ohne- Abstürze (bei mir) lauffähig.
Ich denke es ist nun sinnvoll, wenn ein paar Leute das mal bei sich testen würde. Insgesammt währe es Schade wenn es mit mir einschlafen würde.
Da steckt ja viel Arbeit drin.
Ich denke das wir mal mit der ftduino - Version anfangen. Oder doch lieber mit der Arduino - Variante?
Es soll zumindest so sein, dass ich nicht mit so vielen Meldungen bombardiert werde.
Bei dem ftduino TX Light Programm ist meine Beschreibung im Programm besser und man hat halt keinen weiteren Umbau.
Zudem sollte es am besten erst mal über E-Mail laufen. Danach kann es ja über das Forum laufen.
Hier nun sofort alles online zustellen und auch Anfängerfragen bis ins letzte Detail hinien zu klären, geht (denke ich) über meine Möglichkeiten hinaus. Deswegen besser diesen Weg.
Also wer hätte Interesse und einen ftduino?
Mit freundlichen Grüßen
fishfriend
Holger Howey
PS Bitte RoboPro Version angeben. Etwas Erfahrung bei der Arduino IDE sollte auch vorhanden sein.
PPS
Um es noch mal klarzustellen. Der TX-Light ist kein 100% Ersatz für einen fischertechnik TX oder TXT Controller.
Es ist auch -nicht- als Konkurrenz gedacht. Es sollten die vorhandenen Arduino Unos, an der Schule, für die nicht mehr
vorhandenen ft Interfaces genutzt werden. Auch als Grund war fischertechnik als DIE Alternative zu Scratch, Arduino IDE und ("Baller-") Spielen einzusetzen. Das Ganze dann ab Klasse 5. Ziel war es erst nur Eingänge und Ausgänge zu steuern und damals "vorhandene" ft Modell anzusteuern.
Ich habe dann nur noch meine ft Modelle benutzt.
PPPS
Es kann ja sein, dass z.B. 4 Counter bei der und der RoboPro Version nicht laufen. Das kann es ja dazu führen, dass z.B. Counter rausgenommen
werden. Ob und wie weit nun z.B. I2C Unterstützung mit reinkommt, kann das ja dann auch von anderen Programmieren kommen. Mal schauen.