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