modularer Aufbau der Steuerung von Robotern

[lemmings]

Hallo zusammen,

ich möchte folgendes diskutieren und (optimal) aus dem Ergebnis neue bzw. erweiterte Standards gewinnen:

Bisher werden individuelle Roboter häufig auf Basis eines Prozessor-Eval-Board aufgebaut, was immer ein mehr oder weniger grosser Kompromiss darstellt.

Ich möchte anregen, einzelne logische Baugruppen zu definieren und im Detail bis zur Serienreife zu planen, die jeweils zueinander passen (kompatible Stecker und Protokolle) und so zu individuellen Robotern zusammengesetzt werden können.

Jedes dieser Module sollte eine gewisse "Eigenintelligenz" besitzen, um vom Hauptprozessor lediglich komplexe Befehle, die dann abgearbeitet werden (für den Antrieb z.B. zu bestimmten Koordinaten zu fahren oder für einen Greifer, den Gegenstand an Pos. x zu greifen bzw. an Pos. y abzusetzen).
Ziel ist, den Hauptprozessor zu entlasten.

Um die zu definierenden Standards diskutieren zu können (eine Grundlage, was man bauen will, auch wenns heute technisch nicht mach- und bezahlbar ist) schlage ich als Zielmodell einen humanoiden Roboter vor, d.h. ein künstliches Sketett, was in etwa dem Menschen nachempfunden ist.

Spontan fallen mir folgende Themen (zum Standardisieren) ein:

- Energieversorgung (Akku-Ladeschaltung, Buck Boost Converter (Schaltnetzteil), Redundanz, welche Spannungen, ...)

- Energieversorgungsnetz (welche Farben, welcher Leiterquerschnitt, welche Steckverbinder, welche Steckerbelegung, ...)

- Datenbus (I2C DeviceIDs und Stecker sind bereits definiert)

- 2-Achsen Schrittmotorsteuerung High-Power für Antrieb

- 3-Achsen Schrittmotorsteuerung Mid-Power für Greifarm

- 2-Achsen Servosteuerung High-Power für Antrieb

- 3-Achsen Servosteuerung Mid-Power für Greifarm

- Hinderniserkennung (Ultraschall, IR-Laser Reflektion, ...)

- Positionserkennung (GPS oder besser Galileo, ein "wo bin ich" Device)

- Gleichgewichtserkennung / Beschleunigungssensoren

- Hauptprozessor

...

Beispielsweise könnte das Gleichgewichtssystem ein autonomes Gerät am I2C Bus sein, welches sich nur ums Gleichgewicht kümmert.
Die Gewichte/Belastungen der Extremitäten lassen sich an der Stromaufnahme der jeweiligen Antriebe (per I2C) abfragen, daraus ergibt sich ein mehr oder weniger vollständiges Bild der gesamten Kraft- und Gewichtverteilung.

Was denkt ihr?


Ralph

[Gock]

Hi!
Die Idee ist gut, wenn auch nicht neu. Sie macht die Sache leider nicht einfacher, sondern nur komplizierter. Natürlich hat dieses System Vorteile (CPU Belastung verteilt sich, Ausfall eines Systems kann eventuell kompensiert werden, IO-Pins sind zahlreich vorhanden usw.) aber ein derart komplexes Netz zu programmieren ist in jedem Fall fortgeschritten.
Trotzdem halte ich die Idee für geeignet von mehreren Leuten bearbeitet zu werden.
Hast Du Erfahrung mit sowas oder ist das jetzt eher ein Hirngespinnst?
Wenn Du es ernst meinst, sollte man zunächst abschätzen, wie hoch der Bustraffic minimal sein müsste, um die grundlegenden Funktionen zu gewährleisten. Ich befürchte, mit einem einzigen I2C-Bus kommt man da nicht sehr weit. Die Entfernungen sind im übrigen auch nicht wirklich vorteilhaft.
Aber es muss ja nicht gleich ein hummanoider Roboter sein. Ein einfacher Arm wäre ein Anfang, wenn man ihn im Hinblick auf Erweiterbarkeit aufbaut.
Gruß

[lemmings]

Hast Du Erfahrung mit sowas oder ist das jetzt eher ein Hirngespinnst?


Was ich habe ist Erfahrung in der Planung und dem Aufbau von serienreifen (und produzierbaren) Platinen - d.h. ich beherrsche Eagle und weiss, was ich da tue :-)

Beispiel Stromversorgung:
es ist aktuell kein Problem mehr, mittels ein paar Widerständen, Kondensatoren, einem ATTiny 25, einer Spule, Schottky-Dioden und 2 MosFETs einen Buck-Converter aufzubauen, der aus 4-40 V am Ausgang 12V stabile Gleichspannung bereitstellt.
das Ganze zu Bauteilkosten von weniger als 10€.
Weil es ein Schaltnetzteil ist wird nicht überschüssige Energie zu Wärme "verballert" was bei mobilen Systemen ja sehr hilfreich ist.
Derzeit gibt es kaum ein bezahlbares, kommerzielles Produkt, was vernünftig die Spannungen bereitstellt, die man braucht.
Aber: wenn man z.B. für die Stromversorgung ein 40V Netz definiert, woraus sich dann alle Verbraucher ihren Strom per Schaltregler holen - im Vergleich zu einem 12V Netz würde der Strom nur 1/3 betragen ==> niedrigerer Querschnitt bei gleicher Leistung, dadurch weniger Gewicht.

Bei den Schrittmotorsteuerungen fältt mir bspw. auf, dass das, was verwendet wird, immer noch auf dem L297 / L298 Konstrukt basiert, was grosse Kühlkörper verlangt.
wenn ich eine Hand steuern will muss ich entweder die Leitung zu den Motoren unendlich dick machen, falls die Steuerung im Rumpf ist oder ein riesiges Paddel mit Kühlkörper an die Hand bauen. Das kanns ja irgendwie nicht sein ;-)

Es gibt heute so viele schöne integrierte Schaltungen, die das perfekt mit MosFETs und mit dynamischer Kraftregelung machen (Trinamic), die Zeit für die analoge Technik mit den riesigen Kühlkörpern ist vorbei, was man braucht sind aktuelle Module.
Dann werden die Schrittmotoren im Leerlauf auch nicht mehr so heiss und der Akku hält länger. Das ist alles nur eine Frage des Designs.

Wenn wir wissen, was für Module wir brauchen, kann man die auch bauen.
Das ist allemal besser als sich mit dem x.ten Prozessor-Eval Board zu begnügen oder zu diskutieren, ob der ULN2803 jetzt in SMD ist oder nicht.

Der ULN2803 gehört gar nicht auf's Prozessorboard, der gehört zusammen mit einem ATTiny24A auf ein 8-Bit Open Collector I/O Modul.

I²C Bus => ATTiny => Darlington (so wie PCF8574A, der ATTiny kostet etwa das Gleiche, ist aber frei was die I²C ID angeht).

Ein Modul, was ich im Kopf habe, macht genau das: irgendwo am I²C Bus sitzen und 4 / 8 / 16 Open-Collector Ausgänge bereitstellen.
Ein anderes stellt Eingänge bereit, wieder ein anderes Modul 4 ADCs.
noch ein anderes Modul würde z.B. 2 Schrittmotoren mit bis zu 10A (mit aktueller Technik, dynamischer Drehmomentsteuerung und MosFET-Endstufen) steuern.
die Steuerung würde direkt da sitzen, wo sie gebraucht wird und man müsste nicht unnötig lange und dicke Kabel zum zentralen Controller verlegen.

jedes Gerät wäre an einem (? evtl. ist ein Split in mehrere Busse ab einer bestimmten Grösse sinnvoll, dann braucht es Gateways) Bus angeschlossen und könnte von einem oder mehreren Prozessoren gesteuert werden.

Jedes einzelne der Module könnte getestet und zuende entwickelt werden, ohne dass davon die anderen Module betroffen sind.
Wenn es fertig ist kann man es einsetzen, auch wenn man es nicht selbst entwickelt hat.

Ralph

[Gock]

Aber: wenn man z.B. für die Stromversorgung ein 40V Netz definiert, woraus sich dann alle Verbraucher ihren Strom per Schaltregler holen - im Vergleich zu einem 12V Netz würde der Strom nur 1/3 betragen ==> niedrigerer Querschnitt bei gleicher Leistung, dadurch weniger Gewicht.
Nicht ganz: der meiste Strom wird ja in den Motoren verbraucht, die nach Deinen Angaben Schrittmotoren sind und die benötigen den gleichen Strom, egal wie hoch die Spannung ist...


Es gibt heute so viele schöne integrierte Schaltungen, die das perfekt mit MosFETs und mit dynamischer Kraftregelung machen (Trinamic), die Zeit für die analoge Technik mit den riesigen Kühlkörpern ist vorbei, was man braucht sind aktuelle Module.
Dann werden die Schrittmotoren im Leerlauf auch nicht mehr so heiss und der Akku hält länger. Das ist alles nur eine Frage des Designs.

Also ehrlich gesagt sind Schrittmotoren für ein solches Projekt nicht unbedingt das gelbe vom Ei. Da gibt es heute auch besseres mit höheren Leistungsdichten, zB Piezomotoren oder SynchronServomotoren. Aber das alles steht und fällt mit Größe, Kosten und Komplexität des Projekts sowie Getriebeauslegung und anderer Hardwarefestlegungen. Wahrscheinlich aber werden die Kosten massgeblich.

Der ULN2803 gehört gar nicht auf's Prozessorboard, der gehört zusammen mit einem ATTiny24A auf ein 8-Bit Open Collector I/O Modul.
Das hängt definitv vom Anwendungszweck ab und kann so pauschal nicht gesagt werden. Du hast da offenbar schon was spezielles im Kopf...

I²C Bus => ATTiny => Darlington (so wie PCF8574A, der ATTiny kostet etwa das Gleiche, ist aber frei was die I²C ID angeht).

Dieser Tiny kann aber nicht viel, er hat nicht mal einen 16BitCounter onboard, geschweige denn ein komplettes TWI Modul.

Ein Modul, was ich im Kopf habe, macht genau das: irgendwo am I²C Bus sitzen und 4 / 8 / 16 Open-Collector Ausgänge bereitstellen.
Ein anderes stellt Eingänge bereit, wieder ein anderes Modul 4 ADCs.
Das nächste Problem ist, dass man oft einen Mischmasch an Funktionen braucht: Den Strom der Handmotoren analog messen, die Position per Drehencoder analog oder per Pulsung messen usw. Da kommt Dein Tyny sehr schnell an seine Grenzen.
Aber wie gesagt, prinzipiell ist das eine gute Idee und ich habe ja auch sowas im ähnliches im Kopf und plane ein Verwirklichung. Aber man muss schon sehr genau überlegen, was man tut, bevor man anfängt. Busraten abzuschätzen wäre wie gesagt das erste. Wenn sich nämlich herausstellt, dass I2C nicht gehen wird, hat sich die einfache Kommunikation mit den Tinys erledigt. Ich kann ohnehin nicht glauben, dass man ohne CAN oder vergleichbar hier weiter kommt. Aber würde man zB einen AT90CAN32 Automotive verwenden, wäre das schon interessanter...
Was ich sagen will ist, dass Du noch etwas unausgereift klingst, aber ein ähnliches Ziel hast wie ich, was ich schon mal sehr gut finde. Wir sollten auf jeden Fall weiter darüber nachdenken und voranschreiten!
Gruß

[Schlebinski]

hallo!

ich wäre an soetwas sehr interessiert, habe auch ein open robot projekt in der richtung wie du es dir vorstellst ins leben gerufen, leider schläft das momentan sehr und es wurde auch nur sehr wenig bisher getan blog, forum, wiki und svn existieren zurzeit unter http://www.hellfuck.net.

angefangen haben wir mal mit einem i2c protokoll, über das sich smarte sensoren, aktoren etc automatisch an "knotencontrollern" mit namen etc anmelden sobald sie angeschlossen werden. weiterführend war zur pc seite eine usb anbindung angefangen. netzwerktransparent sollte hierüber und über i2c (sowie beliebige andere bussysteme je nach anforderung) auch ein flashen aller module mit neuer software möglich sein. diese verbindung sollte auch weiterführbar sein über ethernet, ich habe mal angefangen, mich mit der roboterplatform yarp (http://eris.liralab.it/yarp) auseinanderzusetzen, die mir als sehr geeignet erscheint. bei uns am institut wurde hierfür MCA entwickelt (http://www.mca2.org), jedoch sagt mir das yarp system mehr zu. beides ist open source. ziel ist es beliebige module (d.h. sowohl soft- wie auch hardwaremodule) über beliebige verbindungen lokal sowie internetweit leicht miteinander verbinden zu können. sobald solch ein framework existiert, braucht nicht jeder roboterentwickler jedes rad neu erfinden...

wenn man sich anschaut, was die entwicklergemeinde von linux auf die beine gestellt hat... warum soll das nicht auch mit roboterhard- und software funktionieren?

grüße,
christian

[lemmings]

Aber: wenn man z.B. für die Stromversorgung ein 40V Netz definiert, woraus sich dann alle Verbraucher ihren Strom per Schaltregler holen - im Vergleich zu einem 12V Netz würde der Strom nur 1/3 betragen ==> niedrigerer Querschnitt bei gleicher Leistung, dadurch weniger Gewicht.



Nicht ganz: der meiste Strom wird ja in den Motoren verbraucht, die nach Deinen Angaben Schrittmotoren sind und die benötigen den gleichen Strom, egal wie hoch die Spannung ist...


:-)
Da der Schrittmotor bei entsprechender Drehzahl (Bspw. 500 RPM) Frequenzen von einigen 100khz bis zu ein paar Mhz "normal" sind ist der Schrittmotor auch eine nennenswerte Induktivität.
wenn ich das maximale Drehmoment abverlange muss ich auch den Strom gewährleisten.
Bei der Frequenz kann der induktive Widerstand schon stark angestiegen sein. wenn ich das Drehmoment will muss ich mit der Spannung rauf.
Ich brauche die hohe Spannung letztlich als Reserve um die hohen Ströme hinzubekommen.
Die Spannung sollte nicht über 50V liegen (ich will keine "Vorsicht Hochspannung" Warnschilder ;-) ), d.h. wenn eine Li-Ion Zelle eine Ladeschluss-Spannung von 4.2 V hat und ich 12 Zellen habe lande ich bei maximal 50V bis minimal 12 x 2.5V (Schlussentladespannung) 30V => alle angeschlossenen Module, die nennenswert viel Energie brauchen, müssten sich aus dem ungeregelten Netz bedienen.
Der technische Aufwand ist ein zusätzlicher Schaltregler, d.h. eine Spule, eine Diode, ein paar R's und C's und ein Microcontroller mit Analog-Input und PWM-Output.
Durch die insgesamt höhere Spannung habe ich entsprechend niedrigere Ströme bei gleicher Leistung, dadurch brauche ich weniger Leitungsquerschnitt, was wieder gut für's Gewicht ist.
"Nach Oben" würde ich die Grenze unterhalb von dem setzen, was als "tödlich" angsehen wird... und das sind (glaube ich, müsste man mal recherchieren :-) ) 60V.

Heisst: wenig Gewicht haben wollen erfordert dünne Leitungen
dünne Leitungen bedeutet niedrige Ströme, bei gleicher Leistung bedeutet das hohe Spannung.
Je höher die Spannung, desto leichter wird das Modell.
Der Preis dafür ist ein intelligenter Regler an jedem Verbraucher, der nur das aus dem Netz entnimmt, was gebraucht wird.
Damit sind Konstrukte mit Längsreglern wie dem 7805, die die restliche Energie in Wärme umsetzen, grundsätzlich nicht wünschenswert.
Der Roboter soll ja alles andere sein als eine mobile Heizung, die sich autonom bewegt.

... obwohl... ein warmer Roboter, der dir an kalten Wintertagen folgt, um dich zu wärmen hat auch etwas :-)
[/quote]



Es gibt heute so viele schöne integrierte Schaltungen ...




Also ehrlich gesagt sind Schrittmotoren für ein solches Projekt nicht unbedingt das gelbe vom Ei.
Da gibt es heute auch besseres mit höheren Leistungsdichten, zB Piezomotoren oder SynchronServomotoren. Aber das alles steht und fällt mit Größe, Kosten und Komplexität des Projekts sowie Getriebeauslegung und anderer Hardwarefestlegungen. Wahrscheinlich aber werden die Kosten massgeblich.


je nach Anwendung kann man doch das perfekte Modul für den jeweiligen Antrieb designen.

was braucht ein Servo-Antrieb?

einen DC-Motor, ein Getriebe, ein Potentiometer, 2 Gabellichtschranken, ein Längswiderstand, um die Stromaufnahme zu regeln.

eine halbe "Full Bridge" (d.h. 4 MosFETs oder 4 PWM-Pins für die Gates), ein Getriebe (das ist halt mechanisch), einen ADC-Eingang für's Poti, 2 I/O-Pins (oder, wenn ich die LEDs in den Gabellichtschranken pulsen will, um die Stromaufnahme zu reduzieren noch 2 Pins mehr) und noch einen ADC für die Stromregelung

4xPWM, 2x ADC, 4x standard-I/O.
Dazu noch SDA&SCL für I²C-Bus.

ein ATtiny24A wäre perfekt.

Das Modul könnte man auf einer 3x3cm oder max 4x4cm Platine (siehe Bild) unterbringen.
Je nachdem, wie intelligent man den ATtiny programmiert (I²C Protokoll, logische Funktionen wie "drehe 3200 1/100 Umdrehungen" verteilt über eine Zeit von 5,3 Sekunden mit maximal 2cm/s Beschleunigung, ...) kann man das Teil dann als universelle Steuerung für Servos in den Baukasten legen. und 4x4cm ist nicht wirklich gross... den meisten Platz auf der Platine brauchen die Stecker und die Leistungs-MosFETs


Der ULN2803 gehört gar nicht auf's Prozessorboard, der gehört zusammen mit einem ATTiny24A auf ein 8-Bit Open Collector I/O Modul.


Das hängt definitv vom Anwendungszweck ab und kann so pauschal nicht gesagt werden. Du hast da offenbar schon was spezielles im Kopf...


Ja und auch wieder Nein... Für kleine Aufbauten mag das durchaus OK sein, die jeweiligen Prozessor-Eval-Boards einzusetzten oder etwas universelles zu verwenden, bei dem 1001 Peripherie-Geräte mit auf dem Board sind. sobald das aber etwas komplexer wird ist dieses Vorgehen, alles mit einem prozessor zu machen , immer nur ein schlechter kompromiss.
Soll ein Roboter denn durch die Anzahl der I/O-Pins des Prozessors bestimmt sein?
Ich will weg von den Kompromissen. das geht nur individuell mit speziellen Lösungen, die dann aber wieder für sich eigenständige und funktionsfähige module sind.


I²C Bus => ATTiny => Darlington (so wie PCF8574A, der ATTiny kostet etwa das Gleiche, ist aber frei was die I²C ID angeht).



Dieser Tiny kann aber nicht viel, er hat nicht mal einen 16BitCounter onboard, geschweige denn ein komplettes TWI Modul.


Du brauchst ja auch gar nicht mehr. für ein simples I/O-Modul reicht das völlig.

[quote="Gock"]
Da kommt Dein Tyny sehr schnell an seine Grenzen.
/quote]

Simmt, aber wie ich's oben schon beschrieben habe reichen die mageren Funktionen der ATtiny's für die kleinen Dinge aus.
Die ATtiny's sind billig und unkompliziert.
Ob man dann den oder einen anderen Chip und aus der Automotive-Serie oder sonstwoher nimmt spielt doch keine Rolle.

Welcher Bus verwendet wird sollte auch kein allzugrosses Problem darstellen... I²C und CAN sind nicht so sehr verschieden - zumindest nicht elektrisch....

ein Projekt kann ja auch ein Farb-LCD mit Grafik entwickeln, wo dann das LCD auch nebenbei mit anderer Software auch als ein I²C Monitor/Analyzer eingesetzt werden könnte... oder eine LED-Balkenanzeige "I²C - Load" im 8-Bit I/O Modul ;-)

Ralph

[Schlebinski]

ja und was ist wenn man videos übertragen will? dann reicht die bandbreite von i2c nicht. macht ja auch nichts denn dafür ist es auch nicht gedacht. trotzdem hat i2c seine daseinsberechtigung und gerade für so einen motorcontroller ausreichend und billig. wichtig bei so einem projekt ist, dass es schnittstellennormen gibt an die sich jeder hält. ausserdem ist ja die verwendung von adaptern hubs und switches möglich und sinnvoll. wenn i2c zB für sensoren und aktoren einfacher art verwendet wird, werden irgendwo mehrere i2c busse an einem größeren controller zusammenlaufen, wo evtl auch rs485, can busse und eindraht-busse oder was auch immer ankommt. dieser wiederum kann per highspeed usb an einem PC hängen, an dem wiederum weitere controller hängen können. und mehrere PCs sind wiederum über ethernet verbunden. stellt sich heraus, dass es irgendwo einen flaschenhals gibt, wird auf mehr busse umgesteckt. die module melden sich neu mit ihrem identifier an, es muss nichts neu programmiert werden. deswegen nun irgendein bussystem zu verteufeln ist nicht sinnvoll. sie haben alle ihren anwendungszweck. das eine für kurze distanz, das andere für weite und auch noch schnell, dafür halt teurer. wenn das modulare framework jedoch alles unterstützt, kann man bequem das nehmen, was passt. und jeder hält sich ajn die norm und kann so auch mal schnell den sensor anstecken, den jemand anderes entwickelt hat.

grüße,
christian

[lemmings]

und wenn's ein modulares Framework gibt lohnt es sich auch eher, es selbst zu nutzen... wie man den Stecker belegt und auf welchen Pins letztlich SDA und SCL liegen ist eigentlich egal, aber wenn es alle gleich machen ist es wenigstens auf dieser Ebene kompatibel.
Wenn man dann noch ein gemeinsames Adressierungsschema hinbekommt und sich auch ein Busprotokoll einigen kann - perfekt.

dann muss nicht mehr jeder das Rad selbst neu erfinden und das wäre ein sinnvolles Ziel.

[marvin42x]

Das hat teilweise Ähnlichkeiten mit diesem Ansatz:

http://www.marvins-lab.roboterbastler.de/index.html

Vielleicht ist da das eine oder andere was zur Diskussion beiträgt.

Netter Gruß

[Gock]

@lemmings
Die Sache mit den hohen Frequenzen ist schon klar, aber die Kabelquerschnitte werden durch die niederfrequenten Ströme bestimmt. Trotzdem Sind natrülich 40V bei einem System wie diesem, das recht hohe Leistung benötigt und mobil sein soll besser, als 12V.
Mit Servomotor meinte ich eigentlich SynchonServos bzw. bruchless DCs. Ist aber erstmal wurscht. Denn soetwas festzulegen ist im Moment zu früh.
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.
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.
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. Die Elektronik wird ohnehin nur einen Bruchteil der Mechanik kosten.

@Schlebinski
Da ist wohl was dran, je komplizierter, desto mehr Bussysteme braucht man natürlich. In dieser Hinsicht bin ich ebenfalls sehr für Modularität. Ein Datanbus zur Videoübertragung kann vorgesehen werden, darf aber nicht Grundvorraussetzung für die Funktion sein, es muss also auch ohne gehen. Ähnliches gilt für Internetsteuerung oder sonstwas, denn das ist natürlich schon recht fortgeschritten.

Marvins Dinge sind schon ziemlich interessant, auch wenn ich nicht auf Anhieb erkennen konnte, was schon existiert und was geplant ist. Aber die beste Internetverbindung nützt natürlich nichts ohne eine funktionierende Mechanik bzw. die PSteuerung derer...
Gruß erstmal...

[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-Definitionen#Servo_Stecker_.28sowie_Sensoren.2FAkt oren_die_einen_Port_ben.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-Definitionen#Datenportstecker_10polig_.288_Ports.2 9

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

[Gock]

Hi!
Ok, nehmen wir das einfach mal so an. Wenn ich das richtig sehe, kommen die Wannenbuchsen seitlich daran, d h die Größe erhöht sich um diese.
Wie wäre folgendes: Benutze gewinkelte Wannenbuchsen in SMD an der Oberseite, die seitlich gesteckt werden und den µC befestige von unten direkt drunter. Dadurch wird es erstmal kleiner. Die Bohrungen könnte man diagonal machen, das gibt mehr Stabilität, vielleicht braucht man in einem solch mobilen System sogar 3 Schrauben.
Könntest Du mal 3,2mm Bohrungen vorsehen und die Umrisse bemaßen, damit man die Größe abschätzen kann?
Gruß

PS: Hab leider nicht so viel Zeit im Moment.

[lemmings]

Ok, nehmen wir das einfach mal so an. Wenn ich das richtig sehe, kommen die Wannenbuchsen seitlich daran, d h die Größe erhöht sich um diese.


Ja, Du hast mich beim Schönreden erwischt. Die Platine wird dadurch grösser als das eigentliche Stück Epoxy. aber nur etwa 5mm pro seite im mittel.
mir geht es aber um die platinengrösse (Kosten, mm² fläche der platine) und um "Lötfreundlichkeit"



Wie wäre folgendes: Benutze gewinkelte Wannenbuchsen in SMD an der Oberseite, die seitlich gesteckt werden und den µC befestige von unten direkt drunter. Dadurch wird es erstmal kleiner. Die Bohrungen könnte man diagonal machen, das gibt mehr Stabilität, vielleicht braucht man in einem solch mobilen System sogar 3 Schrauben.
Könntest Du mal 3,2mm Bohrungen vorsehen und die Umrisse bemaßen, damit man die Größe abschätzen kann?


Ups, das war jetzt viel auf ein Mal...

die Variante gewinkelte Wannenbuchsen / Proz unten drunter bringt wegen dem 2x so grossen footprint der stecker keine kleinere Platine (siehe bild)... aber schonmal überlegt, wie du das "von Hand" löten willst ? ;-)

Bohrungen? die Platine ist 0.8 x 1" bzw. 1" x 1" (oder auch 2,54 cm x 2,54cm) gross,
d.h. da passen gerade mal etwa 64 x 3mm Löcher drauf, dann ist die Platine weg.
Bei den Adaptern hab ich 3.2mm (sollten 3.2mm sein) Löcher vorgesehen, auch beim controller ist noch platz für 2 löcher... und - ohne zuviel von dir wegen der mechanik wissen zu wollen - ein gegenstand, der 2,5 x 2,5 cm gross ist (oder auch 3cm x 3cm mit steckern) ist mit 2 x M3 Schrauben perfekt befestigt, das hält auch so gut genug.
das ist so gross wie ein 2 Euro Stück... 3 schrauben ist zwar kein problem (ich guck mal), aber IMHO völlig oversized :-) :-)

Update:

so, temp2.png jetzt mit bemassung und 3 Löchern - damit es auch sicher hält 8-)

[Gock]

Jo, die Platine wird nicht kleiner, aber der Gesamtaufbau. Mit den Maßen sieht alles schon viel kleiner aus ;-)
Jetzt könnte man das Ganze natürlich noch auf die Spitze treiben und den 6-pol ISP Stecker zum µC nach unten gesellen und die oberen soweit auseinanderschieben, das man die Stecker zumindest noch löten und beschriften kann (sehr wichtig). Eine Platinenbeschriftung mit Name und Versionsnummer sollte auch noch irgendwo hinppassen. Bestückungsdruck wegen Kosten am besten nur einseitig.
Wenn das 3,2mm Löcher sind, brauchen die einen größeren Freiraum um sich herum (denke ich), damit die Schraube nicht die Leiterbanen zerstört. 3 Schrauben sind wirklich zu viel, diagonal oder mittig kann nicht unbedingt schaden, ist wohl aber auch nicht unbedingt notwendig.
Allerdings fällt mir gerade folgendes ein: Will man mehrere dieser Module befestigen, sollten sie Bauklotzartig zusammenpassen. Stapeln setzt vorraus, dass unterschiedliche Module die gleichen Schraubbefestigungen besitzen. Man solle also zuerst das aufwedigste Kleinmodul konstruieren und die restlichen der Größe anpassen.
Dieses könnte seine Schrauben an einer Seite haben, wie Du vorgeschlagen hast. Das nächstgrößere hat zusätzlich eine Fläche auf der anderen Seite der Schraubne und wird daurch etwa 1,5 - 1,8 mal so groß. Andere Module noch länger und oder breiter. Wenn sie breiter würden, würde es helfen, wenn die kleinsten nur an 2 Seiten Steckverbinder besitzen, weil die anderen dann von den längeren / breiteren Modulen versteckt werden.
Naja, das waren jetz einfach mal so ein paar Gedanken auf die Schnelle... Was meinst Du?
Sehr schön jedenfalls.
Gruß

[lemmings]

das man die Stecker zumindest noch löten und beschriften kann (sehr wichtig). Eine Platinenbeschriftung mit Name und Versionsnummer sollte auch noch irgendwo hinppassen. Bestückungsdruck wegen Kosten am besten nur einseitig.


Was ist mit Stecker beschriften auf dem Kupfer-Layer der Bauteilseite (Top-Layer, das rote) und den Druck komplett weglassen?
Was nutzt die Beschriftung der Bauteile, wenn es nur 3 Bauteile ausser den Steckern auf der Platine sind ;-)



Wenn das 3,2mm Löcher sind, brauchen die einen größeren Freiraum um sich herum (denke ich), damit die Schraube nicht die Leiterbanen zerstört.


Kunststoff-Schrauben und Distanzhülsen?




3 Schrauben sind wirklich zu viel, diagonal oder mittig kann nicht unbedingt schaden, ist wohl aber auch nicht unbedingt notwendig.


Ich denke auch eher an Kabelbinder als an Schrauben...
oder Klebe-Pads ;-)



Stapeln setzt vorraus, dass unterschiedliche Module die gleichen Schraubbefestigungen besitzen. Man solle also zuerst das aufwedigste Kleinmodul konstruieren und die restlichen der Größe anpassen.


Hab ich auch in der gleichen Reihenfolge berücksichtigt - die Servo's sind am kompliziertesten vom Layout - analog in ist kein problem (8 Widerstände und 8 Kondensatoren) - bei den Schrittmotorsteuerungen muss das Modul ohnehin anders aussehen , ebenso bei Full- und Half-Bridge (Stromversorgung muss seperat zugeführt werden können) da kommt man mit 5V nicht besonders weit.

Das läuft aber wieder auf den zentralistischen Aufbau hin.
der Vorteil der Modularität liegt darin, die Ports zu den Motoren zu bringen und nicht irgendwo einen dicken Klotz aufzustapeln. Stapelbar ist gut und schön, aber mit dieser Bauweise ist die Elektronik endlich mal kleiner als die Motoren... und die werden ja auch gerne dahin gebaut, wo sie gebraucht werden ;-)

Ralph