[Jderobot-dev] kinectserver y kinectviewer

franciscomiguel.rivas en urjc.es franciscomiguel.rivas en urjc.es
Mie Mar 7 12:28:26 CET 2012


Buenas,
siguiendo con los pasos de actualización de los componentes de kinect  
he borrado del repositorio los componentes obsoletos de jdenect y  
visornect, he borrado el kinectServer que había subido que utiliza  
openni para que suba Alex su servidor de PCL que de momento será la  
versión oficial que utilizaremos y para mantener el soporte de openni  
subo también mi server pero renombrado a openniServer para no perder  
la funcionalidad que ofrece openni, ya veremos si esto sigue así o  
conseguimos unificar todo en un mismo driver, esperamos dejarlo  
zanjado en los próximos días.

Alex cuando quieras ya puedes subir tu server de PCL.

un saludo a todos,
Fran.



franciscomiguel.rivas en urjc.es escribió:

> Buenas,
> ya veo... has utilizado el openni-grabber que ofrece PCL para acceder
> al driver... consume mucha cpu?? estaría bien probar cual tiene mejor
> rendimiento... tiene muy buena pinta la verdad..
>
> Los dos peros que le veo son:
> 1. Necesitar PCL instalado (si se van a hacer cosas con solo con las
> cámaras es un poco mas complicado... aunque por lo general siempre se
> va a usar con PCL)
> 2. Perder toda la funcionalidad que nos ofrece openni como es la
> detección de "players", detección automática de la mano y una serie de
> patrones que están ya funcionando de forma robusta en openni y que
> igual en algún trabajo nos puede venir bien.
>
> Las ventajas:
> Si vas a trabajar con nube de puntos tienes soporte ya en PCL en ambos
> lados y no tienes casi ninguna conversión.
>
> ¿que pensáis?
>
> un saludo!
>
>
> "Alejandro Hernández" <ahcorde en gmail.com> escribió:
>
>> 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).
>>>
>>
>
>
>
> ------------------------------------------------------------------
> 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).
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>



------------------------------------------------------------------
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