[Jderobot-dev] kinectserver y kinectviewer
JoseMaria
josemaria.plaza en gmail.com
Lun Mar 5 14:21:34 CET 2012
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
More information about the Jde-developers
mailing list