Basteleien seit Marvin

Hallo liebe Roboterbastler-Gemeinde,

nachdem ich vor längerer Zeit Marvin fertiggestellt hatte und mich mit Schrittmotoren beschäftigt habe, hat man lange Zeit nichts mehr von mir hier gelesen.

Aber - Ehrenwort - ich war nicht faul, sondern habe fleissig hier und da einige Sachen zusammengefriemelt, da es noch sehr viel für mich zu Lernen gibt und ich auf vielen Gebieten haufenweise keine Ahnung habe :)

In den letzten 1-2 Jahren habe ich mich also mit MosFets, ARM7, CPLDs und FPGAs beschäftigt, doch ein Video sagt vielleicht mehr als 1000 Worte, obwohl ich alles nur Ansatzweise gestern mal aufgenommen habe ...

http://www.youtube.com/watch?v=8qOz3oZeGjc

Der Sensorkopf ist recht vollgepackt mit Beschleunigungsmesser, 2 VGA Kameras, 1MB RAM, Laser, LEDs, IR-LEDs, NTCs, US-Sender und -Empfänger, Bluetooth und einigen Controllern sowie 4-Kanal Servosteuerung
Die Kameras werden mit je einem CPLD ausgelesen, da die Controller zu langsam sind, und speichern die Bildern in Rams, aus denen die Bilddaten per ARM7 ausgelesen werden. Die Daten können dann seriell an andere Controller und über SPI oder Bluetooth weiterverschickt werden.
Die 3D-Brille kann Videos per micro-SD abspielen oder Daten via Bluetooth auf die Displays bringen und verfügt ebenfalls über Beschleunigungs- und Gyrosensoren, mit deren Hilfe die Servos auf dem Sensorkopf gesteuert werden können.

CPLDs und FPGAs waren komplettes Neuland, aber für mich wirklich hochinteressant.

Gruß MeckPommer

hi,

wirkllich beeindruckend :-)

Da kann ich nur staunen.
Das einzige was fehlt ist Marvin II, der den Kopf trägt.

Lass mich raten: --> Langzeitziel?


liebe Grüße,

Klingon77

Hi :-)

Nein, der Kopf war eine Machbarkeitsstudie, die mir erhellende Einblicke in Bussysteme und CPLDs geben sollte.
Mein Fazit aus der ganze Geschichte ist, das man die Stereokameras ohne FPGAs nicht wirklich sinnvoll und in
akzeptabler Zeit betreiben kann.
Auf dem Sensorkopf hat jede Kamera einen CPLD zum Auslesen, 512KB RAM und von den RAMs zum µC ist einiges an Bus-Logik,
damit sich Rams, CPLDs und µC nicht in die Quere kommen. Mit einem FPGA und RAMs könnte man das Ganze noch erheblich kompakter
und einfacher aufbauen.
Was den Datenverkehr im nächsten Bot angeht, so gedenke ich das ganze eher als Netzwerk, denn als Bus zu realisieren. Ideen hab ich schon, nun braucht es nurnoch Zeit.

Und ich muss im Bereich Mechanik noch viiiiiieeeeellllll lernen ^^ Es sieht bei mir immer alles nach Feinarbeit mit der Axt aus ;-)

Liebe Gruß,
MeckPommER

hi,

ich bin immer wieder beeindruckt ob Deiner mech. Fertigkeiten.
Wenn man bedenkt, welche Möglichkeiten Du diesbezüglich hast ist das, was du hier ablieferst vom Feinsten :-)

Kleine Dreh- und Fräsmaschinen bekommt man schon im unteren 100€ Bereich.
Evtl. wäre dies ein Einstieg für Dich?

Für benötigtes Zubehör rechnest Du ganz grob nochmals die Investitionssumme der jeweiligen Maschine.

Sind die manuell zu bedienenden Werkzeuge vorhanden kannst Du dich an die Fertigung einer kleinen CNC machen.

Dann ist Deine Werkstatt komplett.


Wenn du nur 100€/Monat "wegsparen" kannst dauert es nicht lange bis Du das Ziel erreichen kannst.


liebe Grüße,

Klingon77

Ach ja ... eine CNC *träum*

Würde komplett reichen, wenn man damit 4mm Alu bearbeiten könnte.

Aber vom Finanziellen abgesehen, ist das Ganze auch einfach ein Platzproblem. Mein Kämmerlein ist ca. 10qm gross und wirklich und absolut vollgestopft mit Technik. Bauteile, Werkzeug, Rechner, Monitore, Serverschrank, Kartons mit Kleinteilen, Platinenentwicklung, Kleinteilemagazine, etc. ... der ganze Kram ist in meinem Kämmerlein schon besser komprimiert als Daten in einer Zip ^^

Es fällt mir auch schwer, meine Frau zu überzeugen, das wir das Schlafzimmer dorthin verlegen und die Zimmer tauschen. Es wollen mir einfach keine Argumente für das vertikale Schlafen oder Doppelstockbetten einfallen ;-)

Und so ganz leise ist eine CNC ja auch nicht grade ... und wenn ich so ein Teil hab, wollen meine Kids bestimmt immer Puppen, Sterne und Katzen gefräst haben ^^

Gruß MeckPommER

Zitat:

---

Zitat von MeckPommER

... Machbarkeitsstudie ... Einblicke in Bussysteme und ...

---

Bewundernswerte Studien, mein Glückwunsch! Durch das Video seh ich erst, wieviel mir noch bei meinem Elektronikwissen fehlt. Ob ich jetzt blass vor Neid oder vor Bewunderung bin, weiß ich nicht und fast hatte ich überlegt, ob ich meinen Lötkolben wegwerfen soll ;).

Viel Erfolg weiterhin

Zitat:

---

Zitat von oberallgeier

...und fast hatte ich überlegt, ob ich meinen Lötkolben wegwerfen soll ;).

---

Behalt ihn ruhig.
Ich habe meinen, trotz mangelnder Zeit und Fachwissen, auch noch :-)
Natürlich bin ich diesbezüglich, wie immer voll der Hoffnung.


liebe Grüße und Sorry für OT.


Klingon77

...mich würde ja Deine Ansteuerungsvariante des Festplattenmotors interessieren.

Kannst Du vielleicht 2-3 Sätze dazu schreiben ?

Wow, von mir auch ein großes Lob!

Das Video hat mich inspiriert meinen Bot weiterzuentwickeln :D, der zwar schon Hardwaremäßig fast fertig ist aber noch viel programmiert werden muss!

Der Sensorkopf ist echt der Hammer und die Applikation dazu! Viele meckern oft rum, dass VB nur für Kinder ist, dem ist aber garnicht so, die sind nur genervt, weil sie immernoch in ANSI C programmieren und zu faul sind VB zu lernen :D

Weiter so!!!

Hallo und bitte entschuldigt, das ich so lange zum Anworten gebraucht habe *schäm*

Der Festplattenmotor wird nicht quick aber enorm dirty angesteuert ;-) MIr ging es nicht um Geschwindigkeitsrekorde (noch nicht *g*), sondern ersteinmal um die bloße Ansteuerung ohne Sensoren an sich. Die Ansteuerung erfolgt mit drei Halbbrücken deren Phasen per Atmega gesteuert werden. Per PWM erfolgt eine Leistungsregelung, da einem sonst beim Start leicht die Spulen kochen.

Auf den Sensorkopf bin ich auch stolz :) War aber eigentlich eher eine Machbarkeitsstudie. Man muss ja mal rausfinden, wie komplex man bauen kann, ohne aus dem Fenster zu springen ;-) Vier doppelseitige Platinen im Sandwich übereinander durch Stiftleisten verbunden ... war schon schön zu sehen, das es funktioniert. Vor allem bedingt es ja auch immer Fortschritte in anderen Bereichen: Platinen-Belichter verbessert, Übung bei doppelseitigen Platinen, etc ... Sinnvoll war es aus heutiger Sicht nicht, denn per FPGA wäre alles einfacher gewesen, aber Spaß gemacht hasts trotzdem :)

Was VB angeht ... also irgendwie ist es mit Programmiersprachen doch wie mit Controllern: immer das nehmen, was am besten passt. So eine Steuerung mit VB ist einfach und schnell strickbar, ein OS würde ich damit aber nicht programmieren wollen ^^ Einen Atmega nimmt man auch nicht für Bildbearbeitung, genausowenig wie einen FPGA für nen Blinker. Um mal eben einen analogen Messwert per serieller auszugeben, schreibe ich nichts in C sondern nehmen Bascom, aber Bit-Schubsereien in Bascom müssen auch nicht sein :)

Zu dem "weiter so ..." - ich sitze momentan an 2-3 Baustellen:
- Kameramechanik für 2 augen um diese einzeln schnell und genau steuern zu können. Ich sitze, wenn ich Zeit habe an den Überresten von Festplatten und DVD-Laufwerken um zu schauen, was man benutzen könnte. Cool wäre, wenn man die Linsensteuerung der optischen Laufwerke verwenden könnte, hab damit schon lustige Experimente gemacht :)
- Bus-System für einen (wirklich) großen Bot. Alle meine Bots haben, so toll das jeweilige Bussystem auch sein mag, immer den Nachteil, das es zu Blockierungen kommt - es kann halt immer nur einer auf den Bus zugreifen. Ich wurschtel grade an einem Bussystem, was eher ein Netzwerk ist, bei dem die einzelnen Knoten die Datenpakete auf unterschiedlichen Wegen ans Ziel leiten können und die Daten speichern, falls aktuell keine Möglichkeit der Datenweiterleitung besteht. Jeder Knoten hat 4 Connections die wahrweise zu Endgeräte oder andere Knoten führen. Mal gucken, was draus wird :)

Liebe Grüße,
MeckPommER

Hi MeckPommER!

Mich würde interessieren, wie du per µC auf UART gehst! Du hast da ja noch den SPI dazwischen. Wie machst du das genau? Welchen Chip nutzt du da und wie überträgst du vom Pc zum Bot hin? Fragt der Atmega immer mal wieder, ob im SPI Slave Puffer Daten sind, oder wie realisierst du das? wie winkst du die Daten durch? Paketiert? Der µC sammelt alle Daten ein, verschickt ein Bundle, um das Programm upzudaten und wartet dann eine gewisse Zeit auf Steuerungsbefehle?

Zum Bussystem: Wie hast du vor, das System zu realisieren? Ich meine: Ein Lan Netzwerk besteht ja auch nur aus verschiedenen Bussystemen, bzw P2P Endpunkten, die zb bei Switchen dann nur durch eine Logik gereicht werden, um zum jeweiligen anderen Endpunkt zu kommen. Dafür braucht man ja die FPGA im Switch. Im Prinzip handelt ein Switch ja auch nur alle Anfragen sequentiell, nur das dann verdammt schnell.

Hi einballimwas,

für genaue Angaben zum Sensorkopf muss ich mir das Programm nochmal genau anschauen um nichts Falsches zu schreiben. Wenn ich ein Projekt aus der Hand lege, verschwinden sofort alle Details aus meinem Kopf ^^ Grob: Vom PC gehts seriell auf ein Board, welches sich das empfangene Kommando anschaut und daraus erkennt, an welches Untermodul im Kopf die Daten per SPI weiterzuleiten sind. Wenn ich nicht irre, hab ich neben SPI noch eine weitere Leitung, die den Status des Untermoduls signalisiert ... Genaueres erst nach Blick auf Hard- und Software :)

Zum Bussystem: das System hat Knotenpunkte, bestehend aus einem Atmega16 mit vier Connects zu anderen Knotenpunkten bzw. der End-Hardware. Diese Knoten haben eine einmalige 2-Byte Adresse und tauschen bei Programmstart die Adressen mit ihren Nachbarn aus. Ein Knoten kann nicht nur direkt weiterleiten, sondern auch bis zu 8 Datenpakete (a 64 bytes oder so) zwischenspeichern. Ein Datenpaket beinhaltet Ursprung und Ziel des Pakets sowie die eigentlichen Daten. Und an den Feinheiten bastel ich momentan noch, denn das Ganze ist herrlich höllisch Komplex und das liebe ich ^^

Das mit dme Bussystem hört sich großartig an :)
Wirst du das auch hier ausführen? Wie gestaltest du die Interconnects zwischen den Knoten? Wie routest du von Sender -> Knoten1 -> Knoten2 -> Empfänger?

Sender releast das Paket, Knoten 1 fragt die angeschlossenen Endpunkte ab und schickt das (wenn der Endpunkt direkt am Knoten hängt) Paket direkt zum Empfänger.

Sender releast das Paket, Knoten 1 fragt die angeschlossenen Endpunke ab und schickt das Paket dann bei negativer Antwort an alle weiteren Netzwerkknoten, die dann ihrerseits das gleiche tun, bis irgendwann einmal ein Paket zugestellt und auf die gleiche Weise quittiert werden konnte?

Denke daran: Bei Paketen benötigst du immer Start, Ziel, Paketlänge, Paketinhalt, Checksumme!

Source 8byte
Dest. 8byte
Lenght 8byte
Content <=255byte (Je nachdem wie groß "Paketlänge" sein darf)
Checksum: 4byte

Ups, eigentlich wollte ich das gar nicht schreiben. Du machst das sicher so wie du es für richtig hälst! Habe mich nur wieder mitreissen lassen von meinen .. Ach, lassen wirs!

Wie implementierst du den SPI Bus, bzw hast du da ein Protokoll für geschrieben, wie die µC kommunizieren? Ich würde da gerne selbst warm werden mit dem System.

Servus!

Echt toll, was du so in deiner Freizeit angestellt hast :-)

Ich bin ja in den letzten Monaten so gut wie gar nicht zum Basteln (ist mein erster Post im Forum seit einer laaaaangen Zeit) gekommen, hab mir aber fest vorgenommen, nach dem ganzen Matura/Abiturstress wieder was anzufangen.
Auf deine Lösung mit dem Netzwerk bin ich schon gespannt! Gibt es dabei einen Punkt, den du zu erreichen beabsichtigst (abgesehen vom "nicht blockieren" der Kommunikation)?

Bin gespannt was die Zukunft bringen wird!

ikarus_177

Hallo Meckpommer,

gratuliere zu dem Projekt, ich werde es sicher weiter mit verfolgen und die Details, soweit du sie verrätst, studieren.