[Jderobot] Camera server y viewer usando icestorm

Francisco Rivas franciscomiguel.rivas en urjc.es
Mie Mar 26 13:57:01 CET 2014


Buenas,
si, de hecho est�n en el repo oficial, el cameraserver tiene la opci�n de
arrancarlo con publicaci�n/suscripci�n y hay un cameraviewer_icestorm.

Lo que no he subido es un script que tenemos para arrancar icestorm. �Tiene
sentido subir este script a alg�n sitio de jderobot? El script lo �nico que
hace es levantar icebox y icestormadmin, pero con sus respectivos .cfg
Esta tarde saco un hueco y documento como se lanza todo para que funcione
con icestorm.

un saludo,
Fran.



> El 26 de marzo de 2014, 13:16, JoseMaria <josemaria.plaza en gmail.com>escribi�:
>
> 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
>>
>> _______________________________________________
>> Jde-developers mailing list
>> Jde-developers en gsyc.es
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>
>
>


-- 
------------------------------------------------------------------
Linkedin: linkedin.com/in/fmrivas

Laboratorio de An�lisis del Movimiento, Biomec�nica, Ergonom�a y Control
Motor (LAMBECOM).
Departamento de Fisioterapia, Terapia Ocupacional, Rehabilitaci�n y
Medicina F�sica.
Universidad Rey Juan Carlos (URJC).
------------ pr�xima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20140326/c66ecdd7/attachment.htm 


More information about the Jde-developers mailing list