Liste der Anhänge anzeigen (Anzahl: 1)
noch ein paar Annahmen zum Diskutieren :-)
Hallo,
einige bisherige Kommentare haben uns darauf hingewiesen, dass es zur Modularität auf Seite der Software-Entwicklung schon ein paar Bestrebungen und auch gute Ansätze gibt.
Da ich denke, dass man das Rad nicht neu erfinden muss, sollten wir diese Ansätze, die Überlegeungen dazu, mit einbeziehen.
Was ganz sicher spezifiziert werden muss ist der Bus, über den die Kommunikation läuft, welche Daten über diesen Bus übertragen werden sollen und für welche Datentypen der gemeinsame Bus tabu ist.
Unter'm Strich wird ein vollständiger humanoider Roboter sicherlich auch so Komplex, dass es nicht nur einen zentralen Prozessor gibt, sondern einen Haupt- und entsprechend viele Sub-Prozessoren, die sich dann um die jeweiligen Peripherie-Gruppen kümmern.
wie die Kommunikation zwischen Haupt- und Sub-Prozessor dann aussieht - wir werden sehen. Es könnte (und sollte vermutlich auch) Ethernet sein.
Die Kommunikation zwischen Sub-Prozessor und jeweiliger Peripherie - das können
Antriebsmodule, Sensoren, Aktoren, ... sein - erfolgt (denke ich) sinnvollerweise über den lokalen I²C Bus des Sub-Prozessors.
Der Hauptprozessor kann dem Subprozessor für den rechten Arm durchaus sagen "mach mal den Finger krumm", der Hauptprozessor muss sich nicht wirklich selbst mit den Motoren in der jeweiligen Peripherie auseinandersetzen.
Es könnte z.B. so aussehen wie im Anhang1 - die gelben, roten und grünen Elemente sind Haupt- bzw. Sub-Prozessoren. Die hellblauen Elemente sind die jeweiligen Peripheriegeräte.
Natürlich kann man das ganze auch zu etwas kleinerem als einem Humanoiden aufbauen. Dann hat es eben nur eine fahrbare Plattform und nur einen drehbaren Arm.
Oder so ähnlich.
Die Berührungssensoren an Armen und Beinen könnten z.B. Dehnungsmessstreifen sein - oder Taster.
Je nachdem würde man dann dafür I/O Module mit analogen oder digitalen Eingangsports verwenden.
Wenn man die Berührungssensoren z.B. überall mit Dehnungsmessstreifen realisiert (die Idee an sich hört sich für mich nicht so schlecht an) braucht man dazu unzählige analoge IO-Ports, die über die ganze Oberfläche verteilen.
Wegen der wiederkehrenden Anforderungen bietet sich aus meiner Sicht die Modularität an.
Ich denke, für die Kommunikation zwischen dem jeweiligen Sub-Controller und den Peripherie-Modulen gibt es wenig sinnvolle Alternativen zu I²C.
Physikalisch ist die maximale Buslänge auf eine Arm/Beinlänge beschränkt - das ist mit I²C OK und ich denke, wenn der Humanoid sich an eine Tastatur setzt und 10 Finger blind auf der Tastatur schreibt - der Hauptprozessor dem rechten Arm über den Bewegungs-Subprozessor den direkten Befehl erteilt, ein "k" zu drücken...
ich denke nicht, dass auch bei 600 Anschlägen in der Minute der I²C Bus nicht zu einem Bottleneck wird - erstens ist das aus Prozessorsicht immer noch langsam und zweitens gibt vorher die Mechanik auf.
Ich kann ja auch schneller denken, als ich sprechen kann.
Und ich kann auch schneller sprechen, als ich schreiben kann.
Das Verhältnis passt also :-)
Kommunikation, die sehr datenintensiv ist wie z.B. Video- oder Bild- Daten sehe ich nicht auf dem I²C Bus.
Die 2 Augen im Kopf des Humanoid werden sicherlich Kameras sein. Vermutlich werden diese Kameras entweder am Hauptprozessor oder an einem Sub-Prozessor für "räumliches Sehen (der wieder den Sub-Prozessoren für Orientierung und Bewegung Rückmeldungen liefern kann, was die Kalibrierung der echten zur errechneten Position angeht) und Bilderkennung" angeschlossen.
Der Bandbreitenbedarf für die Kommunikation hier ist im gesamten System einmalig hoch und sollte nicht als Referenz angenommen werden.
Für diese Art der Kommunikation muss man ohnehin eigene Schnittstellen haben und - was spricht gegen WLAN-Web-Cams, die die Bilddaten per WLAN in den Bruskorb (da hätte ein normaler PC Platz (wohin nur mit den Akkus :-) ) zum Haupt-Controller überträgt - oder, wenn der Hauptcontroller im Kopf sitzt, einfach USB-Cams.
Die Bewegung der Augen (X/Y, Iris, Fokus) kann dann wieder über "standard-Module" erfolgen. Z.B. mit 4 Servos (4x PWM out für die Servos, 8x digital in für die Lichtschranken der jeweiligen Endpositionen und 4x analog in für die jeweilige Stromaufnahme der Servos - das könnte so ein Standard-Modul sein) - jeweils einem Servo pro Achse oder Bewegung.
Angenommen, die Kommunikation zu den Peripherie-Modulen würde per I²C erfolgen (was sich anbietet, aber noch diskutiert werden müsste).
Die Belegung des I²C Anschluss ist im RN-Standard spezifiziert, bei dem Software-Protokoll auf dem Bus gibt es bereits Ansätze (ID-Autoconfig, Capabilities in eine Tabelle eintragen etc.).
Damit dieses und andere Themen weiterkommen müsste eigentlich nur noch Hardware vorhanden sein, die sich entprechend programmieren lässt.
"Haupt-Prozessoren" und "Sub-Prozessoren" gibt es genug - die jeweiligen Prozessor-Eval-Boards mit ihrer begrenzen Anzahl Ports.
Bei der Peripherie gibt es ein bischen etwas (L297/L298 - Lösungen , ...) aber nicht wirklich viel.
Genau hier will ich ansetzen.
Wenn man sich auf das Design der Hardware einigen kann (und das sollte nicht so schwer sein) und auf diesem Weg nach und nach ein paar Standard-Module zusammenbekommt kann man parallel auch an den Software-Themen wie dem Busprotokoll weitermachen.
Die I²C Adresse automatisch zu verwalten hat den enormen Vorteil, dass auf dem Peripherie-Modul kein Jumperfeld für die Adresse vorhanden sein muss.
256 Adressen sind 8 Jumper - das ist viel Platz auf der Platine ;-)
So, erstmal wieder genug Text :-)
Ralph
Liste der Anhänge anzeigen (Anzahl: 3)
Ich versuch's mal anhand einer konkreten Anforderung:
Ich möchte 2 Servomotoren steueren, die Stromaufnahme der Servomotoren soll überwacht werden (Feedback für Load) und ich möchte an Start- und Endstellung jeweils eine Gabellichtschranke haben, um die genaue Position zu bekommen.
Die Platine unten adaptiert einen 8-Bit IO Port, um 2 Servos nebst Lichtschranken anzuschliessen.
An den oberen Anschlüssen (normale 2x3 Pfostenstecker, die am Rand der Platine sitzen - "quasi-SMD" :-) ) schliesst man die Servos (Mitte) bzw. rechts und links die Lichtschranken an, auf der einen Seite den ersten Servo, auf der anderen Seite der Platine den zweiten Servo.
Belegung wie http://www.rn-wissen.de/index.php/RN....C3.B6tigen.29
der 2x5polige Stecker unten passt auf einen 8-Bit Standard I/O-Port nach http://www.rn-wissen.de/index.php/RN..._.288_Ports.29
in die GND-Leitung der beiden Servo-Stecker ist jeweils im Layout ein Widerstand (0.1 - 1 Ohm) eingeschliffen, um über einen ADC den Spannungsabfall messen zu können.
Je höher die mechanische Belastung des Servo, desto grösser die Stromaufnahme, je höher die Stromaufnahme, desto höher der Spannungsabfall am Widerdand, den ich per ADC messen kann.
Natürlich ist das nicht die echte Stromaufnahme des Motor, der gemessene Wert ist natürlich um die (sehr geringe) Stromaufnahme der Servo-Elektronik verfälscht.
Aber ich denke, das ist genau genug und mit vertretbarem Aufwand nicht besser machbar.
Die Platine ist 1" x 1" gross und man kann sie entweder mit Schrauben oder Kabelbindern (3mm Löcher vorhanden) befestigen oder auch die überschüssigen Ecken einfach "wegdremeln", wenns noch kleiner werden soll.
Ähnliche Module kann ich mir auch für 8 x Open Collector, 8 x Optokoppler, 8 x Analog-In (mit Vorwiderstand, Spannungsteiler und Puffer-Kondensator für jeden Port auf der Platine), ... vorstellen - oder eben auch 8-Bit I/O-Ports als Modul am I²C Bus, die man dann mit der Platine unten zu einem I²C-Controller für 2 Servos "veredelt".
Interessant ist das für die Leute ohne Löterfahrung und auch die Leute, die Standard-Lösungen nicht immer wieder aufs Neue von Hand aufbauen wollen (wie z.B. ich) und lieber bequem ein fertiges Modul nehmen wollen.
Ich werde mir ein paar dieser Platinen machen lassen. Ich habe gesehen, dass die Platinen bei den 10 Stück, die ich mir machen lassen will, pro Stück recht teuer sind, der Preis aber rapide fällt (es ist ja eine kleine Platine und die Einrichtungskosten werden pro Auftrag berechnet), wenn die Stückzahl steigt.
Besteht Interesse an einer Sammelbestellung?
habt ihr Verbesserungsvorschäge (Design / Layout) ?
[ Nein, ein Ethernet-Thermometer kommt nicht mit auf die Platine ;-) ]
Besteht interesse an weiteren derartiger kleiner Module, bei denen man Sammelbestellungen machen kann? Welche?
Ralph
Liste der Anhänge anzeigen (Anzahl: 1)
8xOpen Collector
so könnte ein 8x Open Collector Treiber / Adapter aussehen
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Zitat von robin
Man muss sich beim Bau des Roboters an die Maße der einzelnen Module halten, was die Freiheit beim aufbau stark einschränkt.
Sorry wenn das jetzt zynisch klingt, aber ich hatte das Thema "mechanische Grösse der Elektronik" zurückgestellt, da ich nicht damit gerechnet habe, dass jemand ein Problem mit der Bauform bekommt, wenn die verwendeten Module insgesamt kaum grösser als die Stecker sind. Für Spezialanwendungen sind Standardmodule sicherlich nicht passend.
;-)
Zitat:
Zitat von robin
Auf der anderen seite hast du in deinem ersten post etwas von Modulen geschireben, die alle über einen Bus miteinander kommunizieren, wozu deine Letzten zwei Posts nicht passen, hier sind nur Adapter, die aber keine ersparnis von Ein-/Ausgängen am µC ermöglichen.
Wegen dem bisher wenigen Feedback und auch dem Hinweis einzelner Member, dass das zu umfangreich ist, hab ich die Komplexität etwas zurückgenommen.
Ein Controller-Modul, was nur am I²C Bus hängt, und 8 I/O Pins bereitstellt konnte so wie unten aussehen (0.8" x 1" gross) , der ISP-Anschluss zum Programmieren ist aus Platzgründen nur 6-pol ausgeführt.
damit hätte man auf weniger als 12cm² einen Controller für 2 Servos, oder 8x OpenCollector Out, oder 4x analog in, 2x analog out und 2x open collector oder auf 5cm² Bit Digital In/Out, ... alles, was sich so zusammenstecken lässt.
Zitat:
Zitat von robin
Ich finde wie gesagt die Idee nicht schlecht, jedoch würde ich in eine andere Richtung denken. Wieso macht man nicht einfach eine art "Sammelforum", in dem jeder Schaltungen zu einzelnen Modulen und der dazugehörenden Firmware hochladen kann und sie somit anderen zur verfügung stellt.
Gibt es schon: http://www.rn-wissen.de
Zitat:
Zitat von robin
- Flexibles Platinenlayout, da nur die schaltpläne hochgeladen werden
Genau das sehe ich nicht als Vorteil.
Einen Robotor zu bauen ist ein komplexes Projekt.
- Idee (und die Idee begreifen)
- Mechanik
- Antrieb (Motoren und Kraftübertragung)
- Elektronik (Hardware)
- Steuerung (Firmware)
- Applikation
Aus meiner Sicht kann man am Ehesten bei der Elektronik standardisieren, ohne sich individuelle Lösungen zu verbauen.
Um von Grund auf von einem Schaltbild zu einer fertigen bestückten Platine zu kommen braucht man etwa:
Layout-Programm, geeigneten Drucker, Standbohrmaschine, Säge, UV-Lampe, Platinenmaterial, Ätznatron, Eisen-III-Chlorid oder Ammonium-Persulfat (gibt auf Dauer IMMER Ärger wegen den Schäden), Lötkolben, Lötzinn.
Mal abgesehen von den Leuten, die aus Prinzip alles selbst machen wollen...
Ein paar wären sicherlich schon glücklich, wenn Lötkolben und Lötzinn reichen würden.
Das bekommt man nur hin, wenn man sich auf Standardmodule einigt und die dann zusammen herstellen lässt.
Alles andere ist nicht bezahlbar.
Ralph
