Intressant med FPGA-lösningen. Skall man måsta ge sig in i FPGA-träsket också? Går det hyffsat snabbt att slänga ihop en lösning med typ den spartan du tänkt dig? Eller är det en jäkla massa jobb?
Jag har en fråga angående matlabkoden du snickrade ihop. Att räkna ut förflyttningen med heltal genererar en jäkla massa fel över ganska så liten tid. Jag tänker mig att om du filmar med 120 Hz framerate så lär man väldigt ofta röra sig mindre än en halv pixel. Rör man sig 0.4 pixlar i 10 sekunder så får man inget utslag, men har rört sig 480 pixlar. Har du några tankar på hur man skall kunna få ut translationen med flyttal?
Korkens Optical Flow sensor
Re: Korkens Optical Flow sensor
Jag gillar FPGA idén, dock så har jag inte någon direkt känsla för hur jobbigt det kommer vara.
Just nu har jag en snurrande (I)FFT, complex normalisering och maximasökning. Så själva matematik delen va ganska enkelt.
Det jag tror kommer vara de jobbiga är kommunikationen med kameran och omvärlden.
Sitter och kollar på FPGA utvecklingskort på http://www.digilentinc.com/ så man kan testa lite.
Men testade skriva en UART lite fort och de va ganska enkelt om man inte ska ändra baudrate on the fly. Kamera interfacet kanske är jobbigare.
När det kommer till subpixel registrering så arbetar jag på det. Jag tänkte ta och göra en konvex approximering runt intensitetsmaxima och sedan ta toppen på den.
Då detta är en korskorrelation vi kollar på så kommer resultatet vara en sinc-funktion och ligger den inte perfekt förskjuten så kan man fortfarande approximera toppen.
Vad tror ni om det? Går att hitta en analytisk formel för det då också.
Idén jag har är att göra såhär (exempel i 2D):
Just nu har jag en snurrande (I)FFT, complex normalisering och maximasökning. Så själva matematik delen va ganska enkelt.
Det jag tror kommer vara de jobbiga är kommunikationen med kameran och omvärlden.
Sitter och kollar på FPGA utvecklingskort på http://www.digilentinc.com/ så man kan testa lite.
Men testade skriva en UART lite fort och de va ganska enkelt om man inte ska ändra baudrate on the fly. Kamera interfacet kanske är jobbigare.
När det kommer till subpixel registrering så arbetar jag på det. Jag tänkte ta och göra en konvex approximering runt intensitetsmaxima och sedan ta toppen på den.
Då detta är en korskorrelation vi kollar på så kommer resultatet vara en sinc-funktion och ligger den inte perfekt förskjuten så kan man fortfarande approximera toppen.
Vad tror ni om det? Går att hitta en analytisk formel för det då också.
Idén jag har är att göra såhär (exempel i 2D):
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: Korkens Optical Flow sensor
Kamerakommunikationen är väl mest att lägga in konfigurationsbit för rätt elektrisk signalering och implementera det bitprotokoll som kameran kräver?
När det gäller val av FPGA så är det nog lurt att först testa att syntisera det man behöver och därefter hitta ett chip som kan hantera krävd hastighet och matrisstorlek.
Utgår från att du har koll på värme, avkoppling, EMI osv.
När det gäller val av FPGA så är det nog lurt att först testa att syntisera det man behöver och därefter hitta ett chip som kan hantera krävd hastighet och matrisstorlek.
Utgår från att du har koll på värme, avkoppling, EMI osv.
Re: Korkens Optical Flow sensor
Att läsa av kameran är att läsa av en bitström med line/frame sync pulser.
Så tror inte att det är så svårt. Dock så konfigureras den via I2C.
Så om man ska ha en liiiten MCU som ställer in allt och sen bara låta FPGAn tugga datat eller om man ska försöka implementera en I2C också (jag personligen hatar dock I2C).
Avkoppling + EMI har jag bra kolla på, har dock aldrig räknat på värmeutvecklingen i FPGAer.
Finns det något bra sätt att räkna ut det? Annars får man väl välja stor kapsel och passande kylfläns.
Så tror inte att det är så svårt. Dock så konfigureras den via I2C.
Så om man ska ha en liiiten MCU som ställer in allt och sen bara låta FPGAn tugga datat eller om man ska försöka implementera en I2C också (jag personligen hatar dock I2C).
Avkoppling + EMI har jag bra kolla på, har dock aldrig räknat på värmeutvecklingen i FPGAer.
Finns det något bra sätt att räkna ut det? Annars får man väl välja stor kapsel och passande kylfläns.
Re: Korkens Optical Flow sensor
Tänkte lite på sub-pixelinmätningen. Nu tar du ju bara absolutbeloppet av ifft. Det är inte så att du kan använda fasen av ifft (eller om det blir innan ifft) för att bestämma förskjutningen på sub-pixel. Har inte tänkt igenom detta, men normalt manifesteras en förskjutning av en linjärt varierande fas i frekvensdomänen.
Re: Korkens Optical Flow sensor
Vad föredrar du över I2C?
Vilken lösning som är att föredra beror på om du föredrar mer hårdvara eller mer mjukvara. Med tanke på komplexiteten så är det nog enklast på sikt att implementera en liten processor i FPGA:n som drar i några I/O linjer. Den behöver ju inte fullt instruktionssätt.
För värmen skulle jag nog kika på avsedd spänning och max ström som kan komma ifråga. För en mer precis analys så borde switchtiden, antal grindar och användningsmönstret ge en hint med HDL-koden som utgångspunkt. Du har ju läst en hel del fysik så det borde vara enkelt
Annars är det väl bara att testa med ett chip.
Vilken lösning som är att föredra beror på om du föredrar mer hårdvara eller mer mjukvara. Med tanke på komplexiteten så är det nog enklast på sikt att implementera en liten processor i FPGA:n som drar i några I/O linjer. Den behöver ju inte fullt instruktionssätt.
För värmen skulle jag nog kika på avsedd spänning och max ström som kan komma ifråga. För en mer precis analys så borde switchtiden, antal grindar och användningsmönstret ge en hint med HDL-koden som utgångspunkt. Du har ju läst en hel del fysik så det borde vara enkelt
Annars är det väl bara att testa med ett chip.Re: Korkens Optical Flow sensor
Andax:
Jag tror inte på att göra det i Fourier domänen, för då måste du ta hänsyn till hela bilden (pga bruset mellan bilder).
Har du väl IFFTat den så har du bara en litet subområde av bilden som är intressant där intensiteten är hög.
I min idé så tänkte jag att man tar maxima + 2 pixlar åt alla håll så man får en 5x5 array man gör detta på så får man nog en riktigt bra approximation.
Eller hade du något speciellt i åtanke?
qx5:
Jag har aldrig gjort en I2C i HW, men är man van med STM32F1s I2C så ryggar man tillbaka lite när man hör ordet.
När det kommer till värmen så tror jag på din approach och bara testa. Det ska bli sjukt kul att bara lära sig början på FPGAer så detta blir nog en intressant resa!
Jag tror inte på att göra det i Fourier domänen, för då måste du ta hänsyn till hela bilden (pga bruset mellan bilder).
Har du väl IFFTat den så har du bara en litet subområde av bilden som är intressant där intensiteten är hög.
I min idé så tänkte jag att man tar maxima + 2 pixlar åt alla håll så man får en 5x5 array man gör detta på så får man nog en riktigt bra approximation.
Eller hade du något speciellt i åtanke?
qx5:
Jag har aldrig gjort en I2C i HW, men är man van med STM32F1s I2C så ryggar man tillbaka lite när man hör ordet.
När det kommer till värmen så tror jag på din approach och bara testa. Det ska bli sjukt kul att bara lära sig början på FPGAer så detta blir nog en intressant resa!
Re: Korkens Optical Flow sensor
En annan sak var om det inte skulle vara en idé att istället dela upp en 256x256 bild i 16 st 64x64 block och estimera var block för sig.
Då borde man kunna skatta rotation och skalningsförändringar....
Då borde man kunna skatta rotation och skalningsförändringar....
Re: Korkens Optical Flow sensor
Kanske man kan låna lite från mpeg-4:s "motion estimation" ..?
@Korken, I2C via direkt bitbangande är inte så jättesvårt. Dock så kan jag tänka mig att hårdvarutillverkare med inbyggd I2C i hårdvara har krånglat till det något infernaliskt. Det man bör tänka på är att det är en open-drain bus elektriskt. Samt att clock+data har viktiga sekvensordningar för att start och stopp skall fungera korrekt. Samt ordningen på läs/skriv osv och ACK bit på slutet.
@Korken, I2C via direkt bitbangande är inte så jättesvårt. Dock så kan jag tänka mig att hårdvarutillverkare med inbyggd I2C i hårdvara har krånglat till det något infernaliskt. Det man bör tänka på är att det är en open-drain bus elektriskt. Samt att clock+data har viktiga sekvensordningar för att start och stopp skall fungera korrekt. Samt ordningen på läs/skriv osv och ACK bit på slutet.
Re: Korkens Optical Flow sensor
Jag skulle inte lägga en softprocessor i den lilla FPGA:n. Det är bara ännu en grej som skall programmeras upp, och du skall lära dig programmera den också. Jag skulle satsa på att lägga I2C:n i FPGA:n. Det borde finnas färdiga block för det. Kanske tom färdiga block för just din kamera? Verkar det bli alldeles för jobbigt, lägg motvilligt på en processor som sköter den delen.
Sedan är jag inte heller så säker på att du behöver så mycket till kylfläns. Välj en så liten kapsel du kan, den fläns som går på den skall räcka. Vi har nått demokort här på jobbet med en spartan3.
En grej som jag funderat över, hur svår är artix-7:orna att jobba med gamla spartan3? Har inte verktygen blivit mycket modernare och enklare att jobba med? Artix-7:orna kostar iofs >250:- mot Spartan >100:-.
Sedan är jag inte heller så säker på att du behöver så mycket till kylfläns. Välj en så liten kapsel du kan, den fläns som går på den skall räcka. Vi har nått demokort här på jobbet med en spartan3.
En grej som jag funderat över, hur svår är artix-7:orna att jobba med gamla spartan3? Har inte verktygen blivit mycket modernare och enklare att jobba med? Artix-7:orna kostar iofs >250:- mot Spartan >100:-.
Re: Korkens Optical Flow sensor
Andax:
jag skulle undvika detta så långt det går, för då kan du få lokala fel.
Tar du hela bilden måste allt vara fel för att få en felregistrering.
Eller hade du någon speciellt teknik i åtanke?
qx5:
Det kan man säkerligen, men jag vet att FFT metoden är så stört robust så jag använder den så långt det går.
När det gäller I2C så hittade jag ett (inte riktigt komplett) VHDL tutorial på I2C, så tror inte det är svårt att implementera efter lite åtanke.
Sen hittade jag att det fanns ganska många på Opencores också.
Agwan:
Jag hittade block för I2C, men inte för kamera interfacet.
Värmeproblemet märker jag när jag börjar testa, behövs en kylfläns så behövs det - annars struntar jag i det.
Jag kollar mest på Artix-7 just nu och vad jag kan se så är den mycket trevlig.
Ska prata med min handledare imorgon så vi köper in några utvecklingskort som man kan testa med.
Tänkte ett Artix-7 kit och ett Spartan-6 kit från Digilent.
jag skulle undvika detta så långt det går, för då kan du få lokala fel.
Tar du hela bilden måste allt vara fel för att få en felregistrering.
Eller hade du någon speciellt teknik i åtanke?
qx5:
Det kan man säkerligen, men jag vet att FFT metoden är så stört robust så jag använder den så långt det går.
När det gäller I2C så hittade jag ett (inte riktigt komplett) VHDL tutorial på I2C, så tror inte det är svårt att implementera efter lite åtanke.
Sen hittade jag att det fanns ganska många på Opencores också.
Agwan:
Jag hittade block för I2C, men inte för kamera interfacet.
Värmeproblemet märker jag när jag börjar testa, behövs en kylfläns så behövs det - annars struntar jag i det.
Jag kollar mest på Artix-7 just nu och vad jag kan se så är den mycket trevlig.
Ska prata med min handledare imorgon så vi köper in några utvecklingskort som man kan testa med.
Tänkte ett Artix-7 kit och ett Spartan-6 kit från Digilent.
Re: Korkens Optical Flow sensor
Senast redigerad av Korken 17 september 2014, 19:02:59, redigerad totalt 1 gång.
Re: Korkens Optical Flow sensor
I2C kontrollern behöver väl egentligen inte vara så komplicerad:
1) Ladda värde
2) Skicka värde
3) Repeat ad infinitum..
Eventuellt med något tillägg:
1) Läs värde
2) Om( x==5 ) så.. Sätt värde = 2 annars värde = 5
osv..
Sammanfattningen är att det borde gå att klara av med en väldigt enkel tillståndsmaskin som absolut inte behöver ha komplexiteten av en processor. Fördelen är att man slipper fler fysiska saker. Och genom att hålla kontrollern enkel så sparar man matrisutrymme i FPGA:n.
1) Ladda värde
2) Skicka värde
3) Repeat ad infinitum..
Eventuellt med något tillägg:
1) Läs värde
2) Om( x==5 ) så.. Sätt värde = 2 annars värde = 5
osv..
Sammanfattningen är att det borde gå att klara av med en väldigt enkel tillståndsmaskin som absolut inte behöver ha komplexiteten av en processor. Fördelen är att man slipper fler fysiska saker. Och genom att hålla kontrollern enkel så sparar man matrisutrymme i FPGA:n.
Re: Korkens Optical Flow sensor
Så! Nu är två utvecklingskort på väg!
Ett baserat på Spartan 6 LX 45 med SD RAM på så man kan lära sig det och ett Artix 7 100T baserat kort.
Nu har jag både logik och dsp styrka så det räcker och blir över.
Ett baserat på Spartan 6 LX 45 med SD RAM på så man kan lära sig det och ett Artix 7 100T baserat kort.
Nu har jag både logik och dsp styrka så det räcker och blir över.
