Hallo, kann mir einer vielleicht einen Tip geben, was ich für ein FPGA-Board verwenden sollte? Ich will eine CMOS-Kamera dranhängen (max. VGA) und ein paar Alogrithmen drüberlaufen lassen (Kantenerkennung, Bewegungserkennung). Das Board sollte möglichst klein/leicht sein, und billig ;) Danke, Nico
Wie wärs denn damit? http://www.terasic.com/english/fpga_04.htm Da ist ein Videoin für PAL/NTSC drauf. Viele Grüße TobiFlex
Weist Du, was FPGA heißt? "ein paar Alogrithmen drüberlaufen lassen" hört sich nach verdammt wenig Ahnung in der Materie an. Sonst nimm einfach Spartan3-Starter Kit von Xilinx, für 99$ Kest
@TobiFlex: Das übersteigt wohl etwas mein Budget.. Danke trotzdem. @Kest: Sorry, das ich mich etwas salopp ausgedrückt hab, ich bin im Hauptstudium Informatik und kenn mich genügend in VHDL aus, um die Komplexität des Projekts einschätzen zu können. Der FPGA soll ein Kamerabild auswerten und nur noch ausgeben: Kamera hat sich nach links/rechts etc bewegt, das Bild als solches ist mir total egal. (In C funktioniert das schon super, muss aber embedded werden). Das bedeutet auch, dass das board keinen ps2/vga/ethernet/IrDA/etc zu haben braucht. d.h. von der Theorie hab ich Ahnung, aber nicht von der Praxis, da ich keinerlei Praxiserfahrung mit fpgas habe, z.b. kann ich nicht einschätzen, wieviele Gates das Ding haben sollte. Da du also zur Hälfte recht hast, überseh ich den leicht beleidigenden Ton von "verdammt wenig Ahnung" und weise darauf hin, dass ebendiese der Grund war, warum ich hier nachgefragt hab.. Nix für ungut, Nico
"Das übersteigt wohl etwas mein Budget.." Wenn Du Student bist hast Du hier einen klaren Vorteil. Schau mal auf die letzte Seite von: http://www.terasic.com/attach/fpga_04/DE2_Introduction.pdf Das Board wird für Universitäten für 269$ angeboten. Und der FPGA ist "riesig". Viele Grüße TobiFlex
Sorry, hab heute nicht sehr gut geschlaffen :-/ Dann muss ich Dir auch nicht erklären, dass C und FPGAs wenig zu tun haben. Wenn schon so, dann steig mal auf MICROBLAZE oder NIOS um. Dabei läuft im FPGA ein 32-Bitter, und Du kannst dann in C alles machen. Du brauchst aber Speicher. Der Knackpunkt ist - wie hängst Du die Kamera dran? Wenn Du mit FPGAs nur wenig gemacht hast, dann entweder FPGA mit NIOS/Microblaze oder anderen Soft-CPUs, oder gleich ein ARM oder ähnliches. Oder eben DSP. Allein im FPGA alles zu machen, also nur SRAM, CMOS-Sensor und das war's wird so nicht gehen. Oder nicht so schnell. Es wird knifflig, obwohl es sich so einfach anhört: 3 Zeilen Code in C können schon Kilogatter bedeuten ;-) Wenn Xilinx - dann mind. 200k (wobei ich denke schon, dass man es auch mit 50k locker schafft). Bei altera, vielleicht 1c2 oder 1c4 oder wie auch immer die heißen mögen. Ist ein bisschen Logic: 1. CMOS einlesen (27 Mhz) 2. ins SRAM schieben 3. Ein Paar Pixel (9?) lesen, Filter berechnen 4. zu 2 gehen So... als einem Informatikstudenten im Hauptstudium habe ich doch ganz schön viel erzählt :-) Kest
Hi! Ich mach grad das gleiche mit nem spartan3 (200k) Ich lese Bilder von ner cmos cam (qvga) und speicher sie in nem asram. Gleichzeitig speichere ich noch ein in Farbklassen eingeteiltes bild mit je 2bit/klasse. noch dazu zeige ich das ganze live auf nem vga output mit 3bit farbtiefe an. Inklusive aufwendiger Farbklassifikation (erfolgt in einem pixeltakt!) brauche ich 93% der 200k Gates. 2% = vga out 3% = cmos input 1% = sram zeitmultiplexer 17% = i2c init (ka wieso, muss ich mal überarbeiten) rest = filtern Nur mal so als Einschätzung ;) Wobei mein Farbklassifikationsalgo schon sehr aufwendig ist da er 20 komplizierte berechnungen+vergleiche pro takt machen muss. Wenn ich von qvga nach vga gehe sollte sich an der ausnutzung nur minimal was ändern, ist schon für vga ausgelegt. Achja, der fpga läuft mit 50mhz, vga out und cam in je mit 25mhz. Da lässt sich aber sicher noch einiges optimieren.
93 % ?! :-o Sag' mal, vomit synthetisierst und fittest Du? Hab mal vor Jahren gelesen, dass man mit Xilinx Tools fast unmöglich ist über 70% zu kommen, weil der Rest für die Verdrahtung drauf geht :-o Oder sind die Tools jetzt besser geworden? Bei Altera sind es oft 98-99%, dachte ist was Ausergewöhnliches Kannst Du noch etwas über die Farbklassifikation etwas erzählen? Verstehe jetzt nicht ganz, was das ist :-o Kest
Ich hab das einfach in webpack geschrieben. Der zeigt mir am ende einfach an das ich 93% belege. Kann auch sein das er einfach die verdrahtung mitzählt ;) Ich glaub die 93% standen aber bei den system gates oder so. Wenn ich noch meinen ps2 input dazupacke bin ich bei 105% (bzw mehr) und es passt nimmer in den 200k 8) Farbklassifikation: Einfach den RGB, HLS oder YUV Farbraum in 4 farbklassen unterteilen. mich interessieren nur rot, weiss, evtl grau und schwarz (= alles andere). Mir gefällt das xilinx tool echt gut. hab aber auch noch nie vorher was mit fpgas/vhdl gemacht. bin echt überrascht wie gut der optimiert. wenn ich alle farbklassen gleich initialisiere kommt am ende sowas raus: Vcc |-----> output(0) GND |-----> output(1) und das ding brauch nur 1% für den filter 8) Was mir nicht ganz so gefällt ist dass es auf meinem celeron 1ghz gut 5min braucht um alles zu kompilieren 8)
Na ja... Früher hat mir Xilinx auch sehr gut gefallen :-/ Dann stieg ich auf Altera um, und muss sagen - bin begeistert! Es geht jetzt nicht um die Optimierung. Einfach um die Ergonomie! Da muss Xilinx noch viel lernen :-/ Ach, was soll's 5 Minuten ist doch nichts ;-) Kann mich erinnern, dass ich auf einem 800 Mhz Pentium 45 Minuten warten musste :-@ Die Zeiten sind aber wohl vorbei Zu der Farbklassifikation: verstehe immer noch nicht so genau, was das ist, kannst Du mal einen Stückchen (pseudo/c/VHDL)Code posten? Gruß, Kest
Wie ist das denn mit Soft-CPUs? Mein (absolut nicht optimiertes) C-Programm braucht @3GHz ca. 2-3 sekunden pro Bild, allerdings bei doppelter Auflösung (=vierfache Bildfläche), als ich eigentlich bräuchte. Glaubt ihr, dass das so überhaupt realisierbar ist? ich würde gern auf ca 10 fps kommen... allerdings macht ein MPEG4-encoder fast das gleiche wie mein Programm, und noch mehr, also geh ich davon aus, das es eine Lösung gibt (einem Mathematiker würde das schon reichen..)
Ausserdem macht jede optische Maus quasi das gleiche, wenn auch mit <50 Pixeln insgesamt und unter optimalen Bediungungen, da sie sich nicht mit veränderlichen Lichtbedingungen rumschlagen muss. Trotzdem ist der für den optischen Fluss zuständige Chip mit blossem Auge fast nicht zu erkennen ;)
pseudocode für yuv: if (y < 200 & y > 10 & u<20 ) then farbe := rot; if (y > 250 ) then farbe := weiss; ... Meiner ist aber wesentlich komplexer und basiert auf rgb. Kann da aber keine genauen Infos zu rausgeben, sorry ;) Zur Maus: Dort sind aber nur 128x128 Pixel drin oder noch weniger. Die arbeiten dann aber auch jenseits der 100fps (1000 oder so ? mal bei agilent hdcs20irgendwas optical mouse sensor gucken)
Wenn die tatsächlich mit doch so hoher Auflösung klarkommen, wäre das mal eine Überlegung wert. Allerdings muss das nicht auf dem Mauspad funktionieren, sondern in der Luft... und das möglichst zuverlässig. Und daran wirds wahrscheinlich scheitern, weil die Agilent chips für ganz spezielle Umgebungsbedingungen ausgelegt sind.
Optische Maus ist nicht VGA ;-) Dein C-Programm bringt dir nichts. Jetzt, weist Du ja, wie "theoretisch" das alles geht, aber im Endeffekt, wenn Du mit dem FPGA was machen möchtest, vergiss alles schnell. ...und ein MPEG4 Encoder in FPGA ist nicht ohne ;-) WAs genau musst Du mit dem Bild oder jedem Pixel machen? Die Rechnung ist einfach und trivial: 27 MHz VGA - wieviele Pixel fallen an? z.B. 50 MHz Frequenz - wieviele SRAM zugriffe können durchgeführt werden? SRAM - was ist das? Wieviele Takte pro Zugriff? Schreiben/lesen? Wieviele Frames sind gewünscht? Wieviele Operationen sind pro Pixel nötig? Dein C-Programm braucht also 2-3 sec pro Bild? Bist Du Dir im Klaren, was das bedeutet? Das sind 6 000 000 000 Operationen pro Sekunde... brrr... Sogar wenn dein Programm noch optimiert werden kann, vergiss am besten FPGAs und nimm DSP. Nicht, dass man das nicht im FPGA machen kann, nein... Ich sag' Dir ehrlich, das ist sehr kompliziert mit nur "theoretischen" Grundlagen/Wissen. Kest
die optischen mausdinger sind nur auf graustufen basierend. Evtl sogar auf infrarot mitempfindlich... Sorry die hiessen nicht HDCS sondern zb ADNS-5020. Musst du mal gucken ob du da ne andere Linse vorbauen kannst und das dann in der Luft nutzen kannst ;) Einfach ne alke Maus zerlegen und experimentieren.
Boa, Leute... @Sssssss: >pseudocode für yuv: >if (y < 200 & y > 10 & u<20 ) then farbe := rot; >if (y > 250 ) then farbe := weiss; egal wie komplex Dein Teil sein mag, aber ist das nicht einfacher eine LUT zu nehmen? Oder bin ich einfach zu blöd? Ich wette, wenn Du hier Deinen Code reinposten würdest, würde sich einer oder anderer finden und den bis zum "geht nicht mehr" optimieren, sodas Du 95% nicht voll, sondern frei hast ;-) Gruß Kest
LUT geht aufm pc gut... Aufm fpga nicht: die LUT wäre >2MByte gross... 256*256*256*2Bit ... Sorry den code kann ich nicht posten, ist ein Uniprojekt bzw wird eines ;) Wie gesagt, hab noch nicht angefangen zu optimieren ;)
Das C-Programm war sozusagen nur Proof-of-concept. Es besteht aus mehreren Schleifen, die hintereinander über das Bild laufen, und zwei hab ich schn in eine gepackt durch geschicktes Falten der jewiligen Filtermatritzen.. es ist also durchaus noch Optimierungspotential vorhanden, und wenn man auf 160x120 geht, reduziert das die Rechenzeit nochmal auf ein Sechzehntel... Das hilft aber alles nichts. Zum Thema DSP: da hab ihc nicht mal theoretisches Wissen, ich bin allerdings für jede Anregung offen, und das ganze Projekt hat keinerlei Deadline, im Notfall läuft es eben erst in ein paar Jahren.. bis dahin gibt es dann vielleicht ja einen speziellen Chip, der mir das irgendwie abnehmen kann. Bis dahin überleg ich mir einen schnelleren Algo, vor allem der zweite Teil hat mindestens O(n³) Laufzeit.. --> das bedeutet eigentlich, dass das mit dem Sechzehntel wohl eher ein 4096stel wird... erstaunlich grübel
Hallo, Nico Um alles im FPGA zu implementieren, solltest Du Dich vom typischen C/PASCAL/JAVA/BASIC - DEnken lösen. Denk wie eine CPU. Pixel lesen - ein Takt. Pixel schreiben - ein Takt. Addieren - ein Takt und so weiter... Irgendwann verstehst Du auch, dass um Daten speichern zu können ein Takt nicht ausreicht (z.B. SDRAM, DDR...) Dann machst Du eine Statemachine, die FIFOs befüllt, leert... Da Du keine Deadline hast, dann vergiss die Wahl des FPGAs, und schreibe einfach VHDL -Code. Den simulierst Du, und sollte das klappen, synthetisierst den. Dann fasst Du Dich an den Kopf, weil Simmulation und Synthese zweit unterschiedlichen Sachen sind! Dann fängst Du vom neuen an... Irgendwann bist Du soweit, dass Du alles fitten kannst... Und wenn das geht - dann weist Du auch, welche FPGAs in Frage kommen. Und erst dann fäng die eigentliche Arbeit an - alles in Betrieb zu nehmen. Und noch was: werde Dir klar, was Du genau brauchst. Muss das VGA sein? Reichen vielleicht 256 Pixel? Oder sogar nur 16? Oder gar nur 5? Du musst doch nur die Richtung bestimmen, in welche sich die Kamera bewegt? Oder irre ich mich da? Wie genau soll alles sein? Wie schnell? Farbe oder Schwarzweis? Wie fein sind die Details, die erkannt werden sollen? Vielleicht kann ja alles einfach mit 4 Fotodioden gelöst werden ;-) Kest Guß Kest
Hallo, hab mal so ein Projekt gemacht mit Bildverarbeitung CCIR-601 (?) mit XILINX-FPGA, das ist alles keine Hexerei, aber man benötigt schon einige Erfahrung im Digital-Design, sonst hängt man sich an Kleinigkeiten auf. Habe damals im Prinzip Differenzen zwischen 2 Zeilen (Y-Richtung), innerhalb einer Zeile (X-Richtung) und zwischen 2 Bildern berechnet und an einen PPC geschickt. Wenn die Berechnungen nicht zu komplex sind, würde ich da keinen Soft-Prozessor bemühen, das geht alles mit ein paar FSMs und etwas Arithmetik. Extern war ein schnelles SRAM zur Speicherung eines Bildes angeschlossen (interner Speicher im FPGA war noch knapp). Du musst ganz gezielt die Stärken eines FPGAs nutzen (alles geht parallel, vieles lässt sich dem Zweck entspr. optimieren) dann klappt das schon ! Wenns mal klemmt wirst Du hier geholfen ....
@Kest: Das C-Programm hab ich auch nur deswegen geschrieben, um ungefähr rauszukriegen, was ich z.b. für ne Auflösung brauch, und ob ich farbe brauch etc. Im Endeffekt ist mir das auch total wurscht, mich interessiert nur die Bewegung der Kamera anhand des optischen Flusses: 2 Bilder hintereinander aufnehmen, und versuchen, von jedem [Objekt|Punkt|etc] einen Pfeil zum entsprechenden Punkt im nächsten Bild aufzustelllen. wenn das dann so aussieht: -> -> -> -> -> -> -> -> -> -> -> -> hat sich die Kamera z.b. nach links bewegt oder gedreht. wenn das eher so aussieht: \|/ -.- /|\ kamera hat sich nach vorne od. hinten bewegt. Und das kann sogar rcht komplex ausgewertet werden, a la wir bewegen uns nach vorne, aber ein hindernis kommta von rechts auf uns zu. aber das auswerten wollte ich dann nicht aufm fpga realisieren. Trotzdem soll die Genauigkeit so hoch wie möglich sein, und ich glaube, dass mit farbigen Bildern das "matching" der Bildbereiche weniger Fehler zulässt, weil mehr info im bild steckt. Jedenfalls muss ich da noch rumprobieren.. @FPGA-User: Könntest du mir bitte von deinem Projekt was zusenden, zumindest teilweise, oder ist das classified? Danke an dieser Stelle für eure Anregungen!
Hallo Nico, darf Dir leider nichts zuschicken - sorry. Aber ein paar Anregungen und Tipps sind schon drin, schreib einfach.
Hi, also wir haben in der Uni was ähniches gemacht, nur war das auf einem Virtex II pro. Ziel war es einen frei programmierbaren Grafikfilter über ein graustufen bild, welches im Ram liegt laufen zu lassen. Der Filter selbst betrachtet pro Pixel den Pixel selbst und die 8 umliegenden, multipliziert jeden Pixel mit je einem individuellen Gewicht, addiert alles zusammen und macht danach noch eine division durch einen 2er potenz. die gewichte und die division sind "von aussen" programmierbar und somit variabel. Das Ganze wurde dann noch so optimiert, dass bei jedem Takt 4 Pixel parallel in einer 7 stufigen pipeline berechnet werden. Das Ergebnis kommt dann auf eine (theoretische) geschwindigkeit von 198Mhz, wobei die Logik des Virtex nur bis ca. 100Mhz verkraftet. Ich denke, dass deine Idee mit nem Spartan schon möglich wäre. Bewegungserkennung als simpler vorher/nachher vergleich (ich hoffe, dass ich dich da richtig verstanden habe) sollte kein problem darstellen. Was meinst du mit kantenerkennung? Ich habe einen Filter in C programiert, der einen Pixel mit 4 umliegenden vergleicht (kontrastfilter) und ab einer bestimmten differenz diesen pixel in einem neuem bild kennzeichnet. Damit kann man konturen einfach und effektiv erkennen. Beides ist nicht so aufwendig, dass man nen virtex bräuchte. Gruß, Thomas
Hallo Von Conrad gibt es einen Video-Bewegungsmelder, vielleicht lohnt es sich mal dessen Methode näher anzuschauen. Er teilt das Videobild in 48 Felder auf und detektiert Helligkeitsänderungen nur in ausgewählten Feldern. Das ist natürlich wesntlich primitiver als die geplante FPGA-Geschichte Ich habe mir das Ding nur wegen seiner Möglichkeiten gekauft, vier Videosignale zu einem zu vereinigen 73 Christoph
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.