Steuerung Roboter

[HaWe]

Evtl gibts ja noch nen anderen "Industrial" als den "101 Industrial" (ich fand nur keinen, aber das Board Layout vom 101 überzeugt mich wirklich nicht - und die Leistungen erst Recht nicht.



https://www.arduino.cc/en/Main/Ardui...dIndustrial101
https://www.arduino.cc/en/Main/Products

versus Due:



https://www.arduino.cc/en/Main/ArduinoBoardDue

aber vlt klärt uns ja der OP auf...?

[Carposept]

Evtl gibts ja noch nen anderen "Industrial" als den "101 Industrial" (ich fand nur keinen, aber das Board Layout vom 101 überzeugt mich wirklich nicht - und die Leistungen erst Recht nicht.



https://www.arduino.cc/en/Main/Ardui...dIndustrial101
https://www.arduino.cc/en/Main/Products

versus Due:



https://www.arduino.cc/en/Main/ArduinoBoardDue

aber vlt klärt uns ja der OP auf...?

vielen Dank!
sehr hilfreich

[nelg23]

Hallo,
freut mich, dass ihr hier so aktiv seid!

Kurzfassung der Aufgabenstellung:
Gefragt ist ein autonomes (nicht ferngesteuertes) System, das schwarze und weiße Tischtennisbällen einsammelt und voneinander unterscheidet. Die schwarzen Bälle sollen über eine Mauer ins das gegenüberliegende Tor geschossen werden, während die weißen nur leicht über die Mauer gestupst werden müssen. Dies alles soll innerhalb von 2 Minuten passieren. (Dies ist Level1)

Level2 hingegen ist wie Level1 mit dem Unterschied, dass Level2 3 Minuten dauert und gegen einen anderen Roboter gespielt wird.
(Level1 ist ein Einzelspiel)

Haben heute bei unserem Treffen besprochen, dass wir den Roboter gezielt auf die Bälle fahren lassen anstatt dass er auf dem Feld (56 cm*81 cm) " wild umher irrt". Dazu wollten wir sozusagen ein "Radar" einbauen, was natürlich mehr Rechenleistung abfordert.
Haben heute Vor- und Nachteile vom Arduino Yun und Raspberry Pi diskutiert. Die sollen von der Leistung her ziemlich ähnlich sein, jedoch hat der Arduino so gut wie keine Dokumentation, während der Pi hingegen eine sehr ausführliche Dokumentation hat, jedoch auf Linux läuft und wir zusätzlich nen Controller bräuchten. Kosten würde das so um die 40 Euronen.

Kenne mich mit Mikrocontrollern leider nicht so aus, was wären denn für solche mobile Roboter weitere Alternativen?
Am besten, was einfach zu programmieren, ne vernünftige Rechenleistung (ähnlich wie Yun und Pi) und nicht zu groß ist, da wir nämlich vom Bauraum sehr beschränkt sind. (17,5 cm*17,5 cm*25 cm ist das zulässige Maximum)

Bin weiterhin dankbar für eure Ratschläge!

[HaWe]

Haben heute Vor- und Nachteile vom Arduino Yun und Raspberry Pi diskutiert. Die sollen von der Leistung her ziemlich ähnlich sein, jedoch hat der Arduino so gut wie keine Dokumentation, während der Pi hingegen eine sehr ausführliche Dokumentation hat, jedoch auf Linux läuft und wir zusätzlich nen Controller bräuchten.

Wie bitte..???
Yun und Raspberry von der Leistung ziemlich ähnlich...???
woher nimmst du das?

Und eine bessere und User-freundlichere Doku als zu den Arduinos wirst du im Netz wohl kaum finden!

Der Yun ist eine 8bit-cpu und hat 2,5KB RAM bei 16MHz,
der Due ist eine 32bit-cpu mit knapp 100KB RAM bei 84MHz und der
der Pi3 ist eine 64bit-cpu mit quadcore (also 4 cores) mit jeweils knapp 1 GHz Takt und mit 1GB RAM.

Der Pi rechnet etwa 30-60x so schnell wie der Yun (single Tasks, per multithreading nochmal bis zu 4x schneller),
und der Due 10x so schnell wie der Yun.

Auf ner Skala von 1 bis 100 für die Rechenperformance
("1" für den absolut leistungsschwächsten Arduino überhaupt)
liegt als grobe Schätzung
der Yun bei 2,
der Due bei 30
und der Pi3 bei 100.

Immerhin - wenn du Platzprobleme hast, könnte ein Adafruit Feather M0 auch eine Idee sein.
Er entspricht einem Arduino Zero oder M0,
er hat 48MHz Takt und 32KB RAM
und liegt auf dieser Skala schätzungsweise bei etwa 20:

https://www.adafruit.com/product/2772

PS,
ich habe hier ein paar Benchmark-Tests zu diversen cpus.
Der Yun ist so schlecht, dass er noch nicht mal diesen Benchmark schafft von seinem RAM her - vom reinen Rechnen her ist er aber vergleichbar mit dem Mega, den ich auf der 100er Skala gefühlsmäßig bei 3 einsortieren würde.
http://www.mindstormsforum.de/viewto...&t=8095#p64772

[021aet04]

Sollte statt den kHz nich MHz stehen?

MfG Hannes

[HaWe]

Danke, stimmt, klar, du hast ntl völlig Recht! Habs soeben berichtigt!


PS,
ein paar weitere ARM-cpu Boards mit Steckbrett-Layout (wie Arduino M0/Zero o.ä.):
http://www.mindstormsforum.de/viewto...p=69397#p69397

[i_make_it]

Hier wurden ja jetzt auch zwei zeitliche Vorgaben genannt.
Einmal 2 Minuten und einmal 3 Minuten.

Das kann auch Einfluß auf die Wahl der Steuerung haben.
Im schlimmsten Fall kommt es wärend einer Runde zu einem Reset.
Dann muß die Steuerung die komplette Power On Routine durchlaufen, während die Zeit weiter läuft.
In diesem Extremfall käme es darauf an möglichst schnell mit der Aufgabe weiter machen zu können.

Da ist dann das Booten und Laden eines Betriebssystems halt immer der zweite Sieger.

Ist halt ein Extremfall, aber etwas was durchaus passieren kann (und beim RoboCup auch schon vor kam).
Sollte man zumindest mal überdenken bevor man sich bei einem Akku betriebenen System dessen Motoren auch mal spontan Spitzenströme ziehen können, auf eine Steuerung festlegt.
Auch EMV Einstrahlung (auch von den eigenen Motoren) kann einen Brown Out oder andere Resetgründe verursachen.

Selbst wenn man es später nicht berücksichtigt, kann man zumindest in die Projektdoku reinschreiben, das man sich darüber Gedanken gemacht hat und das Risiko für vernachlässigbar hielt.
Die Praxis wird dann zeigen wie selten/oft so ein Ereigniss dann eintritt und wo man dann was optimieren muß um es zukünftig zu vermeiden.

In den beiden Diplomarbeiten deren Links in meinem ersten Post stehen, werden ja konkrete Beschleunigungs- und Geschwindikeitswerte genannt, da kann man sich orientieren.
Was den Shooter angeht, muß man die Abmessung und Masse der Bälle und die Höhe der Mauer sowie den Abstand zum gegnerischen Tor kennen damit man den Motor dafür dimensionieren kann.
Eigentlich kann man sich erst danach sinnvoll der Energieversorgung zuwenden.
Denn was nutzt eine Energieversorgung, die bei gleichzeitigen Spitzenstrom von Antrieben und Shooter einen Spannungseinbruch hat, der das System resettet.