modularer Aufbau der Steuerung von Robotern

[lemmings]

Das hat teilweise Ähnlichkeiten mit diesem Ansatz:
http://www.marvins-lab.roboterbastler.de/index.html

Ja, passt ins Thema.
aber wie Du auf der Seite sagst: die Stecker sind definiert, die Softwareschnittstellen fehlen.

zwischen den steckerbelegungen und der software liegt noch die Elektronik.
die ist auch noch gar nicht definiert.

wenn man einen humanoiden Roboter bauen wollte... was für modulare Elemente würde man brauchen?

sicherlich die Kamera-Lösung, die die Bilder in 3D auf einen Webserver schiebt, als realplayer stream oder wie auch immer sonstwie.

da man sich das heute zwar wünschen und auch bauen, aber letztlich nicht bezahlen kann (UMTS-Kosten) und man sicherlich auch noch andere Dinge braucht (Dehnungsmessstreifen auf der "Haut" als Sensoren könnten z.B. mittels ADCs abgefragt werden.

Man könnte einen AVR (Tiny, Mega, egal) an den I²C Bus hängen und z.B. nur 4 4er Gruppen I/O Pins auf Pfostenverbinder legen. auf diese Pfostenverbinder steckt man dann "Personality Module", die den Port zu dem machen, was man braucht.
LED, Open Collector, Relais, Optokoppler, Analog-In, analog Out (geht dann nur an PWM-fähigen PINs), ...

Macht doch mal Vorschläge, was man bauen könnte...

für den Prozessor soll es am I2C Bus hängen und irgendwie helfen, die Peripherie zu kontrollieren.

Die 5V Spannung für die Logik kommt über den I2C Anschluss und darf nur minimal belastet werden, für Leistungsverbraucher steht ein ungeregeltes Gleichspannungsnetz von zwischen 7 und 50V (+/- 10%) zur Verfügung.

Wenn genügend Leute Interesse an den gleichen Komponenten haben kann man die diskutieren, definieren, einen Prototypen bauen, nachbessern, es grossflächig einsetzen.

so wie es jetzt ist warten wir immer auf die nächste Prozessorgeneration mit noch mehr Pins, die dann irgendwo wieder nicht reichen

also! was brauchen wir?

motorsteuerungen? servo? schrittmotoren? piezos?
I/O-Ports? io / out ? analog / digital? open collector? relais?
eine sinnvolles energiekonzept? LiPo? LiIon? Solar?
Displays? Tasten? Touchscreens?
...

[lemmings]

Um nochmal klarzustelen, wovon wir hier überhaupt reden: Es geht um ein System von universellen elektronischen Modulen (Leistung- wie auch logik), deren Zusammenwirken den Aufbau eines komplexen Systems (wie zB den eines hummanoiden Roboters) ermöglichen, die mit einer Grundsoftware ausgestattet sind, mit Hilfe derer Grundfunktionen (zB Motoransteuerungen) bereitgestellt werden.

Genau so ist es von meiner Seite gemeint.

Dabei würde es helfen, wenige unterschiedliche aber großzügig dimensionierte Module zu haben. Wenn also schon Mid und Highpower, dann aber wenigstens mitdem selben Logikmodul. Und das dann bestenfalls einheitlich für alle Aktuatoren. Ähnliches sollte für die Sensorik gelten.

... siehe in meinem anderen Post bzgl "Personality Modul" - das einzige Problem, was ich da sehe ist, dass zu filigrane Stecker in dieser "rough" Umgebung kaum überleben können. mit den 1/10" Pfostenverbindern ist man gut bedient, die kann auch noch fast jeder löten... aber wenn es zu klein wird ist es dann in der Serie nicht brauchbar.

Bis in diesem Detail modular zu sein hat seinen Preis. dann sind 2/3 der Platinenfläche mit Pfostenverbindern und nur 1/3 mit Elektronik belegt. das macht die Sache teurer. es hat seinen Charme, aber auch seinen Preis.

Einfach heißt für mich auch, überall den gleichen µC zu benutzen (außer natürlich beim HauptµC) und nicht 5 verschiedene. Dann bleibt meist nichts anderes übrig, als einen etwas fortgeschrittenen zu benutzen. Allerdings macht es fast keinen Unterschied bei der Programmierung und die 2€ sollte man in Kauf nehmen.

bedingt stimme ich hier zu. es ist sicherlich richtig, dass man das Ganze üppig dimensioniert.

mein Beispiel mit der Servosteuerung, eine Platine von 4x4cm hat eine Fläche von 16cm².
ein Atmega8 (28Pin PDIP) ist etwa 3 cm² gross.
ich möchte die Module nicht unnötig gross machen weil
-je grösser, desto schwerer (Stromverbrauch und - schonmal an Flugmodelle gedacht?)
- die Platinen teuerer werden, wenn sie grösser werden
- es passieren kann, dass etwas für den Einsatzzweck zu gross ist (es einfach nicht reinpasst), aber selten, dass es zu klein ist.

Anyway, ich schlage vor, den ganzen Peripherie-Kram in C zu programmieren.

Das heisst dann auch, dass es letztlich völlig egal ist, welcher Prozessor auf dem Modul sitzt.
Das bedeutet dann, dass z.B. bei einem 8-Bit Open Collector Output Modul eben so "essentielle" Funktionen wie ein 16 Bit Counter (braucht man den für's I²C Protokoll?) eben nicht zur Verfügung stehen. Aber ich glaube, man kann damit leben

btw... ich sehe SMD Bauteile als "normal" an... ich will eben NICHT das Xte Prozessor-Eval-Board bauen. die Bauteile zu sockeln habe ich nicht vor

Die Elektronik wird ohnehin nur einen Bruchteil der Mechanik kosten.

hier stimme ich Dir wieder voll zu



zum Beispiel den Servo-Controller aus meinem Beispiel weiter oben bei einer 50 Stück Serie - ich schätze so ein Modul auf etwa 8 EUR für die Platine und nochmal 8 EUR für die Bauteile. damit müsste man bis zu 10A hinbekommen, hätte 2 Gabellichtschranken, ein Poti und die Messung der Stromaufnahme für unter 20 EUR.

ist das jetzt eher S, M, L, XL oder XXL sized?

Ralph

[marvin42x]

Das RnCom Projekt ist ja ein Kommunikationsprojekt wo es darum geht, dass sich ein Modul im Netz anmeldet, all seine Devices, also ADC-Wandler, oder IO-Pins, oder Kompass, usw. auf befragen runterbetet und ab dann am Netzverkehr teilnimmt, der über verschieden Verbindungsformen (RS232, I2c, TCP/IP) gehen kann. Für das Modul ist das nicht sichtbar, es kommuniziert einfach.
Was hier ins Spiel kommt ist halt das Routing und die Frage wie muss eine Message aufgebaut sein, damit sie geroutet werden kann.

Weiter hat Picnick eine I2C Multimaster Lösung für Bascom zur Verfügung gestellt und das Beispiel um ein Multithread Betriebssystem auf einem AVR in Bascom zu realisieren.

Die Hardwareseite war nur bedingt Bestandteil der Sache. Da es hier im Netz
-eine Standardbelegung
-und Hardware nach dieser Vereinbarung
für mich, der ich eine Null in Elektronik bin zu kaufen gibt.

Wie ich schon sagte, es kann sein, dass es einige Sachen gibt die zu eurem Projekt einen Denkanstoß geben können.

Meine Persönliche Meinung ist, dass das TCP/IP trotz seines Riesenoverhaed am Ende den Sieg über die meisten Busse davonträgt. Die Hardware dafür wird immer kleiner und billiger.
Ich würde dazu tendieren den „Backbone“ damit zu machen und die I2C und RS232 so kurz wie möglich halten und schellstmöglich auf TCP/IP zu wechseln. Die Freqenz auf dem TCP/IP Bus mit erstmal 100MBit sollte echtzeitfähig sein. Ein ping im kleinen Netz schafft es jedenfalls locker auf unter 1ms.

Netter Gruß

Ps, sieht so aus als müsste ich die Webseite deutlich verbessern und aktualisieren damit es übersichtlicher wird

[lemmings]

Die Hardwareseite war nur bedingt Bestandteil der Sache. Da es hier im Netz
-eine Standardbelegung
-und Hardware nach dieser Vereinbarung
für mich, der ich eine Null in Elektronik bin zu kaufen gibt.

solange Du innerhalb dieser Limits bleibst, d.h. mit den verfügbaren Möglichkeiten auskommst, ist das für Dich auch alles perfekt.
Wenn Du aber einen Pin mehr brauchst, als das Board hast musst Du entweder selber was bauen (was eben nicht jeder kann) oder das nächstgrössere Board nehmen.

sobald Du aber etwas umfangreicher baust landest Du mit dieser Herangehensweise schnell an den Grenzen.

Meine Persönliche Meinung ist, dass das TCP/IP trotz seines Riesenoverhaed am Ende den Sieg über die meisten Busse davonträgt. Die Hardware dafür wird immer kleiner und billiger.

innerhalb der mobilen Einheit bringt Ethernet keinen Vorteil, aber natürlich sollte es Prozessorboards geben, die auch per IrDA, Bluetooth, Ethernet (Wireless) bedient werden können.

es kann schon sein, dass hinterher der hauptcontroller auf einem Linux XEN Cluster, der auf ein paar VIA-Boards läuft, werkelt... der hat dann auch einen Webserver und WLAN.
Trotzdem muss der Haupt-Controller irgendwie mit der Peripherie klarkommen, da helfen eigentlich nur intelligente Slaves

Ralph

[lemmings]

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

[Gock]

Ich hatte eigentlich gehofft, die Sache mit dem humanoiden Roboter erstmal beiseite schieben zu können, denn die Planung eines solchen aus dem Stehgreif unter den gegebenen Umständen grenzt an Selbstüberschätzung, sanft formuliert...
Keine Ahung, welche Erfahrung Du mit all den Dingen hast, die Du da ansprichst, aber ganz ehrlich, das klingt mehr nach Wunschdenken als nach Sachverstand.
Das, was Du da vorhast, schaffen Teams mit mehreren Mann nicht, die jahrelang den ganzen Tag nichts anderes machen.
Die gesamte Vernetzung jetzt zu planen ist eine schöne Idee, aber erfahrungsgemäß wirst Du das alles wieder vergessen dürfen, wenn Du zwei Schritte weiter bist, weil Du dann auf Probleme gestoßen bist, die Du heute noch garnicht für möglich hieltest.
Du solltest mal einen Gang runterschalten, dann könnten wir uns über ein "Vorraussetzungsprojekt" unterhalten.
Eine Abschätzung des Bustraffics habe ich bisher immer noch nicht gesehen, genau wie irgendwelche anderen Fakten. Vielleicht solltest Du damit mal anfangen, denn dann wird einem klarer, was wirklich nötig ist...
Abgesehen davon ist die Elektronik von sowas wirklich lachhaft im Vergleich zur Programmierung und ehrlich gesagt fühle ich mich für sowsa nicht im Stande. Ich weiß ja nicht, wie das bei Dir ist, aber etwas zu bauen was man nicht beherrscht...naja,
erstmal gute Nacht...

[lemmings]

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

[lemmings]

so könnte ein 8x Open Collector Treiber / Adapter aussehen

[robin]

Hi,

ich finde deine Idee nicht schlecht, leider ist sie noch nicht ganz durchdacht.

Im großen und ganzen ist es schon Super, wenn man mehr ausgänge, oder was auch immer braucht, steckt man ein Modul an und ändert ein kleines Stückchen code im Hauptprogramm mit großem effekt. Aber deine Idee hat auch eine schwachstelle. Man muss sich beim Bau des Roboters an die Maße der einzelnen Module halten, was die Freiheit beim aufbau stark einschränkt.

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.

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.

Die Vorteile wären:
- Flexibles Platinenlayout, da nur die schaltpläne hochgeladen werden
- einheitlicher Standart (müsste jedoch festgelegt werden)
- hilfe für jeden

das ist nur so eine Grundidee, ich will deine Gedanken auch nicht schlechtreden, falls sich das vlt. so anhört.

mfg robin

[lemmings]

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.

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.

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

- 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