Liebe Forengemeinde, bereits seit geraumer Zeit lese ich hier im Forum quer. Das Thema µC hat mich gepackt und ich möchte endlich einsteigen, ABER ... ich bekomme einfach die Kurve nicht micht zu entscheiden. Der Markt ist so groß und vielfältig, dass es mir bisher nicht gelungen ist mir ein klares Bild zu machen, was für mich das richtige ist, obwohl ich viel gelesen habe. Vielleicht könnt Ihr einem armen, verwirrten Geist Beistand leisten!? Was ich möchte: Ich möchte Roboter und Maschinen steuern und ihnen ein Stückchen Intelligenz einhauchen und die Maschinen "sehen" lassen. Vernetzung ist mein Steckenpferd. Der µc als SPS Ersatz für die Schalttechnik, weil ich Hochsprachen lieber mag als z.B. Codeys und für Privatleute ist das sonst auch schlichweg zu teuer. Ich löte gern, bin aber Maschinebauer und kein Elektroniker. Ich komme von der PC Seite mit C, php, Basic usw. Programmierung. C++ liegt mir nicht so sehr, denn mir ist das zu viel Balast, wenngleich ich die Vorteile der OO Programmierung schon klar sehe. Dennoch würde ich gerne quick & dirty programmieren. Bzgl. µC hatte ich in Richtung Arduino (mit C) und "standard" AVR µC mit Baisc gelesen. Von Arduino habe ich aber nur einen groben Überblick. Das ist ja gewaltig. Ich habe bisher mit dem Raspberry experimentiert, um einen Eistieg zu bekommen und mir mal anzusehen, was leistungsmäßig möglich ist. Linux "semi embbeded" gefällt mir gut, dass 3,3V zu 5V Problem gefällt mir nicht so gut und der Ansatz als MiniPC auch nicht (HDMI brauch ich nicht ich brauche SSH :-) ). Außerdem ist der Raspberry für bestimmte Dinge (Bildverarbeitung) zu langsam und der Banana wird das wahrscheinlich auch nicht packen. Ich hatte mir zunächst gedacht ich gehe das vielleicht so an: - Komplexe Verarbeitung (Z.B. Bild, Raumkoordinaten, größere Datenmengen) via PC (Funk oder Wlan zur Datenübermittlung??) - Kontakt zur µC Ebene via Rasperry der zwischen PC mit WiFi und µC mit I2C Bus "vermittelt" - Antriebstechnik (Hardware) via AVR /Ardurio (soll dezentral / autark arbeiten) Das heißt aber ich müsste PC in C++ unter Windows oder GCC unter Lunux, Raspberry in Phyton (GCC geht auch, aber viele Libs und HowTos gehen auf Phyton) und den µC nochmal anders programmieren, dass erscheint mir doch sehr/zu aufwändig, unübersuichtlich und vor allem unwägbar. Also Raspberry Ebene weglassen!? Daraus meine Fragen an Euch: - AVR mit Basic (mit Assembler, wenn's mal eng wird) oder Ardurio mit Ansi C? (Oder gar vielleich PIC? Hier kenne ich mich noch gar nicht aus) - Kameraanbindung? Wie kommt das Bild schnell und einfach von einer "fahrbaren" Kamera in den PC zur Auswertung? - Wie kann ich eine I2C Anbindung (evt. auch wireless) an den PC am einfach, schnell und stabil realisieren? (PC als Master) Oder bin ich vielleicht mit meiner Herangehensweise völlig auf dem Holzweg? Gegenvorschläge sind willkommen! Ich hoffe ich habe das hier richtig gepostet und wäre sehr dankbar, wenn der ein oder andere mir von seinen Erfahrungen bei ähnlichen Anwendungen berichten könnte. Vielen Dank im Voraus!
Andreas schrieb: > - AVR mit Basic (mit Assembler, wenn's mal eng wird) oder Ardurio mit > Ansi C Lieber AVR mit C. Arduino ist C++, auch wenn das geschickt in einer "eigenen Sprache" verschleiert wird. Andreas schrieb: > - Kameraanbindung? Wie kommt das Bild schnell und einfach von einer > "fahrbaren" Kamera in den PC zur Auswertung? WLAN. Gibt's fertig. Andreas schrieb: > - Wie kann ich eine I2C Anbindung (evt. auch wireless) an den PC am > einfach, schnell und stabil realisieren? (PC als Master) http://www.harbaum.org/till/i2c_tiny_usb/index.shtml Treiber dazu ist im Linux-Kernel.
Konzentriere dich mal und schreib ordentlich auf, welche Kriterien für deine konkrete Anwendung wichtig sind. Dann kann man Dir auch helfen. Der obige Wirrwarr kann nur zu zwei Dingen führen: - Eine endlos ziellose Diskussion über Programmiersprachen und/oder Arduino - Gar keine Antwort, nach dem Motto: Wenn du ihm nicht gezielt helfen kannst, dann Klappe zu. Ich plapper gerade einfach drauf los. Sollte vielleicht auch besser mal die Füße still halten und einfach nur mitlesen.
Danke für Deine Antwort Ahab (Captain? :-)) > Andreas schrieb: >> - Kameraanbindung? Wie kommt das Bild schnell und einfach von einer >> "fahrbaren" Kamera in den PC zur Auswertung? > > WLAN. Gibt's fertig. Meinst Du WLAN Cam? Das wäre zu langsam. Ich brauche genug Saft für 2 USB HD Cams und min. 25 Bilder/s. Der Raspberry schafft es die Bilder zu Streamen oder auch Photos ind so schneller Folge zu machen und zu versenden. Wenn der zwecks Vereinfachung rausfällt? Wie dann? > Andreas schrieb: >> - Wie kann ich eine I2C Anbindung (evt. auch wireless) an den PC am >> einfach, schnell und stabil realisieren? (PC als Master) > http://www.harbaum.org/till/i2c_tiny_usb/index.shtml > Treiber dazu ist im Linux-Kernel. Danke!
Bildverarbeitung ist nicht grad die starke Seite von Mikrocontrollern ohne Betriebssystem. Nicht aufgrund des Betriebssystems, sondern aufgrund üblicherweise mangelnder Ressourcen.
Kritik ist erbeten. Anwendung 1: (Privat)Roboter bewegen, Umgebung wahrnehmen, vermessen und merken. Intelligent reagieren. Lerfähig. Anwendung 2: (Beruflich) Sägeblattzähne vermessen (so schnell es geht). Zahn messen, takten bis 360°, Positionierung via Lasergabellichtschranke, Vermessung optisch mit 3 Kameras. Geht beides in die gleiche Richtung. Grundsätzliche Vorgehensweise, Soft- und Hardware ist gesucht.
:
Bearbeitet durch User
Andreas Beier schrieb: > Wenn der zwecks Vereinfachung rausfällt? Wie dann? Bild "vor Ort", also Nahe der Kamera Vorverarbeiten. Dazu eignen sich (je nach gewünschtem Grad der Vorverarbeitung) Video-DSPs und/oder FPGAs. http://thomaspfeifer.net/fpga_dsp_bildverarbeitung.htm Tipp: klein anfangen. LED an AVR blinken lassen. Dann weiterschauen.
Ich habe mit USB-HD Kameras zu tun. 25 Frames mit 2 Mbytes = 50 Mbytes pro Sekunde pro Kamera. Unter 1GBit-Ethernet läuft da kaum etwas. Und dann nur mit Kabel. Sonst ist die Übertragung zu instabil oder zu langsam.
Also eine Menge Bildverarbeitung und auch noch möglichst schnell. Dann würde ich für diese Hauptaufgabe einen (oder mehrere) PC verwenden, und einen Mikrocontroller mit möglichst primitiver Firmware zur Ansteuerung der Maschine. Verwende fertige Kameras mit (wie auch immer geartetem) PC Interface. Für den Mikrocontroller-Part wäre spannend zu wissen, welche und wie viele Sensoren abgefragt werden sollen, sowie welche und wie viele Motoren angesteuert werden sollen. Wie gesagt sollte die Firmware des µC nur dumm Befehle des PC ausführen. Die ganze Hauptlogik würde ich auf den PC auslagern. Ich denke, der Raspberyy Pi wäre in diesem Fall nur halbgar. Für Steuerungen hat er zu wenig Anschlüsse und zu ungewisses Timing (wegen Linux). Für Bildverarbeitung hat er hingegen zu wenig Rechenleistung. PC plus Arduino (oder mehrere davon) könnte klappen. Da du aber schon mit C vertraut bist, würde ich eher von der Arduino Software abraten. Die Module sind jedoch hardwaremäßig Ok.
Am besten erst mal anfangen, bis Klar wird, was überhaupt die Anforderungen sind. Mit Bilderkennungsalgorithmen auf PCs experimentieren kannst du auch ohne Roboter. Motorsteuerungen auf Basis von Mikrocontrollern kannst du auch ohne Bilderkennung ausprobieren. Vielleicht brauchst du auch einen ganz anderen Ansatz. Bildverarbeitung um die Drift der Bewegungssensoren auszugleichen... oder irgend was anderes. Erst im 3. Schritt dann Hardware aussuchen, die für die Kombination klein und robust genug ist.
Andreas Beier schrieb: > Anwendung 1: > (Privat)Roboter bewegen, Umgebung wahrnehmen, vermessen und merken. > Intelligent reagieren. Lerfähig. > > Anwendung 2: > (Beruflich) Sägeblattzähne vermessen (so schnell es geht). Zahn messen, > takten bis 360°, Positionierung via Lasergabellichtschranke, Vermessung > optisch mit 3 Kameras. > > Geht beides in die gleiche Richtung. Grundsätzliche Vorgehensweise, > Soft- und Hardware ist gesucht. Handelsüblicher PC, sinnvollerweise ein flotter Quadcore (Intel i5/i7) ggf. mit leistungsfähiger Grafikkarte. Dazu genug RAM. Wenns kompakt werden soll: Es gibt auch Mainboards im ITX-Format und Industrietauglich... Für einfachere Sachen kann man auch über einen viel günstigeren AMD A10 oder einen Intel NUC nachdenken. Mit einem Raspberry macht das sicher keinen Spaß, der ist viel zu langsam... Andreas schrieb: > Kameraanbindung? Wie kommt das Bild schnell und einfach von einer > "fahrbaren" Kamera in den PC zur Auswertung? Mit einem kurzen Kabel. Der PC ist dann sinnvollerweise auch fahrbar und möglichst nah bei der Kamera...
Erstmal vielen Dank an alle für Eure Mühe und Einschätzung! Zusammenzufassen: PittyJ & Ahab @ Bild: Datenmenge ist klar. FPGA super interessant und ich denke der richtige Weg. Für mich aber aktuell entweder finanziell (Boards z.B. von TI) oder vom Programmieraufwand her nicht zu stämmen. Oder siehst Du das anders Ahab? Ich denke: Später & im Hinterkopf. Streiche HD setze "möglichst schnell und möglichst gut auflösend". => Frage: Bildübertragung zum PC wie? WLan wäre aus meiner Sicht das Einfachste. Oder gibt's da was neben Raspberry od. Banana, was Photos vom USB Cam schießen und die via WLan an PC verschiken kann? Stefan us schrieb: > Also eine Menge Bildverarbeitung und auch noch möglichst schnell. ja. s.o. > Dann würde ich für diese Hauptaufgabe einen (oder mehrere) PC verwenden, > und einen Mikrocontroller mit möglichst primitiver Firmware zur > Ansteuerung der Maschine. Verwende fertige Kameras mit (wie auch immer > geartetem) PC Interface. ja genau. Daher würde ich µC gleich so aufbauen, dass Aufgaben bei Hardwareüberforderungen gespittet werden können. Gibt's hier außer i2C etwas Besseres, um idealer Weise mehrere Master gleichzeitig und möglichst flott im Netz miteinander reden zu lassen? > Für den Mikrocontroller-Part wäre spannend zu wissen, welche und wie > viele Sensoren abgefragt werden sollen, sowie welche und wie viele > Motoren angesteuert werden sollen. Wie gesagt sollte die Firmware des µC > nur dumm Befehle des PC ausführen. Die ganze Hauptlogik würde ich auf > den PC auslagern. ja. Klingt gut. Senosorenmenge wird sich herausstellen. Hatte überlegt mit DIP AVR Tiny, Mega oder gleich mit vorbestückten Platinen wie Babyoranguthans anzufangen. Wird so oder so nicht reichen, daher i2C im Hinterkopf und gleich mitprogrammiert, auch wenn es am Anfang dann nur einen Master und einen Slave gibt. Die Frage ist, wen ich hier als Master in's Netz klemme (da war der Raspberri als "Overhead"-Master für gedacht). Ich überlege zwar mittelfristig auch meine eigenen Platinen zu ätzen, aber jetzt muss ich erstmal mit einfachen Mitteln loslegen und Erfahrungen sammeln. > Ich denke, der Raspberyy Pi wäre in diesem Fall nur halbgar. Für > Steuerungen hat er zu wenig Anschlüsse und zu ungewisses Timing (wegen > Linux). Für Bildverarbeitung hat er hingegen zu wenig Rechenleistung. Halbgar trifft es gut. Aber ich brauche eine Alternative (siehe unten A10 Board o.ä.?) Das Timing würde ich pers. hinten anstellen und alles, was Echtzeit bedingt an den/die µC weiterreichen. D.h. der "Raspberry" müsste nur Daten sammeln "so schnell es eben geht". Am Bsp. Roboter: Roboter steht und hält das Gleichgewicht, bis Bewegungsaufforderung. Wartet dann wieder. Am Bsp. Vermessung: Misst so schnell er kann, taktet danach weiter. Je schneller die Hardware, desto flüssiger. Das ist ja letztlich nur eine Frage der Verabeitungsgeschwindigkeit und damit leider auch des Geldes. > PC plus Arduino (oder mehrere davon) könnte klappen. Da du aber schon > mit C vertraut bist, würde ich eher von der Arduino Software abraten. > Die Module sind jedoch hardwaremäßig Ok. Ok. Sehe ich auch so. Danke. Schreiber schrieb: > Für einfachere Sachen kann man auch über einen viel günstigeren AMD A10 > oder einen Intel NUC nachdenken. Mit einem Raspberry macht das sicher > keinen Spaß, der ist viel zu langsam... Klingt gut. Gibt's dafür ein Board, dass Wlan, 2xUSB und z.B. I2C hat? Ich suche nach dieser "Brücke" zwischen WLAN und µC. Noch einer schrieb: > Am besten erst mal anfangen, bis Klar wird, was überhaupt die > Anforderungen sind. Ja, das möchte ich auch aber ich habe Sorge, dass ich viel Geld investiere um festzustellen, dass es einen Flaschenhals gibt oder es viel einfacher gegangen wäre. Spricht etwas gegen Bascom für den Anfang bzgl. AVR? Welche Programmierumgebung würdet Ihr mir für ANSI C und c++ empfehlen?
:
Bearbeitet durch User
PittyJ schrieb: > Ich habe mit USB-HD Kameras zu tun. 25 Frames mit 2 Mbytes = 50 Mbytes > pro Sekunde pro Kamera. Dann geht wohl nur Embedded-PC. Wieviel Mannjahrhunderte hast Du dafür geplant? Ich würde erstmal 100 Nummern kleiner anfangen. Ein Roboter kann auch mit Lichtschranken, Bewegungssensoren usw. viele interessante Sachen machen. Und man kann erstmal ein Gefühl für das ganze mechanische Gedöns bekommen. Z.B. wie kann er sich bewegen, ohne ständig umzukippen.
> Gibt's hier außer i2C etwas Besseres, um idealer Weise > mehrere Master gleichzeitig > und möglichst flott im Netz miteinander reden zu lassen? Ethernet, RS485. I2C eigent sich nur für ganz kurze Leitungen, vorzugweise nur für Verkabelungen innerhalb eines Gerätes/Gehäuses. Sobald ein kabel aus dem Gehäuse Raus kommt, würde ich auf RS485 oder Ethernet wechseln. Es muss ja nicht gleich TCP/IP sein, Ethernet auf MAC Ebene ist recht einfach zu verwenden. > Spricht etwas gegen Bascom für den Anfang bzgl. AVR? Für mich ja, denn ich habe das letzte mal vor 20 Jahren in Basic programmiert. keine Ahnung, wie effizient der compilierte Code im Vergelich zu C ist. > Welche Programmierumgebung würdet Ihr mir für ANSI C und c++ empfehlen? Bei AVR das Atmel Studio (Windows only) oder Netbeans mit C/C++ Pugin und AVR-GCC Compiler. Manche Leute nehmen auch Eclipse dazu. Oder einfach nur einen Texteditor mit Syntax-Highlighting.
Peter Dannegger schrieb: > Wieviel Mannjahrhunderte hast Du dafür geplant? Problem ist klar und bekannt. Es war ein Beispiel für eine Idee: erweiterbar => dezentralisiert & skalierbare Hardware Stefan us schrieb: > Ethernet, RS485. ok. Dann Ethernet. Ggf. RS für Senoren. > Es muss ja nicht gleich TCP/IP sein, Ethernet auf MAC Ebene ist recht > einfach zu verwenden. Ok. Danke für den Tip. >> Welche Programmierumgebung würdet Ihr mir für ANSI C und c++ empfehlen? > Bei AVR das Atmel Studio (Windows only) oder Netbeans mit C/C++ Pugin > und AVR-GCC Compiler. Manche Leute nehmen auch Eclipse dazu. Oder > einfach nur einen Texteditor mit Syntax-Highlighting. Klingt gut. Denke Amtel Studio. Eure Idee zusmemngefasst: AVR unter C mit Amtel Studio. Ethernet als Bus für die Antriebstechnik. Spätere Option FPGA o.ä. zur Vorverarbeitung von Bilddaten (Filtern) Bleibt die Frage: "Master" Auswahl. Nun dann mit Ethernet, statt I2C. Hoffe ich fasse das so richtig zusammen!?
Als Master würde ich einen Industrie Rechner von der Stange nehmen. Ethernet haben die ja alle dabei, RS485 kann man leicht per USB oder interne Karte nachrüsten.
Bezüglich des Bus Systems würde ich dir auch davon I2C zu verwenden. Sobald es, wie schon erwähnt, aus einem Gehäuse herausgeht und möglicherweiße Stecker usw verbaut sind wird es Störanfällig. Für größere Strecken und Robouster gegen Störungen sind Diferentielle Bussysteme wie CAN oder ein auf RS485 Basierendes Protokoll.
Da fehlt was ;D... "Bezüglich des Bus Systems würde ich dir auch davon ABRATEN I2C zu verwenden." sollte es heißen
Hatte ich mir bereits dazugedacht :-) Bzgl. Bus habe ich heute noch recherchiert. Sehr interessant fand ich: https://www.youtube.com/watch?v=9jBmIxgIRj4 Was das Thema Ethernet mit µC für mich nun doch etwas zweifelhaft macht. Daher noch eine abschließende Frage: CAN Bus-Unterstützung ist in einigen AVRs bereits integriert, wie ich las. Ich habe so etwas noch nie programmiert. Hat da jemand Erfahrungen bzgl Aufwand und Schwierigkeitsgrad? Ist der Ansatz AVR inkl. CAN Modul ok, oder ist ein externes Modul zur Umsetzung besser leistungsfähiger einfacher zu programmieren? CAN Bus macht irgendwo Sinn um auch den Brückenschlag zur SPS zu nehmen, fall mal nötig.
Vergiss dieses Video. Es gibt zahlreiche bewährte implementierungen von TCP/IP für Mikrocontroller, zum Beispiel µIP und lwIP (beide von Adam Dunkels). Es gibt auch Ethernet Controller mit integriertem IP Stack, zum Beispiel von der Marke Wiznet oder Espressif. Auf meiner Homepage findest du ein Anwendungsbeispiele für AVR Mikrocontroller mit µIP. Das geht schon, auch ohne Probleme und sehr zuverlässig. Für die Berechnung der Prüfsummen geht sehr viel CPU Zeit drauf und je nach gewünschter Paketgröße brauchst du auch Pufferspeicher - womit AVR Mikrocontroller ja nicht gerade üppig ausgestattet sind. Jedoch zwingt dich niemand, TCP/IP zu nutzen. Du kannst Ethernet auch ohne diesen Protokollstack nutzen, und dann wird es ziemlich simpel. Im Gegensatz zu RS485 bietet Ethernet eine vollständige Potentialtrennung und der Ethernet Controller löst Kollisionen auf (ohne dass du programmieren musst). Statt dieses Youtube Video, schau Dir lieber mal diesen Wikipedia Absatz an: http://de.wikipedia.org/wiki/Ethernet#IEEE_802.3_Tagged_MAC_Frame Bei den meisten Ethernet Controllern musst du dich lediglich um den inneren Ethernet Frame kümmern, wobei die Prüfsumme vom Chip automatisch berechnet wird. Dazu musst du nur ein paar Füllbytes anhängen. Also brauchst du mit deinem Mikrocontroller lediglich folgende Daten zu verarbeiten: - Quell-Adresse - Ziel-Adresse - Ein paar Flags - Bis zu 1500 Bytes Nutzdaten Checksumme, Präambel und Kollisionen behandelt der Ethernet Controller von alleine. Der CP2201 wird mit einer eindeutigen MAC Adresse ausgeliefert, die kannst du aus einem seiner EEPROM Register auslesen. Achtung: Wenn du die Pakete in ein anderes netz routen willst (z.B. Internet), wirst du jedoch um TCP/IP nicht herum kommen.
Kleiner Nachtrag: Die Checksumme im Ethernet paket berechnen die meisten Ethernet Controller selbstständig. Beim TCP/IP Protokoll gibt es darüber hinaus noch eine weitere Prüfsumme, die dein Mikrocontroller berechnen muss - falls du auf TCP/IP setzt. Statt Can würde ich auf RS485 setzen, denn das kann jeder Mikrocontroller und auch jeder PC (=serielle Schnittstelle + RS485 Treiber).
Andreas Beier schrieb: > CAN Bus-Unterstützung ist in einigen AVRs bereits integriert, wie ich > las. Ich habe so etwas noch nie programmiert. Hat da jemand Erfahrungen > bzgl Aufwand und Schwierigkeitsgrad? CAN ist sehr einfach, da Dir die meiste Arbeit die Hardware abnimmt. Adressierung, Arbitrierung, Fehlererkennung, Retry usw. macht alles die Hardware. Im Prinzip geht CAN so: - CAN initialisieren - Daten in Sendepuffer ablegen -> Sendeinterrupt -> fertig - Empfangsinterrupt -> Daten aus Puffer lesen -> fertig Z.B. der AT90CAN128 hat 15 solche Puffer, man kann also quasi parallel mehrere Pakete senden/empfangen. Das ganze Gegenteil davon ist RS-485, da muß man allen Tod und Teufel umständlich in Software programmieren. Ein RS-485-Stack kann daher viele 10kB groß werden.
Es ist immer wieder überwältigend zu sehen, wieviel Power in so einer Community steckt und wie viel Hilfbereitschaft man bekommt. Eure Ausführungen haben mir sehr bei der Abschätzung meines Weges geholfen. Ich werde nun meine ersten Schritte wagen, Hardware bestellen und mich mit Ethernet ohne TCP/IP (danke Stefan ich werde gerne auf Deiner Website mal gucken) und CAN Bus (danke Peda) beschäftigen. Ich danke sehr für die Zeit, die Ihr alle Euch genommen habt und das so kurz vor Weihnachten und wünsche Euch allen da draußen ein FROHES UND BESINNLICHES WEIHNACHTSFEST!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.