[Jderobot] Camera server y viewer usando icestorm
JoseMaria
josemaria.plaza en gmail.com
Jue Mar 27 08:32:14 CET 2014
Estupendo Fran.
Sí, subiría ese script al repositorio oficial.
El sitio no lo veo claro, casi me vale cualquiera. No es un componente,
pero lo dejaría en components, en un subdirectorio que se llamase
ice-utils o algo así. Por ejemplo visualHFSM tampoco es un componente,
sino una herramienta y lo hemos colocado ahí para distinguirlo de las
bibliotecas y los interfaces... Si se te ocurre otro mejor, avanti.
Saludos,
JoseMaria
On Wed, 2014-03-26 at 13:57 +0100, Francisco Rivas wrote:
> Buenas,
> si, de hecho están en el repo oficial, el cameraserver tiene la opción
> de arrancarlo con publicación/suscripción y hay un
> cameraviewer_icestorm.
>
>
> Lo que no he subido es un script que tenemos para arrancar icestorm.
> ¿Tiene sentido subir este script a algún sitio de jderobot? El script
> lo único que hace es levantar icebox y icestormadmin, pero con sus
> respectivos .cfg
> Esta tarde saco un hueco y documento como se lanza todo para que
> funcione con icestorm.
>
>
> un saludo,
> Fran.
>
>
>
> El 26 de marzo de 2014, 13:16, JoseMaria
> <josemaria.plaza en gmail.com> escribió:
>
> Hola Oscar,
>
> más contexto: sí, uno de los puntos que envié el otro
> día a tratar es
> incorporar a los servidores que tenemos la capacidad
> de ofrecer sus
> datos sensoriales como llamada a procedimiento remoto
> RPC (como hasta
> ahora) o bien como publicación/suscripción (usando
> icestorm del propio
> ICE). La idea es que ambos coexistan y cada cliente
> decida si se conecta
> en una modalidad u otra según convenga, configurable.
>
> En su día hicimos alguna prueba con icestorm y
> cameraserver, pero hasta
> ahora lo teníamos todo como RPC para que fuera el
> cliente quien
> gobernara el ritmo de comunicaciones, con
> independencia del ritmo de
> captura sensorial en el servidor. Ahora, en algunas
> aplicaciones, vimos
> la utilidad de organizarlo como suscripción y que sea
> el servidor quien
> notifica las novedades a los clientes suscritos. En
> teoría disminuye las
> latencias y en segun qué configuraciones, algo de
> consumo de CPU. Los
> números reales en las pruebas hechas los ha dado
> Roberto.
>
> Hasta ahora con ParallelIce teníamos un polling al
> servidor para
> solventarlo e implementar un pseudopush desde el
> servidor sensorial. El
> paso adelante es usar publicación/suscripción per sé,
> aprovechando que
> ICE lo facilita con icestorm. La idea es aumentar la
> funcionalidad de
> nuestros servidores (cameraserver, openniserver,
> etc...) para que
> amplíen su oferta con este servicio, sumándoselo al
> actual.
>
> Además de discutirlo en la reunión de este viernes lo
> iremos comentando
> vía lista. Avanti,
>
> JoseMaria
> On Wed, 2014-03-26 at 12:47 +0100, Roberto Calvo
> wrote:
> > Hola,
> >
> > Fran te dará los detalles, pero si, él ya se peleó e
> hizo funcionar una
> > versión con IceStorm y está funcionando, así que eso
> que
> > re-aprovechamos :-)
> >
> > > Esto nos proporcionará las siguientes ventajas:
> > > 1.- Una reducción drástica de la elevada latencia
> que añade el patrón
> > > actual.
> > > 2.- Reducir el tráfico y la carga de sistemas
> empotrados en el robot.
> >
> > Sobre esto, aunque inicialmente pensabamos lo mismo
> la práctica dice lo
> > contrario. No hay casi diferencia (en cuanto a CPU y
> recursos) entre
> > mandar 20 imágenes por segundo usando RPC con
> cameraClient, que usando
> > publicación/suscripción para hacer el push de esas
> mismas 20 imágenes .
> > Si ganas en saber seguro que cada push es una nueva
> imagen, o si
> > cameraserver diera imágenes a un flujo que oscilara:
> 5, 10, 15fps ...
> > pero eso no pasa con cameraServer/openniServer a día
> de hoy.
> >
> > En general publicación/suscripción desahoga mucho al
> sistema cuando no
> > sabes el ritmo de obtención de datos, o si se mandan
> 1 vez cada mucho
> > tiempo (evitas hacer polling).
> >
> > Si cameraServer obtiene 20fps y cameraView pide
> mediante RPC a 20fps, no
> > hay diferencia en usar publicación/suscripción (en
> cuanto a CPU y
> > recursos). De hecho pub/sus te obliga a leventar un
> proceso más (IceBox)
> > y reenviar todas las conexiones.
> >
> > La prueba (trabajando a 20fps):
> >
> > CPU % - RPC
> >
> > 7.0 ./cameraserver --Ice.Config=cameraserver.cfg
> > 1.3 ./cameraview --Ice.Config=cameraview.cfg
> >
> > CPU % - IceStorm
> >
> > 7.0 ./cameraserver --Ice.Config=cameraserver.cfg
> > 1.4 ./cameraview_icestorm
> --Ice.Config=cameraview_icestorm.cfg
> >
> >
>
> --
>
> http://gsyc.urjc.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
>
>
>
>
>
>
>
>
> --
> ------------------------------------------------------------------
> Linkedin: linkedin.com/in/fmrivas
>
>
> 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
--
http://gsyc.urjc.es/jmplaza
Universidad Rey Juan Carlos
More information about the Jde-developers
mailing list