[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