[Jderobot-dev] kinectserver y kinectviewer

franciscomiguel.rivas en urjc.es franciscomiguel.rivas en urjc.es
Mar Mar 6 19:03:36 CET 2012


Buenas a todos,
> Mejora 0: Creo que no es tan sencillo como un corta pega, ahora mismo mi
> componente utiliza un wrapper que esta sobre PCL, ya que de esta manera
> tengo las imagen de color, profundidad y nube de puntos en variables sin
> necesidad de hacer ninguna transformación. Como creo que sería necesario de
> sacar la nube de puntos a partir de la imagen de profundidad.

mmm... la forma de funcionar es la misma? tienes un "servidor" que se  
conecta al kinect y ofrece los datos en interfaces de ICE y otro que  
se coneta en modo "cliente"??
Si es así ¿has reecrito los componentes por completo? ¿me puedes decir  
donde tienes los componentes para echarles un ojo y ver que podemos  
hacer para unificar lo máximo posible? Si no es posible de ninguna  
manera nos tendremos que decantar por usar uno de los dos y ahora es  
un buen momento para decidirnos.


Creo que de momento tendremos que abordar esto antes de seguir con las  
siguiente mejoras, ¿no os parece?

un saludo!




"Alejandro Hernández" <ahcorde en gmail.com> escribió:

> Hola Jose María,
>
> Te comento:
>
> Mejora 0: Creo que no es tan sencillo como un corta pega, ahora mismo mi
> componente utiliza un wrapper que esta sobre PCL, ya que de esta manera
> tengo las imagen de color, profundidad y nube de puntos en variables sin
> necesidad de hacer ninguna transformación. Como creo que sería necesario de
> sacar la nube de puntos a partir de la imagen de profundidad.
>
> Mejora 1 y 2 : Ahora mismo esta incluido en el fichero de configuración
> pero se puede incluir una par de métodos que modifiquen ese valor sin
> problema.
>
> Mejora 3: Cualquiera de las dos versiones debería de funcionar con esto.
>
> Mejora 4: La mejora 4 no la entiendo muy bien
>
> Mejora 5: Tiene que ver con la interfaz.
>
> Mejora 6: Creo que lo mejor es usar Openni porque es lo que están usando
> las librerías que están saliendo alrededor de Kinect.
>
> En cuento a las dos versiones de KinectServer, creo que estas son las
> diferencias después de mirarme lo componentes:
>
>    - El componente de Fran da la imagen a color, profundidad, controla el
>    servo y el color del LED
>    - Mi componente da la imagen a color, profundidad y nube de puntos.
>    - Las interfaces de las imagenes cambian yo utilizo la interfaz cámara
>    sin modificar y Fran utiliza una que extiende de la interfaz camera (
>    entiendo que esta interfaz es compatible 100% con cameraview, no?)
>
> Espero no dejarme nada sin comentar.
>
> Saludos!
>
> Álex.
>
> El 5 de marzo de 2012 14:21, JoseMaria <josemaria.plaza en gmail.com> escribió:
>
>> Hola,
>>
>> retomo aquí los avances sobre kinectServer y kinectViewer, contando con
>> los que ha subido Fran al repositorio oficial y las mejoras de Alex, que
>> no sé hasta que punto están unificadas.... Sigamos asentándolo.
>>
>> Decisiones que hemos tomado:
>> 1.- unificar en un único servidor que ofreciera varios interfaces, las
>> dos cámaras (color y profundidad) y el nuevo interfaz de puntos.
>> 2.- kinectserver basado en OpenNI. Teníamos otra implementación del
>> driver basada en libfreenect (ahora openkinect), pero tienen una
>> comunidad detrás menos activa que la de OpenNI y consume mucha CPU. Si
>> luego mejoran ya veremos.
>> 3.- el interfaz de nube de puntos es muuuuy voluminoso, para que ice
>> pueda con ello hay que muestrear esa nube de puntos para reducirla a un
>> tamaño manejable.
>>
>>
>> Mejoras:
>> 0.- unificar código. Ahora mismo no sé si hay una o dos versiones
>> (Alex-Fran). ¿Podriamos tomar como referencia los que hay actualmente en
>> el repositorio? Corta-pegando lo necesario para incorporar tus últimas
>> mejoras Alex?
>>
>> 1.- Alex, podrías unificar dentro del mismo interfaz de nube de puntos
>> dos nuevos métodos, el que fija el ratio de muestreo y el que lo
>> pregunta (SetSamplingRate y GetSamplingRate o algo así). Es que ese
>> parámetro sólo tiene sentido asociado con los puntos. El interfaz podría
>> ser algo asi como la secuencia de puntos en 3D y estos métodos metidos.
>> ¿Cómo lo ves?
>>
>> 2.- Si ves que no es necesario cambiarlo en tiempo de ejecución lo
>> dejamos exclusivamente como parámetro del fichero de configuración y
>> listo. Habría que incluir en cualquier caso que pudiera coger el
>> parámetro de SamplingRate desde el fichero de configuración de
>> kinectServer...
>>
>> 3.- Con vistas a poder utilizar más de un kinect en la máquina conviene
>> en el fichero de configuración de kinectserver poder decirle qué fichero
>> usar como configuración de OpenNI. Fran está con ello.
>>
>> 4.- Fran va a meter también en el fichero de configuración de
>> kinectserver la posibilidad de especificarle un cierto tamaño a la
>> imagen de profundidad. Hasta ahora capturaba en nativo siempre en el
>> mismo tamaño y con opencv redimensionabamos la imagen de profundidad a
>> posteriori. Al capturar directamente a baja resolución igual hasta es
>> más ligero computacionalmente.
>>
>> 5.- Fran refactoriza kinectviewer para que aparezcan varias subventanas,
>> no como ahora que aparece la ventana opengl aunque no tengamos puntos.
>>
>> 6.- El driver actual no va todo lo rápido que nos gustaría o consume
>> "bastante" CPU (menos que el de libfreenect, en cualquier caso). Creo
>> que no merece la pena optimizarlo nosotros (de momento), sigamos
>> adelante e igual los chicos de OpenNI dan con alguna técnica para
>> acelerar el rendimiento. No creo que estén usando DMA estos chismes...
>>
>> ¿Qué os parece? Va a quedar chulisimo...
>>
>> Saludos,
>>
>> JoseMaria
>> On Mon, 2012-02-27 at 09:12 +0100, Alejandro Hernández wrote:
>> > Hola a todos,
>> >
>> >
>> > ya que tenemos claro que lo mejor es unificarlo todo, he modificado
>> > KinectServer para que sirva las imagenes del Kinect según las
>> > interfaces de cámaras que ya existen junto a la interfaz que me he
>> > creado para la nuve de puntos. También he modificado el visor para que
>> > la visualización en 3D tire de la nube de puntos y no a partir de la
>> > imagen en profundidad.
>> >
>> >
>> > Un saludo.
>> >
>> >
>> > Álex.
>> >
>> > El 21 de febrero de 2012 18:34, Fran Rivas
>> > <franciscomiguel.rivas en urjc.es> escribió:
>> >         Totalmente de acuerdo con José María... Si tenemos un
>> >         componente mejor será tener in driver integrando todo y que
>> >         este sirva todo lo que necesitemos... Siempre podemos activar
>> >         solo lo que queramos desde el fichero se configuración...
>> >
>> >
>> >         Sobre la integración de la nube de puntos... Yo subiré mañana
>> >         al repo oficial los dos componentes y si no es mucho lío que
>> >         alex añada la parte de la nube de puntos...
>> >
>> >         Un saludo,
>> >         fran
>> >
>> >         Enviado desde mi iPhone
>> >
>> >         El 21/02/2012, a las 18:01, JoseMaria
>> >         <josemaria.plaza en gmail.com> escribió:
>> >
>> >         > Por mi parte también unificaría en un componente
>> >         kinectserver que pueda
>> >         > servir varios interfaces a la vez: imagenes color, imagenes
>> >         profundidad,
>> >         > nube de puntos. En una ejecución concreta se le configura
>> >         para que sirva
>> >         > sólo los que realmente se necesiten para esa aplicación, y
>> >         si son todos,
>> >         > pues todos.
>> >         >
>> >         > Una ventaja de este diseño es que si tenemos dos componentes
>> >         cliente
>> >         > simultaneamente, uno que necesite puntos y otro que necesite
>> >         imagen de
>> >         > profundidad, el servidor puede atenderlos a ambos sin
>> >         problema. Si
>> >         > hacemos dos servidores habría problemas porque sólo uno de
>> >         ellos puede
>> >         > acceder al dispositivo en local, el segundo no tendría
>> >         permisos al estar
>> >         > ocupado el dispositivo.
>> >         >
>> >         > Otra ventaja es que tenemos centralizado en un único sitio
>> >         las
>> >         > peculiaridades del acceso en local a kinect, y no en dos,
>> >         que habría que
>> >         > actualizar ambos cada vez que saquen una nueva versión del
>> >         driver local,
>> >         > openNI, etc.
>> >         >
>> >         >>> ¿cómo lo veis?
>> >         >>
>> >         >> ¿Existe algún dispositivo a parte del kinect del que
>> >         podamos extraer la
>> >         >> nube de puntos? Si la respuesta es SI, separaría los
>> >         componentes ya que
>> >         >> la nube de puntos puede venir de otra fuente de datos.
>> >         >
>> >         >> Si NO haría únicamente 1. Si algún día salen más
>> >         dispositivos que
>> >         >> ofrezcan sólo la nube de puntos, quizás tienen sentido
>> >         tener un único
>> >         >> driver para eso. Pero ahora mismo veo más eficiente y mejor
>> >         tener un
>> >         >> único driver.
>> >         >>
>> >         >> Reutilizar código, interfaces y crear diferentes módulos es
>> >         muy bueno y
>> >         >> potente. Pero si siempre lo vamos a utilizar de la misma
>> >         manera, es
>> >         >> gastar tiempo y emplear recursos (literalmente). Cuando
>> >         lleguen nuevos
>> >         >> dispositivos que ofrezcan la nube de puntos creo que  será
>> >         el momento de
>> >         >> reorganizar código y dividir los componentes.
>> >         >
>> >         > A día de hoy no. Y si lo hay en un futuro no hay problema en
>> >         que dos
>> >         > componentes diferentes ofrezcan el mismo interfaz. Por
>> >         ejemplo
>> >         > cameraserver y gazeboserver ofrecen el mismo interfaz de
>> >         cámara.
>> >         >
>> >         > Alex, el driver que has hecho usa openNI?
>> >         >
>> >         > JoseMaria
>> >         > --
>> >         > http://gsyc.es/jmplaza
>> >         > Universidad Rey Juan Carlos
>> >         >
>> >         >
>> >         > _______________________________________________
>> >         > Jde-developers mailing list
>> >         > Jde-developers en gsyc.es
>> >         >
>> >
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>> >         _______________________________________________
>> >         Jde-developers mailing list
>> >         Jde-developers en gsyc.es
>> >
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>> >
>> >
>> >
>>
>> --
>> http://gsyc.es/jmplaza
>> Universidad Rey Juan Carlos
>>
>>
>>
>



------------------------------------------------------------------
Laboratorio de Análisis del Movimiento, Biomecánica, Ergonomía y  
Control Motor (LAMBECOM).
Departamento de Fisioterapia, Terapia Ocupacional, Rehabilitación y  
Medicina Física.
Universidad Rey Juan Carlos (URJC).


More information about the Jde-developers mailing list