[Jderobot-dev] kinectserver y kinectviewer
Alejandro Hernández
ahcorde en gmail.com
Lun Mar 5 18:16:12 CET 2012
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
>
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20120305/550580c4/attachment.htm
More information about the Jde-developers
mailing list