Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Hallo Kids, hier ist eine Ecke extra für euch!
Ihr könnt hier Fragen aller Art stellen, die wir euch gerne so schnell wie möglich beantworten.
Ihr dürft hier aber auch gerne eure Modelle einfach mal anderen Fischertechnikern vorstellen.
Mahlzeit
Beiträge: 20
Registriert: 06 Sep 2020, 10:40

Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von Mahlzeit » 02 Okt 2020, 09:18

Hallo zusammen!

Ich möchte heute gerne über ein kleines Projekt berichten, dass ich in der letzten Woche durchgeführt habe und da es hier nicht mehr um Bluetooth geht, habe ich mal ein neues Thema gestartet.


Mein Kumpel hat einen Lego EV3 Brick mitgebracht und wir wollten dann mal schauen wie sich ft TXT Controller, Lego EV3 Brick und ein Computer im Vergleich bei der Umsetzung einer einfachen Programmierung schlagen.

Der Text ist recht lang geworden, daher hier die Kurzfassung: der TXT Controller ist im Vergleich deutlich schneller als ich angenommen hätte.



Testaufbau:
Auf dem ft TXT läuft natürlich die CFW 0.9.4.
Auf dem Lego Ev3 Brick habe ich mit EV3dev das Gegenstück zur FT CFW installiert, sodass hier jetzt Python3 und Debian Linux läuft.
Der EV3 Brick wurde für diesen Test zunächst von 300 MHZ auf 456MHz übertaktet (das laut Datenblatt spezifizierte Maximum für diesen Prozessor), um ein bisschen näher an den 600 MHZ starken TXT Controller zu kommen.
Zuletzt kommt noch ein PC zum Einsatz mit Windows 10 und Pycharm.

Als Benchmark habe ich ein Skript mit Rechenaufgaben aus dem Bereich LinA gefunden, dass ich gut für die beiden Controller anpassen konnte und dass zunächst erstmal vollkommen ohne Systemeigenheiten wie Motorklassen etc. auskommt. Nach der Berechnung gibt das Skript die benötigte Zeit für die Berechnungen per print aus:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

# Roughly based on: http://stackoverflow.com/questions/11443302/compiling-numpy-with-openblas-integration
# and adapted after: https://gist.github.com/SwimmingTiger/7dbea709d052a127135569d9af950b20

import numpy as np
from time import time

# Let's take the randomness out of random numbers (for reproducibility)
np.random.seed(0)

size = 128
A, B = np.random.random((size * 2, size * 2)), np.random.random((size * 2, size * 2))
C, D = np.random.random((size * 256,)), np.random.random((size * 256,))
E = np.random.random((size, size))
F = np.random.random((size, size))
F = np.dot(F, F.T)
G = np.random.random((size, size))

# Matrix multiplication
N = 20
t = time()
for i in range(N):
    np.dot(A, B)
delta = time() - t
print('Dotted two %dx%d matrices in %0.2f s.' % (size, size, delta / N))
del A, B

# Vector multiplication
N = 5000
t = time()
for i in range(N):
    np.dot(C, D)
delta = time() - t
print('Dotted two vectors of length %d in %0.2f ms.' % (size * 128, 1e3 * delta / N))
del C, D

# Singular Value Decomposition (SVD)
N = 3
t = time()
for i in range(N):
    np.linalg.svd(E, full_matrices = False)
delta = time() - t
print("SVD of a %dx%d matrix in %0.2f s." % (size / 2, size / 4, delta / N))
del E

# Cholesky Decomposition
N = 3
t = time()
for i in range(N):
    np.linalg.cholesky(F)
delta = time() - t
print("Cholesky decomposition of a %dx%d matrix in %0.2f s." % (size / 2, size / 2, delta / N))

# Eigendecomposition
t = time()
for i in range(N):
    np.linalg.eig(G)
delta = time() - t
print("Eigendecomposition of a %dx%d matrix in %0.2f s." % (size / 2, size / 2, delta / N))

print('')

Und hier die Ergebnisse:

Ergebnis Computer Intel Pentium:

Dotted two 128x128 matrices in 0.00 s.
Dotted two vectors of length 16384 in 0.02 ms.
SVD of a 64x32 matrix in 0.01 s.
Cholesky decomposition of a 64x64 matrix in 0.00 s.
Eigendecomposition of a 64x64 matrix in 0.02 s.


Ergebnis FT TXT Controller:

$ python3 bench.py
Dotted two 128x128 matrices in 1.39 s.
Dotted two vectors of length 16384 in 2.26 ms.
SVD of a 64x32 matrix in 1.09 s.
Cholesky decomposition of a 64x64 matrix in 0.04 s.
Eigendecomposition of a 64x64 matrix in 1.97 s.


Ergebnis EV3 Brick Lego, übertaktet:

robot@ev3dev:~/bench$ python3 bench.py
Dotted two 128x128 matrices in 10.58 s.
Dotted two vectors of length 16384 in 23.06 ms.
SVD of a 64x32 matrix in 8.23 s.
Cholesky decomposition of a 64x64 matrix in 0.25 s.
Eigendecomposition of a 64x64 matrix in 17.92 s.

Wie man sieht ist dieser Test zu wenig fordernd um für den PC interessante Ergebnisse zu produzieren, doch für die beiden Controller war er schon eine Herausforderung und die Ausführung des Skripts dauerte auf dem Lego Gerät etwa 15 Minuten. Fazit TXT vs EV3 Brick:
Der TXT benötigt für die Berechnungen nur etwa 10% der Zeit die der EV3 Brick benötigt.

Ich fand das schon ziemlich beachtlich doch mein Kumpel war nicht wirklich überzeugt. Schließlich ist dieser Test ja noch weit von einem realen Setting entfernt und testet zunächst erstmal nur numpy. Diese zutreffende Kritik stimmt aber sicher nur zum (überwiegenden) Teil. Mit dem hier verwendeten numpy Modul könnte man z.B. einen Kalman Filter für den ft-Gyro Sensor umsetzen, was doch eigentlich sehr nützlich wäre, sodass es auf dessen Leistungsfähigkeit schon ankommen könnte. Wir haben uns dennoch lieber einen Test überlegt, der etwas näher an einer konkreten Anwendung liegt, z.B. einer Situation wie sie bei einem Roboterwettkampf vorliegen könnte:

Mit einem Ultraschallsensor und 2 Motoren wird eine einfache Logik programmiert, die auf Gegenstände die weit entfernt sind zunächst zusteuert, letztlich aber v.a. durch rechtzeitiges Aufstoppen oder Bremsen eine Kollision verhindert. Diese kleine Logikschleife wird 40.000 Mal laufen gelassen und geschaut wie lange die Geräte dafür brauchen, bzw. wie viele Loops die Geräte pro Sekunde schaffen.

Beide Geräte sind dabei möglichst identisch programmiert, und nutzen die jeweils im System vorhandenen großen Motoren + einen US Sensor.

Die Überlegung ist, dass ein Gerät dass in diesem Test mehr Loops pro Sekunde schafft dann auch in einem realen Anwendungsfall z.B. bei Verwendung eines PID Controllers in Verbindung mit 2 Farbsensoren (verb. Linienfolger) oder einem Gyro deutlich schneller bzw. häufiger Korrekturen ausführen könnte. Ein optimales Ergebnis würde demnach theoretisch immer dann vorliegen wenn die loops pro Sekunde mindestens der schnellsten Samplerate des abgefragten Sensors entspräche, wobei schneller auch nicht schadet, letztlich erhält man dann eben alte Sensorwerte.

Auf dem TXT Controller sieht der Testcode so aus:

Code: Alles auswählen

from time import perf_counter
import ftrobopy

txt = ftrobopy.ftrobopy('192.168.178.51')

lMotor = txt.motor(1)
rMotor = txt.motor(2)
ultraschall = txt.ultrasonic(1)
lMotor.setSpeed(0)
rMotor.setSpeed(0)
lMotor.setDistance(0)
rMotor.setDistance(0)
geschw = 0
LOOPS = 40000
txt.updateWait()

startTime = perf_counter()

for a in range(0,LOOPS):
    if ultraschall.distance() >= 80:
        geschw = 508
    elif ultraschall.distance() >=32:
        geschw = 10 * ultraschall.distance()
    elif ultraschall.distance() >= 20:
        geschw = 260
    elif ultraschall.distance() >= 15:
        geschw = 180
    elif ultraschall.distance() >= 8:
        geschw = 0
    elif ultraschall.distance() >= 4:
        geschw = -350
    else:
        geschw = 0
    if geschw > 507:
        geschw = 508
    else:
        pass
    lMotor.setSpeed(geschw)
    rMotor.setSpeed(geschw)

endTime = perf_counter()

lMotor.stop()
rMotor.stop()

print("Loops pro Sekunde: " + str(round(LOOPS / (endTime - startTime))))
print("Benoetigte Zeit fuer " + str(LOOPS) + " Loops betraegt " + str(round((endTime - startTime),2))+ " Sekunden")

Auf dem Lego EV3 Brick sieht es dann so aus:

Code: Alles auswählen

from time import sleep
from time import perf_counter 
#from ev3dev2.motor import *
#from ev3dev2.sensor.lego import UltrasonicSensor
from ev3fast import *


lMotor = LargeMotor('outA')
rMotor = LargeMotor('outB')
us = UltrasonicSensor()
us.mode='US-DIST-CM'



geschw = 0
LOOPS = 40000
time.sleep(0.5)

startTime = perf_counter()

for a in range(0,LOOPS):
    if us.distance_centimeters >= 80:
        geschw = 1000
    elif us.distance_centimeters >=32:
        geschw = 20 * us.distance_centimeters
    elif us.distance_centimeters >= 20:
        geschw = 510
    elif us.distance_centimeters >= 15:
        geschw = 350
    elif us.distance_centimeters >= 8:
        geschw = 0
    elif us.distance_centimeters >= 4:
        geschw = -300
    else:
        geschw = 0
    if geschw > 1000:
        geschw = 1000
    else:
        pass
    lMotor.speed_sp = round(geschw)
    rMotor.speed_sp = round(geschw)
    lMotor.run_forever()
    rMotor.run_forever()

endTime = perf_counter()

lMotor.stop()
rMotor.stop()

print("Loops pro Sekunde: " + str(round(LOOPS / (endTime - startTime))))
print("Benoetigte Zeit fuer " + str(LOOPS) + " Loops betraegt " + str(round((endTime - startTime),2))+ " Sekunden")



Und hier wieder die Ergebnisse:
Messung am PC mit dem Txt Controller (online) ferngesteuert:

Connected to TX2013 firmware version 4.6.6
Loops pro Sekunde: 226800
Benoetigte Zeit fuer 40000 Loops betraegt 0.18 Sekunden


Messung am TXT Controller direct mode:

$ python bench2.py
Connected to TXT direct firmware version not detected
Loops pro Sekunde: 2663
Benoetigte Zeit fuer 40000 Loops betraegt 15.02 Sekunden


Messung mit EV3dev-lang unter Verwendung der orig. Python Bibliothek:

robot@ev3dev:~/bench$ python3 bench2.py
Loops pro Sekunde: 57
Benoetigte Zeit fuer 40000 Loops betraegt 703.8 Sekunden


Messung mit EV3dev-lang-python-fast, eines alternativen Python Moduls für EV3dev:

robot@ev3dev:~/bench$ python3 bench2.py
Loops pro Sekunde: 348
Benoetigte Zeit fuer 40000 Loops betraegt 114.81 Sekunden


und zuletzt noch EV3dev mit RPYC ausgestattet und dann vom PC ferngesteuert, in der Hoffnung ein Ergebnis analog zum Ftrobopy online Modus zu bekommen:

Loops pro Sekunde: 5 (!)

Die benoetigte Zeit fuer 40000 Loops habe ich dann bei zu erwartenden 2h / 8000s nicht mehr getestet..


Fazit: Die Ergebnisse sind wieder beachtlich. Der Txt Controller schafft mind. 7x mehr Loops als der EV3 Brick, je nach Szenario aber auch deutlich mehr. Es scheint außerdem, dass die Möglichkeiten nochmals deutlich gesteigert werden können wenn das Programm im online modus über den PC läuft. Dass das nicht selbstverständlich ist, zeigt der Vergleich mit RPYC auf dem Lego Brick.

Mein Kumpel war ziemlich überrascht und wir haben überlegt wie diese Ergebnisse zu erklären sind. Ich kann nur vermuten, dass die Ergebnisse nicht ausschließlich mit dem größeren Speicher und den 144 Mhz Taktdifferenz zu erklären sind die der Txt dem EV3 vorraus hat, sondern dass auch bei FTrobopy, CFW, ft etc. schon bei der Implementierung gute Arbeit geleistet wurde um die knappen Ressourcen des Controllers einzusetzen.

Im Anhang noch ein Bild vom Testaufbau nebst herbeigerufenen Schiedsrichtern.

Ich spare jetzt bis Weihnachten auf den tx-pi und dann will ich mal gucken wie dieser sich schlägt. Außerdem würde ich dann mal testen wie sich die Geräte schlagen wenn im Online Modus statt eines PCs ein aktuelles Handy für die Berechnungen eingesetzt wird.


VG, Dennis
Dateianhänge
ftpi.jpg
ftpi.jpg (107.42 KiB) 8657 mal betrachtet
Zuletzt geändert von Mahlzeit am 02 Okt 2020, 11:08, insgesamt 3-mal geändert.

Benutzeravatar
The Rob
Moderator
Beiträge: 968
Registriert: 03 Dez 2015, 12:54

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von The Rob » 02 Okt 2020, 09:29

Klasse Test!
Habt ihr - passend zur zweiten Messung - auch noch den Praxistest gemacht, ob man beim tatsächlichen abfahren einer Linie einen Unterschied erkennt?

Benutzeravatar
PHabermehl
Beiträge: 2429
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von PHabermehl » 03 Okt 2020, 00:32

Mahlzeit hat geschrieben:
02 Okt 2020, 09:18
Ich spare jetzt bis Weihnachten auf den tx-pi und dann will ich mal gucken wie dieser sich schlägt.
Na Mahlzeit...

Hallo Dennis,
der TX-Pi hat natürlich ein Vielfaches an Leistung im Vergleich zum TXT. Und ich sag mal, das TX-Pi-Projekt würde sicherlich auch von Dir profitieren.
Aber der TX-Pi hat ja zunächst mal den Nachteil, dass er nativ keine ft-IO hat. Auch der I2C-Bus und die RPi-I/O sind ohne zwischengeschaltetes Breakout oder den TX-Pi-Hat nicht zu erreichen, zumindest wenn man den TX-Pi (empfehlenswerterweise) im Gehäuse hat.

Wenn Du ft-Hardware ansteruern willst, brauchst Du zwingend noch irgendein I/O-Modul. Das können alte ft-Interfaces sein, die über USB angeschlossen werden, oder ansonsten allen Mögliche, was Du Dir über BT oder WLAN ansteuerst. Der vorgenannte HAT bietet natürlich auch entsprechende Anschlüsse.

Sehr praktikabel ist auch die Kombination aus TX-Pi und ftDuino. Aber das bringt mich auf den Gedanken, ob denn nicht eher der ftDuino 'was für Dich wäre? Natürlich bietet der weniger Ressourcen, aber - als Arduino softwareseitig natürlich unendliche Möglichkeiten.

Viele Grüße
Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

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

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von MasterOfGizmo » 03 Okt 2020, 12:21

Wie schon neulich geschrieben ist Lego aus dem Rennen eh ausgestiegen. Der neueste Baukasten "Robot Inventor 51515" setzt auf einen sehr viel einfacheren Controller aber dafür intelligentere Sensoren und Aktoren. Der Abstand des TXT wächst also an der Stelle. Gleichzeitig wird der TXT vom Raspberry-Pi im gleichen Maße abgehängt. Auch da liegt je nach Benchmark ein Faktor 10-50 dazwischen.

Was ich aber immer viel beeindruckender finde ist, was die Leute aus den Geräten rausholen. Und da macht der Lego-Gemeinde niemand was vor. Mir fällt kein Beispiel ein, wo der TXT seinen Vorteil auch tatsächlich mal ausspielen konnte.

Und die interessante Frage, die fischertechnik sich nun stellen muss ist: Wie soll das weitergehen? Wenn der TXT einen Nachfolger bekommt, worauf ist der dann ausgerichtet? Mehr CPU-Power und mehr Speicher? Wozu? Das nutzt beim TXT schon niemand. Oder wie Lego sogar reduzieren und sich auf stabilen Betrieb und Basisfunktionen konzentrieren? Ich bin gespannt, zu welcher Antwort sie kommen ...
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Lars
Beiträge: 564
Registriert: 25 Okt 2016, 21:50

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von Lars » 03 Okt 2020, 14:31

Hallo Till,
MasterOfGizmo hat geschrieben:
03 Okt 2020, 12:21
Und die interessante Frage, die fischertechnik sich nun stellen muss ist: Wie soll das weitergehen? Wenn der TXT einen Nachfolger bekommt, worauf ist der dann ausgerichtet? Mehr CPU-Power und mehr Speicher? Wozu? Das nutzt beim TXT schon niemand. Oder wie Lego sogar reduzieren und sich auf stabilen Betrieb und Basisfunktionen konzentrieren? Ich bin gespannt, zu welcher Antwort sie kommen ...
Ein Nachfolger sollte die Konstruktionsfehler des TXT beheben wie beispielsweise fehlender Anlauf bei Stromversorgung. An deren Stelle würde ich mich aber einfach bei Arduino einhängen und einfach gute Gehäuse und kaskadierbare Hats für Aktoren und Sensoren sowie Displays herausbringen. Den Weg der Standards sollten sie aber beibehalten und beispielsweise I²C und SPI vernünftig herausführen.

Mit freundlichen Grüßen
Lars

Karl
Beiträge: 2212
Registriert: 24 Sep 2016, 17:28

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von Karl » 03 Okt 2020, 15:32

Ich für meinen Teil denke immer daß der Raspberry eine gute Wahl wäre, glaube der neuere Typ hat 8 GByte Ram.
Darauf könnte man für stationäre Anwendungen gleich ein Betriebssystem, ein angepaßtes Robo-Pro und evtl. noch
andere Programmiersprachen darauf einrichten, z. B. für den Arduino und Konsorten weiterhin, Ftduino, Micro:Bit.
Für mobile Anwendungen wäre der Raspberry-Pi-Zero doch auch geeignet, ist doch eine kleinere sparsame Version des
Standard-Pi.
Programmieren des "Zero" über den "Stations-Pi". Ob beim "Zero" die Kamera auch funktionert ?
Bräuchte man oder frau nicht mehr unbedingt den PC, nur noch Bildschirm, Tastatur, Maus oder andere nützliche
USB-Eingabegeräte. Ausgaben über evtl. mehrere Schnittstellen, I2C, CAN, SPI, Tx-Rx, oder
SonstIrgendWasFischertechnikBrauchbares.

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

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von MasterOfGizmo » 03 Okt 2020, 16:43

Lars hat geschrieben:
03 Okt 2020, 14:31
An deren Stelle würde ich mich aber einfach bei Arduino einhängen und einfach gute Gehäuse und kaskadierbare Hats für Aktoren und Sensoren sowie Displays herausbringen. Den Weg der Standards sollten sie aber beibehalten und beispielsweise I²C und SPI vernünftig herausführen.
Ich denke nicht, dass das deren Welt ist. Wenn sie beim Arduino-Shield-Standard bleiben hiesse das auch ungeschützte Ein- und Ausgänge usw. Das ist in der 9V-Welt der fischertechnik m.E. nicht handhabbar. Alternativ führen sie ein eigenes Stapelsystem ein. Dann sind wieder alle unzufrieden, dass es inkompatibel zum Original-Arduino ist. Ich glaube ich der Tat nicht, dass sie den Weg gehen werden.

Tatsächlich habe ich ja auch mal genau darüber nachgedacht und bin vor allem aus Kostengründen am Ende beim wesentlich einfacheren und robusteren jetzigen ftDuino-Design gelandet. Mehr Gehäuse, mehr Stecker, mehr Einzelteile machen die Sache auch für ft teurer.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

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

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von MasterOfGizmo » 03 Okt 2020, 16:56

Karl hat geschrieben:
03 Okt 2020, 15:32
Ich für meinen Teil denke immer daß der Raspberry eine gute Wahl wäre.
Und der unterscheidet sich dann in der "fischertechnik-Variante" wodurch vom TXT? Einfach nur schneller und mehr RAM? Das würde in der Robo-Pro-Welt für den User welchen Vorteil haben?

Rasp-Pi macht Sinn, wenn man auch wirklich in die Rasp-Pi-Welt will. Wenn man sich mit einem Linux auseinandersetzen will und Sachen wie Bilderkennung usw machen will. Die ganze Machine-Learning-Sache wird damit auf einmal möglich. Aber ist das der Markt von ft? Im Education/Schulbereich sicher. Allein deshalb weil Arduino und Raspberry und Co ihren Weg in die Klassenzimmer und Lehrpläne längst gefunden haben. Aber im Kinderzimmer? Ja, es gibt Kinder, die mit Arduino und sogar Raspberry-Pi umgehen können. Aber das ist nicht der Normalfall. Als Spielzeughersteller willst Du ja die breite Masse als Kunde und nicht nur die Spezialisten.

Das ist dann eher was für einen Mittelsmann, der sich auf fischertechnik und Education spezialisiert. Das wäre eine Schiene, über die ft in so eine Richtung gehen könnte. Aber das braucht jemanden, der zwischen schwarzwälder Mittelständler und Maker-Community übersetzt. Die sprechen einfach nicht die gleiche Sprache.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Lars
Beiträge: 564
Registriert: 25 Okt 2016, 21:50

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von Lars » 03 Okt 2020, 17:01

Hallo Till,
MasterOfGizmo hat geschrieben:
03 Okt 2020, 16:43
Lars hat geschrieben:
03 Okt 2020, 14:31
An deren Stelle würde ich mich aber einfach bei Arduino einhängen und einfach gute Gehäuse und kaskadierbare Hats für Aktoren und Sensoren sowie Displays herausbringen. Den Weg der Standards sollten sie aber beibehalten und beispielsweise I²C und SPI vernünftig herausführen.
Ich denke nicht, dass das deren Welt ist. Wenn sie beim Arduino-Shield-Standard bleiben hiesse das auch ungeschützte Ein- und Ausgänge usw. Das ist in der 9V-Welt der fischertechnik m.E. nicht handhabbar.
an sich klar, aber mit den Standards meinte ich auch nicht typische Hat-Platinen. Da bin ich stillschweigend davon ausgegangen, daß es da wie bei Calliope und MicroBit immer Adapter geben wird, der die ft-Welt mit dem jeweiligen Controller verbindet.

MasterOfGizmo hat geschrieben:
03 Okt 2020, 16:43
Tatsächlich habe ich ja auch mal genau darüber nachgedacht und bin vor allem aus Kostengründen am Ende beim wesentlich einfacheren und robusteren jetzigen ftDuino-Design gelandet. Mehr Gehäuse, mehr Stecker, mehr Einzelteile machen die Sache auch für ft teurer.
Der ftDuino könnte von seiner Design-Qualität und auch der Qualität der Anleitung her von ft selbst stammen - großes Lob dafür von mir.

Es fragt sich, über welche Entwicklerkapazitäten ft eigentlich verfügt bzw. welche sie einsetzen wollen. So elegant der ftDuino sozusagen als ft-feste Arduino-Hardware ist, so wenig genügt die Arduino IDE den didaktischen Ansprüchen der von ft bedienten Märkte. Da bräuchte ft vermutlich einen "didaktischen Aufsatz", der entweder transparent oder verdeckt den Code erzeugt und aufspielt. Hätten sie sowas, müßten sie vermutlich nur alle vier oder fünf Jahre den zugrundeliegenden Arduino aktualisieren.

Mit freundlichen Grüßen
Lars

Benutzeravatar
PHabermehl
Beiträge: 2429
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von PHabermehl » 03 Okt 2020, 17:04

MasterOfGizmo hat geschrieben:
03 Okt 2020, 16:56
Karl hat geschrieben:
03 Okt 2020, 15:32
Ich für meinen Teil denke immer daß der Raspberry eine gute Wahl wäre.
Das ist dann eher was für einen Mittelsmann, der sich auf fischertechnik und Education spezialisiert. Das wäre eine Schiene, über die ft in so eine Richtung gehen könnte. Aber das braucht jemanden, der zwischen schwarzwälder Mittelständler und Maker-Community übersetzt. Die sprechen einfach nicht die gleiche Sprache.
Den Gedanken hatte ich auch schon. Scheint ein gut Teil Russisches Roulette zu sein. Aber Du gehst doch mit Deinen "Produkten" genau in die Richtung....
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

Karl
Beiträge: 2212
Registriert: 24 Sep 2016, 17:28

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von Karl » 03 Okt 2020, 17:23

Hallo,
meine Meinung, prinzipiell wäre der TXT mit seinem Arm-Prozessor zu mehr fähig oder vermisse ich etwas ?
Mir scheint es ist mehr eine "Krücke" der damaligen Entwicklung geworden.
Der hat doch sicherlich mehr Power als nur die wenigen Ausgänge, Eingänge, die Zählereingänge und seinen
inneren Müll zu verwalten.
Per Programmierung am PC und Übertragung der Daten zu ihm bekommt er ja auch nicht die Bildchen der
Robo-Pro zum Abspielen eingespielt, soweit nicht explizit vom "Programmierer" gewünscht.

Lars
Beiträge: 564
Registriert: 25 Okt 2016, 21:50

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von Lars » 03 Okt 2020, 18:58

Hallo Karl,
Karl hat geschrieben:
03 Okt 2020, 17:23
meine Meinung, prinzipiell wäre der TXT mit seinem Arm-Prozessor zu mehr fähig oder vermisse ich etwas ?
Mir scheint es ist mehr eine "Krücke" der damaligen Entwicklung geworden.
als Krücke würde ich ihn nicht bezeichnen, zumal er in Wirklichkeit aus zwei Controllern besteht: Einem für die zeitgerechte "Bedienung" der Ein- und Ausgänge (ARM Cortex M3) und ein leistungsfähigerer Prozessor (ARM Cortex A8) für Touchscreen, USB und Bluetooth, WLAN. Der spielt dem "Kleinen" ggfs. auch eine neue Firmware zu.

Mit freundlichen Grüßen
Lars

Mahlzeit
Beiträge: 20
Registriert: 06 Sep 2020, 10:40

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von Mahlzeit » 04 Okt 2020, 13:58

The Rob hat geschrieben:
02 Okt 2020, 09:29
Habt ihr - passend zur zweiten Messung - auch noch den Praxistest gemacht, ob man beim tatsächlichen abfahren einer Linie einen Unterschied erkennt?
Bisher noch nicht. Mein Kumpel hatte nur den US-Sensor mitgebracht und um zu zeigen, dass es auf die Anzahl der Loops auch wirklich ankommen kann taugt der eher nicht. Ein gutes Testsetup wären 2 Farbsensoren mit 2 Motoren pro Modell und anstatt wie normal zu versuchen mit nur einem Sensor einen gewissen Wert zu erreichen um so der Spurkante zu folgen würde man dann stattdessen nur den Fehler zwischen den beiden Sensoren betrachten. Also so:

Code: Alles auswählen

import ftrobopy
import time
txt = ftrobopy.ftrobopy('auto')  # connect to txt

# i/o setup
lMotor = txt.motor(1)
rMotor = txt.motor(2)
lSensor = txt.colorsensor(1)
rSensor = txt.colorsensor(2)

# set constants
LOOPS = 40000

startTime = time.time()

#start test loops

for a in range(0,LOOPS):
  valueL = lSensor.farbsensor.value()
  valueR = rSensor.farbsensor.value()
  totalL = (valueL[0] + valueL[1] + valueL[2])
  totalR = (valueR[0] + valueR[1] + valueR[2])
  error = totalL - totalR
  lMotor.setspeed(300 + error)
  rMotor.setspeed(300 - error)
endTime = time.time()
print("Benoetigte Zeit: ", (startTime - endTime))
Ich habe das noch nie gemacht aber theoretisch wenn bei diesem Programm die Anzahl der Loops hoch genug ist, müsste der Roboter richtig sanft, ohne sichtbare Korrekturen fahren können. Ich möchte das gerne bald mit "FT-vs-Lego" testen. Nach den Herbstferien frage ich mal rum wer von meinen Freunden noch was daheim hat, wenn ich 2 Farbsensoren für Lego auftreiben kann dann reiche ich das auf jeden Fall nach.

MasterOfGizmo hat geschrieben:
03 Okt 2020, 12:21
Wie schon neulich geschrieben ist Lego aus dem Rennen eh ausgestiegen. Der neueste Baukasten "Robot Inventor 51515" setzt auf einen sehr viel einfacheren Controller aber dafür intelligentere Sensoren und Aktoren.

Was ich aber immer viel beeindruckender finde ist, was die Leute aus den Geräten rausholen. Und da macht der Lego-Gemeinde niemand was vor. Mir fällt kein Beispiel ein, wo der TXT seinen Vorteil auch tatsächlich mal ausspielen konnte.

Und die interessante Frage, die fischertechnik sich nun stellen muss ist: Wie soll das weitergehen? Wenn der TXT einen Nachfolger bekommt, worauf ist der dann ausgerichtet? Mehr CPU-Power und mehr Speicher? Wozu? Das nutzt beim TXT schon niemand.
Volle Zustimmung, die Lego Bauprojekte die man im Netz im Bereich Robotik finden kann sind wirklich heftig. Ich beschäftige mich damit erst seit kurzem aber da gibt es 6-DOF Arme die man schon fast als Prothese einsetzen könnte und autonome Roboter die durch das ganze Haus fahren können und dabei von allen Räumen Karten in Python anlegen in Form von Listen von Listen. Diese Baupläne und den Code kann man sogar runterladen und ohne eigene Kenntnisse dann selbst mehr oder weniger umsetzen.

Wenn man sich aus diesem Blickwinkel die CFW für den TXT lädt ist man erstmal enttäuscht. Anfangs gibt es hier eigentlich nichts. Der Cubesolver ist ja wegen Inkompatibilität gelöscht und das interessanteste Programm auf der frisch installierten CFW ist wahrscheinlich der portscanner :oops:

Die CFW mit dem TXT ist mächtig, aber dass diese Möglichkeiten jemand nutzt und das dann verfügbar macht für andere scheint selten zu sein. Das meiste scheint nur als "proof-of-concept" zu existieren.

Lego hat natürlich deutlich mehr aktive Nutzer im Bereich Robotik als ft und durch die Lego exclusiven Roboterwettbewerbe wie FLL und WRO ist man als Teilnehmer sicher auch ständig zu Innovation gezwungen was wiederum dann den Weg zurück in die Community findet. Das fehlt bei FT.

Ich fänds schön wenn ft sich da auch mal einkaufen könnte. Ich würde gerne mal an so einem Wettbewerb teilnehmen und habe sogar schon überlegt mir extra dafür Lego zuzulegen.

Das neue Set von Lego finde ich für mich aber nicht so interessant. Keine SD Karte, keine Firmwaremöglichkeiten, kein CPython, keine Entwicklertools oder Schnittstelle. Nur 6 Ports insgesamt für alles. Das ist ein abgeschlossenes System und ob das dann 6DoF Armprothesen und autonome Roboter wie zuvor hergibt ist offen. Dann wurde auch noch der Stecker getauscht, sodass alle alten Komponenten nicht mehr weiterverwendet werden können, das ist echt ärgerlich wenn man zuvor von seinem ersparten ins alte System investiert hat.

Ist denn schon raus, was Lego in Bezug auf das neue Set wirklich vor hat? Sie schreiben ja auf ihrer Seite: " SPIKE Prime bereitet sie [Anm.: die Schüler] außerdem auf einen anspruchsvolleren Lehrplan vor, wenn sie bereit sind, zu MINDSTORMS EV3 aufzusteigen." und Legos Education Verkaufspartner bewerben Spike Prime mit diesen Stufendiagrammen als Zwischenschritt zwischen EV3 und wedo. https://www.gfdb.de/wp-content/uploads/ ... 0x1500.png Bleibt für Legofreunde eventuell also noch die Hoffnung, dass das auch bedeutet, dass es doch noch etwas geben wird, dass den EV3 zukünftig an der Spitze ablösen soll inkl. Linux und co?

PHabermehl hat geschrieben:
03 Okt 2020, 00:32
Aber der TX-Pi hat ja zunächst mal den Nachteil, dass er nativ keine ft-IO hat. Auch der I2C-Bus und die RPi-I/O sind ohne zwischengeschaltetes Breakout oder den TX-Pi-Hat nicht zu erreichen, zumindest wenn man den TX-Pi (empfehlenswerterweise) im Gehäuse hat.

Wenn Du ft-Hardware ansteruern willst, brauchst Du zwingend noch irgendein I/O-Modul.

Sehr praktikabel ist auch die Kombination aus TX-Pi und ftDuino. Aber das bringt mich auf den Gedanken, ob denn nicht eher der ftDuino 'was für Dich wäre?
Hey Peter!
Ich bin da komplett hin- und hergerissen. Die Kombo aus TX-Pi und ftDuino ist wahrscheinlich von den Möglichkeiten her nicht zu toppen. Meine ft Sachen sind aber immer ganz schön schwer, wenn man jetzt den großen ftduino noch als breakout für den TX-Pi nutzt wird das ein ziemlicher Brocken für die ft-Motoren oder? Andererseits hat der fthat natürlich deutlich weniger IO und kostet genauso viel wie der ftduino. Mit Arduino hatte ich noch nie Kontakt. Was könnte man denn mit dem ftduino allein machen was mit dem TXT so nicht ginge?

Lars hat geschrieben:
03 Okt 2020, 14:31
An deren Stelle würde ich mich aber einfach bei Arduino einhängen und einfach gute Gehäuse und kaskadierbare Hats für Aktoren und Sensoren sowie Displays herausbringen.
Vielleicht nicht als Nachfolger aber als Idee: wie wäre es mit einem usb-otg FT breakout fürs Handy mit entsprechender App in den Appstores. Oder statt TXT 2.0 Hardware für FT und i2c Anschlüssen auf Basis eines mod. Handys. Das Handy liefert bereits Wlan, BT, Kamera, Gyrosensoren, Batterie, Touchscreen, Lautsprecher, Mikrofon etc und die Prozessoren laufen ja auch mit Linux und teilw. deutlich über 2GHZ und verfügen wahrscheinlich trotzdem über 1000 Stromsparmodi.

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

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von MasterOfGizmo » 05 Okt 2020, 15:06

Mahlzeit hat geschrieben:
04 Okt 2020, 13:58
Was könnte man denn mit dem ftduino allein machen was mit dem TXT so nicht ginge?
....
wie wäre es mit einem usb-otg FT breakout fürs Handy mit entsprechender App in den Appstores.
Genau das kann der ftDuino z.B. aber der TXT nicht. Siehe: https://harbaum.github.io/ftduino/www/m ... .html#6.17

Die passende App gibt es zwar nicht im App-Store, aber immerhin hier: https://github.com/harbaum/ftduino/rele ... -debug.apk

Ich spiele aber mit dem Gedanken, das deutlich auszubauen. Zur Zeit ist die App nur eine Demo und wer ein Modell steuern will müsste die App anpassen. Die Idee ist, die nötigen Steuerelement auf dem ftDuino zu hinterlegen und die App zeigt da automatisch immer die passende Benutzeroberfläche an. So wie ich es bei ftDuinoBlue auch gemacht habe: http://ftduino.de/blue.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
EstherM
Beiträge: 1466
Registriert: 11 Dez 2011, 21:24

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von EstherM » 05 Okt 2020, 17:47

Hallo zusammen,

was ist denn jetzt die Kaufempfehlung für Mahlzeit: ein TX-Pi, ein ftduino, oder beides?

Wer könnte denn Tipps für Wettbewerbe geben, an denen man auch mit fischertechnik-Robotern teilnehmen kann? Da war doch mal was, wo Familie Fox nur außer Konkurrenz teilnehmen durfte, weil kein Student dabei war, wenn ich mich richtig erinnere.
@Mahlzeit: bist du im "Jugend-forscht"-Alter? Prothesen-Bau ist eventuell eine gute Idee. Technische Innovation zusammen mit gesellschaftlicher Relevanz kommt gut an.

Gruß
Esther

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

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von MasterOfGizmo » 05 Okt 2020, 18:34

Der.Wettbewerb ist der RoboCup Junior:
https://www.robocupgermanopen.de/de/junior

Die Fox's haben m.E. mal bei der Studenten-Version ausser Konkurrenz mitmachen müssen, weil sie eben keine Studenten waren. Aber der Junior Cup ist explizit für Schüler.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von richard.kunze » 05 Okt 2020, 21:05

EstherM hat geschrieben:
05 Okt 2020, 17:47
was ist denn jetzt die Kaufempfehlung für Mahlzeit: ein TX-Pi, ein ftduino, oder beides?
Wenn das Budget für beides reicht natürlich beides :P

Sonst ist meine Empfehlung ein ftduino. Der kann für sich selbst schon einiges, und wenn das nicht reicht kann man immer noch einen PC (per USB für stationäre Modelle oder per Bluetooth-Bridge für mobile Sachen) oder ein (Android-)Smartphone als Hauptrechner dranhängen. Das Smartphone ist dann sogar auch mobil, und bringt gleich noch einen ganzen Sack voll Sensoren mit (Kamera, Kompass, Beschleunigungsmesser, GPS,, ...).

Einziges Problem (bzw die Herausforderung) dabei: Fürs Smartphone müsste man sich die passende Software selber bauen (z.B. auf Basis von https://github.com/harbaum/ftduino/tree/master/android).

Benutzeravatar
PHabermehl
Beiträge: 2429
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von PHabermehl » 06 Okt 2020, 18:51

Mahlzeit Mahlzeit,

also, ich würde tatsächlich auch erstmal den ftDuino empfehlen. Vielleicht kannst Du uns noch mal einen Tipp zu Deiner tatsächlichen Altersklasse geben, die 10 nehme ich Dir nicht wirklich ab...

Nach dem Raketenstart, den Du hier hingelegt hast, denke ich, der Einstieg in die Arduino-Welt würde Dir recht leicht fallen. Der ftDuino hat den großen Vorteil, dass er hardwareseitig großtenteils kompatibel zu TX/TXT ist. Du hast die ft-I/O UND den I2C-Bus. Da kannst Du Dich recht lange mit beschäftigen.

Wenn Du unbedingt eine Benutzerschnittstelle brauchst, kannst Du über I2C auch Displays anschließen, und Knöpfchen zur Interaktion natürlich auch. Und all' die Sachen, die Richard schon erwähnt hat, natürlich.

Der TX-Pi ist ein schöner Host für die cfw. Den kannst Du natürlich immer noch 'dranhängen. Und wenn Du einen ftDuino hast, brauchst Du den Pi-HAT nicht mal unbedingt, das macht den Gehäusestack schon flacher und das Gerät günstiger. Den ftDuino kannst Du über USB mit dem TX-Pi verbinden, über BT bestimmt auch, und dann läuft der ftDuino halt als Slave, macht die (schnelle) I/O und der Pi als Master stellt die Benutzerschnittstelle zur Verfügung. Letztlich kannst Du natürlich die Funktionalitäten beliebig auf die Geräte verteilen. Kamera mit Bildauswertung am Pi mit OpenCV, unabhängige (Schritt-)Motorsteuerung auf dem ftDuino, was auch immer.

Gruß
Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

FortniteGamer3
Beiträge: 8
Registriert: 07 Okt 2020, 11:33

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von FortniteGamer3 » 08 Okt 2020, 11:03

Hi,
ich bin neu hier aber ich muss schon sagen das dein Projekt richtig cool klang. Da du dich mit Messreihe möchte ich wissen was dein Tatsächliches alter wissen. Es wundert mich nur soll nicht schlimm sein aber trotzdem meiner Meinung nach ist das ein geiler Vergleich gewesen. Ich würde dir aber auch erstmals den ftDuino empfehlen.
Gruß,
FortniteGamer3

nur als Vorbemerkung ich mag kein Fortnite hab nur was richtig random gesucht und dachte mir diesen Namen aus. 😁

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

Re: Messreihe: Wie schnell ist eigentlich der ftTxt im Vergleich zu PC und Lego?

Beitrag von Dirk Fox » 09 Okt 2020, 19:12

Hallo Mahlzeit,

eine gute Idee, die Controller-Rechenleistungen einmal zu vergleichen.
Auch wenn diese Leistung in der Praxis wahrscheinlich nur selten bei einem Modell relevant sein dürfte.

Aber wenn Ihr in die Tests auch den Arduino und den ftDuino integrieren könntet, ließen sich mit unterschiedlichen Tests sicher Entscheidungshilfen für die geeignete Controller-Wahl erzeugen.
Mahlzeit hat geschrieben:
02 Okt 2020, 09:18
Es scheint außerdem, dass die Möglichkeiten nochmals deutlich gesteigert werden können wenn das Programm im online modus über den PC läuft.
Vorsicht: Da findet die Rechenoperation auf dem PC statt, hinzu kommt die serielle Datenübertragung an den Controller. Die Kombination sagt also wenig über den Controller selbst.

Wertvoll wäre ein Benchmark, der die Geschwindigkeit der Auswertung angeschlossener Sensoren (Abfragefrequenz) misst. Der Ultraschallsensor ist da keine so gute Wahl, weil er eine relativ lange feste Laufzeit hat. Da dürften Arduino und ftDuino deutlich besser abschneiden, während sie bei Berechnungen sicherlich weit hinter die anderen Controller zurückfallen.

Beste Grüße,
Dirk

Antworten