[Jderobot] Camera server y viewer usando icestorm

[JoseMaria]

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