Algorithme gevraagd voor mijn high-speed detectie systeem.

Ik denk dat je beter het verschil kunt pakken tussen elk pixel en zijn (bijna) directe buren, dan heb je eigenlijk al een afgeleide (helling) bepaald. Een geldige detectie zijn een positieve en negatieve piek na elkaar, op kleine afstand.

Iets anders wat me in je plaatje opvalt, is dat je bij een geldige detectie een monotoon oplopende en aflopende flank hebt, dus vanaf de piek gaat de lijn over 2 pixels achter eenvolgens omhoog en omlaag. Misschien kun je daar nog iets mee doen.

Op 30 maart 2013 18:18:07 schreef SparkyGSX:
Iets anders wat me in je plaatje opvalt, is dat je bij een geldige detectie een monotoon oplopende en aflopende flank hebt, dus vanaf de piek gaat de lijn over 2 pixels achter eenvolgens omhoog en omlaag. Misschien kun je daar nog iets mee doen.

Ja die vorm zal er altijd inzitten bij een geldige trigger. Dit komt omdat de laserstraal slechts een beperkte diameter heeft waardoor hij nooit meer dan enkele pixels gelijktijdig kan belichten. Bij een sterk signaal komen er max enkele pixels bij omdat er enkele in verzadiging kunnen gaan hierdoor wordt de top dan afgeplat maar die detecteren geeft zelden een probleem vanwege het grote signaal.

Het zijn vooral de heel lage signalen, die vb een piek van 5 unit rond het gemiddelde geven met links en rechts nog een pixel met iets lager signaal. Maar deze kunnen zweven op een hoger omgevingslicht en enkel met niveau's kan ik daar geen goede (veilige)detectie meer van maken.

ps: ik heb mijn huidige bereken methode in de topic bijgevoegd.
Ik gebruik ook die groene lasers om de straal zelf ook te kunnen zien in volle zon. Zo kan ik mijn toestel richten op de insecten. rode lasers zie ik niet zo goed ( typisch mannen oog probleem). Moest ik een bandpass filter vinden die een smalle doorlaat bezit op 525 nm (groene lasers) dan zou dit ook heel veel helpen. testen met een R72 highpass IR filter helpt te weinig (zonlicht gaat van 90 naar 52 units en dat is de moeite niet omdat ook het lasersignaal een beetje verzwakt. Voor een R72 filter zou ik een extra meetlaser op 830 nm moeten bijplaatsen.

Update:

Voor je eerste sugestie, ik ga proberen een opname in volle zon te maken en eens zien hoe die vormen daar voorkomen. Flanken van het laserlicht zullen idd zeer dicht bij elkaar liggen en altijd stijgend-dalen zijn, de volgorde ligt ook vast door het uitlezen van de line array. Trouwens zonlicht en geldig laserlicht op dezelfde pixels tellen altijd op in de sensor zolang er geen saturatie optreedt. ik moet wel even denken hoe dit praktisch moet uitgewerkt worden tijdens het scannen van de array.

Oeps waarschijnlijk ook niet zo moeilijk een paar shift register die de verschil richting geven, daar kan ik onderling dan gemakkelijk resultaten vergelijken met 1, 2 of meerdere bitjes delay onderling.... Ga er wat mee spelen...

De data toont idd dat dit goed mogelijk zal zijn hierbij enkele gedeelten uit de laatste 5 scan voor de trigger:

33 33 34 36 39 40 37 35 33 33 32
33 33 34 36 39 40 38 35 33 33 32
33 33 34 36 39 40 38 35 33 34 32
33 33 34 37 40 40 38 35 33 33 32
33 33 34 37 40 41 38 35 33 33 32 hier nu detectie (door die 41)

Deze laatse rij geef mij nu detectie omdat die meer dan 8 hoger is dan de gemiddelde waarde(32).

Aangezien de resolutie beperkt is tot 8 bits, zou je ook iets met een bucket sort kunnen proberen, waarbij je eigenlijk telt hoe vaak elke samplewaarde voorkomt. Je zou dan bijvoorbeeld kunnen bepalen of de hoogste 3 samples allemaal meer dan 5 punten boven de hoogste van de onderste 56 samples liggen (dus 5 samples negeren).

Je zoekt dan als het ware de hoogste piek in het plaatje, streept de hoogste 8 samples weg, kijkt wat het hoogste sample is wat je dan overhoudt, en bekijkt of de piek genoeg boven die quasi-piek detector uit komt. Het lijkt me trouwens ook wel handig om te bekijken of die 3 hoogste samples in ieder geval naast elkaar liggen.

Voor de analyse zou je kunnen proberen zoveel mogelijk te doen terwijl de samples binnen komen, maar zolang de vertraging voorspelbaar is, lijkt het me ook niet zo'n probleem om (een deel) pas te doen als alles ontvangen is, terwijl er tegelijk een nieuwe serie samples wordt binnengehaald.

In plaats van tellen hoe vaak elke waarde voorkomt, kun je ook bij elk binnengekomen sample zijn waarde in de array ophogen, en alle waarden eronder, zodat elk element in de array het aantal samples met die waarde of lager bevat, dat lijkt me verderop in het algoritme handiger.

Een alternatieve implementatie zou natuurlijk een lijst met de hoogste waardes kunnen zijn, waarbij je aan het eind dus een array met de 8 hoogste samples overhoudt. Het lastige daarbij is natuurlijk dat je steeds een nieuwe sample ergens in de lijst moet toevoegen, en de hele lijst moet doorschuiven, waarbij de laagste eruit valt.

[Bericht gewijzigd door SparkyGSX op zaterdag 30 maart 2013 22:00:04 (12%)]

ik heb je nog een mail gestuurd met info die ik helaas niet online mag zetten.

Bedankt SparkyGSX en Robert2411.

Robert, ik heb je mail ontvangen en een antwoordje terug gestuurt. Er valt zeker iets mee te doen.

@SparkyGSX ,

Berekeningen mogen over meerdere scanlijnen gaan, hoe minder hoe beter maar tot max 8 lijnen vertraging kan geen kwaad. Een vaste vertraging tot 8 scanlijnen komt overeen met 400 us totaal. Binnen deze tijd moet het trigger besluit zeker aanwezig zijn. Sneller is beter, nu hebt ik dit na een volle scan lijn of 50 us. Tenzij ik het digitaal filter inschakel en dan heb ik ook extra delay's van 50 us per extra lijn.

Er is ook verschil als je altijd alle data nodig hebt uit 8 scan lijnen. Dat wordt wel kritisch. Heel snel bewegende objecten blijven niet altijd een geldige signaal waarden geven over veel scanlijnen. Hierdoor wordt de trigger detectie te streng, je gaat wel geen slechte opnames maken maar ook heel weing goede. Dat er af en toe eens een minder gunstige trigger voorkomt is minder erg, die opname wip je eruit. Maar wat niet mag zijn random triggers onder invloed van de zon zelfs zonder dat je meetlaser aanligt. Ik heb een beeper die een signaal geeft als de triggervoorwaarde voldoet ( soms gebruik ik dit om te testen of een object zal trigeren). Als ik nu in de zon loop is de beeper af en toe te horen vooral in de buurt van struiken waar er veel licht variatie ontstaat onder invloed van de zon op de struiken. Het is zo een data dat ik de volgende tijd eens zal opnemen om een algemene indruk te hebben hoe die signalen random eruit zien.

Tot heden bereken ik de gemiddelde waarde van een gedeelte van de array (uit 64 van de 128 samples) het heeft weinig zin de buitenste pixels mee in rekening te brengen want ze vallen altijd buiten het detectie venster. Het ideaal detectie punt is 64 zijnde het midden van de array. Dit wordt zo afgesteld opdat de camera op die afstand perfect in focus staat. Via mijn toetsenboard kan ik dit referentie punt verschuiven als ik ondervind dat de beestjes niet de optimale afstand hebben. Rond dit referentiepunt neem ik dan 32 pixels links en 32 pixels recht voor de berekening van de gemiddelde waarde. Op het einde van de scanlijn kan ik deze som dan 6 bit shiften en bekom de gemiddelde waarde.

Ik heb ook een instelbaar detectie venster. Dit is een zone rond het ingestelde referentie punt. Normaal is deze rond +/- 12 pixels. Met een referentie waarde van 64 is dan een detectie toegelaten tussen pixel positie 64-12 = 52 en 64+12= 76. Tijdens het inlezen van de pixels onhoud ik de waarde en de positie van de hoogste pixel waarde. Als deze pixel in de detectie zone valt (tussen 52 en 76) wordt dit een geldige trigger. Naast deze geldige zone moet de piekwaarde een minimale waarde hoger liggen dan het gemiddelde om een trigger te valideren. Dit verschil is ook een parameter die ik op het display kan ingeven (noise parameter).

Maandag ga ik mij eens verdiepen hoe ik jullie tips kan verwerken en een test code schrijven. Het weer blijft koud, de beestjes vliegen toch niet. ideaal om dit op te lossen.

Beste dank voor alle tips!

Frans.

Ik neem aan dat je een verandering wil detecteren. Ik zou dus de 1ste (detecteert een flank) afgeleide nemen. Dat doe je door van elke scanline de vorige scanline af te trekken. Met deze data ga je dan aan de slag.
Ik kan wel eens naar de data kijken, maar dat lukt niet vandaag ivm familieverplichtingen.

Dag fotoopa,

Een mogelijke oplossing voor dit probleem is een DCT (Discrete Cosine Transform). Dit is de ruimtelijke tegenhanger van een FFT en wordt ondermeer toegepast in JPEG en MPEG. Dit klinkt ingewikkeld, is echter heel doenbaar. Elke kabel TV ontvanger heeft een inverse DCT of IDCT.

De output van een DCT is een array met de spectrale voorstelling van de beeldinhoud. Net zoals de DC component bij een FFT terecht komt in de eerste plaats van de array a[0], komt de gemiddelde luminantie eveneens terecht in a[0]. Door deze op 0 te zetten is deze dan weg. Als je dan nog kwantisatie toepast, dat is een moeilijk woord voor digitaal afronden, dan hou je enkel nog een mooie puls over.

1) DCT
2) A[0] = 0
3) Kwantisatie.
4) IDCT

Groeten

Bedankt JoWi & Yoko Tsuno.

Vandaag heb ik ook maar heel beperkt wat tijd. Morgen zal het beter zijn.

Voor Yoko Tsuno, Ik ken spijtig genoeg veel te weinig af van deze soorten berekeningen waardoor ik het niet kan omzetten. Termen zoals:
DCT
Kwantisatie
IDCT

zijn voor mij echt latijn. Met een beschrijvende opeenvolgende soort bewerkingen zou het mij wel moeten lukken maar ikzelf kan deze begrippen niet in de juiste bewerkingen zien.

Array's van data maken, fifo's voor meerdere lijnen op te slaan, dat is allemaal geen probleem. Daar heb ik vroeger al veel mee gewerkt. zo lang ik maar weet hoe de onderlinge bewerkingen moeten uitgevoerd worden op die data.

Update:

Ik heb zo een valse detectie opgenomen. Enkel het zonlicht heeft hierbij voor een ongewenste detectie gezorgt. De lasers waren niet in gebruik. Morgen herhaal ik deze test wel met terzelfde tijd een geldige trigger.

Oeps gezien de flitsen op de opname staan was er toch lasersignaal aanwezig. Ik zal deze test nog eens moeten overdoen want waarschijnlijk is de kleine midden piek wel de echte detectie. Die vorm komt in ieder geval wel overeen.

False detection due to the ambient sunlight by fotoopa, on Flickr

De detail tekening is de scan lijn 111, die de trigger veroorzaakte.

Update:
Ik heb die afgeleide eens gemaakt in excel en dat ziet er idd heel goed uit. Maandag ga ik verder....

Frans.

Dag Fotoopa,

- Ik wil je best wat helpen met de implementatie van dit DCT algorithme. Je zal echter nog altijd in staat moeten zijn om de data uit deze DCT te interpreteren. Een leerproces is dus onvermijdelijk en als het echt snel moet dan raad ik deze DCT ook af. Of deze methode beter scoort als "eenvoudige" algorithmes is moeilijk te zeggen. Wat ik wel kan zeggen is dat je na de DCT een veel beter inzicht hebt over de samenststelling en gedrag van dit omgevingslicht.

Voor je eraan begint kan je dit misschien even doornemen vanaf The discrete cosine transform(DCT) om te zien of dit gaat lukken. Dit artikel legt met een minimum aan wiskunde en in heel eenvoudige woorden uit wat een DCT doet. Omdat beelden meestal 2D zijn is dit hier ook een 2D-DCT. Laat iets van je horen. Als dit Chinees voor je is gaat het echt niet lukken vrees ik.

http://vsr.informatik.tu-chemnitz.de/~jan/MPEG/HTML/mpeg_tech.html

- Processing power: Wat type FPGA is dit? Om je een idee te geven hoe snel een DCT kan, in een TV setup box moet voor SDTV (Analoge PAL resolutie) ruwweg binnen 20ms, 3 matrices (Luminantie, Chrominantie Cr & Cb) van 720 x 576 pixels worden verwerkt. Het feit dat jouw DCT 1D is en minder pixels heeft is een voordeel.

Groetjes

Oei nee, dat gaat nooit lukken. Is veel te complex voor mij. Ook de snelheid zou een probleem kunnen zijn. Mijn huidig gebruikt algorithme die nu al in de meeste gevallen werkt heeft het resultaat in 50 us, dit is de scantijd voor de 128 pixels van 8 bit resolutie binnen te lezen in de FPGA. Direct nadat alle 128 pixels binnen zijn kan ik 500 ns later reeds het resultaat van de trigger weergeven.

De andere aangehaalde methodes van "Jowi" en "robert2411" lijken mij veel eenvoudiger en zijn hopelijk meer dan voldoende. Het is niet zo kritisch dat er nooit geen valse trigger mag zijn maar ze mogen niet om de 10 sec voorkomen. Trouwens als ik nu reeds het noise level wat verhoog vallen de meeste ongewenste triggers reeds weg. Enkel de gevoeligheid gaat hierdoor achteruit omdat de reflectie signalen wat sterker moeten zijn.

Ik heb al enkele simulatie's gedaan deze middag in excel en ik denk wel dat het zal werken. In de volgende dagen geeft ik hier wel de resultaten. Eerst moet ik nog enkele kritische opnames maken om de data te kunnen overtappen op de PC. Vandaar dat ik die nu in een 64 Kbyte ram bewaar tot de USB-COM poort verbonden is met de PC. Overtappen duurt 7 sec.

Voor realtime detectie mag ik zeker niet meer dan 8 scanlijnen van elk 128 pixels moeten gebruiken juist omdat hierdoor de delay 400 us wordt. Die 50 us is de minimale integratietijd van de line array + de uitlezing. De basis clock voor de line array en de ADC convertors draaien op 64 MHz. Langere integratie tijd overdag is ook niet gewenst want dan gaat het omgevingslicht nog meer oplopen tot zelfs saturatie. S'nachts kan ik dit wel verhogen, het is trouwens op mijn controller instelbaar tot 820 us. Hiermee kan ik uiterst kleine bewegende objecten zelfs minder dan 0.5mm op een afstand van 400 mm van de lens detecteren. Enkel in vol zonlicht komen de problemen.
Maar de meeste beestjes vliegen slechts als de zon uit zit!

De gebruikte FPGA is een Altera Cyclone IVE EP4CE22F17C6 met 22320 LE's en 608256 bits interne ram. Er zitten ook 132 stuks 9 bit multipliers in. 4 PLL's zorgen voor de nodige clokken.

Toch bedankt voor je steun

Ik zou eigenlijk niet weten waarom de oudere data, of een afgeleide in de tijd, interessant zou zijn voor het algoritme; wat voor algoritme zou je daar op los willen laten?

Ik vraag me af of dit niet eenvoudiger en betrouwbaarder op te lossen is met auto-correlatie, maar ook daar heb ik weinig ervaring mee.

Jammer dat de informatie van Robert2411 niet publiek gedeeld mag worden; ik neem aan dat dat komt omdat het eigendom is van een werkgever of zo?

@Robert2411: kun je er iets over vertellen, zonder de details die eventueel geheim moeten blijven?

Op 30 maart 2013 18:18:07 schreef SparkyGSX:
Ik denk dat je beter het verschil kunt pakken tussen elk pixel en zijn (bijna) directe buren, dan heb je eigenlijk al een afgeleide (helling) bepaald. Een geldige detectie zijn een positieve en negatieve piek na elkaar, op kleine afstand.

Een van de mogelijkheden dat Robert mij gestuurd heeft komt idd hiermee overeen. Hiermee ben ik nu verder data aan het vergelijken en simuleren. Het grote voordeel van mijn nuttig laser signaal is dat zijn breedte vrij beperkt en constant is. Zodra er dan een stijgende flank in het signaal voorkomt moet voor een geldig signaal enkele pixels later een duidelijke omgekeerd verloop aanwezig zijn. De laser kan bijna geen signaal geven over meer dan 7 pixels door zijn projectie diameter en het optisch meetsysteem. Dat is een enorm voordeel.

De fout die ik gemaakt heb is om over een bepaalde afstand het gemiddelde te berekenen als basis. Dat is niet juist tov de max 7 pixels goede puls door de laser. Omdat ik nu niet onderzochte of er zowel een positieve als een negatieve flank binnen een beperkte zone voorkwam krijg ik nu detectie bij iedere voldoende sterke flank. Die komen veel voor in felle zon door sterke uitgesproken schaduwen.

Ik denk dat jullie mij hier op de heel goede weg geholpen heb. ik implementeer zo snel mogelijk deze methode en zal die dan vergelijken met de vroegere resultaten.

Hallo Frans,

Ook even deze discussie gevolgd. Als ik het zo bekijk zal hier inderdaad een aardige stukje signaalprocessing nodig zijn om in volle zon er het piepkleine signaal uit te pikken. Misschien een beetje off-topic, maar moest er geen enkele van de voorgestelde methodes lukken, kan je misschien van de nood een deugd maken en juist van het sterke zonlicht optimaal gebruik maken. Mijn oplossing zou er in bestaan om op de data van de linesensor er een contrast detectie algorithme op los laten. Een eenvoudige methode - zeker niet optimaal - zou er in bestaan om van een aantal pixels b.v. de middelste 32 de som van de absolute verschilwaarden van de pixels onderling te maken. Deze som is dan een maat van het aanwezige contrast. Via een ingestelde of eventueel automatisch berekende drempelwaarde kan dan beslist worden de triggering in te zetten. Dus maximum contrast = beeld in focus.

Dit is wat ik bedoel in volgende stukje pseudo code :

//
// Check Contrast in Line Sensor
//
unsigned long contrast Check_Contrast(int arr_size)
{
int i; // loop counter
unsigned long abs_sum; // sum of absolute values

abs_sum = 0; // initialyse sum of absolute values

for (i=1;i<arr_size;i++)
{
abs_sum = abs_sum + abs(line_sensor_data - line_sensor_data[i-1]); // update sum of abs value's
}
return abs_sum; // return sum of absolute values
}

@Arnoldus,
De voorgaande tips die ik gekregen heb zijn heel eenvoudig. Op het einde van iedere scanlijn zou het resultaat reeds bekent zijn. Alle berekeningen gebeuren dan terwijl de pixels binnen lopen. Die afgeleide nemen is enkel een aftrekking, slechts 1 clock tick heb ik hiervoor nodig. Op het einde nog enkele testen en het is klaar.

Ondertussen heb ik hier een simulatie kunnen maken via kunstlicht. Die simulatie toont heel mooi aan waarom mijn huidige methode faalt.

patroon2 by fotoopa, on Flickr

Via 1 Kw belichting is hier een schaduw gesimuleert. Omdat ik de gemiddelde uit een deel van een volle scanlijn bereken als referentie komt door die schaduw plots de voorwaarde geldig voor een detectie.

Die voorwaarde was:
waarde op pixel 32 moet minimaal 20 eenheden boven het gemiddelde zijn. Door die schaduw wordt plots de gemiddelde waarde veel lager en voldoet de voorwaarde terwijl die helemaal niet door de laser komt.

Ah, maar dan is het duidelijk: je wilt een opgaande en een neergaande flank zien binnen 8 pixels. Iets wat je volgens mij prima kunt doen door een afgeleide te berekenen, en dan te kijken waar je een grote positieve waarde en een grote negatieve waarde binnen 8 pixels vindt. De x-positie van de piek zou dan precies tussen die twee waardes in moeten zitten.

Dag fotoopa,

Dit idee van deze dubbele afgeleide is inderdaad niet slecht denk ik. Dit wil echter wel zeggen dat je het netto sensorbereik wat inkort (20-tal pixels). Ik neem echter aan dat dit niet echt relevant is.

Ter informatie: In een DCT zou die schaduw zich manifesteren als een hoge waarde in het begin van de array a[1], a[2] en dit onafhankelijk van de locatie van de schaduw. Deze is dan volledig weg als je de waarde op 0 zet of kwantiseert.

Veel succes met het implementeren.

Op 1 april 2013 10:43:38 schreef alex278:
Ah, maar dan is het duidelijk: je wilt een opgaande en een neergaande flank zien binnen 8 pixels. Iets wat je volgens mij prima kunt doen door een afgeleide te berekenen, en dan te kijken waar je een grote positieve waarde en een grote negatieve waarde binnen 8 pixels vindt. De x-positie van de piek zou dan precies tussen die twee waardes in moeten zitten.

Ja dat klopt. Heb ik ondertussen reeds gesimuleerd in excel met een nieuwe test data. De resultaten zijn verbluffend goed en eenvoudig.

Ik heb eerst de afgeleide gemaakt maar met 2 pixels verschil dus x-x2 voor het aftrekken. Dit geeft gezien mijn laser systeem nog betere resultaten. Dan neem ik een afgeleide maar juist omgekeerd dus: x2-x Dit kan ik doen terwijl de pixels binnen gelezen worden. Via een korte shift register kan ik ze vertragen voor de bewerkingen. Met die beide afgeleiden ga ik dan mits onderlinge vertraging de lopende som maken. Zo worden de beide resultaten opgeteld en worden die sommen dubbel zo groot en binnen het geldig venster. Nu kan ik die sommen nog wat bijhouden om ze te onderzoeken in een triggervenster. Is er dan een som waarde die boven een minimale ingestelde ruiswaarde ligt dan heb ik de perfecte trigger. Bij de simulatie werkt het voorlopig perfect. Veel pixels verschuiven moet ik niet, hoogstens zullen er 5 of 6 nodige zijn. Dat wordt geen probleem. Nu nog de verilog code schrijen

@YokoTsuno,

Ja ik heb pixels over langs beide kanten. De array is 128 pixels waarvan ik er normaal nooit meer dan 32 nodig heb in mijn geselecteerd venster. Door het referentie punt van dit venster te verschuiven kan ik de zone voor de juiste trigger via mijn klavier bijregelen. Ook de toegepaste breedte van de triggerzone is instelbaar alsmede het ruisniveau maar ook nog eens de integratie tijd van de sensor. Die integratietijd heeft wel invloed op de scan tijd Maar in volle zon moet die integratietijd zo kort mogelijk staan om saturatie te vermijden.

Update:
Meteen nog een extra foto hoe ik de testopstelling gemaakt heb om de zon te simuleren en een ongewenste trigger te bekomen:

Test setup for detection algorithme C1B9479 by fotoopa, on Flickr

Met die 1000 W halogeen lamp en korte afstand kom het wel wat warm tijdens de testen!

Hiermee kan ik beter opnames vergelijken of de nieuwe algorithmes echt wel beter gaan werken. Nu volop de code aan het voorbereiden. Programatie wordt zo opgevat dat de instelling die invloed hebben op het algorithme via parameter setting gemakkelijk kunnen aangepast worden. Een ringbuffer voor de input sensor data kan hierbij veel helpen.

[Bericht gewijzigd door fotoopa op maandag 1 april 2013 17:04:36 (18%)]

Resultaat implementatie van het nieuwe algorithme.

Ik heb op basis van de gekregen tips hier in deze topic het algorithme uitgewerkt. Meteen heb ik vele data eerst opgenomen om een simulatie van die opnames te kunnen maken. Het algorithme maakt gebruik van de aangeprezen methode om de afgeleiden te bepalen van het binnen komende sensor signaal. Tijdens mijn simulatie's heb ik gezien dat mijn echt nuttig lasersignaal een zeer konstante vorm heeft en een heel beperkte breedte (aantal pixels signaal 6 tot max 7). Dit komt mij zeer goed van pas tijdens de verwerking.

Hierbij een basis tekening waarop ik de verilog code heb ontwikkeld:

detector_berekening by fotoopa, on Flickr

Op Flickr staat een hogere resolutie beeld indien gewenst. Ook daarstaat wat uitleg bij maar dit herneem ik hier even:

====================================
Ik maak gebruik van de afgeleide van het sensor signaal terwijl het binnen komt. Bovenaan de sensor data op t0, t1, t2 enz. Deze data wordt telkens bij een nieuwe input doorgeschoven. Omdat ik voor de volgende bewerkingen ook moet aftrekken zijn de waardes als signed voorzien en meteen op de breedte van de eindberekening. Vandaar dat ik de input data tot 10 bit signed maak.

De 2 volgende registers bepalen de afgeleiden maar berekend op een afstand van 2T van elkaar. Door de vorm van het signaal door de laser blijkt na simulatie dit een betere methode dan met 1T verschil. Ik maak zowel de afgeleide voor de positieve als de negatieve flank omdat ik die later ga samentellen met een verschuiving in 2T of 3T samples.

De sum registers zijn die optelling. Het resultaat is dat je eigenlijk zowel de opgaande flank als de verschoven neergaande flank optelt. ik heb hiervoor 2 verschillende sum registers gemaakt eentje voor 2T en eentje voor 3T verschuiving. Bij de simulatie heb ik ondervonden dat voor zwakke signalen van de laser de 2T verschuiving het best werkt. Met 3T verschuiving gaat het beter voor sterkere signalen. Dit komt omdat de basis vorm van het meetsignaal iets breder is bij sterke signalen.

Nu praktisch kan ik selecteren uit 4 detectie methodes.
1. Hier wordt enkel level gebruikt zoals vroeger. Kan niet beter als het omgevingslicht konstant is, dus zonder zon of bij overtrokken weer.

2. sum met 2T verschuiving. Werkt heel goed voor kleine signalen.

3. sum met 3T verschuiving, iets beter voor sterke signalen.

4. sum 2T en sum 3T samen. Dit is iets strenger van voorwaarde bij sterke zon. De meet gevoeligheid zal wel iets lager zijn.

Het geheel is nu afgewerkt en reeds getest.
Binnenhuis met een flits als stoorbron kan ik het verschil enorm goed zien. Level detectie stoort heel snel onder de invloed van het minste flitslicht terwijl de andere standen ruimschoots onderdrukken.

Buitenhuis in de field in volle zon zijn de ongewenste triggers bijna volledig te vermijden. Is er echt veel zon met storingen dan moet ik het level slechts een klein beetje verhogen. Maar echte zon reflectie's op random achtergrond kunnen nog blijvend storen. Daar zijn de stoor signalen dan echt te sterk. Maar praktisch is het nu al heel goed werkbaar. Gelukkig heb ik heel veel parameters om mee te spelen.
Dit algorithme kost mij geen extra reken tijd omdat op het einde van iedere scan lijn de detectie reeds gekent is. De detectie tijd blijft hierdoor op 50 usec.

===================================

De uitleg is een beetje met mijn eigen woorden, je kunt het waarschijnlijk in een wiskundige regel samen vatten. Maar het werkt vrij behoorlijk en vooral het kost mij geen extra vertraging door deze berekeningen. Alles draait binnen de FPGA synchroon met het serieel binnen nemen van de sensor data op 64 MHz. Alle bewerkingen gebeuren dan ook op deze clock zijnde 15.6 ns per add of sub bewerking.

Samengevat:

Het is een grote verbetering, het sluit niet alle ongewenste triggers uit maar het is toch veel stabieler in volle zon. Anderzijds heb ik ook het oude level algorithme beschikbaar die ik vanaf het klavier kan inschakelen. Zodra de zon verdwenen is of als het donker wordt is dit de meeste gevoelige methode.

Vandaag deze soort mug-vlieg opgenomen in volle zon, ze vliegt hier net weg, haar vleugels zijn reeds open en de pootjes zijn net los aan het komen van de achtergrond:

D400386 by fotoopa, on Flickr

Deze hommelkoningin was er heel even maar zodra ze mij in het visier had was ze er weer vandoor.

Aardhommel - Bombus terrestris D400366 by fotoopa, on Flickr

Het blijft spijtig zo koud dat ik geen andere beestjes gezien heb. Zelfs de vliegen laten het afweten. Maar volgende week gaan we blijkbaar toch een verbetering hebben, dan volgt de eindtest.
Nogmaals mijn vele dank bij de hulp van de ontwikkeling van dit algorithme!

Frans.

Ik kan alleen maar zeggen dat ik er weer even stil van ben

Op 4 april 2013 17:14:33 schreef fotoopa:
ze vliegt hier net weg, haar vleugels zijn reeds open

De foto is zo scherp dat het geslacht te zien was?

Naar aanleiding van deze post in het SYP topic: http://www.circuitsonline.net/forum/view/message/1553703#1553703

Het leek me handiger om daar niet teveel inhoudelijk op in te gaan, maar het in dit topic een beetje bij elkaar te houen.

Op 19 oktober 2013 08:59:08 schreef fotoopa:
[...]De detectie problemen zullen nooit volledig ideaal oplosbaar zijn. Wel wordt de meetgevoeiligheid jaar na jaar verhoogt.
De echte problemen zijn:

- Detectie van een uiterst klein (zwart) snel bewegend object kleiner dan 1mm tot op 0.5 meter focus afstand van de camera lens.
- Het moet ook kunnen werken bij sterk zonlicht (beestjes vliegen liever als het mooi weer is).
- De IR laser moet een heel lage duty cycle hebben. vb 2 usec on, 48 usec off. Hierdoor zien de beestjes minder goed die laserstraal.
- De meetcyclus ( laser on + laser off) mag max 50 usec zijn.
- Er is een bandpass filter nodig afgestemd op de laserstraal. Dit om de invloed van het omgevings licht te beperken.

Ik wist niet dat je de laser tussendoor ook steeds uit zette; gebruik je de data die je in die tijd van de sensor krijgt om de invloed van het omgevingslicht te verminderen? Je zou simpelweg de meetwaarden van de laatste scan zonder laser kunnen neme en die van de scan met laser af kunnen trekken. Je doet dan eigenlijk de aanname dat de invloed van het zonlicht tussen 2 opvolgende scans niet noemenswaardig veranderd (dus ook niet verschuift op de sensor, dat zou wel eens een probleem kunnen zijn). Alleen op de plaatsen waar de laser invloed heeft op de meetwaarde zou je dan een groot verschil tussen die scans moeten zijn.

Je meet met 2 lasers, toch? Misschien zou het zinvol zijn om ze achter elkaar in plaats van tegelijk aan te zetten, zodat je van elke laser een aparte scan hebt. Je zou dan bijvoorbeeld kunnen bepalen of een object in de richting van het focus punt beweegt, of juist er vandaan, als je van de beide scans een detectie op een andere plaats krijgt. Met de voorwaarde dat je een object kunt volgen terwijl het naar het focus punt beweegt, kun je het geheel misschien nog wel wat gevoeliger maken.

Ik heb heel weinig verstand van optica, maar misschien is er een mogelijkheid om de laser door een halfdoorlatende spiegel te laten schijnen, en dat licht op een of andere manier weer te mengen met het licht dat je terug krijgt, als een soort van auto-correlatie filter of zo?

Met een dergelijke constructie van spiegels zou je misschien ook heel selectief in de lengterichting van de laser kunnen meten, waarbij je naar de sensor van de linker laser kijkt terwijl de rechter aan staat, en andersom natuurlijk.

Nog een wild idee: kun je een laser ook gebruiken als een detector, op dezelfde manier als dat je een LED kunt gebruiken als fotodiode? Zo ja, is het ding dan ook selectief op de golflengte en de openingshoek van het inkomende licht?

@SparkyGSX

Oeps ik had deze posting niet gezien...

Even verduidelijken. Ik heb al veel verschillende meetsystemen gebouwd en die zijn soms totaal verschillend van werking. De bedoeling blijft wel steeds hetzelfde. Een zo kleine mogelijk vliegend insect in volle vlucht te detecteren.

Nu eerst de gebruikte systemen wat meer uitleggen:
In deze origineele topic ging het over een line-array detector die werkt op licht in de range rond 700 nm maar gaan ook nog prima voor de groene lasers op 535 nm. Voor IR lasers op 980 nm die ik ook nog heb en die wel schakelbaar zijn, werken deze line-array's niet meer.

Best zou eigenlijk de rode lasers zijn rond de 700 nm maar ikzelf zie niet zo goed rood licht waardoor ik last krijg in volle zon om de laserstraal op een object te zien. Vandaar dat ik die groene laser gebruik van 535 nm. Maar deze groene lasers kunnen niet geschakeld worden. Ik moet ze konstant sturen. Hoewel er 2 groene lasers gebruikt worden is de 2de laser enkel voor mijn ogen opdat ik zou zien waar de beide projectie punten vallen (dit is het focus punt van de camera). Die 2de groene laser is trouwens niet geschikt om een meetsignaal te geven via reflectie op de line array omdat dit gewoon inline staat en niet onderhoek. Opdat hij echter geen storend licht zou projecteren op de line-array wordt die laser iets hoger gericht waardoor dat meetsignaal net te hoog boven de line array komt.

Een ander meetsysteem is er een met een IR laser op 980 nm en een photodiode BPW41N met ingebouwde band-pas filter afgesteld rond de 950 nm. De gebruikte IR laser is hier wel schakelbaar (tot 5 MHz via de voeding). Hierbij gebruik ik nu reeds het aan en uitzetten van die IR laser en meet eerst het omgevingslicht en direct erna het omgevingslicht+IR licht om het verschil te maken. Dat werkt trouwens nu al enkele jaren zo met vrij goed resultaat. Ook bij dit systeem heb ik nog eens afzonderlijk mijn 2 groene lasers maar die maken geen deel uit van het meetsysteem en zijn enkel bedoeld voor de visualisatie. Die 535 nm is sterk onderdrukt door de band-pass-filter bij de BPW41N photodiode. Ook hier staan de groene lasers trouwens een paar mm hoger geprojecteerd zodat ze toch geen signaal zouden geven op de detector.

Deze BPW41N diode was direct gekoppeld aan een Atmega328 ucontroller om de lichtwaarde te bepalen via de ADC. Ook hier een On en Off time ieder 50 us zodat ik weer omgevingslicht en som IR + omgevingslicht kon berekenen. Iedere 100 us had ik dan een signaal om te bepalen of er detectie was of niet.

Nu wou ik die 50us On en 50 us Off tijd wijzigen. Daarvoor moet de eigen capaciteit van de photodiode zo laag mogelijk worden. Dit kan met een gewijzigde schakeling want als de reverse spanning op die diode hoger wordt verlaagd de C waarde behoorlijk en is de stijlheid van het signaal veel beter. Vandaar dat ik nu reeds op 4 us On tijd en 46 us Off tijd kan werken met een veel beter signaal. Omdat er nu minder tijd beschikbaar is voor de ADC convertor heb ik er een snelle ADS7885 bijgeplaatst. Die heeft slechts een acquisitie tijd van 270 ns nodig en kan ik de piek van het signaal snel meten. Het omgevingslicht kan ik nu net voor het einde van de 46us off tijd opmeten waardoor ik nog beter het verschil tussen IR en omgeving bekom. Dat is opnieuw een zeer grote verbetering. Het eerste resultaat staat trouwens hier al:

Analog signal of the reflectd IR laser signal. by fotoopa, on Flickr (klickbaar)

Schema: maar is ondertussen iets gewijzigd vanwege bias voor de BPW41N:
http://www.flickr.com/photos/fotoopa_hs/10294651695/

Maar alle problemen zijn nog niet opgelost. Als de zon er is kan het omgevingslicht de versterker satureren. Ik kan dit verhinderen door de meetlens toe te draaien (er zit een diafragma op) maar dan verlaagd ook het IR signaal, dus de totale gevoeligheid gaat naar beneden. Ik zou ook de verstering kunnen aanpassen maar de kleine extra capaciteit die op mijn BPW41N diode komt zorgt weer voor sterke vertragingen. De stroom in de diode ligt rond de 10 uA en de huidige weerstand bij de opamp is 270k. Breng je die veel hoger dan bekom je wel meer signaal voor de zwakke beestjes maar het kan gebeuren dat ik de On tijd moet vergroten door de grotere vertraging van het signaal. Een langere On tijd wil ik nu juist vermijden opdat de beestjes minder snel dit IR meetlicht zouden zien ( want ja beestjes zien IR en vermijden er door te vliegen).

Ik werk nog een oplossingen zoals een mini smd relais voor de instelling van andere weerstanden in de kring, of met een analoge schakelaar (maar weer het probleem van de C) enz. Omdat er momenteel weinig zon is kan ik het omgevingslicht bij sterke zon nog niet nauwkeurig bepalen. Wel heb ik dit vroeger al eens gedaan en daarbij komt de diode stroom tot ver boven de 100 uA. Dit is een zeer hoge waarde tov het nutig signaal die slechts enkele uA bedraagt. Ik zou een soort auto bias systeem moeten kunnen maken die meeloopt met het omgevingslicht opdat het omgevingslicht de versterker niet zou satureren en toch een hoge versterking bied om de kleine toename van het IR licht door het beestje toch te kunnen detecteren. Maar dit betrouwbaar maken is niet zo eenvoudig. S'avonds als het donker is heb ik al deze problemen niet want er is geen meetbaar IR licht van het omgevingslicht.

Meten met 2 lasers heb ik nog niet in detail nagezien. Hier kan wel iets inzitten. Wel moet rekening gehouden worden dat de lasers naast elkaar moeten staan en daardoor een verschuiving projecteren. Of die niet te groot zou zijn moet even berekend worden. Met de line-array was richting bepalen vanzelfsprekend. Die kon je afleiden uit de belichte pixels. Met 1 diode kan ik enkel met de level rekenen. Richting kan ik er niet uit bepalen tenzij het te laat is (signaal loopt op en dan weer af zonder aanduiding naderen of verwijderen)

Ik zoek dus een oplossing voor het sterke zon licht overdag. Die zorgt voor een BPW41N stroom die zelfs boven de 100 uA gaat terwijl het nuttig signaal ergens rond de 0.1 tot 10 uA max bedraagt. Er moet een oplossing gevonden worden om bij sterk zonlicht (boven de 100 uA in de diode) toch de volledige range van de opamp van 0.1 tot 3V output te kunnen gebruiken. Ik zoek een oplossing in de richting van instellen van de versterker in functie van gemeten zonlicht. Er is voldoende tijd in de order grote van 10-20 usec om dit te meten en een nieuwe meting uit te voeren met de aangepaste instellingen. ik denk hierbij aan sample en hold chips, ook eventueel DAC chip voor het instellen van de meetlevels. Alles moet binnen een cyclus van rond de 50 us kunnen behandeld worden. Na iedere cyclus moet een nieuwe instelling berekend worden om de gewijzigde toestand van het zonlicht te beheren. Ik stuur alles via een FPGA controller, berekenen en uitvoeren is binnen deze tijd geen probleem.

Samengevat:
Het aandeel IR laser signaal ligt tussen 0 en 10 uA en moet 50% van de opamp range kunnen weergeven (ongeveer 2.2V variatie naar de ADC7885).
De waarde van het omgevings licht kan schommelen tussen 0 en 100 uA op de BPW41N.
S'avonds is het omgevingslicht = 0 uA en mag een afzonderlijke instelling hebben.
Een meet- en regel cyclus is max 50 usec. Maar indien nodig kan een meet cyclus van het omgevings licht en de bijhorende regel cyclus verlengd worden met max extra 50us.
Het IR laser signaal mag max 4 usec On , min. 46 usec Off staan.
Ik beschik over meerdere OPA380 chips en ADS7885 ADC convertors. sample en hold ic's moet ik eventueel nog aankopen alsook analoge switches. Gezien ik toch nog nieuwe bestellingen moet maken bij Mouser is dit geen probleem.

En je detectiesignaal moduleren, zeg maar zoals die tv infraroodontvangers werken?

Het probleem blijft vooral buiten op witte oppervlakte waar de zon direct opvalt. Ook struiken waar waterdruppels opliggen kunnen heel sterke zonnestralen weerkaatsen, daar zit enorm veel IR licht in en het veranderd constant als je beweegt. De moeilijkheid is om het IR licht van een heel klein object toch te kunnen meten. Een enkele puls met een duur van 4 usec moet dit kunnen. In de schaduw of bij bewolkte hemel werkt dit nu al perfect. Alle infrarood ontvangers zijn veel te traag omdat die een regelsysteem nodig hebben voor hun gain regeling. Mijn probleem blijft nog enkel het omgevingslicht op de opamp te kunnen beheersen omdat die minstens factor 100 tot 1000maal sterker is dan het nuttig meetsignaal.

Nu werkt het al zeer goed omdat ik de totale lichthoeveelheid bij zonlicht beperkt via het diafragma op de meetlens maar dit is ten koste van de gevoeligheid. Resultaat is dat de beestjes iets groter moeten zijn, enkele mm, en liefst niet volledig mat zwart omdat dit het IR licht minder weerkaatst.

Ik zoek eigenlijk een oplossing hoe ik de input moet kunnen instellen opdat het omgevingslicht de opamp niet in saturatie brengt. Ik denk dat het meten van het omgevingslicht net enkele us voor het meten van het IR laser signaal en hierna de opamp instellen een oplossing moet kunnen brengen. Er is toch 46 us tijd voor deze meting en regeling uit te voeren, daarna gaat de laser aan gedurende 4 us en moet het gereflecteerd signaal kunnen gemeten worden.

Ik zou graag verder werken op basis van dit schema aangevuld met een regeling:

IR detector opa380 + ADS7885 by fotoopa, on Flickr

Schema is iets gewijzigd, de BPW41N heeft een extra -5V bias om de eigen capaciteit te verlagen en de componenten met een * zijn niet allemaal bestukt. R12 is weggelaten en R5 is 270k.

Ik neem aan dat je weet dat zwart niet perse zwart is voor infrarood?
Een voorbeeld:

Voor het normale oog ziet die er gewoon donkerblauw uit.

Ja dat de gewone te traag zijn geloof ik, maar die maak je dan zelf. Het gaincontrol systeem hoeft niet supersnel te zijn toch?

Heb je al geexperimenteerd met een polarisatiefilter? Je laser is waarschijnlijk wel gepolariseerd, zonlicht willekeurig, dus je filtert de helft er al uit. En je insecten zijn niet 'metalig' denk ik, dus zullen in dezelfde polarisatie reflecteren. Reflecties van auto's en 'moderne' ruiten heb je neem ik aan niet zo'n last van.

En hoe zit het met het andere eind van het spectrum? Misschien hebben ze minder last van (near)UV?