[Jde-dev] redimiento temporal en 5.0
David Lobato
dav.lobato en gmail.com
Lun Feb 22 18:54:53 CET 2010
Si sólo usas una hebra para pedir todas las imágenes, creo que estamos en el
mismo escenario, no?
La velocidad de actualización de las imágenes es la misma. Como dijiste en
el mensaje anterior, 70ms por cámara, por lo que 70ms * 4 = 280ms -> 4ips
Lo de los 50ips no me huele bien, suponiendo que pudíesemos actualizar las
imágenes al ritmo máximo que son capaces de dar (30) , significaría que el
~40% del tiempo estas repitiendo trabajo, no?
2010/2/22 Sara Marugan <s.marugan en alumnos.urjc.es>
> Ya he hecho una prueba con un thread para obtener las imágenes de todas las
> cámaras. Utilizo el mismo comunicador, inicializándolo en el proceso
> principal pero usándolo desde la hebra. Este thread copia los datos de las
> imágenes (protegiendo con un semaforo) en la zona de memoria que el proceso
> principal indique.
>
> La verdad es que funciona bastante bien. Ahora el componente itera a unos
> 50 ips si sólo recibe imágenes y las muestra en el GUI.
>
> De todos modos echaré un vistazo a la suscripción de ICE, que sería la
> solución buena.
>
>
> David Lobato wrote:
>
>> 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 <mailto:
>> 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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <http://www.juanantonio.info>
>>
>> www.roboticaenlaescuela.es <http://www.roboticaenlaescuela.es>
>> <http://www.roboticaenlaescuela.es>
>> www.robotica-urjc.es
>> <http://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>
>> <mailto: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>
>> <mailto: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/c68fd417/attachment-0001.htm
More information about the Jde-developers
mailing list