[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