Zitierenein I2C geht auch via druckerport
Hier weht ja ein ziemlich rauher Wind...
Zur Auswahl des Buses sind noch weitere Faktoren entscheidend, zB die Entfernung zwischen den Geräten. Mit I2C kommt man nur einige zig cm weit oder verliert Geschwindigkeit bzw. erhöht die Fehlerrate. Wenn Du mehr als hundert Komponenten hast könnte der Signallaufweg bereits zu weit sein. Erklär doch mal, was Du alles anschließen willst und ob zeitkritische Komponenten darunter sind. Denn dafür ist der PC ohnehin ungeeignet. Außerdem bringt er weitere Probleme mit sich...
I2C ist nicht wirklich schnell aber immerhin recht sicher. Wenn Du einen Master hast, der zeitunkitsche Komponenten abfragen soll, dann kann das gehen. Allerdings nur bei "kleinen" Entfernungen und wenn EMVRichtlinien berücksichtigt werden, sonst kann es schnell Probleme geben.
Bei so vielen Slaves ist es nahezuz wangsläufig, dass sie recht weit auseinander liegen. Dafür gibt es bessere Bussysteme wie zB CAN oder LIN oder sonstwas. Eine weitere Variante ist RS485. Die isst für weite Strecken und bis zu 128Teilnehmern, wenn ich nicht irre, aber leider recht langsam.
DIeses Thema ist sehr umfangreich und wenn Du etwas derart komplexes aufbauen willst, dann solltest Du Dich intensiv mit Bussystemen, Kommunikation, Mikrocontrollern und Schnittstellen auseinander setzen, denn hier im Forum hat kaum einer den Überblick über Deine gesamten Anforderungen und kann Dir somit wohl nur grobe Ratschläge geben.
Du brauchst also auch ADWandler. Es gibt solche mit unterschiedlichen seriellen Protokollen, auch I2C. Bevor Du sie benutzen kannst, musst Du jedem eine Adresse einprogrammieren, weil die eingestellte Standartadresse nicht mit den anderen 99kompatibel ist. Allerdings hat man nicht immer 10Bit zu Auswahl, was bereits Probleme erzeugen kann. Auch hier gilt wieder: EMV beachten!
Mit CAN oder Lin wird alles gleich wieder etwas komplizierter, weil es weniger eigenständige Komponenten gibt (zB ADCs). An einem CAN-Bus hängen normalerweise µCs, die dieses Protokoll verstehen. Du wirst also wahrscheinlich nicht um die µC Programmierung herumkommen.
Als Beispiel kannst Du Dir die Kommunikation im Auto ansehen. Da hängen teils über hundert µCs zusammen. Das ist dann übrigens kein Architektur- bzw Denkfehler, sondern geht ganz einfach nicht anders...
Gruß
ein I2C geht auch via druckerport
@oberallgeier
Ich erkenne in deinem Beitrag nur Sarkasmus, nichts themenspezifisch hilfreiches.
@Besserwessi
Das OS (Windows, Linux) muss ja nichts in Echtzeit produzieren, da das die einzelnen Komponenten selbst machen sollen. Sicher kann es passieren, dass das OS die ein oder andere Sekunde hängt und damit der Roboter stillsteht, aber das ist vernachlässigbar, sonst würden ressourcenlastige 3D-Spiele auch nicht sauber laufen. Abhilfe wäre aber durch ein Echtzeitlinux gegeben, falls es doch notwendig werden würde.
@Gock
Ich habe grob die Umsetzung eines großen humanoiden Roboters im geistigen Auge und will bei einem Arm anfangen, Schulter- und Ellenbogengelenk zuerst. D.h. es gibt erstmal einige Servos zu steuern, deren Position, Stromaufnahme etc. ich auslesen will. Vonnöten sind ein paar PWMs und A/D-Wandler, und natürlich die Software, die ein paar bestimmte Bewegungsprofile kennt und abspulen sowie auf Eingangssignale (z.b. erhöhte Stromaufnahme) reagieren kann.
Da ich aus Ressourcen- und Handhabungsgründen einen mC je Arm/Bein wählen würde, müssten diese Bewegungsprofile von einem weiteren mC gesteuert werden, der pausenlos den aktuellen Zustand aller Arme/Beine abfragt und reagiert.
Aus meiner Sicht, und soweit ich die Main-Unit 2.0 kenne, ist der mC für einen Arm schon ausgelastet, falls es überhaupt möglich ist, das mit einem mC zu machen. Dieser mC hat nur 2 PWM-Ausgänge. Andere mC haben mehr Power. Allerdings wären dann auch bei einem mC je Arm viele Ressourcen (Ports) ungenutzt.
Wie kann man denn die Kommunikation zwischen mC umsetzen?
Hab ich denn die Möglichkeit, AD-Wandler oder PWM-Generatoren mit I2C-Interface selbst zu basteln? Vielleicht existiert ja irgendwo ein Tutorial dafür. Ich habe leider keins gefunden.
Danke sehrZitat von magic33
Allerdings mag ich bei USB bleiben, da die anderen üblichen Ports auf neueren Rechnern nicht mehr vorhanden sind.
usb to lpt 8,5euro Reichelt
und den kann man dan steuern wie man will
4ports raus +8Datenports +4 ports in
sowie 1x Ack open drain für SPI
und das tollste
es gibt in allen sprachen C,asm,Basic,PYTHON eine unterstützung
Ich denke du wirst wohl für einige Gelenke immer einen µC brauchen der
die Steuerung des selbigen und die Kommunikation mit dem Master übernimmt. Da es sich bei deinem Projekt um eine sehr große Anzahl von Aktoren handelt werden da auch zwangsläufig Störungen auf dem I2C Bus die Folge sein. Ich würde da auch eher zu Can Bus raten da dieser dafür geradezu prädestiniert ist. Aber da Can -Controller Area Network- bedeutet das, das du um Controller nicht herumkommen wirst. Das hat aber auch seine Vorteile; wenn du erstmal ein Gelenk mit einem µC hinbekommen hast inklusive Software werden die restlichen ein Kinderspiel werden.
Die Master Steuerung würde bei diesem Lösungsvorschlag der PC darstellen da er das Can System Steuern kann. Ich kann dir aus Berufserfahrung sagen das Steuerungsprozesse in Idustriebetrieben und Anlagen immer über Bussysteme mit Controllern an den Endpunkten gelöst werden. Als andere Systeme fallen mir da noch Device Net, Ether Cat, Profibus, AS Interface, und Feldbus ein. Kannst ja mal schauen was die so für Vor und Nachteile haben. Aber so ein System selber zu entwickeln ist wirklich nicht ohne....
MfG
Neutro
Neutro
Jemand mit einer neuen Idee ist ein Spinner, bis er Erfolg hat.
(Mark Twain)
Die eingangs gestellte Frage lässt sich beantworten durch googlen nach "usb i2C".
Allerdings befürchte ich, dass Du für das Problem schon einen Schritt zu weit gegangen bist. Dass es sich dabei nicht um ein Anfängerprojekt handelt und Du durch dieses ziemlich komplexe Thema nicht nebenbei etwas über Elektronik lernst, sei mal dahin gestellt.
Du solltest Dir zu allererst im Klaren darüber sein, welche Funktionen Du überhaupt implementieren willst und von welchem Element diese ausgeführt werden sollen (vielleicht weißt Du das ja schon...).
Wird die Greifhand geregelt und was soll sie regeln? Der PC? Dann brauchst Du einen sehr schnellen Bus, der eventuell nur solche Regelsignale verarbeitet. Außerdem ist USB ungeeignet weil nicht echtzeitfähig, unabhängig von Windows oder Linux. Dafür brauchst Du eine Controllerkarte im Rechner. Deren Leistungsfähigkeit legt die meisten Dinge festgelegt.
Willst Du nur steuern, dann wird das relativ diletantisch aussehen, vor allem, wenn das Ding mal laufen soll...
Wenn Du in jedes Gliedmaß einen µC einbauen willst, warum reicht es dann nicht, jeden µC an den Bus zu hängen und die Sensoren dann an diesen sternförmig? Und das sollen dann immernoch 100 sein?
Welche Aufgaben sollen diese übernehmen? Nur Daten auf Abfrage weiterleiten? Wieviele Daten kommen da zusammen? Wie groß ist die Regelfrequenz, wie hoch die Auflösung? Wiegroß also der Traffic auf dem Bus? Wie groß ist die maximale Zeitdilatanz?
Kann man den Traffic verringern? Benutzt man lieber 2 Busse, einen für Regelungsdaten und den anderen für Steuerungen?
Oder wilst Du nur eine ganz einfache Steuerung, die die Hand öffnen und schließen kann, vom PC gesteuert? Dann sollte man vielleicht nicht von humanoiden Roboter sprechen, denn ein solcher kann laufen.
Und wie geht man dieses Problem am besten klein an und baut darauf auf?
Sicherlich wird Dir hier geholfen werden, wenn man merkt, dass Du keine Luftschlösser bauen willst.
Gruß
Ohne mir jetzt die anderen Posts durchgelesen zu haben (Doppelantwort...)...Was genau ist denn daran fehlerhaft? Es ist einfach eine andere Architektur in meinem Augen. Bei meiner Anwendung bräuchte ich dann mehrere mC, die sich auch noch untereinander verständigen müssten. Der PC erscheint mir als mC in diesem Fall am sinnvollsten.
Ich würde mich freuen, wenn du mir nochmal genauer erklären könntest, wo bei mir der Denkfehler liegt. Denn ich bin Anfänger auf dem Gebiet der Elektronik. Als Softwareentwickler sehe ich das als modulares System, für das ich jederzeit weitere Module/Plugins entwickeln und anschließen kann. Vielleicht ist auch einfach nur die Wahl des Bus' falsch?
Als Softwareentwickler verstehe ich dein Denken schon und kann es auch nachvollziehen. In der Software sind modulare Systeme erstrebenswert.
Hardwaremäßig sieht das (meiner Meinung nach) anders aus. Hier heist die Lösung meist System-on-a-chip. Also möglichst viel auf einen IC bringen. Dieser Trend ist nicht nur in der Industrie ein fester Bestandteil (man stelle sich einmal ein Handy mit 50 ICs vor...) sondern hat auch im Hobbybereich zahlreiche Vorteile:
- * Geringerer Platzverbrauch (~ Faktor 20)
* Geringerer Stromverbrauch (~ Faktor 100)
* Geringerer Schaltungsaufwand (über 30 Chips zu verdrahten ist enorm fehleranfällig)
* Entlastung von Bussystemen
* Weeeesentlich billiger (spezielle I2C-Chips sind oft nicht gerade preiswert)
* usw.
Du kannst auch in einem IC eine Modularisierung der Komponenten erreichen bzw. das ist schon gegeben. Du kannst die Module wie ADC, EEPROM, PWM etc. ja völlig entkoppelt voneinander verwenden. GENAU das Selbe wie wenn du die Arbeit auf x ICs verteilst, nur mit den oben genannten Vorteilen.
Ein µC macht dann einfach die Arbeit von x diskreten ICs, hat jedoch nur eine I2C-Adresse. Da du das Protokoll ja völlig frei schreiben kannst kannst du auch bestimmen welche Befehle ADC, PWM, etc. de-/aktivieren.
Die Erweiterungsfähigkeit ist nach wie vor gegeben, sogar besser. Du hast dadurch mehr I2C Adressen zur Auswahl. Brauchst du ein spezielles Feature aktivierst du es einfach im µC, ist er bereits ausgelastet baust du den nächst-größeren der Familie ein und fertig.
So betrachtet ist auch mein Architekturvorschlag eine Aneinanderreihung von Controllern, die halt dann nur eine einzige Aufgabe bewältigen können.
Ich finde F4obs Darstellung macht's etwas einfacher für mein Verständnis. Das Problem bei den mir bekannten Controllern sehe ich in den für meinen Fall unzureichenden Schnittstellen. Die C-Control z.b. kann nur zwei Servos ansteuern, dafür hat sie zuviele Digitalports. Am Beispiel der Armsteuerung ist dieser Chip die falsche Wahl. Andere Controller sind ähnlich.
Ich bin beim Stöbern auf einen ausführlichen Beitrag zum CAN-Bus gestoßen. Ist ja das Gleiche in Grün, aber dann muss ich mir keine Sorgen mehr um die Zuverlässigkeit und Geschwindigkeit machen. Sicher ist das vor allem für einen Elektronikneuling schwieriger umzusetzen als I2C, wie Neutro sagt.
Ich grab halt immernoch in der Theorie rum und les Spezifikationen. Leider fehlt mir der richtige Einstiegspunkt. Tutorials zum Herstellen eines CAN-Geräts finde ich nicht im Netz. Vorschläge zu Büchern lassen sich leider schlecht beurteilen, bevor man sie kauft. Und ich glaube einfach, dass ich nicht weiterkomme, wenn ich mit analoger (?) Elektronik anfange. Einen Schaltplan kann ich mit wenig Unterstützung umsetzen. Vielleicht kennt ihr da was.
Wäre natürlich eine Möglichkeit. Aber das ist wie wenn man für jeden Zweck ein eigenes Auto kauft, anstatt gleich auf einen Combi/Allrounder zu greifen.
Mo-mo-ment...die C-Control ist kein Microcontroller, sondern ein Embedded System Device, was auf einem AVR aufbaut! Der AVR ist der eigentliche Mikrocontroller, und der meistert mehr als 2 Servos spielend.
Du hast auch noch nicht den µC genannt, den du einsetzen willst. Ein System aus mehreren 8 Bittern kann ich noch stellenweise nachvollziehen. Wenn du aber schon planst x Devices an einen Bus zu hängen würde ich gleich zu einem 32 Bitter greifen. Die sind derart leistungsstark, dass einer von denen i.d.R. ausreicht.
Berechtigungen
Lesezeichen