[Jderobot-dev] kinectserver y kinectviewer

Alejandro Hernández ahcorde en gmail.com
Mar Mar 6 19:07:54 CET 2012


Hola Fran,

he rescrito completamente el componente. Los tengo en [1] y [2]. La
estructura es la misma cliente-servidor con las interfaces ICE.

Álex.

[1]https://svn.jderobot.org/users/ahcorde/pfc/trunk/kinect/kinectServer/
[2]https://svn.jderobot.org/users/ahcorde/pfc/trunk/kinect/visorKinect/

El 6 de marzo de 2012 19:03, <franciscomiguel.rivas en urjc.es> escribió:

> 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<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.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).
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20120306/f719c599/attachment-0001.htm 


More information about the Jde-developers mailing list