[Jderobot] Camera server y viewer usando icestorm
Francisco Rivas
franciscomiguel.rivas en urjc.es
Jue Mar 27 18:36:06 CET 2014
Buenas,
acabo de subir el script de icebox al repo,. solo hay que modificar el
script para que te cree los interfaces iniciales que va a necesitar, de
momento está con cameraA. Todo lo ejecuta en segundo plano, una vez lanzado
sólo hay que lanzar el servidor y el cliente que tiren de él.
Para el cameraserver hay que modificar el .cfg
CameraSrv.DefaultMode=0
El 1 es para que funcione con rpc y lanzar el cameraview_icestorm.
Con eso debería ser suficiente, en cuanto tenga un hueco lo documento
mejor, pero ando un poco liado y veo que se iba a retrasar todo un poco
un saludo,
Fran.
El 27 de marzo de 2014, 9:17, Francisco Rivas <franciscomiguel.rivas en urjc.es
> escribió:
> Buenas.
>
> perfecto pues esta tarde lo subo todo y lo documento que ayer al final
> estuve con lío y no me dio tiempo.
>
> un saludo,
> Fran.
>
>
> El 27 de marzo de 2014, 8:32, JoseMaria <josemaria.plaza en gmail.com>escribió:
>
> Estupendo Fran.
>>
>> Sí, subiría ese script al repositorio oficial.
>>
>> El sitio no lo veo claro, casi me vale cualquiera. No es un componente,
>> pero lo dejaría en components, en un subdirectorio que se llamase
>> ice-utils o algo así. Por ejemplo visualHFSM tampoco es un componente,
>> sino una herramienta y lo hemos colocado ahí para distinguirlo de las
>> bibliotecas y los interfaces... Si se te ocurre otro mejor, avanti.
>>
>> Saludos,
>>
>> JoseMaria
>> On Wed, 2014-03-26 at 13:57 +0100, Francisco Rivas wrote:
>> > 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).
>> > _______________________________________________
>> > Jde-developers mailing list
>> > Jde-developers en gsyc.es
>> > http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>
>> --
>> http://gsyc.urjc.es/jmplaza
>> Universidad Rey Juan Carlos
>>
>>
>
>
> --
> ------------------------------------------------------------------
> 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).
>
--
------------------------------------------------------------------
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/20140327/059cf256/attachment.htm
More information about the Jde-developers
mailing list