<div dir="ltr">Buenas.<div><br></div><div>perfecto pues esta tarde lo subo todo y lo documento que ayer al final estuve con lío y no me dio tiempo. </div><div><br></div><div>un saludo,</div><div>Fran. </div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">El 27 de marzo de 2014, 8:32, JoseMaria <span dir="ltr"><<a href="mailto:josemaria.plaza@gmail.com" target="_blank">josemaria.plaza@gmail.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Estupendo Fran.<br>
<br>
Sí, subiría ese script al repositorio oficial.<br>
<br>
El sitio no lo veo claro, casi me vale cualquiera. No es un componente,<br>
pero lo dejaría en components, en un subdirectorio que se llamase<br>
ice-utils o algo así. Por ejemplo visualHFSM tampoco es un componente,<br>
sino una herramienta y lo hemos colocado ahí para distinguirlo de las<br>
bibliotecas y los interfaces... Si se te ocurre otro mejor, avanti.<br>
<br>
Saludos,<br>
<br>
JoseMaria<br>
<div class="HOEnZb"><div class="h5">On Wed, 2014-03-26 at 13:57 +0100, Francisco Rivas wrote:<br>
> Buenas,<br>
> si, de hecho están en el repo oficial, el cameraserver tiene la opción<br>
> de arrancarlo con publicación/suscripción y hay un<br>
> cameraviewer_icestorm.<br>
><br>
><br>
> Lo que no he subido es un script que tenemos para arrancar icestorm.<br>
> ¿Tiene sentido subir este script a algún sitio de jderobot? El script<br>
> lo único que hace es levantar icebox y icestormadmin, pero con sus<br>
> respectivos .cfg<br>
> Esta tarde saco un hueco y documento como se lanza todo para que<br>
> funcione con icestorm.<br>
><br>
><br>
> un saludo,<br>
> Fran.<br>
><br>
><br>
><br>
> El 26 de marzo de 2014, 13:16, JoseMaria<br>
> <<a href="mailto:josemaria.plaza@gmail.com">josemaria.plaza@gmail.com</a>> escribió:<br>
><br>
> Hola Oscar,<br>
><br>
> más contexto: sí, uno de los puntos que envié el otro<br>
> día a tratar es<br>
> incorporar a los servidores que tenemos la capacidad<br>
> de ofrecer sus<br>
> datos sensoriales como llamada a procedimiento remoto<br>
> RPC (como hasta<br>
> ahora) o bien como publicación/suscripción (usando<br>
> icestorm del propio<br>
> ICE). La idea es que ambos coexistan y cada cliente<br>
> 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<br>
> cameraserver, pero hasta<br>
> ahora lo teníamos todo como RPC para que fuera el<br>
> cliente quien<br>
> gobernara el ritmo de comunicaciones, con<br>
> independencia del ritmo de<br>
> captura sensorial en el servidor. Ahora, en algunas<br>
> aplicaciones, vimos<br>
> la utilidad de organizarlo como suscripción y que sea<br>
> el servidor quien<br>
> notifica las novedades a los clientes suscritos. En<br>
> teoría disminuye las<br>
> latencias y en segun qué configuraciones, algo de<br>
> consumo de CPU. Los<br>
> números reales en las pruebas hechas los ha dado<br>
> Roberto.<br>
><br>
> Hasta ahora con ParallelIce teníamos un polling al<br>
> servidor para<br>
> solventarlo e implementar un pseudopush desde el<br>
> servidor sensorial. El<br>
> paso adelante es usar publicación/suscripción per sé,<br>
> aprovechando que<br>
> ICE lo facilita con icestorm. La idea es aumentar la<br>
> funcionalidad de<br>
> nuestros servidores (cameraserver, openniserver,<br>
> etc...) para que<br>
> amplíen su oferta con este servicio, sumándoselo al<br>
> actual.<br>
><br>
> Además de discutirlo en la reunión de este viernes lo<br>
> iremos comentando<br>
> vía lista. Avanti,<br>
><br>
> JoseMaria<br>
> On Wed, 2014-03-26 at 12:47 +0100, Roberto Calvo<br>
> wrote:<br>
> > Hola,<br>
> ><br>
> > Fran te dará los detalles, pero si, él ya se peleó e<br>
> hizo funcionar una<br>
> > versión con IceStorm y está funcionando, así que eso<br>
> que<br>
> > re-aprovechamos :-)<br>
> ><br>
> > > Esto nos proporcionará las siguientes ventajas:<br>
> > > 1.- Una reducción drástica de la elevada latencia<br>
> que añade el patrón<br>
> > > actual.<br>
> > > 2.- Reducir el tráfico y la carga de sistemas<br>
> empotrados en el robot.<br>
> ><br>
> > Sobre esto, aunque inicialmente pensabamos lo mismo<br>
> la práctica dice lo<br>
> > contrario. No hay casi diferencia (en cuanto a CPU y<br>
> recursos) entre<br>
> > mandar 20 imágenes por segundo usando RPC con<br>
> cameraClient, que usando<br>
> > publicación/suscripción para hacer el push de esas<br>
> mismas 20 imágenes .<br>
> > Si ganas en saber seguro que cada push es una nueva<br>
> imagen, o si<br>
> > cameraserver diera imágenes a un flujo que oscilara:<br>
> 5, 10, 15fps ...<br>
> > pero eso no pasa con cameraServer/openniServer a día<br>
> de hoy.<br>
> ><br>
> > En general publicación/suscripción desahoga mucho al<br>
> sistema cuando no<br>
> > sabes el ritmo de obtención de datos, o si se mandan<br>
> 1 vez cada mucho<br>
> > tiempo (evitas hacer polling).<br>
> ><br>
> > Si cameraServer obtiene 20fps y cameraView pide<br>
> mediante RPC a 20fps, no<br>
> > hay diferencia en usar publicación/suscripción (en<br>
> cuanto a CPU y<br>
> > recursos). De hecho pub/sus te obliga a leventar un<br>
> 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<br>
> --Ice.Config=cameraview_icestorm.cfg<br>
> ><br>
> ><br>
><br>
> --<br>
><br>
> <a href="http://gsyc.urjc.es/jmplaza" target="_blank">http://gsyc.urjc.es/jmplaza</a><br>
> Universidad Rey Juan Carlos<br>
><br>
> _______________________________________________<br>
> Jde-developers mailing list<br>
> <a href="mailto:Jde-developers@gsyc.es">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>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> ------------------------------------------------------------------<br>
> Linkedin: <a href="http://linkedin.com/in/fmrivas" target="_blank">linkedin.com/in/fmrivas</a><br>
><br>
><br>
> Laboratorio de Análisis del Movimiento, Biomecánica, Ergonomía y<br>
> Control Motor (LAMBECOM).<br>
> Departamento de Fisioterapia, Terapia Ocupacional, Rehabilitación y<br>
> Medicina Física.<br>
> Universidad Rey Juan Carlos (URJC).<br>
> _______________________________________________<br>
> Jde-developers mailing list<br>
> <a href="mailto:Jde-developers@gsyc.es">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>
<br>
--<br>
<a href="http://gsyc.urjc.es/jmplaza" target="_blank">http://gsyc.urjc.es/jmplaza</a><br>
Universidad Rey Juan Carlos<br>
<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>