[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