[Jde-dev] redimiento temporal en 5.0

David Lobato dav.lobato en gmail.com
Lun Feb 22 13:50:47 CET 2010


Hola,

Pues sue�a complicado el asunto.

A priori parece obvio que si ponemos una hebra por cada c�mara y se piden
las im�genes en paralelo podr�amos bajar los tiempos. Aunque habr� que ver
como gestiona esto ICE. Aun estamos en el mismo proceso, y usando el mismo
comunicador para todo. Adem�s habr� que a�adir mecanismos de control de
concurrencia, ahora las imagenes no son punteros y probablemente si no lo
hacemos habr� condiciones de carrera casi seguro.

Quiz� sea momento de usar los mecanismos de suscripci�n que tiene ICE, de
modo que no pidamos im�genes, si no que nos suscribamos a la c�mara y estas
lleguen cuando est�n listas. Aun no he probado este mecanismo, aunque en
Orca tienen varios ejemplos e implementaciones.




2010/2/22 Sara Marugan <s.marugan en alumnos.urjc.es>

> Buenas,
>
> escribo para comentaros las novedades que he visto en cuanto al tema del
> rendimiento temporal. Me he dado cuenta de que no hab�a diferencia entre el
> componente dise�ado con MVC y el componente que no lo estaba, hab�a un bug
> que me hac�a creer que iba m�s r�pido el segundo.
>
> Por lo que he visto haciendo pruebas, el cuello de botella no est� en
> pintar el GUI, sino en recoger las im�genes de entrada. En obtener una
> imagen del proxy tarda 70ms, lo que multiplicado por 4 en mi caso provoca
> que mi componente itere a unos 4 fps sin a�adir los algoritmos.
>
> Como primera soluci�n se me ocurre que el componente genere una hebra por
> cada c�mara y que se encarguen de obtener las im�genes y dejarlas en memoria
> para que est�n r�pidamente accesibles desde el proceso principal.
> Qu� otras soluciones veis?
>
> Un saludo,
>
> Sara
>
>
>
>
>
> David Lobato wrote:
>
>> Buenos d�as (states time),
>>
>> Entiendo que lo que has hecho es quitar la herencia de Observer en la
>> clase View, de modo que ya no recibe las notificaciones del modelo, y llamas
>> al update de la clase desde el programa principal al ritmo que necesitas,
>> �no? Es una soluci�n, aunque se le quita toda la gracia el asunto...
>> �Sigues teniendo una sola hebra para todo?
>>
>> Otra soluci�n que mantiene las ventajas de este patr�n de dise�o podr�a
>> ser indicar a la clase view el ritmo de actualizaci�n, y que al ejecutar el
>> update tras un notify, este s�lo ejecute el c�digo de repintado seg�n el
>> ritmo indicado.
>>
>> Si pasamos a 2 hebras (modelo,controlador | vista), adem�s de lo anterior,
>> podemos hacer que el notify avise a la hebra de la vista para hacer su
>> trabajo. En este caso habr�a que controlar el acceso concurrente al modelo
>> (monitor?).
>>
>> Independientemente de esto, tenemos que pensar que estas gui's son un mero
>> interfaz de depuraci�n. Una vez nuestro componente est� depurado, la manera
>> de comunicarse con el ser� a trav�s de su interfaz ICE que ya soluciona
>> todos estos detalles.
>>
>> David.
>>
>>
>> 2010/2/19 Sara Marugan <s.marugan en alumnos.urjc.es <mailto:
>> s.marugan en alumnos.urjc.es>>
>>
>>
>>    Buenas,
>>
>>    he llegado a una soluci�n intermedia para la implementaci�n de mi
>>    componente eldercare. He mantenido el modelo y su controlador pero
>>    he reemplazado la clase Observer por una clase viewer para el
>>    manejo del GUI, as� se elimina la dependencia de notifyObservers().
>>
>>    La clase viewer se comunica con el modelo a trav�s del
>>    controlador, pero ahora es el programa principal y no el
>>    controlador el que se encarga de indicar a la clase viewer cuando
>>    repintar el GUI.
>>
>>    De esta forma mi componente itera a unas 24 ips, tanto si s�lo
>>    visualizo como si adem�s filtro las im�genes por movimiento.
>>
>>
>>
>>
>>    JoseMaria wrote:
>>
>>        Otra cosilla m�s:
>>
>>        esta separaci�n entre c�digo de visualizaci�n y c�digo de
>>        funcionamiento
>>        es buena para la mayor�a de las aplicaciones que controlan algo o
>>        perciben algo, t�picamente basadas en iteraciones peri�dicas.
>>        Separarlos
>>        en hebras distintas es buena idea.
>>
>>        Tambi�n hay componentes que pueden organizarse "orientados a
>>        eventos",
>>        t�pico de las aplicaciones gr�ficas (con GTK, QT, xforms...). Por
>>        ejemplo opencvdemo (un componente de demostraci�n de opencv, sus
>>        filtros, transformadas y operaciones sobre im�genes) s�lo hace el
>>        procesamiento para ense��rselo al humano. Puede organizarse
>>        como un
>>        conjunto de respuestas a diferentes eventos: que llegue una nueva
>>        imagen, que el usuario pique en un bot�n para activar tal o
>>        cual filtro,
>>        etc.
>>
>>        Saludos,
>>
>>        JoseMaria
>>        On Thu, 2010-02-18 at 16:00 -0500, David Lobato wrote:
>>
>>            Lo primero aclarar que las clases Observer y Subject las
>>            he escrito yo
>>            y no tienen nada que ver con Ice. Por lo que son totalmente
>>            reimplementables/reemplazables. Son muy simples y no hay
>>            nada de
>>            hebras relacionado con ellas.
>>
>>
>>            As� que como deduces, hay una sola hebra haciendo todo el
>>            trabajo. Lo
>>            ideal ser�a que la gui tuviese la suya y pintase
>>            desacoplada del
>>            resto. Pero por pereza/desconocimiento de gtk lo dej� as�
>>            en mi
>>            aplicaci�n, que teniendo una gui muy sencilla no requer�a mas.
>>
>>
>>            Como dice Jos� Mar�a hay que encontrar la manera de
>>            separar ambas
>>            partes. As� que necesitamos que las notificaciones que
>>            emite el Modelo
>>            sean asincronas, cosa que ahora no ocurre, o directamente
>>            pasar a
>>            repintar a intervalos fijos como se ven�a haciendo. La
>>            idea de las
>>            notificaciones es mas elegante pero algo mas compleja de
>>            implementar
>>            (aunque nos podemos apoyar en cosas ya hechas como
>>            SigC++/SigCX;
>>            se�ales al estilo gtk).
>>
>>
>>
>>            2010/2/18 Sara Marugan <s.marugan en alumnos.urjc.es
>>            <mailto:s.marugan en alumnos.urjc.es>>
>>
>>                   Bueno,  investigando un poco m�s con grep, he visto que
>>                   notifyObservers() acaba llamando  a update() de  la
>>            clase View
>>                   del modelo MVC, que realiza lo equivalente a
>>            Viewer::display()
>>                   de la otra opci�n de implementaci�n.
>>                           Ahora tengo la duda de si un objeto
>>            Observer implica crear una
>>                   hebra de ejecuci�n diferente s�lo para la
>>            visualizaci�n. Si
>>                   no, tanto la l�gica de la aplicaci�n como las
>>            instrucciones de
>>                   visualizaci�n se ejecutan en el mismo proceso,
>>            obligando a ir
>>                   al ritmo de la actualizaci�n del GUI.
>>                           He medido las iteraciones por segundo en el
>>            m�todo setimages()
>>                   del modelo y efectivamente son 5 ips, las mismas
>>            que da la
>>                   clase View en su m�todo update(). Por tanto, todo
>>            indica que
>>                   s�lo hay un proceso para todo.
>>                                                   JoseMaria wrote:
>>                           Hola,
>>                                           La separaci�n entre
>>            visualizaci�n y funcionamiento es
>>                           algo deseable para
>>                           el software de robots. Muchas veces se quiere
>>                           visualizar para depurar y
>>                           no es necesario que el robot muestre nada
>>            cuando hace
>>                           tal o cual tarea,
>>                           simplemente que la haga.
>>                                           Por eso en la 4.3 estaban
>>            separados en ejecuci�n el
>>                           c�digo de
>>                           funcionamiento (run,stop,iteration) del de
>>                           visualizaci�n (show,hide).
>>                           Estaban escritos t�picamente en el mismo
>>            fichero, pero
>>                           los ejecutan
>>                           hebras diferentes: El c�digo de
>>            funcionamiento lo
>>                           ejecuta la hebra del
>>                           esquema (a su ritmo genuino) y el c�digo de
>>                           visualizaci�n la hebra de
>>                           graphics_gtk o graphics_xforms (que tambi�n
>>            lleva su
>>                           propio ritmo, unos
>>                           12ips).
>>                                           En 5.0 ahora tenemos m�s
>>            libertad para desacoplar a�n
>>                           m�s el c�digo de
>>                           una cosa y el de la otra. El patr�n
>>                           Model-View-Controller es una buena
>>                           opci�n para ello, pero hay que tener cuidado
>>                           programando para evitar las
>>                           dependencias excesivas de unos con otros.
>>            Por ejemplo
>>                           la visualizaci�n
>>                           deber�a mostrar las iteraciones por segundo
>>            a las que
>>                           funciona el c�digo
>>                           de funcionamiento, no las de visualizaci�n
>>            (que puede
>>                           estar bien, pero
>>                           no es tan relevante). Tambi�n es tolerable
>>            cierto
>>                           desfase (peque�o)
>>                           entre lo que se visualiza y los datos
>>            actuales de
>>                           funcionamiento.
>>                                           �nimo,
>>                                           JoseMaria
>>
>>   Independientemente, lo que andaba buscando es
>>                                   una manera de desacoplar
>>                                   al m�ximo el c�digo de la
>>            visualizaci�n.
>>                                   Actualmente, en los esquemas
>>                                   de la 4.3, todo se entremezcla,
>>            resultando
>>                                   complicado distinguir entre
>>                                   c�digo de la aplicaci�n y c�digo de la
>>                                   visualizaci�n. As� que se me
>>                                   ocurri� que podr�a aplicar alg�n
>>            patr�n de los
>>                                   que se usan en
>>                                   aplicaciones con visualizaci�n. MVC
>>            y sus
>>                                   variantes son patrones de
>>                                   este tipo.
>>
>>                             En este patr�n se separan los datos
>>            (modelo)
>>                                   de la interfaz gr�fica
>>                                   (vista), utilizando un intermediario
>>                                   (controlador). El controlador se
>>                                   encarga de actualizar el modelo con los
>>                                   cambios que provengan de la
>>                                   vista (pulsar un boton, caja de
>>            texto,...) o
>>                                   del exterior (en nuestro
>>                                   cosa de la red). A su vez, el
>>            modelo env�a una
>>                                   notificaci�n de que sus
>>                                   datos han cambiado, que es recibida
>>            por todas
>>                                   las vistas suscritas al
>>                                   modelo (usamos patr�n Observer para
>>            esto) y
>>                                   que se encargan de releer
>>                                   el modelo y actualizarse (repintar
>>            el gui).
>>
>>                   En principio suena bien. Pero pensando en el
>>                                   caso concreto que Sara
>>                                   est� implementando, creo que sucede lo
>>                                   siguiente:
>>
>>                   Supongo que el modelo de Sara no es mas que un
>>                                   almacen de 4 imagenes
>>                                   (cada una de las recibidas de cada
>>            c�mar�) que
>>                                   el el controlador
>>                                   actualiza de 1 en 1 usando un
>>            m�todo tipo
>>                                   setImage1, setImage2,...
>>                                   Dichos m�todos, a su vez, env�an una
>>                                   notificaci�n de cambio a las
>>                                   vistas. Las vistas, que no son
>>            capaces de ver
>>                                   que ha cambiado
>>                                   concretamente repintan todo. Es
>>            decir, que
>>                                   estamos actualizando la gui
>>                                   por cada imagen recibida y de ah�
>>            que el
>>                                   rendimiento haya caido tan
>>                                   notablemente.
>>
>>                   Se me ocurre que podemos a�adir mas
>>                                   informaci�n a la notificaci�n que
>>                                   genera el modelo, para indicar que
>>            es lo que
>>                                   ha cambiado, de modo que
>>                                   la vista s�lo pinte aquello que ha
>>            cambiado.
>>
>>                   �Mas ideas? �Otros patrones que podamos
>>                                   aplicar a nuestros componentes
>>                                   con gui?
>>
>>                   David.
>>
>>
>>
>>                               2010/2/18 Juan
>>            Antonio Bre�a Moral
>>                                   <bren en juanantonio.info
>>            <mailto:bren en juanantonio.info>>
>>
>>                                          Hola Sara,
>>                                          No me he puesto a trabajar
>>            con el MVC
>>                                   de JDRobot 5.0 pero
>>                                          tiene pinta de que en muchas
>>                                   iteraciones de los componentes,
>>                                          los datos pasan por el
>>            controller y
>>                                   otras areas en teoria, te
>>                                          lo digo con desconocimiento
>>            de como lo
>>                                   haces.
>>                                                  Yo hasta donde llego
>>            MVC es un
>>                                   patron de dise�o que se emplea
>>                                          en aplicaciones de gestion,
>>            vease
>>                                   Structs2 [1] no tenia
>>                                          constancia que en Robotica
>>            tambien era
>>                                   valido separar la capa
>>                                          de datos del control. Quizas
>>            debido a
>>                                   eso si la vista es el
>>                                          GUI y el Model es el Sensor,
>>            cada
>>                                   iteracion del Sensor pasa
>>                                          siempre por el controller y
>>            este hace
>>                                   una serie de tareas y
>>                                          quizas por eso repercuta en el
>>                                   rendimiento.
>>                                                  �La forma
>>            tradicional no es
>>                                   valida?
>>                                          �Si un componente gestiona
>>            un sensor o
>>                                   grupo y se comunica con
>>                                          ICE con otra area?
>>                                                  Un abrazo
>>                                                  [1]
>>            http://struts.apache.org/
>>                                                  Sara Marugan escribi�:
>>                                          > Claro, al utilizar el MVC
>>            tiene que
>>                                   introducir algo de latencia, pero
>>             >
>>                                   tanta me parece excesiva.
>>                                          >        >        > Juan
>>            Antonio Bre�a
>>                                   Moral wrote:
>>                                          >          > > Puede que sea
>>            la propia
>>                                   arquitectura MVC.
>>                                          > > �Es posible?
>>                                          > >        > > Sara Marugan
>>            escribi�:
>>                                          > >            > > > Hola,
>>                                          > > >        > > > quer�a
>>            comentaros
>>                                   una cosa y es que he hecho dos
>>            componentes
>>                                        > > > diferentes que reciben
>>            im�genes de
>>                                   4 c�maras a la vez y las muestran.
>>                   > >
>>                                   > El primero est� basado en
>>            varcolorviewgtkmm,
>>                                   que no utiliza el modelo        > >
>>            > MCV, y
>>                                   el segundo en motiondetection, que
>>            s� lo
>>                                   utiliza.
>>                                          > > >        > > > Mi
>>            sorpresa es que
>>                                   mientras que el primero ejecuta a
>>            30 ips, el
>>                                          > > > segundo a 5 ips. �A
>>            qu� puede
>>                                   deberse esto? en el segundo intervienen
>>                                    > > > m�s clases pero me extra�a que
>>                                   introduzcan tanta latencia. �Es
>>           > > >
>>                                   ajustable el ritmo de ejecuci�n?
>>                                          > > >        > > > gracias
>>            de antemano,
>>                                          > > >        > > > Sara
>>                                          > > >
>>
>> _______________________________________________
>>                                          > > > Jde-developers mailing
>>            list
>>                                          > > > Jde-developers en gsyc.es
>>            <mailto:Jde-developers en gsyc.es>
>>
>>                                          > > >
>>
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>                                          > > >        > > >
>>       > > >
>>                                            >
>>
>> _______________________________________________
>>                                          > Jde-developers mailing list
>>                                          > Jde-developers en gsyc.es
>>            <mailto:Jde-developers en gsyc.es>
>>
>>                                          >
>>
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>                                          >        >
>>                                        --                Juan Antonio
>>            Bre�a
>>                                   Moral
>>                                          www.juanantonio.info
>>            <http://www.juanantonio.info>
>>                                          www.roboticaenlaescuela.es
>>            <http://www.roboticaenlaescuela.es>
>>                                          www.robotica-urjc.es
>>            <http://www.robotica-urjc.es>
>>
>>                                                  Este mensaje
>>            (incluyendo los
>>                                   archivos adjuntos) es confidencial y
>>                                   reservado. Si Vd. lo ha recibido
>>            por error,
>>                                   por favor notif�quelo al emisor del
>>            mismo v�a
>>                                   e-mail y borre el mensaje de su
>>            sistema.
>>                                   Cualquier uso no autorizado o
>>            divulgaci�n de
>>                                   su contenido, ya sea en todo o en
>>            parte, est�
>>                                   totalmente prohibido. Tenga en
>>            cuenta que los
>>                                   e-mails son susceptibles de ser
>>            modificados.El
>>                                   remitente no se har� responsable de la
>>                                   incorrecta o incompleta transmisi�n
>>            de la
>>                                   informaci�n contenida en esta
>>            comunicaci�n, ni
>>                                   por ning�n retraso en la recepci�n
>>            o da�o a
>>                                   sus sistemas. el remitente no
>>            garantiza que
>>                                   esta comunicaci�n se ha realizado en su
>>                                   integridad ni que la misma no
>>            contiene virus,
>>                                   intercepciones o interferencias.
>>            Este e-mail
>>                                   ha sido escaneado mediante la
>>            utilizaci�n de
>>                                   Antivirus.
>>                                                  El tratamiento de
>>            los datos de
>>                                   car�cter personal, as� como el env�o de
>>                                   boletines o comunicaciones
>>            realizadas por
>>                                   medios electr�nicos, son conforme a
>>            la Ley
>>                                   Org�nica 15/1999, de 13 de
>>            diciembre, de
>>                                   Protecci�n de Datos de Car�cter
>>            Personal
>>                                   (B.O.E. de 14 de diciembre de 1999)
>>            y a la Ley
>>                                   34/2002, de 11 de julio, de
>>            Servicios de la
>>                                   Sociedad de Informaci�n y de Comercio
>>                                   Electr�nico (B.O.E. de 12 de julio
>>            de 2002).
>>                                   El tratamiento desautorizado de
>>            datos de
>>                                   caracter personal puede suponer una
>>            infracci�n
>>                                   de la Ley Org�nica 15/1999, de 13 de
>>                                   diciembre, de Protecci�n de Datos
>>            de car�cter
>>                                   personal. Si usted no es el
>>            destinatario que
>>                                   figura arriba, o la persona
>>            responsable de su
>>                                   entrega al mismo, deber� de
>>            abstenerse de
>>                                   examinar o utilizar su contenido,
>>            realizar
>>                                   copias o entregarlo a persona
>>            distinta. Para
>>                                   obtener informaci�n sobre la
>>            pol�tica de
>>                                   privacidad o para el ejercicio de
>>                                           derechos de acceso,
>>            rectificaci�n,
>>                                   cancelaci�n y oposici�n, puede
>>            dirigirse a
>>                                   este correo electr�nico, indicando
>>            en el
>>                                   asunto "Protecci�n de Datos".
>>                                                  This message
>>            (including any
>>                                   attachments) is confidential and may be
>>                                   privileged. If you have received it by
>>                                   mistake, please notify the sender
>>            by return
>>                                   e-mail and delete this message from
>>            your
>>                                   system. Any unauthorized use or
>>            dissemination
>>                                   of this message in whole or in part is
>>                                   strictly prohibited. Please note
>>            that e-mails
>>                                   are susceptible to change. The
>>            sender shall
>>                                   not be liable for the improper or
>>            incomplete
>>                                   transmission of the information
>>            contained in
>>                                   this communication, nor for any
>>            delay in its
>>                                   receipt or damage to your system.
>>            The sender
>>                                   does not guarantee that the
>>            integrity of this
>>                                   communication has been maintained
>>            or that this
>>                                   communication is free from viruses,
>>                                   interceptions, or interference.
>>            This email has
>>                                   been scanned using Antivirus
>>
>>  _______________________________________________
>>                                          Jde-developers mailing list
>>                                          Jde-developers en gsyc.es
>>            <mailto:Jde-developers en gsyc.es>
>>
>>
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>
>>
>> _______________________________________________
>>                                   Jde-developers mailing list
>>                                   Jde-developers en gsyc.es
>>            <mailto:Jde-developers en gsyc.es>
>>
>>
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
------------ pr�xima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20100222/2e8b06fd/attachment-0001.htm 


More information about the Jde-developers mailing list