[Jderobot] Camera server y viewer usando icestorm

[Francisco Rivas]

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