[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