www.mikrocontroller.net

Forum: FPGA, VHDL & Co. welcher FPGA für motion detection?


Autor: Nico Blodow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobiFlex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nico Blodow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: TobiFlex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nico Blodow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..)

Autor: Nico Blodow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Nico Blodow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Nico Blodow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....

Autor: Nico Blodow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Nico,

darf Dir leider nichts zuschicken - sorry.
Aber ein paar Anregungen und Tipps sind schon drin,
schreib einfach.

Autor: breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph Kessler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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]
  • [vhdl]VHDL-Code[/vhdl]
  • [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.