[Jde-dev] redimiento temporal en 5.0
Sara Marugan
s.marugan en alumnos.urjc.es
Lun Feb 22 19:07:15 CET 2010
Claro, la idea es pasar finalmente a cuatro hebras que irían cada una a
unos 14 ips y esta sería la entrada a mi algoritmo.
Las 50 ips son porque no impido que no itere si no hay nuevas imágenes,
repitiendo trabajo como tu dices. Probaré con cuatro hebras y os cuento.
David Lobato wrote:
> 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
> <mailto: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>
> <mailto: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>>
> <mailto: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>>
> <mailto: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>>
> <mailto: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>>
> <mailto: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>>
> <mailto: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>
> <http://www.juanantonio.info>
>
> www.roboticaenlaescuela.es <http://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>
> <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>>
> <mailto: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>>
> <mailto: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
>
>
>
>
>
>
>
>
>
>
More information about the Jde-developers
mailing list