[FEEDBACK] Escáner 3d Cyclop

[Jose H]

Hola. Estuve montando un escáner cyclop!!

Como resultado del montaje he escrito las siguientes notas, que pueden
ser útiles para la gente que lo monte en el futuro, también para los
de bq para mejorar los manuales y el software:

A.Notas de montaje:

A1.Montaje del disco y estructura.

A11Montaje del disco
La foto 1.1 no se entiende muy bien lo que es, y al carecer
de cualquier tipo de indicación uno no sabe lo que hacer. De hecho el
film está tan fuertemente pegado que nada indica que se puede
despegar. Una simple pestaña con la palabra "despegar" en el disco
sería de gran utilidad, y mejorar la foto.

A1 6-7 La foto 1.6 es mucho mejor que la 1.1. Pero lo que no
está tan claro es en que lado de la base hay que pegar la lámina
antideslizante. Esto es obvio para el que ha diseñado la máquina
porque sabe exactamente dónde va cada pieza, pero quien está montando
este paso todavía no sabe lo que está montando!!(no tiene consciencia
situacional)

Yo pensé que si me hacen despegar una superficie y luego la lámina
antideslizante, la lámina antideslizante tendrá que ir por el lado
despegado. Sino, para que me hacen despegar la superficie, sino porque
quieren que la superficie esté limpia para que pegue la lámina
antideslizante. Por tanto pensé que tenía que desmontarlo y
pegarlo(por el lado malo), aunque por suerte no lo hice.

A13. El montaje de las varillas es extremadamente confuso.Tengo
experiencia montando Repraps y no me enteré de nada!!

Bueno, de algo me enteré, pero de girar las varillas una y otra vez
casi me llevé el pavonado con mis manos y las varillas quedaron algo
brillantes. Mis manos muy sucias, resaltan las arrugas. Si lo monta
una persona mayor le va a hacer sentir...mayor, aparte de que puede
ser una operación frustrante, huele mal y si tocas el manual con las
manos lo manchas y no se puede limpiar.

Al final me enteré de lo que quería decir el manual: Coloca las dos
piezas a una distancia tal que la rosca interior coincida exactamente
con el borde del taladro interior. Ajusta las dos varillas restantes a
la misma medida.

Esto es difícil de explicar, sería mucho más sencillo si pintarais la
parte a introducir de la varilla central en los dos extremos. De esta
forma se hace obvio para la gente.

También vale con un simple celo enrollado en la medida en la que
colocar la tuerca arandela.

A1.5.Trampa mortal el tener que introducir 2 tuercas por el mismo
agujero. Mortal porque es muy fácil cometer errores y directamente
romper la estructura.

Yo cometí los siguientes errores:
Metí la tuerca y la varilla y rosqué la varilla creyendo que se había
enroscado. Luego intenté enroscar la siguiente y no pude, se me cayó
alguna al suelo, vuelvo a introducirla y mirando por un lado veo que
la tuerca no está introducida del todo, así que intento forzar la
tuerca para que pase.

Forzar es peligroso porque puede cargarse la estructura. Al final
saqué la tuerca y me di cuenta de lo que pasaba:
1. La primera tuerca no había enroscado.
2. La tuerca que se cayo, fue en otro sitio, con lo que introduje 1
tuerca adicional.
3.Si hubiera forzado en serio la tuerca me hubiera cargado la pieza grande.

Fue más sencillo montar la estructura de la printrbot original, que ya
es decir!!

Si las tuercas ya vinieran preinstaladas de alguna forma, pegadas o
algo, sería mucho más sencillo.

A.1.7.3 No existe ninguna foto dónde ser vea la orientación del
soporte láser. Hay dos posibles orientaciones. Yo al principio monté
la que no era.

B. HORUS. 3D SCANNING FOR EVERYONE. BUT MAC USERS.

Estaría bien que pusierais alguna indicación de lo que pueden hacer
los usuarios mac. La cámara la reconoce sin problemas y parece que la
mayor parte de los paquetes se pueden instalar con homebrew, macports
u otros.

Bueno, seguiré probando esto...

Ampliar el hilo aquellos que tengáis algo que pueda resultar útil.

[Iceflow]

Buen feedback :D

--

---
Has recibido este mensaje porque estás suscrito al grupo "Clone Wars: Imprimiendo  impresoras 3D" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asrob-uc3m-impreso...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a asrob-uc3m-i...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[Carlos Arroba]

Esto ayuda en la puesta en marcha, pero no con el montaje:

https://www.youtube.com/watch?v=SfgvchlPJHI&feature=youtu.be

Saludos,

Buen feedback :D

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asrob-uc3m-impresoras-3d+unsub...@googlegroups.com.

[Carlos Arroba]

Aquí si que están las instrucciones de montaje:
http://diwo.bq.com/video/instrucciones-de-montaje-de-ciclop/

Ya decía yo que me sonaba haber visto un video.

Saludos.

[Jose H]

Si, la verdad es que en el montaje de la estructura ayuda poco el
vídeo. Por ejemplo en el vídeo mete las dos tuercas de cada brazo a la
vez, y eso no funciona. Primero puede atrancarse alguna, lo segundo no
puedes ver la tuerca dónde está si la tapas con la otra.

En el montaje de las roscas principales tampoco ayuda. La vista hace
que las roscas se superpongan y no se distinguen una de otra, y
fundamentalmente no se ve la medida.

Dónde si ayuda el vídeo es con el desmontaje de la cámara. Porque
leyendo el manual sólo saber lo que quiere que hagas es resolver un
jeroglífico: Aparecen imágenes con unos puntos misteriosos y te dice:
"Necesitarás un destornillador de estrella". Me retrotrajo a los
acertijos del Monkey Island.

El enigma es fascinante cuando descubres que lo que quieren es que
desmontes la cámara. Porque no aparece por ninguna parte "Desmontaje
de la cámara", o "retira los embellecedores que esconden el tornillo
de fijación de la bisagra". Hacerlo sería desvelar el misterio de los
puntos misteriosos. Sería demasiado fácil, como si Guybrush
Threepwood entrara por una puerta y saliera a los 2 segundos con la
chica y habiendo destruido al pirata LeChuck.

[Iceflow]

xDDDDDD

--

---
Has recibido este mensaje porque estás suscrito al grupo "Clone Wars: Imprimiendo  impresoras 3D" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asrob-uc3m-impreso...@googlegroups.com.

[Alex Tutusaus]

Jose no habras colao por ahi un spoiler del final de Monkey Island o que? xD

Para publicar en este grupo, envía un correo electrónico a asrob-uc3m-i...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Jorge "Dredd"]

Pelotudo Jose,

Has publicado tu post en https://groups.google.com/forum/?hl=en#!forum/ciclop-3d-scanner ??

Lo digo pk ese es el que abrió Jesús Arroyo - BQ para estos temas y creo que si lo pones ahí tb tendrás muchas probabilidades de que te respondan o que encuentren antes tu feedback para tenerlo en cuenta

:)

[Jose H]

@Alex. Puede. :-D

@Jorge. No. La intención primaria de ponerlo aquí era que aquellos de
la lista que vayan a montarlo no cometan los mismos errores que yo.

Los que estáis en ese grupo podéis repostear el mensaje, por si Jesús
Arroyo o alguien de Bq no lee el mensaje.

[ruben.s...@gmail.com]

Muchas gracias JoseH por el feedback!!. Lo vamos a analizar y revisar para tenerlo en cuenta. Gracias.

-----------------------

Rubén Sierra

Soporte bq

[Jose H]

De nada Rubén.

Es siempre difícil diseñar bien documentación porque el diseñador
tiene información que la persona que parte de cero no tiene. El que ha
diseñado 15 proptotipos para llegar a un diseño final se sabe el
modelo de memoria.

Yo ahora mismo podría montar 25 ciclops de golpe y me sería trivial,
porque ya lo he visto en conjunto y entiendo lo que busca el diseño.
Una vez que lo sabes es obvio.

Incluso te da cierta verguenza escribirlo, leyendo tu mismo los
problemas que tuviste, como ahora son obvios, pero es lo que
experimenté al montarlo.

[Jose H]

Con respecto al software Horus.

No me funciona como pone la autocalibración. Sólo funciona cuando no
le haces caso a lo que te dice.

En el wizard, autocheck te pone una foto. Si pongo el check board como
me dice la foto no funciona, se mueve unas cuantas veces y da error.
Entre otras cosas porque se pone a mirar el checkboard por la parte
que no tiene nada dibujada!!!

Así que pongo el checkboard al revés de cómo dice la foto y ahora va
mejor porque previsualiza algo en la pantalla, y la línea verde
avanza, aunque da error.

Así que en lugar de ponerlo cómo dice la foto lo pongo en el medio, y
funciona "All OK".

Así que hay dos posibles errores:

1. Existe un error en el manual de montaje de la cyclop en el
conexionado del motor, en el que se ve un cale negro y tres cables
grises. Obviamente supongo que eso significa que de todos los cables
colorados, el negro va dónde el negro del manual. No está nada claro,
y los conectores que habéis puesto permiten introducirlo de las dos
formas, y (supongo) girar al revés.

2. Existe un error en la fotografía del software Horus, y el patrón ha
de quedar al revés. En ese caso también deberíais corregir en el
manual el montaje del patrón.

[Jose H]

Ok. Parece que es la opción 1.

[Jose H]

El software está muy verde pero que muy verde.

Ya que no tenéis soporte a mac, voy a empezar una aplicación nativa
que al menos pueda controlar la mesa giratoria y los láseres.

wxwidgets me parece demasiado genérico para estas cosas. Tampoco es
que tenga una interfaz tan sofisticada como para necesitar tantos
niveles de abstracción.

[Jorge "Dredd"]

Hola José.

Ya lo tienes hecho en mi fork del github de horus, 

https://github.com/jorgerobles/horus/tree/patchintosh

Eres bienvenido a participar, cuantos más seamos antes mejoraremos el software!

Date una vuelta por el Github de bq para ver las issues abiertas, etc.

Hablé con Jesús en persona y me comentó que no se trataba de no dar soporte, si no de un tema de recursos asignados en BQ en este momento.

Coincidimos los tres en que WxPython promete ser multiplataforma pero despues hay que hacer "tweaks" para que funcione de verdad, y me comentó ideas de cómo mejorarlo, pero es cuestión de recursos (Tiempo, personal)

El mayor problema para la la migración de horus a mac estriba principalmente en que depende de OpenCV, y no tiene un buen soporte para webcam, principalmente por el protocolo UVC de @pple. 

Una gran manera de participar (que he de reconocer que me supera) es integrar la librería UVC que esta en mi fork y pertenece a otro proyecto, Pupil también open source a OpenCV.

En mi fork tienes una abstraccion de la librería con opencv y funciona bien.

Un saludo,

Jorge.

[Juan Gonzalez Gomez]

Esa es la idea del open source. Las cosas no son perfectas. Bien, pues arreglémoslas entre todos.  Con el software privativo no tienes esa opción: te tienes que tragar lo que el vendedor te de y para las plataformas que él te diga. El fabricante piensa por tí y decide qué es lo mejor para tí.  Con el open source cada uno lo podemos adaptar a nuestras necesidades. Mejorarlo. Evolucionarlo. Requiere tiempo y recursos. ¡Claro! pero se puede hacer. Hagámoslo. Don't tell me what is wrong, just improve it

--

---
Has recibido este mensaje porque estás suscrito al grupo "Clone Wars: Imprimiendo impresoras 3D" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asrob-uc3m-impreso...@googlegroups.com.

[Jose H]

@Jorge. Gracias por el link, le echaré un vistazo. Yo haré algo nativo
sobretodo con la idea de usar shaders y aprovechar más el hardware. Lo
que voy a hacer es importar los parámetros de calibración de horus y
crearé una herramienta muy simple para detectar el 3d. OpenCV no es
necesario para extraer las imágenes de la cámara y calcular la nube de
puntos. OpenCV ayuda en la detección del patrón de calibración.

@Juan. Hombre, el primer paso es siempre decir lo que está mal. Por
ejemplo yo no he conseguido escanear nada en condiciones hasta ahora.
Eso es un escáner 3d, open source o no, pues es algo que no debería
pasar.
Si yo compro un coche, lo mínimo es que cuando gire la llave arranque
y que las ruedas giren.

Por ejemplo, que el conexionado del motor no lo indiquéis bien no
tiene pase. Si no se denuncia y se corrige, el 50% de la gente se va a
equivocar ahí, o incluso el 70% si hacen como yo y se fijan en el
cable negro del manual.

[Jorge Robles]

@José, dale caña.. y cuando le eches un vistazo al código me dices lo del OpenCV otra vez... XP

--

---
Has recibido este mensaje porque estás suscrito a un tema del grupo "Clone Wars: Imprimiendo  impresoras 3D" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/asrob-uc3m-impresoras-3d/MR7kcR294n8/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a asrob-uc3m-impreso...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a asrob-uc3m-i...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[Jose H]

@Jorge. Ok.

Una cosa que vendría muy bien es un "cubo de calibración". Un objeto
de referencia que viniera con el escáner de forma que siguiendo un
pequeño howto pudieras ver si el escáner está bien montado o no.

[Jose H]

@Jorge. No encuentro la documentación o README con la documentación de
las dependencias para mac.
Yo he hecho lo siguiente:

brew install opencv

Y me dio el siguiente error:
No module named QTKit

Esto parece que arregla el asunto:
pip install -U pyobjc-core
pip install -U pyobjc

Después me dio este problema:
No module named wxversion

Que parece corregirse con esto:
brew install wxpython

Todavía no le he echado un vistazo, pero parece arrancar.

[Jose H]

@Jorge.

No consigo ver nada, me sale una pantalla en negro y pone algo así:

se.dm9.uvcc[4061] <Error>: uvccSendRawRequest: ControlRequest returned
0xe00002ed (kIOReturnNotResponding): device not responding.

en los tres programas: capture, capture_cv2 y test.py

Investigando el problema ejecuto hardware/uvc_capture/mac_video/raw.py
y salen obviamente dos cámaras:
idVendor 0x2ef
idProduct 0x201
Location 608174080
Apr 13 01:23:26 xxxmac se.dm9.uvcc[4112] <Error>: get_string_desc:
DeviceRequest returned 0xe00002ed (kIOReturnNotResponding): device not
responding.
Product Name: None
Apr 13 01:23:26 xxxmac se.dm9.uvcc[4112] <Error>: get_string_desc:
DeviceRequest returned 0xe00002ed (kIOReturnNotResponding): device not
responding.
Product Serial: None
Apr 13 01:23:26 xxxmac se.dm9.uvcc[4112] <Error>: get_string_desc:
DeviceRequest returned 0xe00002ed (kIOReturnNotResponding): device not
responding.
Manufacturer: None
uId: 0x2440000005ac8502
idVendor 0x2ef
idProduct 0x201
Location 639631360
Product Name: None
Product Serial: 1F347B60
Manufacturer: None
uId: 0x26200000046d0825
Trace/BPT trap: 5

La primera cámara debe de ser la cámara integrada, que da error porque
no debe de ser uvc pura, la segunda debe de ser la logitech.

Parece por lo tanto que intenta usar la cámara integrada por defecto y
no la logitech y da por ello error.

Cómo selecciono la cámara logitech?

[Jorge Robles]

Hola José.

Yo es que solo tengo una cámara, la logitech. en uvc.autoCreateCapture, en vez de 0, usa 1

Creo que es uvc.autoCreateCapture(1,(resolucion)...

[Jose H]

Funciona!! Gracias Jorge.

En test.py hay que poner cv2.VideoCapture(1).

No tengo ni idea de cómo integrar la librería UVC en OpenCV. OpenCV es
demasiado grande y compleja desde el punto de vista de
desarrollador(OpenCV abstrae la complejidad del usuario, pero el
desarrollador de la librería ve toda esa complejidad, e incluso mucha
más por ser multiplataforma y tener que hacer trucos o "chapuzas" que
valgan en todos sitios(*)).

Lo que si puedo intentar es crear una aplicación nativa integrando la
librería UVC, un proyecto mucho más pequeño y por lo tanto sencillo
Si funciona otra persona con conocimientos de OpenCV podrá crear un
wrapper para ella.

Obtener la salida de la cámara en nativo parece trivial, la
complejidad va a estar en sincronizar el control de la exposición
mediante UVC.

Voy a intentarlo de la siguiente manera, creo 2 threads, una nativa
con algo similar al programa AVRecorder de mac, otra que haga uso de
la librería UVC. Pongo el modo en exposición manual en mac, y sin
bloquear la cámara paso el control de la exposición con la librería
UVC, devolviendo después el control a la thread nativa.

Si funciona se podrá abstraer a OpenCV. Si no funciona pues lo hago
nativo puro y me gasto 8 euros en un programa comercial que me
controle la exposición.

*A veces es un infierno trabajar en bajo nivel porque los fabricantes
arreglan los bugs en software en lugar de hardware por ser más barato
y dejan los drivers llenos de agujeros y parches dependiente del
sistema operativo.

[Jorge Robles]

Hola José

En el patchintosh tienes el capture_cv2.py que hace que se use la opencv con la uvc. no usa threads, y no he percibido un problema en el rendimiento.

En cuanto a la integración de opencv con uvc de manera nativa, yo se lo reporté a Jesús/Bq, porque el si que se ha bregado la opencv.

Un saludo,

Jorge.

[Jose H]

Si ves el código OpenCV ahora mismo usa un wrapper alrededor del
código nativo para obtener las imágenes.

Si obtenemos las imágenes con la librería UVC probablemente se
compliquen mucho las cosas. Entre otras cosas la librería UVC está
poco mantenida y está especialmente diseñada para cambiar los
parámetros de la cámara, no tanto enviar las imágenes.

El código nativo está mantenido por Apple, y millones de personas
dependen de él para usar la webcam, aunque sea con exposición
automática, funciona bien.

A día de hoy es posible acelerar con shaders el código en OpenCV,
seguramente usando UVC se complique mucho la cosa porque use la CPU en
lugar de la GPU, con lo que se añaden retardos.

En mi experiencia es muy mala decisión hacerse dependiente de una
librería poco mantenida(libUCV) porque uno se acaba convirtiendo en el
mantenedor de la librería de la que carece de documentación.

Usar la librería para controlar parámetros de exposición, enfoque y
demás es mucho más sencillo. Es mucho más sencillo que funcione bien,
el comando "cambia la exposición a este valor" son apenas unos bytes.
El stream son megabytes por segundo que hay que sincronizar.

[Jorge Robles]

Hola José.

Hasta donde yo sé, OpenCV usa video4linux en linux, pero para mac no había nada hasta que encontré la solución de libUVC buscando por internet hasta dar con el Pupil. No digo que sea la mejor, sólo que es la única que encontré :P

Mantenida o no, esa librería ofrece los controles de UVC (saturacion, etc) que la de apple nativa no expone. Si no no hubieran salido aplicaciones de terceros para controlarlas, digo yo, en la apple store hay un par y no son de apple :P, que ya les vale tb.

Ten por seguro que si los majos de apple hubieran expuesto los controles, habría unas cuantas librerías de python o los chicos de OpenCV, que deben de ser unos cuantos más que Jesús, tú y yo, la habrían implementado :)

Quizá te suponga menos problema crear una extensión de python dependiente de la librería de apple, yo en eso no te puedo ayudar porque no tengo ni idea :(  y así consigues dos cosas: Ser compatible con el desarrollo de Jesús, que lleva un año dandose de ostias, y usar la potencia nativa que jobs parió. XD

Dale duro!

[Jose H]

Esto es lo que yo entiendo que hace ahora mismo:

LibUVC adquiere una imagen en su formato en la CPU(lento)
Desde el formato de imagen de libUVC y su memoria se transfiere la
imagen al formato y memoria de OpenCV(muy lento).
Se hace un resize de la imagen en OpenCV en CPU(lentísimo)
Se hace un transpose de la imagen en OpenCV en CPU(lento).
Se hace un flip de la imagen en OpenCV en CPU.

Ahora hay que añadirle el proceso de calcular bordes, detectar
esquinas(para la calibración) o hacer una simple umbralización(para el
escaneado) y lo que uno tiene que esperar se hace duro.

Empresas grandes como Microsoft, Apple o NVDIA(Firefox lo está
probando en beta) se pueden permitir crear un decoder del stream de
una cámara directamente en la GPU, ya que se envía comprimido por el
cable para poderse mandar por USB 2 que es lento,en el futuro con USB3
posiblemente se pueda mandar descomprimido y uno puede acceder a una
textura decodificada en la GPU.

Hacer un resize, transponer y flip teniendo la textura ya en la GPU es
super rápido(30-120 frames por segundo en lugar de segundos por cada
frame).

Detectar bordes y esquinas también es muy rápido en la GPU.

Según tengo entendido, OpenCV ya puede usar esto para trabajar
directamente en la GPU, usando el código nativo. Me acabo de bajar un
ejemplo que me hace todo tipo de chuminadas con la cámara en OpenCV en
tiempo real.

[Jorge Robles]

Si, si, ya se mas o menos cuanto cuestan las operaciones. No he hecho un benchmark porque no tengo una alternativa con la que comparar, aunque el segundo paso, no es tan lento porque el formato es el mismo.

Pero mi objetivo era hacer funcionar el ciclop en osx (La aceleración por hardware para mi es ciencia ficcion)

Te veo integrando tu librería en opencv. Quedarías como un rey :)

[Jose H]

He estado haciendo pruebas.

He creado un programa en c independiente que modifica el valor de la
exposición sin abrir el stream usando libuvc.

Ahora mismo vuelve tonto a AVRecorder, que por defecto tiene un valor
de autoexposición. Tengo que probar a poner exposición manual a ver si
al hacerlo no se vuelve tonto.

Lo siguiente es hacer un programa similar a AVRecorder , pero que al
cambiar la exposición desconecte la sesión AVfoundation, abra la
sesión con libuvc, modifique la exposición, cierre la sesión libuvc y
reinicie la sesión AVFoundation en modo exposición manual. Esto es muy
rápido, instantáneo, puede hacerse varias veces por segundo sin que se
note.

Aquí habla de la aceleración de Apple por hardware:
http://www.objc.io/issue-23/videotoolbox.html

Lo que dice es que si el codec no es h264 lo descodifica por software.
Esto deja 100% aceleradas sólo cámaras profesionales(por cable HDMI) o
el iPhone, que se puede conectar por cable y utilizar como cámara. El
iPhone si tiene control total de exposición, apertura, foco y todo lo
demás de una cámara. Si el Android tuviera el equivalente podría
prescindirse de la webcam, poniendo el smartphone en su lugar.

[Jorge Robles]

Pues eso es una caña. Si puedes hacer algo para usar el iphone en vez de la logitech, tenemos muuuucha mas resolucion.

Yo intente encontrar algo para hacer eso del iphone con cable pero no tuve suerte.

En android... bueno, hay un ubuntu phone por ahí que el solico podria correr horus XD

[Jose H]

El tema de las cámaras en mac no es un problema de Apple, es un
problema de Logitech, como el 95% de las webcam se usaban en Windows,
Logitech nunca ha pensado en dedicar recursos ni a Linux ni a mac,
ignorándolos completamente.

La gente de Linux lo ha pasado muy mal con las webcam porque para
lograr Video for Linux ha tenido que descifrar el formato por
ingeniería inversa. Los estándares no te dan toda la información,
porque muchas cosas dependen de extensiones que son propias del
fabricante, y los drivers resuelven bugs que no aparecen por ninguna
parte en el estándar.

Al final, que te funcione una cámara bien en Linux acababa siendo una
lotería. Anda que no me he peleado yo con las webcam en ubuntu.

Yo no voy a dedicar mucho esfuerzo a luchar contra los elementos en
este sentido, porque al final se resuelve de la misma manera que los
modems o impresoras que sólo funcionaban en Windows, que se reemplazan
por routers independientes del SO, e impresoras u otros dispositivos
conectados a la red ethernet/wifi local.

Si hacer que funcionen las cámaras logitech se hace demasiado
complicado, pues se pasa de las cámaras logitech, y se utilizan otras
cámaras que sean más amigables al DIY, como la cámara de la Rasperry
py o de teléfonos móviles.

[Xoan Sampaiño]

¿No sería más recomendable que todo en lo que está derivando el hilo lo habléis a través de la lista de desarrollo de Horus? Yo al menos ya no veo demasiada relación con el «feedback» de Cíclope.

-- 
Xoan Sampaiño [xoan@twitter|vimeo|flickr|delicious]

 /\  Document Freedom Day - Liberate your documents
_\/` http://documentfreedom.org/ - March 25th, 2015

--

---
Has recibido este mensaje porque estás suscrito al grupo "Clone Wars: Imprimiendo  impresoras 3D" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asrob-uc3m-impreso...@googlegroups.com.

[Jorge Robles]

Tienes toda la razón Xoan, sorry.

--

---
Has recibido este mensaje porque estás suscrito a un tema del grupo "Clone Wars: Imprimiendo impresoras 3D" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/asrob-uc3m-impresoras-3d/MR7kcR294n8/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a asrob-uc3m-impreso...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a asrob-uc3m-i...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Xoan Sampaiño]

No, si no hay que pedir perdón :D

Solo lo digo porque se está desviando mucho hacia temas técnicos que quizá sería más conveniente que lo viesen también los que de verdad pueden hacer algo con esa información.

-- 
Xoan Sampaiño [xoan@twitter|vimeo|flickr|delicious]

 /\  Document Freedom Day - Liberate your documents
_\/` http://documentfreedom.org/ - March 25th, 2015

[Jose H]

Hola Xoan.

Si en el futuro profundizaré más en la lista de desarrollo de Horus.

[Jose H]

Continuando con el tema de feedback, he conseguido hacer que funcione
el escáner más o menos.

Hay una información IMPORTANTISIMA que no aparece por ninguna parte en
la documentación del escáner. Es muy importante porque sin ella el
escáner no es capaz de escanear con texturas, y con iluminación(no a
oscuras) por lo menos en mi caso, y el escáner parece estropeado:

1- Es necesario escanear con un fondo completamente negro mate.

2- El fondo negro mate debe de estar lo suficientemente alejado del
escáner como para que no sean visibles en la cámara la intersección de
los láseres con el fondo negro.

Ignoro por qué esta información no aparece por ninguna parte en la
documentación. Es más, en todas las fotos de la documentación aparece
fondo blanco, y en algunas se ve el láser intersectando con el
fondo!!.

Sin esta información aparece tantísima cantidad de ruido que es
imposible escanear nada. Yo ya pensaba que me habían vendido algo que
no funcionaba.

[Jorge Robles]

Hola José,

Si, la verdad es que yo lo di por hecho y los mejores resultados los he obtenido así, pero no es tanto el primer punto como el segundo. Es decir, yo he escaneado razonablemente bien cuando no hay un objeto que se interponga en la distancia focal. Por ejemplo, escaneando desde un punto de la habitación a la otra sin objetos en movimiento por en medio. Pero creo que tiene que ver más con el enfoque de la cámara, los láseres y el umbral "threshold" de detección.

[Ángel L.M.]

Hola JoseH,

Por lo general, no es necesario escanear con un fondo negro mate (yo no lo he hecho) para hacer un buen escaneo con textura. Prueba a cambiar el diámetro del ROI en el banco de trabajo de Horus ajustándolo al objeto que quieres escanear para evitar el ruido provocado por elementos externos :)

Un saludo!

[Jose H]

Gracias Angel.

Pensaba que Windows no tenía la opción de ROI, ni ninguna del panel de
escaneado porque parece venir desactivado por defecto el panel.
Ya decía yo, ahora acabo de activarlo con View->Panel. Lo probaré en
cuanto pueda a ver que tal.