[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