3D scannen

[rkr]

als je een hele stapel gopro's neemt lukt het kennelijk wel https://www.youtube.com/watch?v=6qNwjPRqx20

maar als je 100 van die dingen nodig hebt, dan zijn het ook geen hobbyprijzen meer


als kinderen niet te lang stil kunnen zitten, werkt dit toch iets goedkoper https://www.youtube.com/watch?v=OEd5lTmeAH8

[DaBit]

maar ik heb al lopen informeren op allerlei elektronica forums... maar schijnt niet echt makkelijk te zijn om 80 usb cams aan 1 computer te hangen.... meestal wordt zelfs aangeraden het camera gedeelte uit zo'n cam te slopen, en hem niet via USb te gebruiken.... en tja... toen ben ik er maar mee gestopt...

Kwestie van genoeg USB controllers gebruiken. Met (PCIe) port multipliers en losse USB kaartjes kost je dat minder dan 5 euro per USB-poort, waarschijnlijk zelfs minder dan 2,50.

[Swets]

ja er zal best wel een manier zijn.... maar word wel steeds duurder......
bedoel je heb van die cams, met een drukknop, en daar mee maakt hij 1 foto, en wordt opgeslagen in de cam....

dat zou je al buiten USB om kunnen doen...

en dan heb je alleen dat je 80x van usb moet wisselen om de foto er uit te halen.......

denk alleen dat je even moet zoeken naar de goed cams... goedkoop... liefst HD dus niet 320x240 ofzo... en dan met de mogelijkheid van opslaan van een foto...

vaak heeft windows ook last van meer (dezelfde) cams....

[DaBit]

1,3MPix USB cameraatje kost minder dan $5. Misschien kun je voor dat geld ook al wel een 2MP cameraatje kopen.
PCIe port multiplier van 1 naar 4: $60 ofzo. USB 2.0 host controller kaartje met 4 USB-aansluitingen: $9. Kun je per PCI Express slot zowiezo al 16 cameraatjes aansluiten zonder dat je vreselijk veel devices op 1 USB-bus hebt, en dat kost je dan $60 + 4x $9 + 16x $5 = $176 voor 16 cameraatjes. En ik ben er vrij zeker van dat als je er voor gaat zitten dat het nog wel goedkoper kan. Bekabelings-technisch is meedere moederbordjes misschien handiger bijvoorbeeld.

Met Linux kun je al diezelfde USB-cameraatjes enumereren op bus/slot nummer, dus dat het allemaal dezelfde zijn boeit niet. Doe ik met die FT232 USB->RS232 convertertjes in mijn CNC machine ook. Of Video for Linux standaard 80 cameras aankan weet ik niet, maar meestal zijn dat soort limieten makkelijk aan te passen.

PC-tje erbij, stukje script, en je grabt zo je 80 frames. Is het alleen geen open-source hardware, boeien.

[Swets]

het leuke is , dat die link die stuurde : http://www.pi3dscan.com/

eerst helemaal uitlegde welke hard en software die gebruikte.... en nu is het opeens een hele andere pagina...

want naast 3D Catch ( http://www.123dapp.com/catch ) zij er nog meer van dat soort (free) programma's ...

en ik vraag me af of die software moeilijk is? tis ook weer een 3D verhaal....
maar ik denk dat het beter kan, omdat als je die 80 camera's in een hok/telefooncel idee bouw, zou je eerst een foto kunnen maken van een lege kast, en die vergelijken met iets in de kast....

ik bedoel 3D catch zoek in de foto's naar herkenningspunten, om zo uit die foto's de 3D Mesh op te bouwen... ze zeggen ook zelf dat je spiegelend dingen moet voorkomen, maar ook veranderende dingen... zo als heen en weer waaiende bomen enz enz...

ten eerste als je de 80 foto's in 1 keer maakt wordt dat probleem al minder....

ook heb ik ergens gelezen dat foto tegen een gemetselde muur bijvoorbeeld het beste werkt... logies ook, des te meer herkenningspunten de software kan vinden....
maar als elke camera weet hoe het "lege" beeld eruit ziet, weet hij ook wat er extra gevonden wordt in het "volle" beeld....

Dus ik denk in een dicht hokje, met op de ene wand zwarte blokjes, op de andere wand zwarte strepen, eentje met rondjes... enz misschien ook het herkennen beter maakt....

misschien is de software ook een stuk slimmer te maken als deze van tevoren de hoeken tussen de verschillende wanden al weet?

maar ik begrijp ook wel dat het niet even iets is, wat je even schrijf....

maar ik denk wel dat het dan beter te gebruiken is.... ik bedoel probeer jij een kind , of een hond maar eens een poosje stil te laten zitten....

En ik ben zelf ook wel eens gaan zitten, en me vrouw 80 foto's laten maken... maar het valt niet mee om stil te blijven zitten, want je ben toch geneigd te kijken naar de genen die foto's maakt, en draai je toch je hoofd een klein beetje... en daar word de scan niet beter van natuurlijk....


nog even zomaar over het idee....

stel nu dat je een Cam vind met een foto knop erop....die knop zou je naar buiten kunnen halen, zodat je 80 foto's in 1 keer kan maken...
je maak een of ander verdeelboard, met 80 USB aansluiten, en je zorg dat ze allemaal een voeding hebben....

en dan iets maakt bijvoorbeeld met een micro controller, welke 1 voor 1 de cam aan de pc koppelt... dus door 79 cam's uit te zetten, en 1 aan...

en dan een voor een de cam's aflopen, foto naar binnen halen.... misschien als je snel schakelt, heb windows niet eens door dat het opeens een andere cam is?

[hugo stoutjesdijk]

Zou je dan niet handiger een tussenoplossing kunnen maken.
Die centrifuge oplossing, maar dan een zuil met 5 camera's er op, die 360 graden laten ronddraaien ( zeg 1 omw/sec )
en onderweg 20 (x5) foto's maken.
Dan heb je gelijk een hele mooie gelijkmatige achterwand ( mij lijkt een cilinder achterwand, met ruiten, mooier, ook voor de belichting ) Maar dat hangt misschien van de software af.
En misschien is het ook wel handiger om met SPI-camera moduulle'tjes te werken.
Weet niet of je met een raspberry 4 SPI camera's tegelijk uit zou kunnen lezen. (scheelt 75 raspberry's)
Oke en als het dan een commercieel succes dreigt te worden zijn die paar extra camera's ook de kosten niet meer.
Vind die opstelling van die site wel een erg hoog houtje-touwtje gehalte hebben, maar goed alles is voor verbetering vatbaar.

[DaBit]

en ik vraag me af of die software moeilijk is? tis ook weer een 3D verhaal....

Om te gebruiken niet geloof ik, om te schrijven wel. Alhoewel je wel gebruik kunt maken van bestaande libraries.

maar ik denk dat het beter kan, omdat als je die 80 camera's in een hok/telefooncel idee bouw, zou je eerst een foto kunnen maken van een lege kast, en die vergelijken met iets in de kast....

Juist niet. Hooguit de software laten weten waar de camera's staan en wat de karakteristieken van de lens zijn.
Laat voor de rest de SIFT (Scale Invariant Feature Transform) maar uitzoeken welke 'features' matchen.

ook heb ik ergens gelezen dat foto tegen een gemetselde muur bijvoorbeeld het beste werkt... logies ook, des te meer herkenningspunten de software kan vinden....
maar als elke camera weet hoe het "lege" beeld eruit ziet, weet hij ook wat er extra gevonden wordt in het "volle" beeld....

Nee, hoe meer 'ruis' in het beeld, hoe beter. Moet die ruis wel van je object af komen en niet van de camera uiteraard. Een egaal vlak kun je helemaal niet matchen. Perfect witte ruis tot een fractie van een pixel nauwkeurig. En dan alles wat er tussenin zit.

en dan een voor een de cam's aflopen, foto naar binnen halen.... misschien als je snel schakelt, heb windows niet eens door dat het opeens een andere cam is?

Klinkt allemaal maar ingewikkeld en duur. Wat is er mis met 80 videostreams uit webcammetjes die voor een appel en een ei te krijgen zijn en op tijdstip X een beeld uit alle 80 de streams pakken?

Laat je het spul draaien, dan moet je minimaal de camera's kunnen synchroniseren met elkaar zodat ze allemaal op hetzelfde tijdstip een beeld pakken. Kan een beetje CMOS-sensor best, maar is niet goedkoper dan een product inkopen dat per miljoen geproduceerd word.

[Swets]

ja de meeste webcam kunnen 29 frames per sec aan.... maar ik denk niet dat die dat op kunnen slaan in het geheugen van de cam...

dus tja krijg je dat probleem weer...

net ff kijken op alibaba... cams met een shutterbutton, als je ze per 100 koop, komen ze onder de euro.... dus valt mee...

[Swets]

het moet natuurlijk wel voor ons betaalbaar zijn.... toch?

ik vind die oplossing van die ene site wel een beetje dure oplossing...

als geld geen probleem zou zijn....

zou je met een FPGA geen 80 webcams uit kunnen lezen?

[DaBit]

webcams zijn niet handig met een FPGA; dan heb je software en een PHY nodig voor je USB protocolstack. En dan zie ik het voordeel niet meer zo boven een standaard x86 met een berg USB-controllers.
Maar cameramodules die een BT656 stream uitspugen zijn er ook genoeg te krijgen schat ik zo (aangezien ze de basis zijn/waren van veel camera's), en da's een 8-bit busje.

Maar als je toch dat gaat doen kun je net zo goed direct de CMOS-beeldsensoren interfacen.

Ik zou nog steeds gewoon 80 videostreams de PC in pompen.

[Rob65]

De post van de topic starter was duidelijk...

Dat vraag ik me toch echt af.
Math, of is het nou Tijs? Lijkt informatie over 3D scanning te zoeken maar geeft tegelijk ook aan dat hij het al gebruikt.
Wat is nu eigenlijk de vraag? Wil je zelf goedkoop thuis 3D scanning kunnen doen, zoek je een goed werkende oplossing voor bedrijfsmatig gebruik, wil je weten wat de mogelijkheden van het bewerken van scans in SolidWorks zijn of nog heel iets anders?

3D scanning op zich is niet moeilijk, er zijn veel oplossingen waarmee je 3D scans kan maken.
Maar wat wil je met deze scans doen? Reverse engineering van 3D scans naar een SolidWorks model is nog heel wat anders. De 3D scan oplossing in SW maakt een surface model. Er zijn ook programma's die er (automatisch) een STEP of IGES model van maken met ' echte' features.

Zelf maak ik gebruik van 3D scans van verschillende laser/DLP scanners (David, NextEngine, Mephisto, Fuel3D) maar ook van taster-scanners zoals een Microscribe 3D. De laserscans gebruik ik vaak puur als basis om punten uit te halen die ik vervolgens gebruik om vlakken en features van te maken. Voor de microscribe heb ik software waarmee ik vlakken kan maken om daar op te schetsen - die kan ik in SW dan weer gebruiken om features te maken.
Ja, er is ook software waarmee een taster scanner als een Microscribe3D direkt gebruikt kan worden maar dan praat je over dure software. Leuk als je het professioneel dagelijks gebruikt maar niet leuk voor incidenteel gebruik en zeker niet geschikt voor de hobbyist.

[Swets]

webcams zijn niet handig met een FPGA; dan heb je software en een PHY nodig voor je USB protocolstack. En dan zie ik het voordeel niet meer zo boven een standaard x86 met een berg USB-controllers.
Maar cameramodules die een BT656 stream uitspugen zijn er ook genoeg te krijgen schat ik zo (aangezien ze de basis zijn/waren van veel camera's), en da's een 8-bit busje.

Maar als je toch dat gaat doen kun je net zo goed direct de CMOS-beeldsensoren interfacen.

Ik zou nog steeds gewoon 80 videostreams de PC in pompen.

alleen 80 betaalbare cams zien te vinden...


zo iets?:
http://www.ebay.com/itm/1-pcs-OV2640-2M ... 4170ea82b2

[DaBit]

Dat is er eentje van de categorie 'direct de beeldsensor uitlezen'. Dat kan met een FPGA prima.

Zit je alleen met je bekabeling. Daar komen tere digitale signaaltjes uit. Kun je best smokkelen met een metertje flatcable, maar dan houd het wel op.

[hugo stoutjesdijk]

Dat is er eentje van de categorie 'direct de beeldsensor uitlezen'. Dat kan met een FPGA prima.

Zit je alleen met je bekabeling. Daar komen tere digitale signaaltjes uit. Kun je best smokkelen met een metertje flatcable, maar dan houd het wel op.

Nou dan maak je een soort H constructie, 2 zuilen van 2 meter, op het hart de FPGA, en 10 camera's er op.
( blijf je net op max. 1 meter )
Heb je 10 van die units (20 zuilen). Blijft het ook nog een beetje handelbaar.

Maar dat is het mechanische deel, verder ga ik niet.