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
) zum Haupt-Controller überträgt - oder, wenn der Hauptcontroller im Kopf sitzt, einfach USB-Cams.
Zitieren
Lesezeichen