Ich brauche einige Anregungungen für mein Abschlussprojekt: Zwei möglichst große Bilder (je min. VGA (640x480) 24Bit RGB) sollen gleichzeitig aufgenommen werden, der Kontrast und die Helligkeit optimiert sowie die Kanten gesucht und markiert werden. Die Bilder zeigen ein zu untersuchendes Objekt von verschiedenen Blickwinkeln. Eine Erweiterung auf 3-6 Bilder soll auch möglich sein. Die Bilder sollen dann mittels einer geigneten Schnittstelle (USB, Firewire?) an einen PC geschickt werden, wo sie weiterverarbeitet werden. Ich suche also 1) Erhältliche CCDs (Farbe) 2) Einen Mikrocontroller oder DSP der sowas schaffen kann 3) Ev. Alternativen Am Prinzip (aufnehmen - Vorverarbeiten - an PC sendem) kann ich nichts mehr ändern, aber ich bin ziemlich frei, was die anderen Komponenten betrifft. Je mehr Bilder pro Sekunde, desto besser. Minimal sollten jedoch 0.5 Bilder/s geschossen werden. Wichtig ist aber nur, dass sie gleichzeitig gemacht werden (Zu beobachtendes Objekt bewegt sich), wann die Übertragung zum PC stattfindet, ist zweitrangig. Für die Kontrast- und Helligkeitsoptimierung muss zuerst der hellste und dunkelste Punkt gesucht und dann jeder Bildpunkt normiert werden, d.h. eine Division und eine Adition / Subtraktion sind notwendig. Pro Bildpunkt. Für die Kantensuche muss jeder Pixel einmal gelesen und mit 3-6 anderen verglichen werden.
mal so ein paar Tipps: - CCD's in Farbe sind sehr teuer. Halbwegs günstige gibts hier: http://www.theimagingsource.com/de/welcome/ - wenn sich die Objekte bewegen brauchst du progressive Scan, d.h. keine Halbbildaufnahmen wie bei den billigeren CCIT Standard Kameras - es gibt Framegrabber die haben ein FPGA on Board und machen darin die genannten Vorberechnungen. Diese Boards sind aber teuer und die Programmierung ist nicht ganz trivial - es gibt gute Libs (z.B. Intel IPP, OpenCV) die schon gute Algorithmen für die Bildbearbeitung und Kantensuche mitbringen. Die Intel Libs sind sehr gut auf den P4 optimiert und damit superschnell.
Im Prinzip brauche ich einen CCD wie er in einfachen Digitalkameras verwendet wird. Ideal wäre wenn der Sensor das Bild in einen auslesbaren Speicher ablegen würde. Ich benötige keine besonders aufwändige Kantensuche, sondern eben nur die Vorverarbeitung, da der Rest im Rahmen eines anderen Projektes auf dem PC erledigt wird.
Ein paar Gedanken: Willst Du eigentlich die CCD-Kameras selber bauen oder auf fertige Exemplare (z.B. Webcams/Videomodule) zurückgreifen? Eine CCD-Kamera selbst zu entwickeln ist durchaus nicht trivial. Einen USB-Webcam-Treiber auf einem µC allerdings auch nicht. Einen Framegrabber oder ein Firewire-Interface könnte ich mir schon eher vorstellen. CCDs in Farbe sind übrigens durchaus nicht teuer, sondern im Gegenteil meist deutlich billiger als die S/W-Gegenstücke. Grund ist, daß in Massenprodukten ausschließlich Farb-CCDs verbaut werden, und daher die Nachfrage wesentlich größer ist. Aber wie gesagt, ich würde versuchen, auf fertige Module zurückzugreifen. Was bedeutet "Die Bilder müssen gleichzeitig gemacht werden"? Webcams oder einfachere Videokameras kann man nicht ohne weiteres synchronisieren (bzw. nur mit Hardwareeingriffen), und falls jede z.B. mit 30 Bildern/s sendet, hast Du einen maximalen Versatz von 1/60 s. Wenn die Genauigkeit höher sein muß und das Budget nicht gar zu beschränkt ist, könnte man fertige Firewire-Industriekameras verwenden, da müßte es Geräte geben, die sich extern synchonisieren lassen. Als Low-Budget-Lösung könnte man versuchen, Videomodule so umzubauen, daß eins davon z.B. die Shutter- und Frametransfer-Impulse als "Master" erzeugt und an die anderen Module weitergibt. Problematisch könnten dabei unterschiedliche Belichtungszeiten je nach Beleuchtungssituation sein. Man könnte auch asynchron laufende CCD-Kameras mit langen Belichtungszeiten verwenden und mit einer Blitzbelichtung arbeiten. MfG Olaf
Selbst entwickeln will ich eigendlich nicht. Ich muss nur 2 VGA 24Bit Bilder auf einen Mikrocontroller bekommen, dort einige einfache Algorithmen durchlaufen lassen und das Ergebnis an einen PC schicken. Ich brauche auch keine dauernde Aufzeichnung, sondern muss nur auf ein externen Signal (Minimalabstand 0.5 Sek) die Bilder einlesen.
Hast Du mal ausgerechnet, wieviele Operationen pro Sekunde Du etwa benötigst, damit Du überhaupt abschätzen kannst, welchen Mikrocontroller Du brauchst (oder ob nicht doch ein FPGA das Mittel der Wahl wäre). Auch über die Geschwindigkeit des Speicherinterfaces solltest Du Dir Gedanken machen, schließlich willst Du mindestens etwa 4MB Bilddaten/s verarbeiten. D.h., die Kameras schreiben 4MB rein, Du brauchst alleine für die Kontrastanpassung 2 Lese- und einen Schreibvorgang, d.h. nochmals 12MB/s. Kantendetektion kann ich nicht abschätzen, das kommt auf den verwendeten Algorithmus an.
Die Kantenextraktion läuft i.d.R. auf dem Grauwertbild (ansonsten muss das Bild erst in einen anderen Farbraum z.B. HSI transformiert werden). 640x480*RGB in 8 bit = 3*307200Byte, da sind wir schon beim ersten Problem: Wenn das Bild als ganzes verarbeitet werden soll musst Du 1MByte RAM frei haben. Ich vermute mit Kanten markieren meinst Du, die Kanten im aufgenommenen Bild zu markieren. Einfache Kantenerkennung (Sobeloperator, da alles andere mit Multiplikationen verbunden ist), geschätzt (MIPI = Million Instructions Per Image): ca 4 Operationen zur Bildung des Grauwertes für ein Pixel ca. 14 Operationen/Pixel für Sobelfilterung 4 Operationen/Pixel für Histogrammbildung 2 Operationen/Pixel für Kantenentscheidung 3 Operationen/KantenPixel für Markierung 1 Operation/Pixel sonst Der Rest (Schwellenbildung) ist vernachlässigbar. Die letzten beiden Operationen mittel ich mal frech zu 2Ops/Pixel Macht in Summe 26 Op/Pixel => 8 MIPI. Hinzu kommen 40ms für die Aufnahme des Bildes, sofern der chips 25 Bilder/sec liefert. Nehmen wir mal an Du hast eine Schnittstelle mit 3MBit zur Verfügung über die Du ohne Start/Stop-Bits übertragen kannst, dann benötigst Du für die Übertragung nochmal 640*480*3 Byte/3MBit/s = 2,46s. Nun fehlt noch die Optimierung von Kontrast und Helligkeit. Das ist dann schon wieder aufwändiger. Vielleicht ginge ein Histogrammausgleich. Hab das allerdings noch nicht ausprobiert, wie das aussieht wenn man von G->RGB schließt. Kann sein, dass dann die Farben durcheinander kommen. Dafür schätze ich auf jeden Fall nochmals 8 Op/Pixel => 34 Op/Pixel total entspricht 10,5MIPI. Dabei ist immer angenommen, dass Du ohne Waitstates auf den Speicher zugreifen kannst. Also, wenn Du alle 500ms ein Bild verarbeiten willst, musst Du in 460ms (Rest geht für Bildaufnahme drauf) 10,5MIPI leisten können (ca. 23Mips) und Du brauchst 1MByte 0-Wait-State RAM. Wenn Du zwei Bilder gleichzeitig verarbeiten willst sind es 21MIPI in 460ms = 46Mips.
Also müsste ein 66Mhz ARM das schaffen? USB (2.0?) haben einige eh eingebaut. Gleichzeitig verarbeiten muss ich eigendlich nicht, es wäre auch möglich, jeden Sensor einzeln über einen eigenen MC an den PC zu hängen. Bleibt noch ndas Problem mit dem Bildaufnehmen. In welchen Format liefern CCDs ein Bild? Haben sie einen internen Speicher oder ein seriells Interfache?
Hi! Also ich würde sagen vergiss es dafür nen DPS/uC zu nehmen. Selbst auf nem DSP mit 150mhz wirds knapp bis unmöglich. Mit nem FPGA ist das dagegen eine leichtigkeit. Ich mache gerade etwas ähnliches mit später 4 CMOS Kameras mit je 25-50fps an einem FPGA (Xilinx Spartan3) Alleine am einlesen der Bilddaten wirst du mit nem uC scheitern: Die Kameras geben dir vor wie schnell die Daten reinkommen, dh pro Pixel bekommst du einen LO->HI Wechsel. Willst du das mit einem uC einlesen verbrätst du die ganze Zeit mit warten. Wobei mit 0.5fps wird das evtl noch klappen, wird aber trotzdem aufwendig. Die CMOS Sensoren liefern je nach Typ RGB888, YUV422, YUV444, RGB223, ... (meist einstellbar per i2c) Gibt da relativ viel Auswahl. Problem ist nur an die Datenblätter zu kommen. Das für den Sensor den ich verwende hat 500 Seiten. Haben wir auch nur über die Uni bekommen und mussten einen NDA unterzeichnen.
Also bei 66MHz ARM und mindestens 1MB 0-Wait-State RAM (12ns) wird das m.E. so teuer, dass Du besser mit einer USB2.0 oder FireWire Platinenkamera dran bist und die BVV auf dem Host (sprich: PC) laufen lässt. Da hast Du Zugriff auf diverse Bildverarbeitungsbibliotheken (mein Favorit: ltilib, findest Du bei sourcefourge) und muss Dir über Takte etc. keine Gedanken machen. Wenn Du mit weniger Bildern/s auskämest, wäre ein ARM oder DSP vielleicht wieder interessant.
Bildverarbeitung per PC ist eben NICHT meine Aufgabe. Ich soll nur das Bild einlesen, vorverarbeiten und weiterleiten. 100Mhz SDRAM bekommt man billigst aus alten PCs der Pentium III Generation. Wie bekomme ich nun ein Bild von einer erhältlichen Kamera in diesen Chip? Zuerst wird das Bild im RAM gespeichert, dann greift ein ARM darauf zu und verarbeitet die Daten und schließlich wird es versendet.
@Ingo: 1MB SRAM mit 10ns kostet <10. @Lukas: Kennst Du ein ARM-Board, das SDRAM akzeptiert? Selber bauen ist ja wohl keine sinnvolle alternative. Hier gibts ein Board mit einem Arm9 (200MHz) und 8MB DRAM für 400: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=26&products_id=69 Deutlich billiger ist z.B. ein FPGA-Starter-Kit, 1MB SRAM für 100: http://shop.trenz-electronic.de/catalog/product_info.php?products_id=70 bye Markus
Selbst bauen ist sehr wohl eine Alternative, wenn ich nur wüsste was aufs Board gehört. Alle Hilfsmittel zur Platinenerstellung <0,2mm sind vorhanden
@Markus: Das ist schon klar, aber es kommen noch der uC, Hostschnittstelle, Platine und Krimskrams dazu. Und das ist m.E. teurer als der Unterschied zwischen einer Board-Kamera mit USB2.0 Schnittstelle und einer ohne bei sonst gleichen Specs. @Lukas Ich weiss zwar nicht, warum man Dir als Aufgabe gibt das Rad neu zu erfinden, da USB2.0 Kameras recht preiswert sind, aber wenn's denn sein muss: Also Du brauchst _mindestens_: pro Kamera: ARM@>66MHz mit jeweils 1MB 10ns RAM, besser sind 2MB, da Du dann nicht in-place die Bilder verarbeiten musst und ggfs. mit double buffering arbeiten kannst (Gewinn: <40ms). Dann muss der Chip jeweils schnell genug sein, um die RGB Signale direkt in den Speicher schreiben zu können (bei RGB jeweils 8 bit von den Ports lesen und ins RAM schreiben.) Voraussetzung: Du findest eine Kamera, die die Signale auch so liefert. Farbraumtrafo YUV->RGB ist rechenintensiv. Allerdings könntest Du mit einem YCbCr Ausgang besser beraten sein, da Du die Kantendetektion dann direkt auf dem Y-Kanal durchführen kannst. Die Transformation nach RGB kann man danach (auf dem Host) machen, die Kanten im RGB Bild bleiben dabei erhalten. Schnittstelle zum Host, schnell genug das Ergebnisbild in der nach der Berechnung noch bis zum nächsten Bild verbleibenden Zeit zu übertragen. Damit Du nicht den Überblick verlierst, solltest Du zuerst mal alle Anforderungen aufstellen. Insbesondere vermisse ich im Moment, welche Farbauflösung gefordert ist, welche optischen Parameter eine Rolle spielen (Ortsauflösung), ... Diese haben ebenfalls Einfluss auf Dein Design, da z.B. bei geringer erforderlicher Farb- und Ortsauflösung vielleicht eine 4:2:2 oder 4:2:0 Kodierung der Daten, welche Schnittstelle zum Host gefordert ist, ....
USB Cams die preiswert sind vertragen sich nicht mit ihresgleichen am selben PC. Ich habe noch keine USB Kamera <150 gefunden, deren Treiber mehrere gleiche Kameras zeitgleich zulässt. Das Projekt wurde mir zugeteilt. Der Geg an der sache soll ja eben sein, das der MC einen Teil der Bildverarbeitung übernimmt und der PC (Via C3 533Mhz) somit bei mehreren angeschlossensen Kameras entlastet wird. Anforderungen sind mindestens VGA (640*480) oder besser SVGA (600*800) oder gar XGA (1024 * 768) mit 8 oder besser 24Bit Farbtiefe. Der HostPC hat USB 2.0, IEEE 1394 ("Firewire") sowie 100MBit LAN an schnellen Schnittstellen zur Verfügung.
Die Idee ist also, den PC durch einen Microcontroller zu entlasten, der 10-20% der Leistung des PCs hat. Wäre es da nicht sinnvoller, einen PC zu nehmen, der eben 10-20% schneller ist?
Hi! Ich kann dir echt nur raten einen FPGA zu nehmen. Da gibt es sogar schöne eval Kits mit usb2.0 controller mit dabei. Der große vorteil fpga gegenüber uC/DSP: Du kannst bei jeder Flanke an der Vclk leitung die Daten vom Camerabus übernehmen und direkt ins sram schreiben. Du brauchst keine Warteschleifen um auf eine vclk/pixelclock änderung zu reagieren etc. Dann noch nen SRAM mit 10ns dran und fertig. Ich hab vorher einige Experimente mit uC, DSP, Framebuffer + DSP, ... gemacht. Kannste alles knicken... Braucht viel zu viel Ressourcen und ist fehleranfällig (der framebuffer machte bei höheren fps zahlen zb murks etc) Je nach komplexität deiner Berechnungen evtl FPGA in verbindung mit uC oder DSP. Aber nur mit uC/DSP wird das nichts. Ok ausser du nimmst zb nen Blackfin DSP oder so. Da is aber auch nix mehr mit von Hand löten... Die kleineren Spartan3 gibts noch in handlötbarer Form.
Mit FPGAs habe ich mich leider noch nie beschäftigt. Welcher ist für einen Umsteiger von MCs empfehlenswert und kann die Kameradaten + USB verwalten? Das andere Problem bleibt der CCD. Welchen Sensor soll ich nehmen?
Hi! Also ich arbeite seit ein paar Wochen mit dem Spartan3 Board: http://shop.trenz-electronic.de/catalog/product_info.php?products_id=70 (ist aber ohne usb) Zum anfangen/Einstieg ist das sicher nicht verkehrt. Zum Beispiel eine Kamera dranpacken und ins sram schreiben lassen und gleichzeitig auf nem vga monitor in RGB111 anzeigen. Oder die Daten erstmal langsam per serieller Schnittstelle ausgeben. USB dranpacken kann man später immer noch ;) Natürlich musst du dir dann vhdl ansehen, ist nicht ohne. Aber ich hatte damit keine Probleme. Kannst ja mal ein paar Tutorials angucken ;) Oder lad dir das Xilinx Webpack runter und probier drauf los. Kannst sehr viel simulieren und dann gucken. Zum Thema Sensor: Das Hauptproblem sind die Datenblätter. Ohne die läuft nciht viel. Die meisten Webcams benutzen CMOS Sensoren, am billigsten/am einfachsten in der Beschaffung wäre es wohl eine billige Webcam zu nehmen und die Chips auszulöten (geht super mit nem Heissluftfön, hab ich schon gemacht) Da hast du dann gleich noch die passende Optik dazu. CCD Sensoren kenne ich nur die aus den Philips ToUCam Pro 840 oder die alte 740 (hat dieselbe elektronik wie die 840 drin). Die sind echt um weiten besser als jede vga cmos webcam die ich kenne (hab einige ausprobiert). Wie gesagt, nimm den Chip wo du das Datenblatt zu bekommst/findest. Mit Datenblatt meine ich das vollständige Datenblatt(>>100 Seiten), nicht diese 30S Zusammenfassungen. Konfiguriert werden die meisten Sensoren per I2C, wenn du da nicht die Bedeutungen der einzelnen Register kennst wirds schwierig. Viele Hersteller machen ein Geheimnis aus den Datenblättern ::)
Hast Du in meinen anderen Threads, wo es um ähnliche Sachen ging, schon die C-328 von Comedia entdeckt? Die gibt es z.B. beim Herrn Sander in Berlin. Diese Kamera sendet die Daten gleich als JPG-Datei mit 115200 auf der seriellen Schnittstelle. Die Parameter(Auflösung etc.) lassen sich auch über die serielle parametrieren. Ist aber relativ langsam! http://www.sander-electronic.de/gm00021.html Gruß AxelR (vonna arbeit ohne passwort, daher das "y" in der mailadresse)
Andere Frage: Wie sieht es eigendlich mit Netzwerkkameras aus? Sind die brauchbar? Welche ist empfehlenswert?
Hi! Wenn du noch BV durchführen willst solltest du gucken dass du auf raw Bildern arbeitest. Wenn ein Bild erstmal (verlustbehaftet) komprimiert war (zb JPG) dann findest du darin die tollsten "Informationen". Netzwerkkameras hab ich letztens was interessantes gefunden: http://www.elphel.com/ Dadrin werkelt auch ein fpga den man evtl umprogrammieren könnte. Denn die Kameras liefern auch nur einen komprimierten Datenstrom wenn ich mich richtig erinnere. Elphel hat auch Mitarbeiter/Benutzer in Deutschland, einfach mal hinmailen, die sind sehr hilfsbereit.
Bitte 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.