[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