Korkens Optical Flow sensor
Re: Korkens Optical Flow sensor
Annars finns ju alltid latvägen. Mer CLB (grindar) och mer MHz. Fråga bara Intel.. det verkar lösa alla problem
Re: Korkens Optical Flow sensor
Okej, har gjort lite uppskattning av minnesanvändningen för denna algoritm och det ser ut som att jag kommer behöva ett externt minne.
FFTn som måste sparas mellan varje iteration kommer ta 2176 kbit minne vilket överskrider ish alla FPGAers block RAM i den billiga sektorn.
Utöver detta kommer tex en bild behöva buffras, temporära beräkningar osv. Så blir att smyga in några MB med RAM.
Utöver detta så har jag uppskattat lite resursanvändning av FFTn (helt pipelinead, 256 bins, 8 bitar in):
- 12 DSP48 slices
- Ca 1100 SLICEs
Då får man ca 390k FFTer/s vid 100 MHz och det är ingen omöjlighet att ha mer än en i parallell.
Själva algoritmen behöver 245760 FFTer/s vid 120 Hz så man har lite utrymme där också.
Så summa summarum: Det borde gå att göra!
FFTn som måste sparas mellan varje iteration kommer ta 2176 kbit minne vilket överskrider ish alla FPGAers block RAM i den billiga sektorn.
Utöver detta kommer tex en bild behöva buffras, temporära beräkningar osv. Så blir att smyga in några MB med RAM.
Utöver detta så har jag uppskattat lite resursanvändning av FFTn (helt pipelinead, 256 bins, 8 bitar in):
- 12 DSP48 slices
- Ca 1100 SLICEs
Då får man ca 390k FFTer/s vid 100 MHz och det är ingen omöjlighet att ha mer än en i parallell.
Själva algoritmen behöver 245760 FFTer/s vid 120 Hz så man har lite utrymme där också.
Så summa summarum: Det borde gå att göra!
Re: Korkens Optical Flow sensor
Tänker du dig ha möjligheten att använda en vald referensbild då också? Dvs vid ett givet tillfälle sparas en bild från kameran som sedan används för att beräkna förskjutningen till alla nästkommande bilder.
Sedan hade det varit grymt bra att få någon slags kvalitévärde på hur bra det gått att skatta förskjutningen. I ditt matlabprogram plottade jag genomskärningen i iFFT-bilden runt maxvärdespunkten och tittade på grundbruset och värdena runt maxpukten så kunde jag får en känsla för hur bra det går. Tror du det skulle gå att få ut ett värde som grovt estimerar kvalitén?
Sedan hade det varit grymt bra att få någon slags kvalitévärde på hur bra det gått att skatta förskjutningen. I ditt matlabprogram plottade jag genomskärningen i iFFT-bilden runt maxvärdespunkten och tittade på grundbruset och värdena runt maxpukten så kunde jag får en känsla för hur bra det går. Tror du det skulle gå att få ut ett värde som grovt estimerar kvalitén?
Re: Korkens Optical Flow sensor
Att ha en referensbild är ganska enkelt, bara att inte byta ut den gamla FFTn i systemet så de kommer gå enkelt.
Just kvalitén av estimeringen borde gå att fixa. Man kan ha typ SNR i närområdet av toppen.
Har dock inte funderat på detta. Men någon form av kvalitetsmärke borde gå att fixa.
Just kvalitén av estimeringen borde gå att fixa. Man kan ha typ SNR i närområdet av toppen.
Har dock inte funderat på detta. Men någon form av kvalitetsmärke borde gå att fixa.
Re: Korkens Optical Flow sensor
Hmm, funderar på om det skulle gå att använda den här kameran för att få hög positionsupplösning i en DIY pick and place-maskin också. Jag tänker mig att jag tittar med en kamera på footprintet som jag skall placera komponenten på, så sitter den här kameran på en offset från den andra kameran. Pick/place-verktyget sitter såklart på en liten offset från huvudkameran, så jag steppar den offseten efter att ha tagit en bild på footprintet med huvudkameran och så triggar jag flow-sensorn på att spara sin bild. Sedan hämtar jag komponenten och rör mig till exakt samma plats, väl grovt nära switchar jag över till flowsensorn som talar om hur fel jag fått samma position och styr in exakt till rätt med hjälp av den. Med mikroskop på kameran borde tillräckligt hög noggrannhet kunna uppnås.
Fördelen jag ser är att offseten mellan huvudkamera, plockverktyg och flow-sensor inte ändras utan bara behöver mätas upp noga en gång. Så alla glapp och temperaturutvidgningar försvinner (temperaturen ändras förhoppningsvis inte mycket under tiden av en snabb plockning och placering).
Fördelen jag ser är att offseten mellan huvudkamera, plockverktyg och flow-sensor inte ändras utan bara behöver mätas upp noga en gång. Så alla glapp och temperaturutvidgningar försvinner (temperaturen ändras förhoppningsvis inte mycket under tiden av en snabb plockning och placering).
Re: Korkens Optical Flow sensor
Hur går det för dig? Har du något färdigt till helgen så att jag kan börja experimentera lite?
Re: Korkens Optical Flow sensor
Hehe, tyvärr inte. Mycket med doktorerandet just nu.
Men har ish testat alla viktiga delar, bara RAM interfacet kvar att leka med.
Men har ish testat alla viktiga delar, bara RAM interfacet kvar att leka med.
Re: Korkens Optical Flow sensor
Kom ihåg att jag gärna är med och finansierar och testar i det här projektet. Om du kommer förbi Stockholm någon gång kanske vi kunde träffas och prata lite runt hur vi vill använda din lösning.
Re: Korkens Optical Flow sensor
Oj, det låter mycket generöst av er!
Men jag kommer ner till Stockholm den 19e december, om ni vill träffa mig så kan vi ordna det (vi kan ta det via PM).
Lite uppdateringar:
Då jag har lagt tid på KFly nu ett tag så är det lite paus här.
Jag håller på att testar/lär mig hur man använder RAM bäst och generellt sätt är det inga problem (och hastigheterna detta system kräver är inget speciellt.
Jag har dock märkt att jag ibland får bit-fel när skriver/läser RAMet... Ska gå till botten med vad som gör detta så ska jag komma tillbaka med en rapport!
Vet någon vad som kan göra detta?
Jag ligger inom specifikationer på RAMet i hastighet och resten låter jag memory interface generator i Xilinx verktyg fixa.
Men jag kommer ner till Stockholm den 19e december, om ni vill träffa mig så kan vi ordna det (vi kan ta det via PM).
Lite uppdateringar:
Då jag har lagt tid på KFly nu ett tag så är det lite paus här.
Jag håller på att testar/lär mig hur man använder RAM bäst och generellt sätt är det inga problem (och hastigheterna detta system kräver är inget speciellt.
Jag har dock märkt att jag ibland får bit-fel när skriver/läser RAMet... Ska gå till botten med vad som gör detta så ska jag komma tillbaka med en rapport!
Vet någon vad som kan göra detta?
Jag ligger inom specifikationer på RAMet i hastighet och resten låter jag memory interface generator i Xilinx verktyg fixa.
Re: Korkens Optical Flow sensor
Uppdateringsdags!
Nu efter ha varit på två konferenser så har jag dragit mig till föräldrarna över jul/nyår.
Då va tanken att jag skulle fixa det sista med KFly, men i rese-paniken så lyckades jag glömma det i Luleå...
Så då blir det att fixa med Optical Flow sensorn istället!
Vad har jag gjort? Jo jag har testat det mesta och har lyckats komma fram till att en Sprtan-6 LX16 ska räcka med ca 10% till godo.
Dock så hittar jag dåligt med tutorials på hur man använder interfacet genererat av MIG i Xilinx verktyg. Har någon en länk för detta?
Jag knegar MIG-databladet, men det är inte det minsta, så en praktisk genomgång är allt jag behöver egentligen.
Nästa sak jag märkte är att en Artix-7 35T kostar ca 50kr extra och har 3x DSP-enheter och massa mer logik.
Dock en sak stoppar mig, jag hittar inga bra referensdesigner för den.
Det som får mig att fundera på om jag ska ta den istället är att Optical Flow algoritmen jag kör nu har en liten extension som gör att den också detekterar rotation och skalning.
Detta skulle man kunna använda för att beräkna hastighet i höjdled samt använda den för att estimera gyrobias i z-axeln. Då skulle man komma undan magnetometern som gör ett så fruktansvärt jobb om det finns störningar.
Nästa sak är ett "I-landsproblem".
Då algoritmen behöver ca 4MB med RAM (i ca 120MB/s) så kommer jag behöva ett extern RAM.
Och Artix-7an stödjer bara DDR2 och DDR3 (och ironiskt nog är dessa billigare än DDR/LPDDR). Så jag har gått en industrikurs i höghastighets design samt fixat licens för Altium 15 (fick den gratis om jag bara tackar Altium i artiklar jag skriver där jag använder saker jag designat i Altium ).
Så med dessa nya kunskaper och verktyg så blir det att designa min första riktiga höghastighetsdesign.
Men frågan kvarstår... Ska man ta Artix-7an istället för Spartan-6an?... Blir det att man måste upp till Spartan-6 LX25 för någon anledning så är Artix-7an billigare samt att det är det framtidssäkra valet.
Samt blir det Artix-7an så tar jag ett DDR2 minne, dessa fanns i trevliga priser och lagom stora BGAer (ca 10x10mm).
Hur skulle ni göra i detta val?
Känns som jag kanske stirrar mig blind på priser ibland istället för att göra den bästa sensorn jag kan...
Nu efter ha varit på två konferenser så har jag dragit mig till föräldrarna över jul/nyår.
Då va tanken att jag skulle fixa det sista med KFly, men i rese-paniken så lyckades jag glömma det i Luleå...
Så då blir det att fixa med Optical Flow sensorn istället!
Vad har jag gjort? Jo jag har testat det mesta och har lyckats komma fram till att en Sprtan-6 LX16 ska räcka med ca 10% till godo.
Dock så hittar jag dåligt med tutorials på hur man använder interfacet genererat av MIG i Xilinx verktyg. Har någon en länk för detta?
Jag knegar MIG-databladet, men det är inte det minsta, så en praktisk genomgång är allt jag behöver egentligen.
Nästa sak jag märkte är att en Artix-7 35T kostar ca 50kr extra och har 3x DSP-enheter och massa mer logik.
Dock en sak stoppar mig, jag hittar inga bra referensdesigner för den.
Det som får mig att fundera på om jag ska ta den istället är att Optical Flow algoritmen jag kör nu har en liten extension som gör att den också detekterar rotation och skalning.
Detta skulle man kunna använda för att beräkna hastighet i höjdled samt använda den för att estimera gyrobias i z-axeln. Då skulle man komma undan magnetometern som gör ett så fruktansvärt jobb om det finns störningar.
Nästa sak är ett "I-landsproblem".
Då algoritmen behöver ca 4MB med RAM (i ca 120MB/s) så kommer jag behöva ett extern RAM.Och Artix-7an stödjer bara DDR2 och DDR3 (och ironiskt nog är dessa billigare än DDR/LPDDR). Så jag har gått en industrikurs i höghastighets design samt fixat licens för Altium 15 (fick den gratis om jag bara tackar Altium i artiklar jag skriver där jag använder saker jag designat i Altium
).Så med dessa nya kunskaper och verktyg så blir det att designa min första riktiga höghastighetsdesign.
Men frågan kvarstår... Ska man ta Artix-7an istället för Spartan-6an?... Blir det att man måste upp till Spartan-6 LX25 för någon anledning så är Artix-7an billigare samt att det är det framtidssäkra valet.
Samt blir det Artix-7an så tar jag ett DDR2 minne, dessa fanns i trevliga priser och lagom stora BGAer (ca 10x10mm).
Hur skulle ni göra i detta val?
Känns som jag kanske stirrar mig blind på priser ibland istället för att göra den bästa sensorn jag kan...Re: Korkens Optical Flow sensor
Lätt val för mig, Artix-7:an, 50:- hit eller dit spelar ingen roll, inte om det kostar 500:- extra heller. DDR2 skall inte vara så svårt att få till. Grymt bra att du kör Altium med, jag bytte till det för några år sedan och är väldigt nöjd med det jämfört med OrCAD som jag använde innan. Jag kan ta ett titt på layouten när du kommer dit.
Re: Korkens Optical Flow sensor
Hur är det med verktyg för artix-7? Spartan-6 stöds ju av det gratis web-pack men för artix-7 har man väl gått över till vivalo? Finns den i gratis version?
Om det bara finns en gratis syntesprogramvara då tycker jag du ska satsa på prestanda om det bara skiljer 50:- i komponent kostnad.
Om det bara finns en gratis syntesprogramvara då tycker jag du ska satsa på prestanda om det bara skiljer 50:- i komponent kostnad.
Re: Korkens Optical Flow sensor
Verkar som Artix-7 35T stöds av Vivado WebPack som är gratis.
http://www.ti.com/lit/ug/slyu017/slyu017.pdf
Sedan har Avnet ett evalkort som man kan snegla på.
http://www.ti.com/lit/ug/slyu017/slyu017.pdf
Sedan har Avnet ett evalkort som man kan snegla på.
Re: Korkens Optical Flow sensor
Agwan:
Oj, så pass? Jag tänkte själv om HW började kosta mot 1000 kr så börjar det kanske bli för dyrt?
Just nu ligger det på ca 500 kr, vilket är okej - men om jag vill så kan jag då till och med uppa från Artix-7 35T.
Vill man verkligen ta i för framtida grejer så ska 100T passa i samma footprint bara strömförsörjningen räcker.
Samt tack att du kan kolla designen!
Jag sitter och plockar ihop komponenter å så nu, så ska snart börja dra ihop schemat.
Andax:
Jodå, WebPack av Vivado funkar fint! Det enda som man kan klaga på är att bara en dator per konto kan få en WebPack licens för Vivado...
Så jag sitter nu med 3 konton så jag kan ha det på min stationära, bärbara och jobbdatorn.
Samt tack för referensdesignen!
Jag hittade också denna vilket är exakt vad jag behöver (har DDR2 och rätt FPGA): http://www.digilentinc.com/Products/Det ... =NEXYS4DDR
Så nu har jag två referensdesigner att jämföra med!
Dock, jag hittar inte Artix-7 35T i CSG324 kapsel. Finns massvis i FT256, men kör man den så måste man ha minnesinterfacet i Bank 14 och 15.
Detta rekommenderar inte Xilinx (då alla config pinnar sitter i de bankerna, problem med störningar? ), utan de rekommenderar bank 34 och 35. Men på FT256 så tillåter inte MIG-verktyget att jag tar in klockan i bank 34 (FT256 kapseln har inte en klockbuffer där), vilket krävs för att minnesinterfacet ska fungera...
Vet någon man man kan få tex Digikey att ta in den kapseln? De har den, men inte i stock, så man måste köpa minst 126 stycken viket är lite väl många för en prototyp.
Kollade också på http://www.octopart.com och inga tycks ha CSG324-versionen in stock (förutom 100T versionen)...
Oj, så pass? Jag tänkte själv om HW började kosta mot 1000 kr så börjar det kanske bli för dyrt?
Just nu ligger det på ca 500 kr, vilket är okej - men om jag vill så kan jag då till och med uppa från Artix-7 35T.
Vill man verkligen ta i för framtida grejer så ska 100T passa i samma footprint bara strömförsörjningen räcker.
Samt tack att du kan kolla designen!
Jag sitter och plockar ihop komponenter å så nu, så ska snart börja dra ihop schemat.Andax:
Jodå, WebPack av Vivado funkar fint! Det enda som man kan klaga på är att bara en dator per konto kan få en WebPack licens för Vivado...
Så jag sitter nu med 3 konton så jag kan ha det på min stationära, bärbara och jobbdatorn.
Samt tack för referensdesignen!
Jag hittade också denna vilket är exakt vad jag behöver (har DDR2 och rätt FPGA): http://www.digilentinc.com/Products/Det ... =NEXYS4DDR
Så nu har jag två referensdesigner att jämföra med!
Dock, jag hittar inte Artix-7 35T i CSG324 kapsel. Finns massvis i FT256, men kör man den så måste man ha minnesinterfacet i Bank 14 och 15.
Detta rekommenderar inte Xilinx (då alla config pinnar sitter i de bankerna, problem med störningar?
), utan de rekommenderar bank 34 och 35. Men på FT256 så tillåter inte MIG-verktyget att jag tar in klockan i bank 34 (FT256 kapseln har inte en klockbuffer där), vilket krävs för att minnesinterfacet ska fungera...Vet någon man man kan få tex Digikey att ta in den kapseln?
De har den, men inte i stock, så man måste köpa minst 126 stycken viket är lite väl många för en prototyp.Kollade också på http://www.octopart.com och inga tycks ha CSG324-versionen in stock (förutom 100T versionen)...
