Korkens Optical Flow sensor
Re: Korkens Optical Flow sensor
Din kod exekverar fint, behövde ställa om bilddatat bara eftersom min kamera inte verkade stödja din upplösning. Det är svårt att säga hur bra det fungerar med så pass låg framerate. Jag kunde ställa ner storleken på datat som skall användas och då använda 1 istället för 4 på framegrabinteval. Ju fortare man kör desto enklare borde det vara för koden att beskriva translationen rent. Men man behöver isf gå ner på subpixelnivå när man letar efter största punkten annars får man för stort fel där. Det skall inte vara något problem att få ut det med den här metoden heller.
Det ser riktigt bra ut, jag kanske kan börja experimentera lite med det här, behöver fundera ut hur jag skall testa om det är bra nog. Det som sätter stopp är nog att min kamera är för slö, det blir bara suddiga bilder när jag rör lite snabbare.
Det ser riktigt bra ut, jag kanske kan börja experimentera lite med det här, behöver fundera ut hur jag skall testa om det är bra nog. Det som sätter stopp är nog att min kamera är för slö, det blir bara suddiga bilder när jag rör lite snabbare.
Re: Korkens Optical Flow sensor
Kul läsning! Gjorde en liknande grej på högskolan fast med data från en LIDAR istället för vanlig kamera.
Känns som en klockren grej att implementera och labba med på en modern smartphone. Bra kamera osv!
Känns som en klockren grej att implementera och labba med på en modern smartphone. Bra kamera osv!
Re: Korkens Optical Flow sensor
Jo en sak jag tänkte på nu när jag satt och labbade lite, du applicerar inget hammingfönster. Det skulle reducera kantproblemen vilket ger renare resultat.
Edit: Det är en sjukt stabil metod med fasskift. Det går att sabba 80% av bilden och den hittar ändå stabilt rätt skift. Jag skrev om programmet lite så att den tar en bild först och sedan håller den kvar i den och jämför skiftet från den. Sedan kan jag hålla handen framför kameran och blockera. Så plottar jag genomskärningen av fourier-bilden runt största värdet i X och Y, det visar rätt tydligt hur säkert resultatet är.
Edit: Det är en sjukt stabil metod med fasskift. Det går att sabba 80% av bilden och den hittar ändå stabilt rätt skift. Jag skrev om programmet lite så att den tar en bild först och sedan håller den kvar i den och jämför skiftet från den. Sedan kan jag hålla handen framför kameran och blockera. Så plottar jag genomskärningen av fourier-bilden runt största värdet i X och Y, det visar rätt tydligt hur säkert resultatet är.
Re: Korkens Optical Flow sensor
Agwan:
Jodå, jag lägger på en window function.
Kolla apply_window.m
Men jag håller med, den är sjukt stabil!
Jodå, jag lägger på en window function.
Kolla apply_window.mMen jag håller med, den är sjukt stabil!
Re: Korkens Optical Flow sensor
Det vore intressant att kombinera med principen från "normaliserad fattning" där man kan, mha ett sk certainty värde för varje pixel, på ett matematiskt stringent sätt hantera kanteffekter eller annan typ av missad data.
Re: Korkens Optical Flow sensor
Vad tänkte du på? En window function fixar kanteffekter.
Eller tänkte du på något annat?
Eller tänkte du på något annat?
Re: Korkens Optical Flow sensor
En window-funktion viktar ner effekten av kanter. Men om man använder principen kring normaliserad fattning (normalized convolution) fast i frekvensplanet så kan man ha en mask som är sk optimal. Det var bara en ide som dök upp.
Gissar att din metod mer än väl löser uppgiften med bravur. Det är bara nörden inom mig som spånar på!
Gissar att din metod mer än väl löser uppgiften med bravur. Det är bara nörden inom mig som spånar på!
Re: Korkens Optical Flow sensor
Aha nu hänger jag med! Jo, vill man ha det mer optimalt så kan man helt klart göra så!
Jag sitter just nu och leker i lite VHDL för att uppskatta hur stor FPGA man kan behöva för denna metod och det (lata, snabba) resultatet är lite dåligt.
Får inte plats med multiplikatorerna i en Spartan 3E (den minsta), så ska nog skriva lite mer pipeline-ade saker än använda de inbyggda.
Får se hur de går. Va ett tag sen sist jag knegade lite VHDL!
Jo, vill man ha det mer optimalt så kan man helt klart göra så!Jag sitter just nu och leker i lite VHDL för att uppskatta hur stor FPGA man kan behöva för denna metod och det (lata, snabba) resultatet är lite dåligt.
Får inte plats med multiplikatorerna i en Spartan 3E (den minsta), så ska nog skriva lite mer pipeline-ade saker än använda de inbyggda.
Får se hur de går. Va ett tag sen sist jag knegade lite VHDL!
Re: Korkens Optical Flow sensor
Jag ramlade över att i gratisversionen av Xilinx verktyg CORE Gen så fanns det en FFT som man kunde ställa in precis som man ville.
Stämmer det jag räknade så kommer FFTerna inte vara några problem (om man antar 256x256 bilder och 512 FFTer/512 IFFTer per bild) bara man har en lite större Spartan 3E.
Då tog jag 16-bitars fixed-point implementation för real och imaginär delen, allt i block RAM samt randix-2 implementation. Detta ger ca 10u s / FFT.
Detta funkar så bra sen att jag har ha 4 i parallell vilket ger ca 2.5 us/FFT - vilket är under kravet på 4.069 us/FFT för att kunna göra algoritmen i 240 Hz.
Detta tar då 12 av de 20 multiplikatorer som finns i den samt 9 Block RAM.
Låter detta vettigt eller har jag lekt för mycket med verktygen?
Stämmer det jag räknade så kommer FFTerna inte vara några problem (om man antar 256x256 bilder och 512 FFTer/512 IFFTer per bild) bara man har en lite större Spartan 3E.
Då tog jag 16-bitars fixed-point implementation för real och imaginär delen, allt i block RAM samt randix-2 implementation. Detta ger ca 10u s / FFT.
Detta funkar så bra sen att jag har ha 4 i parallell vilket ger ca 2.5 us/FFT - vilket är under kravet på 4.069 us/FFT för att kunna göra algoritmen i 240 Hz.
Detta tar då 12 av de 20 multiplikatorer som finns i den samt 9 Block RAM.
Låter detta vettigt eller har jag lekt för mycket med verktygen?
Re: Korkens Optical Flow sensor
Vad ska den klockas på enl core generator för att ge den prestandan?
Re: Korkens Optical Flow sensor
Det är vid 200 MHz och att en FFT tar 1653 klockcykler.
Låter det vettigt?
EDIT:
Oj, kollade fel på kamerachippet, vid 256x256 bild så går den i 120 Hz.
Så nu har man dubbelt så mycket tid som förut.
Låter det vettigt?
EDIT:
Oj, kollade fel på kamerachippet, vid 256x256 bild så går den i 120 Hz.
Så nu har man dubbelt så mycket tid som förut.
Re: Korkens Optical Flow sensor
qx5:
Jag skulle svara nja på det. Jag behöver sensorn för att kunna få bra inomhusflygning, men det är inget nytt ur vetenskaplig synpunkt.
Men jag arbetar på den på arbetstid när jag har hål över från allt annat.
Jag har luskat runt mer på FPGA fronten också. Finns det någon anledning att ha en Spartan 3E (500)?
För 10kr extra får man en Spartan 6 LX16 som har mer av allt egentligen och den bättre DSP48-slicen.
Vad brukar vara kriterierna när man väljer en FPGA? Att man först gör designen och sedan väljer FPGA, eller att man väljer FPGA och sen gör allt för att allt ska få plats?
Jag skulle svara nja på det. Jag behöver sensorn för att kunna få bra inomhusflygning, men det är inget nytt ur vetenskaplig synpunkt.
Men jag arbetar på den på arbetstid när jag har hål över från allt annat.
Jag har luskat runt mer på FPGA fronten också. Finns det någon anledning att ha en Spartan 3E (500)?
För 10kr extra får man en Spartan 6 LX16 som har mer av allt egentligen och den bättre DSP48-slicen.
Vad brukar vara kriterierna när man väljer en FPGA? Att man först gör designen och sedan väljer FPGA, eller att man väljer FPGA och sen gör allt för att allt ska få plats?
