Alea iacta est

Het zit erop!

Als afsluiter van de periode hebben we zoals eerder aangekondigd een week in Limoges doorgebracht, in het opdrachtgevende bedrijf Dioptik, waar we gisteren een eindpresentatie hebben gehouden. Jammergenoeg kon de stagementor daarop niet aanwezig zijn omdat hij zelf op een buitenlandse missie is. Het departementshoofd van de universiteit was er echter, en vormde dus samen met de wetenschappelijke directeur en een ingenieur van Dioptik de jury. De presentatie is onthaald op zeer positieve reacties en vormde de kers op de taart van de drie boeiende maanden.

Meer details over ons reilen en zeilen hier komen aan bod op onze thuispresentatie en in ons dossier.

Een laatste zuidelijke groet, en tot binnenkort!

Dieter Walckiers
Hannes Claerhout

Testen netwerkmogelijkheden, aanhoudende problemen op gebied van video

Hallo

Gezien we momenteel niet verder na kunnen gaan of op het gebied van lens alles correct werkt (zie vorige week) hebben we ons toegespitst op de andere gebieden die nog voorzien moeten worden in het project:

1) versturen van videosignaal via wifi
2) encoderen van videosignaal in h.264 of ander mpeg-4 formaat.

Gezien er op het ogenblik nog niet echt een wifi-oplossing in zicht is, hebben we tests ontwikkeld voor de klassieke ethernetverbinding. We gaan er van uit dat het wifi-gedeelte voor de stuurprogramma's is en dat het er uiteindelijk op neerkomt om via de juiste interface pakketjes te verzenden (hetzij wifi, hetzij bedraad ethernet).

We slaagden er ondertussen in om de bitmap die we al eerder gebruikten in onze tests (of eender welke) te versturen via UDP en die aan de andere kant opnieuw te laten omzetten in een volwaardige afbeelding. Op dat gebied ziet het er dus goed uit, op voorwaarde dat er ondersteuning voor draadloze adapters ontwikkeld wordt natuurlijk... .

Op het gebied van de videomogelijkheden, blijft de situatie er somber uit zien. We hebben dan wel die nieuwe camera ontvangen en de driver communiceert daadwerkelijk met dit type, maar de driver is blijkbaar nog erg instabiel. We schreven een testprogramma dat gebruik maakt van de video4linux API, - waaruit blijkt dat er wel degelijk gecommuniceerd wordt met de camera - maar op het moment dat de opdracht gegeven wordt om de gegevens van de camera te gaan versturen, loopt alles vast => In de zin dat heel de machine opnieuw moet opgestart worden.

Om na te gaan of het probleem bij onze code lag, hebben we dit testprogramma verstuurd naar ontwikkelaars die hetzelfde type camera gebruiken (maar op een ander hardwareplatform) en zij bevestigden ons dat de code bij hen werkte... . Het probleem zit dus niet in de code, maar in de voorlopig onstabiele driver voor de camera. We contacteerden de ontwikkelaars van de linuxdistributie voor ons platform en ze zijn het probleem aan het inspecteren.

Bij het tweede nog uit te werken topic, zijnde het encoderen van het videosignaal, steken er ook enkele problemen de kop op. Onze hardware (de microcontroller op zich) heeft mogelijkheden om video hardwarematig te coderen naar een ander formaat, maar deze functies zijn op dit ogenblik nog niet geïmplementeerd in onze linuxdistributie.

Een concurrent heeft echter wel reeds bibliotheken ontwikkeld voor dit soort microcontroller, maar zij maken gebruik van een ander ontwikkelplatform. We inspecteerden of het eventueel mogelijk was om deze bibliotheken te compileren voor ons platform, maar dat bleek volstrekt gekkenwerk te zijn, gezien daar ook gebruik gemaakt wordt van specifieke broncode voor dat andere ontwikkelplatform.

Kortom: de bal ligt in het kamp van de ontwikkelaars van de distributie op ons platform om vooruitgang te kunnen boeken op het gebied van alles wat video betreft. (te betreuren)

We zullen zien hoe de situatie zich nog verder ontwikkelt volgende weken. We hebben in ieder geval nog meer dan werk genoeg in verband met documentatie schrijven en opzoekwerk verrichten naar andere oplossingen, dus we zullen niet stil zitten!

Een vriendelijke groet

Hannes Claerhout,
Dieter Walckiers

Project stall

Opnieuw een vervroegde blogpost omdat deze week ook een verkorte is, 8 mei is namelijk een nationale herdenkdag hier.

Ons project heeft momenteel te kampen met een grote vertraging, om verschillende redenen.
Wat de I2C bus betreft is het de communicatie met de hardware, dus de lens, die schort. Via de oscilloscoop hebben we het signaal proberen te onderscheppen dat door het kaartje van Varioptic (zie foto) in theorie zou moeten worden geconverteerd van digitaal naar analoog (tussen 0 en 60 volt), maar we slaagden er niet in om iets te visualiseren, buiten wat willekeurige ruis.
Met een multimeter zijn we alle bereikbare connecties nagegaan en alles werkte, dus moet het het kaartje zelf zijn waarmee er iets scheelt.
Mr. Faugeras, directeur bij Dioptik, is deze namiddag langsgekomen en heeft op zijn beurt alles in zijn eigen kennis geprobeerd, waaronder de kabeltjes hersolderen, ook zonder resultaat.
Als we de datalijnen controleren die we doorsturen die dienen om het componentje aan te sturen op de I2C poort, dus waar ze het ontwikkelingsbord verlaten, zien we dat alles naar wens verloopt. Ze zijn zichtbaar op de oscilloscoop en we zien effectief die bits passeren die we doorsturen vanuit het programma (zie blogpost van 25 april). Dus softwarematig is alles in orde en is ons taak vervuld (op dat vlak). Maar hardwarematig is er dus een defect.
Een nieuw component bestellen zou een wachttijd van 2 weken betekenen, dus daar zit een probleem. Mr. Faugeras uitte echter de mogelijkheid om een gelijkaardige kaart te lenen uit een ander project, om na te gaan of het daarmee wel gaat, en om zo dus de code die we hebben geschreven om de focus aan te sturen 100% te kunnen testen.
Maar voorlopig kunnen we op dat vlak niet meer dan afwachten.
Dat betekent niet dat we met ons vingers zullen draaien, er zijn nog zo veel aspecten om mee te experimenteren. Zoals de WIFI functie. Want het is nog steeds de uiteindelijke bedoeling om de gerecupereerde beelden van de camera ook over een draadloos netwerk te versturen. Dus dat is een uitdaging voor volgende week.


Varioptic digitaal-analoog convertor kaartje, dimensies ongeveer 1 op 1,5 cm

Vriendelijke groeten vanuit het zuiden

Dieter Walckiers
Hannes Claerhout

Aanhoudende camera-problemen, verdere experimenten I2C

Hallo

Wegens het verlengd weekend een vervroegde-blogpost over deze korte week. Terwijl Dieter zich samen met de stagiair van de IUT verder bezighoudt met het programmeren van de I2C-bus, blijven de problemen op het gebied van de camera oplopen.

De camera wordt gestuurd met een heel recent stuurprogramma, waar er nog hier en daar kinderziektes in zitten. Er zijn namelijk verschillende types van dit soort camera, wat voor problemen zorgt. De driver is in principe ontwikkeld voor het type camera met een I2C GPIO expander, die ervoor zorgt dat op de 10 datalijnen een multiplexing kan plaatsvinden.

Ons type camera echter is een type waar de GPIO expander niet op aanwezig is. We slaagden er wel al in om te communiceren met de camera, maar niet tot op het gebied waar de eigenlijke afbeeldingsgegevens overgebracht kunnen worden. Even verduidelijken:

Om een camera te laten beelden opvangen vanuit linux zijn er twee absolute vereisten:

- Een driver voor de camera zelf
- Een soort van bijkomende 'driver' die gebruikt maakt van de video4linux API in C

Het komt er dus op aan om met de functionaliteiten die in video4linux zitten, direct te communiceren met de driver van de camera door gebruik te maken van ioctl. Het proces om te kunnen 'capturen' van de camera is als volgt:

- Het videoapparaat openen
- Het videoapparaat initialiseren
- Beginnen met 'capturen'
- Loopen en gegevens verwerken
- Stoppen met 'capturen'
- Het apparaat desinitialiseren
- Het apparaat sluiten

Voor het ogenblik zitten we vast in de fase van het initialiseren. Tijdens de initialisatiefase worden er allerlei velden gelezen en geschreven van/naar de cameradriver. We kunnen zien dat er reeds verschillende stappen van het lezen/schrijven succesvol uitgevoerd worden, maar het probleem stelt zich bij het instellen van het te capturen formaat.

Gezien we voor het ogenblik niet beschikken over een gemultiplexte camera, moeten we gebruik maken van het formaat BAYER16, terwijl de gemultiplexte camera gebruik maakt van het BAYER8 formaat. Op zich zou dit geen probleem mogen zijn, maar de camera is (waarschijnlijk voorlopig) zo gecodeerd dat hij enkel met het BAYER8 formaat overweg kan.

We hebben gecommuniceerd met de schrijvers van deze drivers en zij beschikken over nieuwere versies van dit stuurprogramma waar dit probleem zich niet meer mee voordoet. Om deze te kunnen gebruiken moet er een kernel gecompileerd worden die niet specifiek voor ons platform is aangepast. Dit hebben we geprobeerd, maar zonder succes.

De enige overblijvende oplossing was dus om een nieuwe camera te bestellen die wel over deze GPIO I2C expander beschikt, zo zijn we ook iets zekerder dat er in de toekomst minder problemen zullen zijn (algemeen gezien meer ervaring met dit type). De camera kan vandaag nog geleverd worden, zoniet wordt het voor maandag.

Wij wensen u een prettig weekend,

Hannes Claerhout
Dieter Walckiers

Kernel patch, I2C bus, camera probs

De vooruitgang deze week kwam aanvankelijk moeilijker op gang, maar in de loop ervan zijn er toch enkele belangrijke doorbraken geweest.
Het project is op dit moment opgesplitst in twee aandachtpunten: De camera en de focus. Beide apparaten werken via een I2C bus, en hier komen we bij de oorzaak van de moeilijkheden waar we vooral maandag en dinsdag mee hebben gekampt. Er was namelijk geen overeenkomstig apparaat voor de I2C bus in de /dev map in Linux.
Dit was ons al opgevallen vlak voor de verlofweek, en we hebben het gemeld aan de ontwikkelaars van de versie van Linux die op de target draait. In het begin van de week hadden ze dan ook een patch geschreven die gebruikt moest worden bij het recompileren van de kernel (op de target). Echter zonder directe betering. Na lang zoeken was er al sprake van een nieuwe versie van de camera te bestellen, die beter zou functioneren met de bestaande drivers. Toen bleek dat het een bepaalde module was die het probleem veroorzaakte, GPIO. Toen we deze optie uitschakelden voor het recompileren van de kernel hadden we enkele nieuwe devices; enerzijds voor de camera: /dev/video0, en (door het aanvinken van alle compilatie-opties die met I2C te maken hadden) 2 I2C apparaten; /dev/i2c-0 en /dev/i2c-1.
Hierna kwam er terug vaart in de situatie. Er kon geëxperimenteerd worden met de broncodes die werden gevonden voor de communicatie met de camera. Hier werd duidelijk waarvoor die GPIO module eigenlijk nodig was. Zonder deze module kunnen we enkel pure rood – groen – blauw waarden schrijven naar de camera. Dus complexere beelden afbeelden wordt niet evident.
Er waren nog enkele andere problemen, kortom, zoals eerder vermeld, deze driver werkt simpelweg niet goed met ons type camera. Daardoor is, samen met opdrachtgevend bedrijf Dioptik, de beslissing genomen een nieuwe camera te bestellen die beter samenwerkt met de driver. Voorlopig zit het op dat vlak dus even vast, maar er is nog altijd de focus ook om ons op te concentreren.
Ook deze wordt gecontroleerd door een I2C bus, die dus dankzij de patch beschikbaar is geworden.
Al vrij snel hadden we een stukje voorbeeldcode te pakken, die aantoont hoe de device geopend dient te worden en een correct adres dient te krijgen.

#define DEVICE “/dev/i2c-0”
#define addr 0x40
fd = open(DEVICE, 0_RDWR);
if(fd<0)
{
printf(“\Erreur, impossible d’ouvrir %s”, DEVICE);
exit(1);
}
if(ioctl(fd,I2C_SLAVE,addr) < 0);
{
printf(“\Erreur, impossible de sélectionner le composant i2c a l’adresse 0x%x: %s”, addr, strerror(errno));
exit(1);
}

De ioctl() functie wijst de addr variabele toe aan I2C_SLAVE, zodat gecommuniceerd kan worden met de slave, in dit geval dus de focus. Natuurlijk, zoals zo vaak in deze situaties, lukte dit niet zomaar. Het bleek hem om een banale syntax fout te gaan.

if(ioctl(fd,I2C_SLAVE,addr) < 0);

Hier staat er een ‘;’ te veel. Syntaxfouten komen wel meer voor, maar ik vermeld dit gewoon even om een markant verschil met Java te illustreren. Deze fout zou in Java direct opgevallen zijn, maar aangezien de C compiler zeer toelatend is ging het er zonder problemen door, met als gevolg dat hij het als een statement beschouwde, en de inhoud tussen de haakjes sowieso uitvoerde. Hierdoor leek de ioctl() functie steeds te falen.
Zodra dat recht gezet was, konden we beginnen testen met het schrijven naar de I2C bus.

char trame[3]; trame[0]=0x04; trame[1]=0x99; trame[2]=0x01;
If (write(fd, trame, 3) < 0)
{
fprintf(stderr, “failed to write : %m\n”)
}

Dit gaf als resultaat "failed to write : remote I/O error"
We waren echter niet zeker of het adres dat we toewezen aan de I2C_SLAVE wel het juiste was. Dit hadden we weliswaar afgeleid uit de handleiding van de lens, maar het was niet zeer duidelijk. Dus besloten we een klein algoritme te schrijven dat via een for-lus alle adressen nagaat en verifieert op welk adres de functie write() geen -1 oplevert.
Echter geen succes. Geen enkel adres werd gevonden.
De oplossing zat hem in de manier waarop de connectoren van de lens waren bevestigd op de i2c poort. Er zijn namelijk verschillende connectoren die moeten verbonden worden met de pinnen van de i2c bus (Zie afbeeldingen). We hadden alles aangesloten gebruik makend van een tabel in de handleiding van het ontwikkelingsbord, waarvan hier de relevante lijnen:

PIN # SIGNAL NAME DESCRIPITION
1A VCC_CAM_EXT External Power supply
2A VCC_3V3 Power supply
3B CAM1_SDA SDA Quick Capture
4A CAM1_SCL SCL Quick Capture
5B GND Ground

Maar de VCC connector van de focus zat op pin 1A, een configuratie die gebruikt dient te worden als het om een apparaat gaat dat zelf een stroomtoevoer heeft, vandaar “external power supply”. Bij ons is dit niet het geval, de lens gebruikt de stroomtoevoer van het bord. Vandaar dat de VCC connector op pin 2A moet zitten, iets waar we eerst geen rekening mee hadden gehouden, en achteraf niet meer bij stil gestaan.
Dat verklaarde waarom hij geen adres vond. Bij het opnieuw runnen van onze code om het adres uit te vissen, kregen we deze keer wel resultaat, namelijk drie verschillende locaties: 0x0, 0x21 en 0x7E. Schrijven (via write()) naar deze locaties lukte, maar enkel schrijven naar adres 0x21 gaf een int 3 als return waarde, wat bleek te wijzen op het feit dat er 3 bytes succesvol waren weggeschreven. Dit was dus het enige juiste adres.
Via een oscilloscoop konden we de signalen die werden doorgestuurd verifiëren en concluderen dat het inderdaad was hetgene we bedoelden (zie afbeelding).
Een anekdote: de stagementor hier, Mr. Halluin, had er plezier in dat wij, software programmeurs in opleiding, ons aan het scheel staren waren op de kleine hardware componentjes!
Nu we weten dat de juiste elektronische signalen worden doorgestuurd naar de i2c poort, is de volgende stap de spanning controleren die doorkomt op de focus. Want het is namelijk een apparaatje dat elektronische signalen omzet naar spanning, en de lens verandert zijn focus op basis van deze spanning.
Meer hierover volgende week!


De i2c poort waarop de focus wordt aangesloten


De connectoren van de focus, die dus op de pinnen van de i2c poort moeten


Focus geconnecteerd, op de correcte manier


Opstelling, verbonden met een oscilloscoop, om te meten welke elektronische signalen worden doorgegeven


De output van de oscilloscoop (het onderste signaal is de klok). Hierop is te zien dat we eerst de waarde van het adres doorsturen (0x21, dus 0010 0001), gevolgd door een acknowledgement (kleine uitstulpsel naar onderen toe). Hierna volgt de informatie van de trame variabele: 0x04, 0x99, 0x01.

Groeten vanuit Brive.

Dieter Walckiers
Hannes Claerhout

Zoektocht naar camera-modules en onderzoek naar threads

Hallo

Deze week hebben we ons vooral toegespitst op het laten functioneren van de camera. We moesten voordien wachten op een speciaal aansluitingskabeltje vooraleer we aan het sturen van de camera konden beginnen. De camera wordt zoals elk linux-apparaat bestuurd door het schrijven naar een specifiek /dev/ bestand. Het probleem dat zich stelt met de camera namelijk is dat er geen /dev/video0 (verwachtte apparaatnaam) aangemaakt wordt.

Eerst dachten we dat dit misschien te wijten was aan een slechte aansluiting van de bedrading, maar later bleek dat in de nieuwe versie van de BSP (zie vorige week); enkel een andere type cameramodule ondersteund wordt. We moesten dus op zoek gaan naar de bijpassende kernelmodules voor onze camera. We vonden reeds enkele geprecompileerde modules voor onze camera, maar deze werden gecompileerd op een ander platform dat niet compatibel is met het onze.

Gelukkig hebben we reeds enkele contactpersonen op IRC, die verantwoordelijk zijn voor de linuxdistributie op ons platform. We namen dus contact met hen op om te vragen of de camera in de nabije toekomst ondersteund zou worden. Men liet ons weten dat de modules voor de camera nog in aanmaak waren en erg onstabiel bleken. De dag erna echter, liet de ontwikkelaar van deze modules ons weten dat er onverwachte vooruitgang gebeurd was op het gebied van de modules. Hij beloofde ons dat als we enkele dagen zouden wachten we een afgewerkte versie zouden toegestuurd krijgen. Het wordt dus nog eventjes de kat uit de boom kijken, maar we hebben er alle vertrouwen in (in samenspraak met het opdrachtgevende bedrijf) dat het de moeite loont om af te wachten.

Verder hebben we ons wat geconcentreerd op het maken van documentatiebestanden voor onze reeds ontwikkelde testprogramma's. Er moet in gedachten gehouden worden dat wij slechts een prototype aan het ontwikkelen zijn en dat deze documentatie in een later stadium zeker nog van pas zal komen.

We dachten ook reeds aan de toekomst en hebben een klein testprogrammatje gemaakt op basis van threads. Het programma bestaat uit twee threads: een die gebruikt wordt om het programma af te sluiten en een andere die instaat voor het verplaatsen van een scrollbar. Later zullen we nood hebben aan een gelijkaardige opstelling, één thread die de scrollbar met de waarde voor de focus beheerst en een andere gelijktijdige thread die de input van de camera op het scherm tovert.

Volgende week zal er geen blogpost gemaakt worden, gezien de IUT zijn deuren sluit en er bijgevolg niet aan het project kan gewerkt worden.

Groeten uit Brive

Hannes Claerhout
Dieter Walckiers

Scrollbar, BSP update, I²C-Bus

De week is zeer gunstig begonnen op vlak van touchscreen mogelijkheden. In de loop van vorige week hadden we namelijk enkele problemen;
In de broncode van tslib was te zien hoe - na het laden van de touchscreen device - enkele benodigde modules werden geladen.
Deze device ("event0") laden leverde geen probleem (na verandering van het pad dat werd meegegeven in de code van "/dev/ts/" naar "/dev")

tsdevice = strdup("/dev/event0");
ts = ts_open (tsdevice, 0);

Pas bij het configureren ervan doken er enkele problemen op. Dit gebeurde met de functie ts_config met als argument de tsdevice. Hierin wordt een configuratiebestand ts.conf geopend.

f = fopen("/etc/ts.conf","r");

Dit configuratiebestand bevat een hoop commentaarlijnen waarvan men van de gewenste de commentaartekens moet weghalen zodat ze gelezen kunnen worden. Bijvoorbeeld, in het originele ts.conf bestand staat:

# Uncomment if you wish to use the linux input layer event interface
# module_raw input

Door de hekjes weg te halen voor module_raw input, zal het programma deze module proberen laden. Het heeft even geduurd voor dit duidelijk was, we waren er eerst niet opgekomen om de inhoud van ts.conf te bekijken.
Verder was er enige verwarring tussen het filesysteem op de target en dat van de host, omdat er op allebei een ts.conf bestand stond. Het ts.conf bestand op de host (ontwikkelingscomputer) zagen we per ongeluk aan als het ts.conf bestand in kwestie, op de target.

Maar de functie ts_config neemt dus tokens van dat ts.conf bestand en geeft de te laden modules (input in ons geval) door naar de functie __ts_load_module(...). Deze functie bouwt op zijn beurt een pad, dat oorspronkelijk "/lib/ts/" was, waar we effectief modules aantroffen, waaronder ook input.so. Het pad wordt dus gebouwd met de doorgegeven naam van de module als bestandsnaam.

strcpy(fn,"/lib/ts");
strcat(fn, "/");
strcat(fn, module); // doorgegeven modulenaam, "input" dus
strcat(fn, ".so");

Het zag er goed uit, maar bij het uitvoeren bleek dat de module niet werd gevonden, hoewel alles wel op de juiste plaats stond. Hier stonden we even voor een raadsel. De oplossing was uiteindelijk de module verplaatsen naar een andere map "/usr/lib/ts/". .so bestanden zijn namelijk shared objects, en de ene locatie is blijkbaar beter geschikt dan de andere om ze te delen. Het is nog niet geheel duidelijk waarom deze map wel werkte, maar het werkte, dus dat was positief!

De nodige modules werden geladen (naast de module_raw input waren er nog een paar gewone modules; pthres, variance, dejitter, linear) en de functies gebruikt in de broncode van ts_lib konden getest worden.
Functies werden aangepast en naar onze hand gezet. Al gauw slaagden we erin lijnen en pixels te tekenen met onze vinger, alsook drukknoppen te programmeren en na enig proberen deze drukknoppen te verslepen. Hierdoor was de stap minimaal om een scrollbar te maken, wat nodig is voor het uiteindelijke ontwerp.

Op dat vlak zit het dus goed. Er is in de loop van de week echter nog een andere uitdaging opgedoken. We kregen we een e-mail van Mr. Granger, een ingenieur van het opdrachtgevende bedrijf Dioptik. Deze vertelde ons dat er een nieuwere versie uit is van de BSP (board support package) dan de huidige op de target. Deze versie ondersteunt het vastleggen van video via een camera en heeft een grafische bibliotheek.

Het installeren van deze nieuwe BSP was niet zo eenvoudig. Eerst moesten we uitzoeken hoe de broncode juist gecompileerd moest worden, daarna moesten we de gecompileerde "images" op het ontwikkelaarsbord zien te flashen.

Het compileren gebeurt aan de hand van een tool genaamd ptxdist. Na het configureren en uitvoeren van ptxdist beschik je vervolgens over een nieuwe kernel-image en een image met het volledige bestandssysteem voor de target. Deze images kunnen normaal gezien snel op de target geflashed worden met behulp van de bootloader u-boot. Het flashen gebeurt dan via een ethernet-verbinding met een TFTP server op de ontwikkelingscomputer. Er is echter een probleem in de code van u-boot wat ervoor zorgt dat we de ethernet-interface niet kunnen gebruiken. De oplossing is dan ofwel (indien er al/nog linux op het bord staat) de images rechtstreeks via linux op het flashgeheugen te schrijven ofwel gebruik te maken van een windows-tool die het flashgeheugen kan updaten via een seriële poort. Gezien een vorige poging mislukt was en we bijgevolg geen toegang meer hadden tot de linuxversie op de target, hebben we dan maar de windows-tool gebruikt; met succes.

Donderdag zijn de directeur en een ingenieur van Dioptik weer langsgeweest, met deze keer ook de algemene directeur bij. Ze hebben onze vooruitgang bekeken en geduid hoe het verder moest. Ook meteen een misverstand uit de wereld geholpen, want wij waren er van overtuigd dat we een zoomfunctie moesten programmeren, terwijl het eigenlijk de focus van een lens is die we besturen. Het beeld scherpzetten dus.
Een illustratie die ze maakten toonde aan dat deze lens bestuurd moet worden via een I²C-bus, die elektrische signalen doorgeeft naar de lens. Op basis van deze signalen verandert bijgevolg de focus van de lens.

Deze concepten in praktrijk brengen is dan ook de uitdaging die ons rest voor volgende week.

Groeten vanuit het zuiden

Dieter Walckiers
Hannes Claerhout