<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Buenas,</span><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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</div>
<div style="font-family:arial,sans-serif;font-size:13px">Esta tarde saco un hueco y documento como se lanza todo para que funcione con icestorm.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
un saludo,</div><div style="font-family:arial,sans-serif;font-size:13px">Fran. </div><div class="gmail_extra"><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra"><br><div class="gmail_quote">El 26 de marzo de 2014, 13:16, JoseMaria <span dir="ltr"><<a href="mailto:josemaria.plaza@gmail.com" target="_blank">josemaria.plaza@gmail.com</a>></span> escribió:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hola Oscar,<br>
<br>
más contexto: sí, uno de los puntos que envié el otro día a tratar es<br>
incorporar a los servidores que tenemos la capacidad de ofrecer sus<br>
datos sensoriales como llamada a procedimiento remoto RPC (como hasta<br>
ahora) o bien como publicación/suscripción (usando icestorm del propio<br>
ICE). La idea es que ambos coexistan y cada cliente decida si se conecta<br>
en una modalidad u otra según convenga, configurable.<br>
<br>
En su día hicimos alguna prueba con icestorm y cameraserver, pero hasta<br>
ahora lo teníamos todo como RPC para que fuera el cliente quien<br>
gobernara el ritmo de comunicaciones, con independencia del ritmo de<br>
captura sensorial en el servidor. Ahora, en algunas aplicaciones, vimos<br>
la utilidad de organizarlo como suscripción y que sea el servidor quien<br>
notifica las novedades a los clientes suscritos. En teoría disminuye las<br>
latencias y en segun qué configuraciones, algo de consumo de CPU. Los<br>
números reales en las pruebas hechas los ha dado Roberto.<br>
<br>
Hasta ahora con ParallelIce teníamos un polling al servidor para<br>
solventarlo e implementar un pseudopush desde el servidor sensorial. El<br>
paso adelante es usar publicación/suscripción per sé, aprovechando que<br>
ICE lo facilita con icestorm. La idea es aumentar la funcionalidad de<br>
nuestros servidores (cameraserver, openniserver, etc...) para que<br>
amplíen su oferta con este servicio, sumándoselo al actual.<br>
<br>
Además de discutirlo en la reunión de este viernes lo iremos comentando<br>
vía lista. Avanti,<br>
<br>
JoseMaria<br>
<div><div>On Wed, 2014-03-26 at 12:47 +0100, Roberto Calvo wrote:<br>
> Hola,<br>
><br>
> Fran te dará los detalles, pero si, él ya se peleó e hizo funcionar una<br>
> versión con IceStorm y está funcionando, así que eso que<br>
> re-aprovechamos :-)<br>
><br>
> > Esto nos proporcionará las siguientes ventajas:<br>
> > 1.- Una reducción drástica de la elevada latencia que añade el patrón<br>
> > actual.<br>
> > 2.- Reducir el tráfico y la carga de sistemas empotrados en el robot.<br>
><br>
> Sobre esto, aunque inicialmente pensabamos lo mismo la práctica dice lo<br>
> contrario. No hay casi diferencia (en cuanto a CPU y recursos) entre<br>
> mandar 20 imágenes por segundo usando RPC con cameraClient, que usando<br>
> publicación/suscripción para hacer el push de esas mismas 20 imágenes .<br>
> Si ganas en saber seguro que cada push es una nueva imagen, o si<br>
> cameraserver diera imágenes a un flujo que oscilara: 5, 10, 15fps ...<br>
> pero eso no pasa con cameraServer/openniServer a día de hoy.<br>
><br>
> En general publicación/suscripción desahoga mucho al sistema cuando no<br>
> sabes el ritmo de obtención de datos, o si se mandan 1 vez cada mucho<br>
> tiempo (evitas hacer polling).<br>
><br>
> Si cameraServer obtiene 20fps y cameraView pide mediante RPC a 20fps, no<br>
> hay diferencia en usar publicación/suscripción (en cuanto a CPU y<br>
> recursos). De hecho pub/sus te obliga a leventar un proceso más (IceBox)<br>
> y reenviar todas las conexiones.<br>
><br>
> La prueba (trabajando a 20fps):<br>
><br>
> CPU % - RPC<br>
><br>
> 7.0 ./cameraserver --Ice.Config=cameraserver.cfg<br>
> 1.3 ./cameraview --Ice.Config=cameraview.cfg<br>
><br>
> CPU % - IceStorm<br>
><br>
> 7.0 ./cameraserver --Ice.Config=cameraserver.cfg<br>
> 1.4 ./cameraview_icestorm --Ice.Config=cameraview_icestorm.cfg<br>
><br>
><br>
<br>
--<br>
</div></div><a href="http://gsyc.urjc.es/jmplaza" target="_blank">http://gsyc.urjc.es/jmplaza</a><br>
Universidad Rey Juan Carlos<br>
<div><div><br>
_______________________________________________<br>
Jde-developers mailing list<br>
<a href="mailto:Jde-developers@gsyc.es" target="_blank">Jde-developers@gsyc.es</a><br>
<a href="http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers" target="_blank">http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers</a><br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>------------------------------------------------------------------</div><div>Linkedin: <a href="http://linkedin.com/in/fmrivas" target="_blank">linkedin.com/in/fmrivas</a></div>
<div><br></div><div>Laboratorio de Análisis del Movimiento, Biomecánica, Ergonomía y Control Motor (LAMBECOM).</div><div>Departamento de Fisioterapia, Terapia Ocupacional, Rehabilitación y Medicina Física.</div><div>Universidad Rey Juan Carlos (URJC). </div>
</div></div>