[Jderobot-dev] kinectserver y kinectviewer

JoseMaria josemaria.plaza en gmail.com
Vie Mar 16 13:43:25 CET 2012 

Hola,

bueno, pues ya hemos unificado criterios. Para acceder al dispositivo
kinect tenemos un API unificado, repartido en varios interfaces ICE: 
(a)!! camera, para la imagen de color o la de infrarrojo, es el mismo
que ya usamos en otras aplicaciones para ver imágenes, asi maximizamos
compatibilidad.
(b)!! pointcloud, Alex si quieres ponle este nombre al de la nube de
puntos, súbelo al directorio oficial de los interfaces y engancha con
ello tu kinectserver. La idea de llamarlo pointcloud y no kinect es para
luego poder usarlo con otros dispositivos similares, como el de asus.
(c) kinectleds, para manejo de los leds
(d) pose3Dmotors (para controlar el motorcito tilt de kinect).
Los más importantes son (a) y (b). 

El interfaz (a)(b) es único y hay dos componentes que lo ofrecen:
- kinectserver, basado en PCL, que ha hecho Alex
- openniserver, basado en openni, que ha hecho Fran
No está tan clara la cosa como descartar a ninguno de los dos.

Adicionalmente tenemos la herrameinta kinectviewer, que se conecta a los
interfaces de kinect oportunamente y los muestra en pantalla. Podeis ver
un video de la última versión en [1], recién salido del horno.

[limpieza repositorio]
- Acabo de borrar el interfaz kinect.ice, que ya estaba obsoleto y
despistaba.
- Habría que borrar el directorio visornect y dejar el unico
kinectviewer
- Habría que subir componente kinectserver, enganchando con el interfaz
pointcloud
- Alex, igual hay que retocar un poco también recorder y replayer.

Ánimo,

JoseMaria
[1] robotica-urjc.es/~frivas/videos/new-kinectViewer.flv

On Thu, 2012-03-08 at 14:22 +0100, franciscomiguel.rivas en urjc.es wrote:
> Buenas,
> ayer y hoy he estado haciendo pruebas con el nuevo servidor de kinect  
> que ha hecho Alex sobre PCL y hay alguna cosilla que comentar sobre el  
> driver en PCL:
> 
> 1. Funcionamiento con varios kinects:
> - Es bastante mas sencillo diferenciar los kinects sobre PCL,  
> simplemente funcionan con un ID numerado. El problema es que no  
> consigo que funcionen 2 kinecServer de forma simultánea.. el primero  
> funciona bien pero al lanzar el segundo que queda el primero bloqueado.
> - La única opción que se me ocurre es reescribir el servidor para que  
> cree un "kinectDevice" por cada kinect que pongamos en el fichero de  
> configuración del componente pero habría que hacer el componente casi  
> por completo...
> 
> 2. Resoluciones del openNiGrabber:
> En el API de PCL tenemos la posibilidad de usar los siguiente modos  
> tanto para la imagen de color como para la de profundidad  
> (configurables de forma independiente):
> OpenNI_Default_Mode
> OpenNI_SXGA_15Hz
> OpenNI_VGA_30Hz
> OpenNI_VGA_25Hz
> OpenNI_QVGA_25Hz
> OpenNI_QVGA_30Hz
> OpenNI_QVGA_60Hz
> OpenNI_QQVGA_25Hz
> OpenNI_QQVGA_30Hz
> OpenNI_QQVGA_60Hz
> 
> Para la kinect solo funcionan lo que van a 30Hz en teoría. Digo en  
> teoría porque he probado todos los modos compatibles y la imagen sigue  
> siendo de 640x480, se configura justo al crear el grabber:
> const pcl::OpenNIGrabber::Mode &depth_mode =  
> pcl::OpenNIGrabber::OpenNI_QVGA_30Hz  ;
> 	const pcl::OpenNIGrabber::Mode &image_mode =  
> pcl::OpenNIGrabber::OpenNI_QVGA_30Hz  ;
> 
>     pcl::Grabber* interface = new  
> pcl::OpenNIGrabber("#2",depth_mode,image_mode);
> 
> Pero no hay manera.. no se Alex te suena algo de esto...
> 
> 3. Referencia para las coordenadas de los puntos.
> - Alex, ¿que referencia toma PCL para las coordenadas de los puntos?  
> necesito saber exactamente como va para poder utilizar las dos  
> kinect... hasta ahora obteníamos los puntos a partir de la imagen de  
> profundidad y teniendo la cámara calibrada dentro de un entorno.  
> Tenemos que saber como "calibrar" esa nube de punto.
> 
> 4. Utilización de las funciones propias de openNi utilizando el  
> openNiGrabber de PCL.
> - Directamente es imposible, y no se si hay alguna forma de hacer  
> conversiones para poder utilizarlo, por el momento me parece muy muy  
> complicado porque, por ejemplo el skeleton que da openni para el  
> seguimiento de un player y obtener la posición del sujeto utiliza  
> directamente el conexto (xn::Context) de openni que accede  
> directamente a la kinect.
> 
> 5. PCL ofrece directamente la imagen de profundidad sobre la imagen de  
> color... (ésto nos daba problemas de "flasheo", que tengo que hacer  
> alguna verificación, con el openniServer)
> 
> 
> Sobre el consumo de CPU de los dos servidores es muy muy similar..  
> ¿alguien sabe alguna manera de medir el consumo que no sea  
> "simplemente" con top?
> 
> 
> un saludo a todos,
> Fran.
> 
> 
> "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).

-- 
http://gsyc.es/jmplaza 
Universidad Rey Juan Carlos

More information about the Jde-developers mailing list