www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Embedded-System mit Kamera und genügend Performance für Bildverarbeitung


Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich (Dipl.-Inf.) bin gerade auf der Suche nach einer möglichst leichten 
Plattform mit integrierter Kamera und genug Rechenpower um onboard 
Bildverarbeitungsalgorithmen laufen lassen zu können. (Als erstes 
kleines Projekt will ich die Position der Kamera relativ zu einer oder 
mehreren Landmarken bestimmen (10fps würden sicherlich reichen)... 
später würden aber auch noch aufwendigere BV-Algorithmen hinzukommen...)

Am liebsten wäre mir (da Mikrokontroller, Mikroprozessor & DSP für mich 
Neuland sind (immerhin habe ich Erfahrungen im Bereich der 
Bildverarbeitung und C)) eine fertige Hardware-Lösung mit Kamera und 
einer Beispiel-Standalone-Applikation (als Source) in der bereits die 
Bilder in den Speicher geladen werden (so dass man über eine Array auf 
die Pixel (RAW oder bereits zu einem Farbbild vorverarbeitet) zugreifen 
kann) und gezeigt wird wie über UART (oder I2C) mit anderen Komponenten 
kommuniziert werden kann...

Folgende ganz interessante Produkte habe ich bisher gefunden:

Surveyor SRV-1 Blackfin Camera: http://www.surveyor.com/blackfin/ (mit 
Blackfin BF537 processor (500MHz))

VC21 Series Camera COG 
http://www.virtualcogs.com/store/product_info.php?... 
auf i.MX21 (VCMX212) COG 
http://www.virtualcogs.com/store/product_info.php?... 
(mit Freescale Semiconductor i.MX21 multimedia ARM9 processor (266MHz))

Kennt jemand diese? Oder kann mir noch andere (leistungsfähigere) 
Lösungen empfehlen?
Ich schätze die Surveyor SRV-1 Blackfin Camera sollte die 
leistungsfähigere Variante sein!? In diesem Thread hier 
Beitrag "Bildverarbeitung und Mustererkennung (Automobilbereich)" wurde ja jedenfalls schon 
der Blackfin DSP im Zusammenhang mit BV-Algorithmen empfohlen...

Für die Lösung von virtualcogs gibt es immerhin bereits ein kleines 
Standalone Beispielprogramm (inkl. Source) zum aufnehmen eines Bildes 
und übertragen des Bildes an den Computer: 
http://wiki.virtualcogs.com/index.php?title=VC21CC....
Bei der Surveyor SRV-1 Blackfin Camera wird standardmäßig eine eigene 
Firmware mitgeliefert ... allerdings befürchte ich dass ich mit dieser 
nicht so weit komme (werde in diese Richtung aber auch noch mal etwas 
recherchieren...).
Alternativ könnte ich aber uClinux darauf installieren oder meine 
Applikation Standalone dafür entwickeln. Zwei letzte Fragen dazu noch:
Würde meine Anwendung unter uClinux deutlich langsamer laufen / mit was 
für Jitter müsste ich in etwa rechnen?
Wie schwierig ist es mit der GNU-Toolchain und dem Blackfin erstmal so 
weit zu kommen, dass man in einer Standalone-Anwendung die Videobilder 
in den Speicher bekommt und man mit anderen Boards (über UART oder I2C) 
kommunizieren kann?

Viele Grüße,
Hannes

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
suche mal nach "Smart Cameras" bei AVT bzw. Cognex...

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

zur SRV-1 koennte ich ein paar Kommentare loswerden, allerdings bin ich 
diesbezueglich nicht ganz neutral :-)
Der SRV-1 ist ja eigentlich ein Roboter und nicht primaer eine 
Netzwerkkamera, aber ich bin sicher, dass Surveyor auch die Kameraboards 
einzeln verkaufen wuerde. Der Sensor ist ein Omnivision 9655, der schon 
einige Vorverarbeitung macht, man kriegt z.B. die Daten im YVUV-Format 
raus, was beim JPEG-Komprimieren oder manchen BV-Algorithmen eine 
Vorverarbeitungsstufe spart. Man kann aber auch andere OV-Chips 
dranhaengen, die Rohformate liefern. Grosser Nachteil am SRV1-Modul ist 
bloss, dass es keinen Ethernet-Anschluss hat, die Entwicklung unter 
uClinux wird so also recht muehsam, herausgefuehrt sind nur die UARTs.

Zu deinen Fragen bezueglich uClinux:
Die Performanceeinbusse und eine gewisse Latenz ist natuerlich gegeben, 
je nach Auslastung des Systems hast Du keine Garantie, dass du z.b. 10 
fps verarbeiten kannst. Wenn auf garantierte Latenzzeiten angewiesen 
bist, benoetigst du gewisse Echtzeit-Patches. Aus eigenen Experimenten 
ermittelt waeren etwa Latenzen von um die 100 µs drin, ohne Patch kann's 
aber laengere Haenger geben.
Falls du komplexere Algorithmen schreibst, gewinnst du allerdings mit 
uClinux wieder dank Cache. Ich schaetze mal, du verschenkst so etwa 5% 
Rechenzeit ans uClinux-Framework.

Zur Entwicklung: Ich biete eigentlich genau die Tools an, um in Kuerze 
zu einem Ergebnis mit GNU/uClinux/Blackfin zu kommen, diesbezueglich 
auch meine nicht ganz neutrale Aussage, dass das alles recht einfach 
ist:

- Coremodul (CSP Minotaur, Bluetechnix), oder STAMP BF537 eval kit
- ICEbear JTAG Adapter
- standalone 'shell' Code mit Beispielen zu i2c, SPI, PPI, etc.
- Adapter PPI -> Omnivision
- PC mit Debian/Ubuntu Linux fuer die Entwicklung

Mit Windows gehts natuerlich auch, allerdings kann man da kein 
Linux-Kernel compilieren. Falls man rein mit uClinux arbeitet und keine 
Treiber entwickelt, braucht's den JTAG Adapter nicht zwingend.

Hoffe, das hilft dir weiter.

Gruss,

- Strubi

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@mario

Die von dir empfohlenen Kameras sind sicherlich schöne Geräte. Habe 
allerdings das Gefühl, dass man dort keine Möglichkeiten besitzt seine 
eigenen BV-Algorithmen auf dem Gerät zum laufen zu bekommen... oder 
täusche ich mich da?


@strubi

Vielen Dank für deine ausführliche Antwort :-) Habe deine Anmerkungen 
aufgegriffen und noch mal ein wenig recherchiert...:

Bei der SVR-1 fand ich vor allem ganz schick, dass dort direkt eine 
Kamera schon bei ist. Ich bräuchte mir also dann keine Gedanken darum 
machen wie ich aus elektronischer Sicht die Kamera mit einem Blackfin 
verbinde. Nach deiner Antwort und weiterer Recherche* scheint mir das 
aber evtl. gar nicht so kompliziert... (allerdings sagen mir bisher noch 
nichts die angegebenen package options bei den OV-Sensoren wie z.B. 
CSP-22, 28-pin oder 38-pin CSP2, ... Sprich hätte noch keine Ahnung 
welche Sensoren sich anschließen ließen (und mit was für Steckern...)).

Zu uClinux: Was für Patches? Und auf was für Intervalle beziehen sich 
die 100µs (wäre ja lediglich eine 10000stel Sekunde)?

Zu deinen Entwicklungs-Tipps: Die Bluetechnix Module hatte ich auch 
bereits entdeckt... dachte aber ich würde dann zwingend ein EVAL- oder 
DEV-Board benötigen, so dass ich diese Lösung dann im Vergleich zur 
SVR-1 recht teuer fand. Da dies aber anscheinend gar nicht der Fall ist 
fände ich ein Bluetechnix CM-BF561 Core Module mit einem Kameramodul 
eine noch bessere Lösung (insbesondere da ich früher oder später 
vermutlich zwei Kameras benutzen will). Kannst du mir noch einen Tipp 
bezüglich der benötigten Adapter geben (PPI -> Omnivision/Kamera Modul)? 
Haben die Kameramodule Stecker die man kaufen kann oder lötet man ein 
Flachbandkabel direkt an die Sensoren? Und woran kann ich erkennen 
welche Kamera Module kompatibel sind?

Den ICEbear JTAG Adapter werde ich mir auch noch mal angucken (und wofür 
er genau benutzt werden kann). Verstehe ich das richtig dass du ihn 
entwickelt hast?

Was für "standalone 'shell' Code mit Beispielen zu i2c, SPI, PPI, 
etc..." meinst du?  Kennst du auch Code-Beispiele bezüglich einer oder 
sogar Stereo-Kameras?

Viele Grüße,
Hannes


* Auszüge aus der Diplomarbeit "Tinyphoon - Entwicklung einer 
Hardwareplattform für einen autonomen Fußballroboter" von Daniel 
Steinmair (http://www.steinmair.com/dipl/Tinyphoon_final.pdf):
Für die Bilderkennung ist ein geeignetes paralleles Interface für die 
Kamera nötig. Hierzu stellt der BlackFin eine 16 Bit breite PPI 
(Parallel Peripheral Interface) Schnittstelle zur Verfügung. Dazu gibt 
es noch einige Synchronisationsleitungen sowie einen Bustakt. Diese 
Schnittstelle kann unter anderem auch im für Videoanwendungen 
verbreiteten ITU656 Modus betrieben werden. ... Doch zunächst zur Kamera 
selbst: Es handelt sich, wie bereits erwähnt, um eine CMOS Kamera von 
Omnivision [OMN05]. Diese liefert Bilder in VGA Auflösung wahlweise im 
RGB, oder YUV Format. Zur Kommunikation werden mehrere Schnittstellen 
zur Verfügung gestellt.
Um die Kamera zu konfigurieren, dient ein proprietäres 
Two-Wire-Interface (TWI) namens SCCB (Serial Camera Control Bus). Dies 
ähnelt sehr dem I²C Bus. Damit können die internen Register gesetzt 
werden, die Anpassungen in der Bildvorverarbeitung erlauben (z.B. 
Empfindlichkeit, Weißabgleich, Kontrast, Helligkeit, u.a.). Außerdem 
können auch die Bildgröße (Tabelle 19) und das Übertragungsformat 
(Tabelle 18) eingestellt werden. ... Die Übertragung der Bilder erfolgt 
über einen 8-Bit breiten Datenbus. Zur Synchronisation liefert die 
Kamera einen Bustakt sowie H-Synch und V-Synch oder Href zur 
Bildsynchronisation. ... Die Kamera lässt sich über den PWDN Eingang 
abschalten, ein RESET Signal erlaubt das Rücksetzen des Chips. Außerdem 
will die OV7660 mit einem Takt versorgt werden. Damit die volle 
Bildwiederholrate von 30 Bildern pro Sekunde (fps) garantiert werden 
kann, sollte dieser 27MHz betragen. Da der Tinyphoon allerdings nicht so 
viele Bilder benötigt, wurde der gepufferte Systemtakt des 
BlackFin-Coremoduls CM-BF533 verwendet (25MHz).
Die Kamera benötigt drei unterschiedliche Versorgungsspannungen. Der 
Sensor wird mit 2.5V betrieben, der integrierte Bildprozessor verlangt 
eine Spannung von 1.8V. Die I/O-Spannung kann schließlich auf die 
Bedürfnisse der angeschlossenen Hardware angepasst werden und beträgt 
hier 3,3V.
Die Beschaltung ist denkbar einfach, zu beachten ist einzig, dass an den 
Leitungen des SCCB zwei Pullup-Widerstände vorzusehen sind. Die 
Datenleitungen können direkt am PPI-Port des BlackFin Core-Modules 
angeschlossen werden. Die genaue Pinbelegung ist im Kapitel 6.2 
nachzulesen.)
Unter http://www.tinyphoon.com sind auch noch weitere interessante 
Publikationen zu finden...

Autor: Strubi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,

ich versuch mal, eins nach dem andern zu beantworten:

SRV1/Omnivision-Sensoren: Es gibt von einer Firma "Comedia" in Hongkong 
fertige Eval-Module, habe mal eben ein aelteres Posting vorgegraben, wo 
mehr dazu steht:
Beitrag "Re: Bildverarbeitung und Mustererkennung (Automobilbereich)"

Fuer das STAMP-Board BF533/BF537 von Analog Devices haette ich fertige 
Adapterplatinen von Eval-Modul auf PPI (zum selberloeten), fuers 
Bluetechnix-Modul brauchst du allerdings irgend ein Basisboard mit den 
Mini-Steckern. Leider gibt's noch kein BF561 STAMP, und an nem EZKIT 
haettest du eine aehnliche Bastelorgie vor dir. Dann lieber ein sauberes 
Basisboard fuers CM-BF561 designen (meine Meinung, kein Ratschlag!).
Habe mal den Schaltplan des Adapters Omnivision -> PPI angehaengt.

Zu uClinux: Der Echtzeit-Patch nennt sich "Xenomai". Es gibt auch einen 
alternativen "Rt-preemt"-Patch, aber den habe ich nicht ausprobiert. 
Xenomai sieht mir nach einer etwas eleganteren Loesung aus, und 
funktioniert bisher prima. Die 100 µs beziehen sich auf die Zeit, die 
ein Prozess braucht, um auf die eintreffenden Videodaten zu reagieren 
(schliesst hier schon die Datenaqcuisition mit ein).

ICEbear: Das Ding ist von mir, drum mach ich mal besser nicht zu sehr 
Werbung :-) Prinzipiell kann man mit JTAG Hardware debuggen, Flashs 
programmieren, im Fall vom Blackfin direkt auf der CPU debuggen.

Zur "standalone shell": Separat zum ICEbear und der Toolchain biete ich 
unter http://www.section5.ch/software etwas Beispielcode an, um ohne 
Betriebssystem "mal schnell" ein Laempchen zum blinken zu kriegen. Da 
sind dann eben auch inzwischen ein paar Demos zum Ansteuern von SPI, 
PPI, usw dabei, ueber den UART kann man simple Kommandos ausfuehren, 
Bilder einlesen, als Dump ausgeben, etc.
Fuer Stereo hab ich leider nix, obwohl wir mal was angefangen haben mit 
zwei parallel Sensormodulen und nem CPLD, das die Videosignale 
gemultiplext in den BF537 einzieht. Gab aber Probleme mit der 
Bildsynchronisation..

Hoffe, das hilft dir erst mal weiter.

Schoene Gruesse,

- Strubi

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Strubi,

Danke für den Tipp mit den Sensor/Kamera-Modulen... anscheinend werden 
die Module dann ja über http://www.electronics123.net verkauft. Das 
AA-9620 oder AA-9655 war dort zwar nicht mehr zu finden... dafür aber 
das AA3620 mit 3.1MP: 
http://www.electronics123.net/amazon/datasheet/AA3620.pdf ... vermute 
das sollte genauso funktionieren und hatte vermutlich sogar für mich den 
Vorteil, dass ich auch aus etwas größeren Abständen noch Landmarken 
erkennen kann.

Zu dem Adaptern:
Danke für den Schaltplan! (Wozu der 2,5V Spannungsregler? Braucht das / 
brauchen die Kamera-Module nicht alle 3,3V?)
Ob wir das komplette Modul selber designen werde ich mir noch mal 
überlegen (bzw. mit einem etwas erfahrenen Löter besprechen).
Theoretisch würde es aber doch auch reichen sich einen passenden Stecker 
für das Bluetechnix-Core-Modul zu kaufen und dort (ggf. mit kleiner 
Adapterplatine) die gewünschten Pins abzugreifen oder?

Deinen Beispielcode werde ich mir jedenfalls auf alle Fälle auch noch 
angucken... VIELEN VIELEN DANK noch mal ... du hast mir schon mal sehr 
weitergeholfen!

Gruß Hannes

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,

also, Vorsicht mit dem Schaltplan, es gibt da ein paar 
Bestueckungsoptionen (interne/externe Clocks) - wenn's unklar ist, kann 
ich Details noch posten (muesst's jetzt aber auch nochmal rausgraben).
Die 2.5V sind fuer das OV9655-Modul, das tut zwar offensichtlich auf dem 
SRV1 auch mit 3.3, aber ich wollte die Option trotzdem mal haben.

Den Stecker kannst du natuerlich selber ans Coremodul anfrickeln, ev. 
kriegst du von Bluetechnix auch ein Sample mitgeliefert, wenn du die 
nett fragst :-) Allerdings haette ich jetz die Investition in ein 
kleines Design mit eigenem Evalboard gewagt, bei so freifliegenden 
Verdrahtungen hast kommst du doch oft mal an die Grenzen der Stabilitaet 
(sowohl mechanisch als auch elektrisch). Bei einem freifliegenden 
Omnivision hatte ich schon mal ein "double clocking" drin, also ein Bild 
sporadisch um ein Pixel nach rechts verschoben, bis ich das ganze 
debuggt hatte, haette ich auch gleich ein 'gscheites' Design machen 
koennen...

Lass uns mal wissen, wenn Du was am Laufen hast, ist immer interessant, 
was andere so an Kameraprojekten mit den Blackfins machen. Leider halten 
sich da die grösseren Kamerahersteller wie Cognex usw. immer sehr 
bedeckt..

Gruss,

- Strubi

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Strubi,

werde mich auch auf alle Fälle melden wenn ich/wir uns entschieden haben 
für eine Hardwarelösung... und hoffentlich dann auch nochmal etwas 
später wenn ich was am laufen habe (wenn ich's nicht zum laufen bekomme 
evtl. mit einem Hilferuf ;)).

Viele Grüße und vielen Dank,
Hannes

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als kurze Info:
Wir wollen jetzt zunächst mal mit der Surveyor SRV-1 Blackfin Camera 
anfangen  und versuchen dort verschiedene CMOS Kamera-Module 
anzuschließen...

Gruß,
Hannes

Autor: Darko Milovanovic (darko_mi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hai zusammen, gab menges interessantes Zeugs zu lesen.

Ich habe die einzelnen Produkte angeschaut, aber irgendwie komm ich da 
bei der Entscheidung nicht weiter :-(

Folgendermassen mein Problem:

Ich muss einen Kartenzähler entwickeln, bzw. ich muss das Muster auf 
einer Karte erkennen.

Bin flexibel, kann sozusagen alles verwenden...

Jedoch liegt aber der Preis fest, ich möchte eigentlich nicht mehr als + 
/ - 100 Euro pro Cam mit integriertem Logic Board (zur Mustererkennung) 
ausgeben.

Könnt Ihr mir villeicht helfen, was ich da einfaches nehmen soll???

Es geht um eine Semesterarbeit im Modul Embadded Systems.
Studiengang (Elektrotechnik)


Danke im Voraus auf eure Antwort

grüsse

Autor: gnom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 100 Euro
> ...
> Es geht um eine Semesterarbeit


Und Dein Uni Institut ist zu geizig Dir die passende Hardware zur 
Verfügung zu stellen?
Bzw. hast Du da schon gefragt?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OpenSource Kamera:

http://www.scs-vision.ch/de/leanxcam/hardundsoftware.html

Einziger Haken: Die komplette Entwicklungsumgebung (VMWARE)
inkl. fertig aufgebauter CAM kostet als Kit ~200 Euro.

Vielleicht kann man ja durch "freundliches Fragen" mit
dem Hinweis auf die Studienarbeit die Umgebung auch so bekommen.

Das nur so mal als Hinweis auf dieses Projekt. Vielleicht hilft es ja
weiter..

Autor: Darko Milovanovic (darko_mi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NE neee... Da liegt das Problem nicht, ich bekomm schon alles...

Aber die wollen das wir das selbst herausfinden :-) Was wir einsetzen 
sollten.
doch ich hab keinen blassen schimmer wie ich das rausfinden soll...

Eine Möglichkeit wäre ein FPGA (80Dollar) + Camera und dann die Daten 
extern schreiben, und gleichzeitig karten einlese + schreiben + 
analysieren :-)

Das Ziel ist es, die Anlage so billig zu machen wie möglich.

Und trotzdem einfach.
Die CMUCam3 kenn ich... aber eben... Wenn ich mal mein Gerät fertig 
entwickelt hab, kann ich das nie Verkaufen, da es vieeeeel zu teuer sein 
würde :-)


Deswegen dachte ich, ihr kenn da was tolles...

Style - "insider" :-)

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ein paar kurze Anmerkungen:

- Die Entwicklungsumgebung zur leanXcam ist kostenlos, auch nichts 
anderes als die offizielle toolchain von blackfin.uclinux.org.
- Die leanXcam ist m.E. im Preis wenig zu schlagen - ich kenne momentan 
nichts vergleichbares fuer low end machine vision. Habe mir auch gerade 
mal eine bestellt :)
- Es gibt noch die SRV1-Kamera mit rolling shutter Farbsensor 
(Omnivision). Die duerfte bei etwa 100 Euro ohne Zoll und Versand 
liegen. Nachteil: kein Ethernet. Die neue Platine von surveyor.com hat 
USB 2.0 (also WLAN-faehig), ist aber noch nicht raus.
- FPGAs machen die Kamera teuer (nicht die HWkosten, sondern 
Entwicklungskosten). Zudem muss man das Problem von Firmware-Update im 
Feld loesen.

Gruesse,

- Strubi

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.