Ik ben niet zeker of dit hier moet of in schoolvragen, het is schoolgerelateerd, maar wel een research project
We zijn van een hogeschool in leuven en bezig met een robot die leren op het basisonderwijs moet verbeteren. We zijn nu de software aan het ontwikkelen voor het systeem.
Er zijn verschillende sensoren:
* 2 Cameras
* Veel aanraaksensors (onder de vacht)
* Ping))) Modules om obstakels te detecteren
* Microfoon
* GPS
Er zijn ook actuatoren (gelukkig maar):
* 2 motoren om te rijden
* 2 motoren om 'hoofd' mee te draaien
* Luidspreker
* Aantal lichtjes
We zouden gebruik willen maken van een Apple Macbook om de robot te besturen omdat dit heel krachtige hardware is met een degelijk besturingssysteem. Verder willen we kunnen interfacen met iPads wat denken we eenvoudiger is via een Mac.
We hebben alles aangesloten op de computer en kunnen nu vanuit LabView de robot doen rijden. Eerst willen we een soort proof-of-concept applicatie maken die herkent wanneer leerlingen een rode T-Shirt aanhebben als ze voor de robot zitten. We hebben dit gemaakt in NI Vision Assistant met de kleurherkenningsfunctie maar het probleem is dat dit redelijk traag gaat, het kost enkele seconden verwerkingstijd per plaatje. De CPU belasting is dan ook op alle cores 100% waardoor de accu leeg is op 1 uur. De bedoeling uiteindelijk is om gezichtsherkenning en 3D zicht te realiseren.
We zouden graag weten wat we fout doen waarom dit zo traag is want het is niet bepaald iets moeilijk.
AC/DrieC
Den Dries www.hulens.be
Ik heb vorig jaar meegewerkt aan soortgelijk project. Wij hadden "De beste" pc ter onze beschikking met daarop ROS. Hiermee deden we oa aan beeldherkenning en dit ging ook niet al te snel. Kan liggen aan de grote van de beelden die de camera doorstuurt,snelheid computer, algoritme om beelden te analyseren,....
Daan Timmer
Ik ben programmeur! geen electronicus! http://www.daantimmer.nl/ Er is een ontwerp! nu nog inhoud :-)
Heeft puur te maken met het feit dat jouw PC alles serieel uitvoert.
Oftewel elke pixel wordt achter elkaar behandeld. Heb je 1000x1000 pixels? Dan moeten er dus 1.000.000 pixels doorlopen worden.
Nu doe je vaak niet 1 bewerking in het geval van object-tracking, maar doe je meerdere bewerkingen per pixel.
Dan zit je ook nog met memory management, een lap aan andere programma's die in de achtergrond draaien. Beperkt geheugen. en je komt zo aan een paar seconden per frame dat je binnenhaalt.
640x480 zal nog wel redelijk goed gaan. Maar groter dan 1280x1024 wil je toch echt niet gaan.
Daarbij, labview is nou niet echt heel snel
Nu weet ik niets van de vision app binnen labivew, maar labview zelf is dus niet snel.
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Die hoge resolutie is wel handig als je iets met gezichtsherkenning e.d. wilt gaan doen. Het lijkt me dan een goed idee het beeld eerst grof te analyseren, door bijvoorbeeld in horizontale en verticale richting elk 4de pixel te bekijken. Op die manier bepaal je wat de interessante gebieden zijn (door de plaats van de gezichten te zoeken en zo), en die gebieden ga je vervolgens in een hogere resolutie analyseren.
Labview is ontzettend traag, zeg maar zo traag als diepgevroren dikke str*nt, als je het op generieke hardware wilt draaien. Nu is LabView waarschijnlijk wel snel genoeg voor de andere bewerkingen (besturing van de robot en zo), maar kun je de analyse van de beelden beter in een stukje C code of zo doen.
Op welk OS draait dit geheel? Je kunt LabView op een generiek OS draaien, of op hun eigen OS (weet even niet meer hoe dat heet). Voor de korte reactietijd is dat zeker aan te raden, maar ik betwijfel of de analyse van de beelden veel sneller zal gaan.
Overigens ben ik absoluut geen expert op het gebied van LabView! Ik heb er, in een grijs verleden, "wel eens" iets mee gedaan, veel meer als dat ook niet. Wat me het meeste bij is gebleven, is dat ik het ontzettend frustrerend vond, en alles tergend langzaam ging.
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
Tommyboy
Zo goed als het vroeger was, is het nooit geweest.
Dat doet de CPU inderdaad, met geoptimaliseerde code, en niet met generieke software als labview 
Gelukkig zijn er al drivers voor de kinext module, zodat je die op een standaard PC kunt gebruiken. Wel moet je zelf alle herkenningssoftware schrijven.
We werken met een resolutie van 480x480 en een een verscherpingsfactor van 2.2 maar andere waarden geven geen verschil
Het besturingssysteem is apple, dit is het beste kwa reactietijd.
We hebben tijdelijk de kleurherkenning gelaten en proberen de face recognition module te gebruiken. Na lang trainen op 1 gezicht leek het resultaat van de detectie nog steeds gewoon random. Hij zag of er een gezicht voor was, maar we hadden getraind met een meisje en dan hou ik mijn kop ervoor, geeft die een hogere likelyhood dan bij het meisje zelf (misschien zegt dat iets over mij?). Je kop 10 graden draaien kan een verschil maken op de likelyhood van meer dan 40%. Je kunt symbolen laten aanbrengen op de output stream met kenmerken van het gezicht, maar die verspringen heel de tijd. Toen hadden we 3 gezichten proberen te trainen en dan kreeg je bij nummer 2 van die 3 dit:
Likelyhood 1: 68%
Likelyhood 2: 69%
Likelyhood 3: 71%
In-Set Likelyhood: 97%
Nu getest met iemand die er niet bij zat, een vrouw is, en bovendien aziatisch van afkomst is:
Likelyhood 1: 74%
Likelyhood 2: 76%
Likelyhood 3: 44%
In-Set Likelyhood: 99%
Normaal zou het laatste nu laag moeten zijn omdat ze niet bekend is bij het systeem, en er echt wel voldoende anders uitziet dan de rest.
Hier kun je echt geen touw aan vastknopen.
Op de camera zit een klein beetje ruis, maar absoluut niet storend, toch had iemand getest met zijn goede HD videocamera. Dat gaf helaas geen verschil, behalve dat het met HD beeldkwaliteit enorm traag ging, hier spreek je dan over enkele minuten per plaatje.
De Microsoft Kinect heb ik eventjes naar gekeken maar ik vind nergens een uitleg hoe je hem moet koppelen met labview. We hebben wel dit gevonden: https://github.com/OpenKinect/libfreenect maar dat gaat onze pet ver te boven.
We hebben ook online zitten kijken en hadden daar iets gevonden over 2-d fourieromzetting wat goed zou zijn. We hebben dit gewoon eens geprobeerd maar dat gaat niet want die module werkt op een signaal van het type matrix en niet op een camera image.
Wat wel positief nieuws is dat we deuren kunnen detecteren via de Sobel Edge Detector module. Dit werkt heel goed bij duidelijk herkenbare deuren (bijvoorbeeld rood tegen een witte muur) maar niet bij een minder opvallende. Ook wordt bijvoorbeeld een stoel dikwijls al gezien als een deur. We hebben het systeem proberen te tunen met de treshold factors van de Pattern Detection module die is aangesloten op de Sobel module maar dat is niet te doen, je kunt dat dan goed krijgen voor 1 bepaalde deur bij 1 bepaalde hoek maar dan werkt het niet voor een andere.
Dit project is voor een wedstrijd, wat je kunt doen in de plaats van stage als je hoog genoege resultaten hebt. Het is het eerste jaar dat er wordt gebruik gemaakt van labview. De voorgaande jaren werd er maar voortgewerkt op een basis die iemand ooit jaren geleden gemaakt (de robot toen had goed gescoord) had in C, maar omdat alles gemaakt was met heel ingewikkelde codes en algoritmen was het bijna niet te doen om veranderingen te maken.
We zijn nu aan het onderzoeken hoe die code werkt (want die had dat camera gedeelte, hoewel toen slechts met 1 camera, heel goed gemaakt) zodat we het kunnen omzetten naar LabView. Helaas is er geen duidelijke beschrijving bij wat waarvoor dient, en er zijn ook files waar niets in staat behalve bijvoorbeeld:
float PRECOMP_face_nose_angle[128]={1.39729,...};
Die gezichtsherkenning werkt erg goed, als je het commando intikt om een gezicht op te slaan neemt die enkele foto's en erna kan hij het herkennen en dat ziet wel of het die persoon of iemand anders is.
We denken dat die files eigenlijk de afregelwaarden zijn voor het detectiealgoritme en als we deze kunnen inladen in LabView dat het even goed zal werken, klopt dat?
We moeten ook nog aan de originele C code zien te komen want we lazen in oudere verslagen dat op een gegeven moment iemand iets had aangepast en daardoor is de colored object tracking kapot gegaan. Er komt als je de monitor aansluit op de uitgang daarvan een gedrogeerd beeld (de kleuren lopen door mekaar en alles trilt) en geen gedetecteerd object. Natuurlijk wist die snul niet wat hij had aangepast en kon het ook niet ongedaan maken. Ik zeg dit maar omdat iemand misschien weet wat voor fout in het algoritme zo'n beeld geeft.
Die gezichtsherkenning is inderdaad niet zo veel soeps precies.
Die fourrier transform is een wiskundig concept, dat blijft bruikbaar ook als het blokje niet de goede input heeft. Je kunt vrij makkelijk van een image naar een matrix gaan, dat is dan gewoon een 480 bij 480 matrix met op elk element de waarde van R, G of B op die pixel.
Voor de kinect, kun je in labview geen C gebruiken? Misschien kun je dan de algoritmes van die C code ook inladen als die toch goed werken.
Die precomp dingen lijken me gewoon tabellen met waarden die op voorhand berekend zijn (precomputed) om het uitvoeren van het algoritme sneller te maken. Ze zijn allesinds specifiek voor het algoritme en heel waarschijnlijk niet bruikbaar in een ander programma.
Wat voor verandering aan een bepaalde implementatie van een bepaald algoritme een bepaald soort foute output levert gaat niemand je kunnen vertellen zonder op zijn minst de code te posten.
MAH
Every machine is a smoke machine if you operate it wrong enough
is het nodig om iedere pixel te analyzeren? neem eens 10 losse beeldlijnen mooi verdeeld over het scherm of zelfs een raster van 10x10(of ander aantal). Het gevolg is dat je nu veel minder pixels moet bekijken.
Of zoals free aangeeft, analyzeer een kinect. dat ding trackt veel punten en kan veel. Wat een ander al heeft gedaan of beter kan moet je dus niet zelf gaan doen, zeker niet als het er makkelijker of goedkoper van wordt.
Ik meen dat er op macbooks ook een functie zit dat je vanalles met het beeld van de webcam kan doen, mogelijk dat je dat kan gebruiken.
Zo gebruik ik op dit moment een wii-motionplus voor een robot, ideaal, t is voorgesoldeerd, aansluitingen erop etc en kost minder dan een enkel los chippie dat erop zit.
We zijn met de C code niet verder gekomen, ze is gewoon te moeilijk gemaakt. We hebben gebeld met iemand van labview en die zeggen dat we dit nodig hebben om sneller en nauwkeuriger te werken: http://www.ni.com/fpga/ kan dit helpen?