Oktopod Projekt

Na wenn du meinst, ich bin mir zwar ziemlich sicher, dass da nix wackelt, aber jeder darf die Erfahrung machen, dass CAD leicht zu konstruieren ist und real fummelig zu montieren.

Zum Board: Absoluter Overkill, braucht kein Mensch soviel Leistung für so ein System. Abgesehen davon ist es leichter mit µC Hardwarenahe zu programmieren. Wenn es schon ein Board sein soll und kein µC (was ich nicht weiter verstehen muss), dann würde ich wohl wirklich auf ein embedded Board setzen. Da gibt es Mittlerweile eine so große Auswahl an Lösungen, dass es auch schon sehr leistungsfähige Boards mit niedrigem Stromverbrauch gibt. Das Quad braucht 10Watt, da gibt es genug Embedded Boards die mit 1 bis 2Watt auskommen. Die Laufzeit des Hexas würde mit einem niedrigeren Verbrauch signifikant gesteigert werden. Ganz abgesehen davon, dass ein kleineres Board auch viel weniger wiegt.

Ich war fast sicher, dass eine solche Antwort kommt... :rolleyes:

Bevor ich hier eine Diskussion anzettel - gibt es ein paar Beispiele, wo einer eurer n-Pods zügig umher läuft (so schnell, wie es die Servos erlauben), Hindernissen ausweicht, etc.
Ich finde auf YouTube meist nur kleine Test-Läufe, ruckelige, oder sehr langsame Robots.

Zitat:

---

...
Ja, richtig gibt es ein paar Beispiele, wo einer eurer n-Pods zügig umher läuft (so schnell, wie es die Servos erlauben), Hindernissen ausweicht, etc.
Ich finde auf YouTube meist nur kleine Test-Läufe, ruckelige, oder sehr langsame Robots.

---

Ja, richtig...und vermutlich wird sich Deiner sehr bald dazu gesellen. Du wirst schon noch früh genug feststellen das Du keinen Rennwagen baust und DEIN Werk nicht mit maximal Geschwindigkeit an die Wand fahren willst.

Mir ist klar, dass es keine Rennwagen sind, aber sowas ist doch bereits möglich, wenn auch in einem kommerziellen Produkt:
http://youtu.be/-vVblGlIMgw

Dass man am Anfang alles superlangsam laufen lässt, solange man die Software entwickelt und testet ist klar, aber irgendwann sollte man doch diese Bremse einmal lösen.
Mir geht es bei meiner Frage darum, zu sehen, was mit µC möglich ist.

Ich habe mich damals für eine Hybridversion entschieden: die Motore werden von einem Microcontroller gesteuert, damit sie sich genau an den Heartbeat von 100/s halten. Steuercomputer war einfach ein Smartphone über RS232. So musste der Steuerrechner kein RTOS haben und wurde nicht vom Timing laufend unterbrochen. Die RS232-Befehle waren dann recht simpel. Heute würde ich natürlich USB verwenden - oder sogar Bluetooth, dann kann man auch mal nur die Mechanik vom PC kontrollieren.

Ruckeln und langsam ist keine Funktion der Prozessorleistung! Viel mehr eine Frage der Programmierung und der Mathematik die dort implementiert wurde. Meine ersten Hexas liefen sehr ruckelig und langsam und mit jeder Version werden sie "geschmeidiger".
Die Geschwindigkeit hängt von den Servos ab bzw. der Stellgeschwindigkeit. Mit Modellbauservos geht nicht viel mehr als 20ms pro Richtungsänderung.

Matt Denton hat da eigentlich gezeigt was mit Modellbauservos möglich ist.
https://www.youtube.com/watch?v=quN3...aW_5n2A0Wk--57

Die PhantomX hexas sind dann in Sachen Geschwindigkeit sehr beeindruckend schnell:
https://www.youtube.com/watch?v=lnCOLP33Te0

Die PhantomX Teile sind ja beeindruckend!

Ich gebe dir auch Recht, dass das Quadcore-Board oversized ist. Allerdings bin ich (zumindest momentan) noch zu doof um C zu programmieren und möchte es über Python realisieren, was als Interpretersprache natürlich Performance schluckt. Zum anderen denke ich, dass man es über ein komplettes Betriebssystem leichter hat, den Bot mit anderen Rechnern anzubinden. Alles ist auch sicher mit µCs möglich, aber sicher nicht so komfortabel = schnell umgesetzt.
"Ruckeln und langsam ist keine Funktion der Prozessorleistung!" -> Schon, aber weiche Abläufe sind mathematisch komplexer -> geht auf die Performance, genau so wie öfter die Sensoren auslesen und auswerten. Öfter Auslesen -> man kann den Bot vermutlich schneller laufen lassen, weil Kollisionen schneller erkannt werden.

Und falls sich rausstellt, dass sich mein Quad furchtbar langweilt, kann ich ja auch wieder zurück aufs Beaglebone schwenken. :-)

Ich dachte mehr an ein kleines embedded Linux Board, z.b. das Himbeerdings. Allerdings muss ich gestehen, dass ich mit Linux persönlich nicht zurecht komme, ein paar mal habe ich schon den Umstieg versucht, aber bisher hat es nie geklappt. Auf denen läuft dann auch Python! Ansonsten würde ich sagen, dass es eine Frage der Reichweite der Sensoren ist. Bei 5m Reichweite, kann ich den Sensor auch bequem nur alle paar Meter auslesen. Hexas sind in der Regel nicht so schnell, dass sie mehrere Meter in der Sekunde überbrücken. Klar, wenn die Sensoren nur 10cm Reichweite haben wird es Probleme geben, aber wer verwendet schon solche Sensoren?


Mein Vinculum hat einen 8 Core µC bekommen mit 80MHz, damit lässt sich schon einiges machen, die Servos limitieren dann als nächstes die "geschmeidigen Bewegungen"

Ich dachte auch eher an die Druck- und Kollisions-Sensoren der Füße. Das Teil soll ja durch unebenes Gelände und muss merken, wann der Boden da ist.

So, das "Wandboard" hat mich doch etwas länger aufgehalten, weil ich ja auch kein Linux-Crack bin. LAN + WLAN mit automatisch verbinden ist nicht so einfach, wenn man bei Ubuntu den Klickibunti X-Desktop deinstallieren muss...

Das Hexabein ist erst mal fertig und in der ersten Version bei shapeways in Bearbeitung. Die Details zu modellieren dauert dann doch immer etwas länger...
Das Ergebnis: Vom alten großen Spiderbein aufs kleine Hexabein gibt es eine kräftige Gewichtsersparnis bzgl. der 3D-Teile. Alt = 217g, neu = 123g (Ebenso hat sich der Preis von EUR 155 auf EUR 97 reduziert.)

Auf verschraubbare Teile hab ich diesmal verzichtet - alles was "angebaut" werden muss, wird mit Schnapp-Mechanismus realisiert. Jetzt heißt es erst mal ca. 3 Wochen abwarten...

Bild hier  

Bild hier  

Das nächste Bild zeigt, wie der Kram zu shapeways geht. Dort gibt es kräftig Rabatt, wenn das Material mehr als 10% vom Gesamtvolumen ausmacht.
Bild hier