[Jderobot] Camera server y viewer usando icestorm

Roberto Calvo rocapal en gsyc.urjc.es
Mie Mar 26 12:47:56 CET 2014


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


-- 
Roberto Calvo Palomino        | Robotics Lab (GSyC) 
R&D Android Mobile Engineer   | Universidad Rey Juan Carlos

Twitter: @rocapal 
Linkedin: http://www.linkedin.com/in/rocapal



More information about the Jde-developers mailing list