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...