jueves, 17 de noviembre de 2016

Network Virtual Enviroment with Flocks

Network Virtual Enviroment with Flocks


Introducción

Hace unos años me intereso el algoritmo que podría simular los movimientos de los pájaros, de grupos de pajaros. Esto es lo que se conoce como flocking algorithm

Estos algoritmos, pueden simular no solamente movimientos de pájaros, si no lo que sería de un grupo de objetos, individuos,...en este caso, yo elegí tanques, pero la implementación es general, no es siguiendo exactamente lo que haría un grupo de tanques.





Pero ahora, que hace pocos meses me he metido, por mi nuevo trabajo, en temas de simulación, donde un ordenador realiza una tarea, y se la comunica a otra por red,...y así, crear un simulador, y de hay lo que sería un Network Virtual Enviroment. Y entonces, quería aprender un poco más sobre esto, y que mejor que crear tu propio NVE.

NVE de Tanques

Y que mejor que para comprender mejor este mundo, que leer un buen libro. Y me leí el libro

"Networked Graphics Building Networked Games and Virtual Environments" de Anthony Steed, Manuel Fradinho Oliveira

Y vaya casualidad, que esos, usaron el movimiento de flocking para simular un NVE. Es decir, tener un flock (o grupo de objetos que deben moverse) en un ordenador y que los demás vean a ese grupo. Y asi crear un NVE.

Y entonces, me dije, de modificar el que ya había desarrollado. Abajo un pantallazo. Siento haberlo realizo con solo dos Flocks clientes, pero no me daba la memoria para tener dos maquinas virtuales corriendo :-( . Tengo que poner megas pero ya...



Arquitectura del NVE de Tanques

En el libro, se detallan varios tipos de arquitecturas, pero la que más me gusto implementar fue
la de peer to peer con servidor de entrada. Esta arquitectura, hay dos aplicaciciones, una el cliente que simula el flock y el servidor (otra aplicacion). El cliente solo debe saber la IP de donde está el servidor, y el servidor, le enviará las IPs de los demás clientes, y asi de esa forma, la configuración es un tanto más cómoda.






Aquí, los Flocks Client, al iniciar la ejecución se comunicaran con el servidor (en naranja) para que le envíe la lista de las ips de los otros ordenadores donde se simula y así entrar en el NVE. Una vez que tiene la lista, ya no se comunica más con el servidor y ya lo hace peer to peer con los demás ordenadores que están simulando los flocks.

Los pasos que se siguen a nivel general, son los siguientes en el Flock cliente cuando se esta simulando.

paso 1
- Actualizar el Flock Local (pero teniendo en cuenta los flocks remotos)
- Enviar la información de Flock Local a los demás flocks remotos.

Por otro lado, ¿como el cliente flock obtiene los flocks remotos?

Paso 2

Se define una clase RemoteSimulations, que representa a los flocks remotos, y internamente, está a la escucha de recibir información de los flocks remotos (por un puerto UDP ya predefinido entre los client flock), y cada vez que recibe uno, lo añade a la lista, que esta lista, la pedirá el paso 1, cuando el algoritmo de Flocking tenga que tomar en cuenta todos los flocks (local y remotos) para realizar el calculo del movimiento.

Y aquí dejo un video del NVE de tanques....


Futuro

En el libro anteriormente citado, se comenta los problemas que hay en los NVE, que surgen por la latencia de la red. Como que de repente un objeto se mueve más rápido, o parece que se para, o que vaya a tirones. Sería interesante simular estos problemas para así, poder desarrollar medidas que palíen en cierto grado estos problemas.


Félix Romo
felix.romo.sanchezseco@gmail.com





martes, 13 de octubre de 2015

Patrón de Diseño - Decorator


Introducción


Los patrones de diseño es algo que leí hace tiempo, he usado algunos en los proyectos en los que trabaje y en los que trabajo, pero una forma de asimilarlos, creo yo, es practicar con ellos con ejemplos y por eso este post. Con este post,intentaré implementar un patrón de diseño pero de forma que fuese como parte de algo real. Digo esto por que hay algunos libros en los que ponen los ejemplos con nombres de clases como "classA" "parrentClassA". Aunque puede ser explicativo, a mí se me queda mejor con nombres más concretos.

Y como hay mucha, mucha información, donde explican este tipo de patrón, dejo más que nada, la fuente original.

"Design Patterns: Elements of Reusable Object-Oriented Software"




Hace tiempo estuve trabajando en una empresa en la que por pantalla visualizaba viajes de buses, y pasando el cursor, mostraba informacón sobre el bus.

He tomado este caso para hacer un ejemplo del patrón Decorator.

Patrón Decorator


En este ejemplo, tenemos unos autobuses (Bus.cs) los cuales los conduce un conductor asociado al Bus(DriverInfo.cs). Y unos de los requisitos es que cuando pasa el cursor por el bus dibujado en pantalla, que se muestre la informacón asociada al conductor. En este caso, para complicar un poco más la cosa, se muestra dos informaciones del conductor:
- Información del nombre del conductor (Texto) (DecoratorInfoDriver.cs)
- Gráfica de las horas conducidas (Gráfico) (DecoratorGraphicsDriver.cs)

Aquí, abajo se muestra el diagrama de clases.


Comentarios


En el patrón de diseño decorator, se ve que los objetos que decoran el objeto, tiene el mismo interfaz o métodos que
el objeto que decora, para que de esta forma, los objetos clientes, no 'noten' la diferencia y traten a ambos como iguales.

Pero luego, como los objetos se les añade funcionalidad a través de añadir decorator, pero ¿y a la hora de quitarla?. A la hora de quitarla, sería, supongo, quitar los objetos decoradores, pero en este ejemplo, se quitan todos los decorados a la vez. La forma en que se quita un objeto un decorator es de la forma.

//borrar de la lista de _buses todos los objetos decorators (los que muestran la información del conductor)
private void removeInfoDriverInfo()
{
    for (int i = 0; i < _buses.Count; i++)
    {
        DecoratorInfo decoInfo = _buses[i] as DecoratorInfo;

        //Si hay en la lista algún objeto decorado..
        if (decoInfo != null)
        {
            //obtener el objeto que esta siendo decorado
            Bus bus = decoInfo.GetVehicule() as Bus;
            _buses.Remove(decoInfo); //borrar el objeto decorado de la lista de visualizaicon
            _buses.Add(bus); //añadir a la lista de visualiacion el objeto que era decorado
        }
    }
}

El método removeInfoDriverInfo, en runtime, va añadiendo y borrando objetos a la lista de visualización y de está forma, se añade o se borran las funcionalidades de cada objeto.

Luego el método "GetVehicule", retorna le objeto que esta siendo decorado. No estoy seguro, si me estoy ciñendo a la teoría, pero al acceder al objeto que esta siendo decorado, era necesario, para incluirlo dentro de la lista de visualización (List<ControlsUI.VehicleUI> _buses), y una forma de obtener el objeto decorado através de sus decoradores era con el método GetVehicule() (también se podría haber llamado GetDecoratedObject(), pero como estamos dentro del dominio del problema de los buses...)

public VehicleUI GetVehicule()
{
    if (_vehicle is DecoratorInfo)
    {
        DecoratorInfo decoratorInfo = (DecoratorInfo)_vehicle;
        return decoratorInfo.GetVehicule();
    }
    else
    {
        return _vehicle;
    }
}


Conclusión

La conclusión, una que por lo menos saco, es que si no lo hubise implentado, no me hubiese encontrado con el problema de como recuperar el objeto decorado, para quitar de esta forma, la funcionalidad añadida que le dan los objetos decoradores.

Habrá muchas formas, pero la que he escogido para simplificar, es que en a lista  List<ControlsUI.VehicleUI> _buses, estén todos los objetos, tanto Bus como  ecoratorGraphicsDriver y/o DecoratorInfoDriver, si se van borrando y añadiendo objetos a esta lista, a la par que quiera el usurio que un Bus tenga una funcionalidad añadida (ver info del conductor) o no.

Y creo que lo mismo ha sido un ejemplo, muy sencillo, pero ha sido una forma de verlo un poco más, y de no solo leerlo.

El código fuente se puede descargar aquí.

Félix Romo
felix.romo.sanchezseco@gmail.com



miércoles, 9 de septiembre de 2015

Contar Olivos con Ortofoto: Parte II (Clustering con K-Means)


Introducción


El siguiente post, por su propio titulo lo indica, es la segunda parte del post 'Contar Olivos con Ortofoto: Parte I'.

En esta segunda parte, se trata de ver que métodos o de que forma se puede discriminar, que son olivos y que no son, para de esta forma tener el número de olivos de una ortofoto con el menor margen de error (+- 4 olivos creo que es un margen razonable¿?):

Nota: para quién quiera ver los olivos que tiene cada recinto, una herramienta que puede utilizar es el SIGPAC (Sistema de Información Geográfica de Identificación de Parcelas Agrícolas).



Redes Neuronales

Utilice redes neuronales con una capa oculta, pero no era capaz de aprender con un margen de error mínimo.

Como un olivo puede estar representado por diferentes tamaños en pixeles. Por ejemplo, 20x20, 15x15, 4x4,..etc..lo que se hacía, era pasar todas las imagenes a un tamaño fijo, 7x7. Con este tamaño, las muestras de olivos, y las muestras de no olivos, para que aprendiese la red neuronal, daba un error grande, y no aprendía bien. Era por que la diferencia entre las imagenes de los olivos y los que no eran olivos, era muy pequeña.

Es posible, con ortofotos de alta calidad, donde un olivo puede ser representado por tamaños de 50x50, se pueda usar una red neuronal.¿?. Ya que la diferencia ahora, entre una imagen de lo que es un olivo y lo que no, se diferencian más.

Entonces, ¿qué usar?


Clustering k-means

Para una mejor explicación, ver Clustering k-means.  Y a mi modo de ver, este algoritmo lo que hace es que dado un número determinado a priori de clusters, el algoritmo, va mirando si los valores de un elemento, un objeto, está más cerca de un cluster o de otro. Y encuentra un cluster que este más cerca, asigna ese objeto a ese cluster. Creo que no está muy bien explicado. En el caso concreto que nos atañe.

Se han identificado por ejemplo 100 posibles olivos de diferentes tamaños (5x5, 20x20,..etc). Ahora, el algoritmo, inicializa aleatoriamente, los clusters a los que pertenece cada objeto. Es decir, va diciendo..."objeto 1 tu perteneces aleatoriamente al cluster 0, tu el objeto 2, al cluster 3,...hasta 6 clusters".

Luego se calcula el centroide de cada cluster. El centroido sera el tamaño medio de los objetos que lo componen. 
Y luego ya por ultimo, entramos en el 'while'. Que será, mientras haya cambio de un objeto de un cluster a otro, se hace: se va por cada objeto, y se mide la distancia (distancia de Euler) de ese objeto a todos los cluster, si se encuentra que el cluster más cercano encontrado, es distinto al que pertenece el objeto, eureka!, el objeto no pertenece a ese cluster y se pasa al otro.

Al final del algoritmo, en este ejemplo, tenemos 6 clusters, y cada uno con objetos similares entre sí.

Aquí, se supone que como los olivos serán casi todos del mismo tamaño, estarán casi todos en un mismo cluster, y los objetos que no son olivos, en otro clusters distinto.

Veamos un pantallazo.



Ene el pantallazo se ven rectangulos semitransparentes. Esto son cluster que se han determinado que no entran a formar parte del computo de la suma de los olivos. Y como se van son rectangulos que no tienen nada que ver con un olivo.

Pero, aquí está el problema que veo, que hay objetos en un cluster, que son olivos y otros que no son. Por ejemplo, el Cluster 5, son olivos, pero luego hay etiquetas 5 en el tejado de una casa.

¿como solucionar esto?

Un solución rápida, sería que el usuario, definiera una región de la ortofoto, donde se le diga, donde debe contar, y los objetos que estén fuera de esta región (la marcada por el trazado rojo), no entrar en el conteo de los olivos. 

El trazado rojo, está dibujado con el Paint, y no ha sido implementado en el programa, pero no sería un ejercicio complicado el crear una región y aplicar clipping.

Conclusión

No ha sido muy elegante la solución, por el hecho de tener que dibujar una región, pero si por lo menos para una primera versión, si contaría los olivos correctamente. Ahorrando los costes de llevar personal para que los cuente (tiempo, viajes, dietas,....).

El programa en release está aquí.

Félix Romo
felix.romo.sanchezseco@gmail.com





martes, 1 de septiembre de 2015

Un producto software, varios clientes. O como customizar.

Introducción


Hace un tiempo, unos años, trabaje en una empresa donde tenían un producto para varios clientes, Y cada cliente, requería un nuevo requisito, o quitar alguno, esto generaba código del estilo:

#if __CLIENT_A__

// habilitar caracteristica del cliente A


#endif


Este tipo de código a lo largo, de miles de lineas de código, mezclado con las demás funcionalidades de los demás clientes, el código es más difícil de seguir que una demostración matemática (al menos para mí...)

  Hace un tiempo, me tope con este problema, pero no quería extender la complejidad de los #if a lo largo de todas las clases del programa. Debía de encapsular esta complejidad en una clase.

Pero antes, veamos un ejemplo práctico.

Ejemplo práctico


Imaginemos, que tenemos un software que tiene las siguientes funcionalidades:

- Exportar sus datos a un fichero Txt (__TXT__EXPORT__ )
- Exportar sus datos a un fichero Excel (__EXCEL_EXPORT__)
- Visualización 2d (__2D_VIEW__ )
- Visualización 3d (__3D_VIEW__ )
- Exportación del modelo 3d generado a un fichero (__EXPORT_3D_MODEL__ ). Esta funcionalidad solo se activo si está activa la visualicación 2d y 3d.

La función drawOptionsInstallOldWay dibuja en pantalla las opciones instaladas de la forma #if. Y la función drawOptionsInstallNewWay las dibuja de otra forma que ya veremos.

El aspecto de la aplicación sería con las siguientes opciones activadas:
__TXT__EXPORT__, __2D_VIEW__,__3D_VIEW__





La parte izquierda se dibuja con el método drawOptionsInstallOldWay y la parte derecha (azul) con el método drawOptionsInstallNewWay .

Ahora, veamos cual de los dos métodos es más difícil de leer y de mantener a la larga.

 private void drawOptionsInstallOldWay(Graphics g)
        {
            
            float y = 40.0f;
#if __TXT__EXPORT__ 
                g.DrawString("Txt Export", SystemFonts.DefaultFont, Brushes.Black, 10.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
#endif

#if __EXCEL_EXPORT__
                g.DrawString("Excel Export", SystemFonts.DefaultFont, Brushes.Black, 10.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
#endif

#if __2D_VIEW__
                g.DrawString("2d View", SystemFonts.DefaultFont, Brushes.Black, 10.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
#endif

#if __3D_VIEW__
                g.DrawString("3d View", SystemFonts.DefaultFont, Brushes.Black, 10.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
#endif

#if __3D_VIEW__ && __2D_VIEW__ // __EXPORT_3D_MODEL__
                g.DrawString("Export 3d Model", SystemFonts.DefaultFont, Brushes.Black, 10.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
#endif


        }


 private void drawOptionsInstallNewWay(Graphics g)
        {
            float y = 40.0f;

if(RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.EXPORT_TXT__REQUERIMENT))
            {
                g.DrawString("Txt Export", SystemFonts.DefaultFont, Brushes.Blue, 200.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
            }
if(RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.EXPORT_EXCEL__REQUERIMENT))
            {
                g.DrawString("Excel Export", SystemFonts.DefaultFont, Brushes.Blue, 200.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
            }

            if(RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.GRAPHICS_2D_REQUERIMENT))
            {
                g.DrawString("2d View", SystemFonts.DefaultFont, Brushes.Blue, 200.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
            }

            if (RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.GRAPHICS_3D_REQUERIMENT))
            {
                g.DrawString("3d View", SystemFonts.DefaultFont, Brushes.Blue, 200.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
            }

            if (RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.GENERATE_3D_MODEL))
            {
                g.DrawString("Export 3d Model", SystemFonts.DefaultFont, Brushes.Blue, 200.0f, y);
                y += SystemFonts.DefaultFont.Height + 2.0f;
            }
        }

Vemos que el método drawOptionsInstallNewWay no hace uso de #if, sino de llamadas a un objeto de tipo RequerimentsActivator, el cual, le responde si una funcionalidad o requisito está activo o no.
Con esto se consigue que la complejidad de los #if, está centralidad, encapsulada en la clase RequerimentActivator.

La clase RequerimentActivator


Esta clase sigue el patrón de diseño singleton. De esta forma, se podrá acceder desde cualquier parte del programa, pero, yo creo que las partes donde se debería de acceder, es desde el interfaz, pero no llamarla desde las clases del problema de la aplicación.
Es decir, hacer uso de esta clase, RequerimentActivator, solo desde el MainForm.cs o clases que deriven de la clase Form. Así, las clases del dominio del problema no estarán acopladas a esta clase.


Esta clase tiene un enumerado llamado OptionalRequeriments donde se enumeraran todas las opciones que se pueden activar y desactivar.

public enum OptionalRequeriments { EXPORT_EXCEL__REQUERIMENT = 0, EXPORT_TXT__REQUERIMENT = 1, GRAPHICS_2D_REQUERIMENT = 2,GRAPHICS_3D_REQUERIMENT = 3, GENERATE_3D_MODEL=4 };
            int _MaxOptionalRequeriments = 5; //numero de opciones


Y el método iniRequeriments inicializa el array booleano _requeriments a true o a false dependiendo si un requisito se activo o no. Pero, ¿cómo?

Haciendo uso, ahora sí, de los #if.


#if __EXCEL_EXPORT__
                _requeriments[(int)OptionalRequeriments.EXPORT_EXCEL__REQUERIMENT] = true;
#endif
#if __TXT__EXPORT__
                _requeriments[(int)OptionalRequeriments.EXPORT_TXT__REQUERIMENT] = true;
#endif

Sí por ejemplo el simbolo __EXCEL_EXPORT__ no está definido, entonces 
 _requeriments[(int)OptionalRequeriments.EXPORT_EXCEL__REQUERIMENT] estaría a falso.

La función completa sería:

   private void iniRequeriments()
            {
                _requeriments = new bool[_MaxOptionalRequeriments];
            
                for (int i = 0; i < _MaxOptionalRequeriments; i++)
                {
                    _requeriments[i] = false;

                }

#if __EXCEL_EXPORT__
                _requeriments[(int)OptionalRequeriments.EXPORT_EXCEL__REQUERIMENT] = true;
#endif
#if __TXT__EXPORT__
                _requeriments[(int)OptionalRequeriments.EXPORT_TXT__REQUERIMENT] = true;
#endif
#if __2D_VIEW__
                _requeriments[(int)OptionalRequeriments.GRAPHICS_2D_REQUERIMENT] = true;
#endif

#if __3D_VIEW__
                _requeriments[(int)OptionalRequeriments.GRAPHICS_3D_REQUERIMENT] = true;
#endif

#if __2D_VIEW__ && __3D_VIEW__
                _requeriments[(int)OptionalRequeriments.GENERATE_3D_MODEL] = true;
#endif

            }

En negrita he puesto el requisito 'generar modelo 3d a fichero'. Como este requisito depende de dos requisitos, no se define un simbolo de tipo __GENERATE_MODEL_3D__.

La gracia de esto, es que se puede establecer una jerarquía de requisitos. Requisitos que se activen o no, dependiendo de otros requisitos!!

Además, de luego, la facilidad para habilitar los menús, dependiendo de las funcionalidades activas. Como se ve abajo.

private void updateMenuFromRequerimentsNewWay()
        {
            txtToolStripMenuItem.Enabled = RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.EXPORT_TXT__REQUERIMENT);

            excelToolStripMenuItem.Enabled = RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.EXPORT_EXCEL__REQUERIMENT);

            View2dToolStripMenuItem.Enabled = RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.GRAPHICS_2D_REQUERIMENT);

            View3dToolStripMenuItem1.Enabled = RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.GRAPHICS_3D_REQUERIMENT);

            generateModel3DToolStripMenuItem.Enabled = RequerimentsActivator.GetInstance().IsRequerimentInstalled(Versions.RequerimentsActivator.OptionalRequeriments.GENERATE_3D_MODEL);
            
        }

Conclusión

Creo que está forma de activar o desactivar los requisitos de un software, hace más mantenible a la larga el código fuente, ya que, encapsula la complejidad de los #if . Además, esto permite, aumentar la complejidad, pudiendo crear jerarquías de requisitos (activar un requisito cuando varios requisitos están activos, o pueden obedecer a una lógica booleana).


El código fuente se puede encontrar aquí.

Félix Romo
felix.romo.sanchezseco@gmail.com

lunes, 27 de julio de 2015

Contar Olivos con Ortofoto: Parte I (Algoritmo Secuencial de Etiquetado)

Contar Olivos con Ortofoto: Parte I (Algoritmo Secuencial de Etiquetado)


Introducción


Hace muchos años, trabaje en Tragsatec, donde trabajaba manteniendo el GIS Dinamap. Había una parte del programa que me fascinaba. A partir de una ortofoto de un campo de olivos, Dinamap, contaba los olivos. De esta forma, se podría saber los olivos de un terreno y la subvención correspondiente. De esta forma, se evitaba que una persona, se trasladase al lugar y contarlos.

Siempre me pregunte que tipo de algoritmo se usaba. ¿Como los contaba? Y siempre me quedo esa espinita. Y creo que hoy, poco a poco, me lo voy sacando.

Pero, es lo mismo que contar estrella en una foto, solo que aquí, el fondo es negro y los elementos a contar blancos o más claros.


Mi implementación - Algoritmo Secuencial de Etiquetado


Primeramente, no he implementado todo el proceso, pero si una parte. Los pasos que yo veo para contar olivos, o estrellas...es el siguiente.

1-  Extraer todos los elementos de la imagen sean o no olivos. (Algoritmo Secuencial de Etiquetado)
2. - Determinar si el elemento extraído es un olivo.

En este post se ha implementado la primera parte, extraer todos los elementos de la imagen. Para este proceso se el algoritmo de tipo Algoritmo Secuencial de Etiquetado.



Implementación Algoritmo Secuencial de Etiquetado.

Imagen de test.



Dado una imagen en una escala de grises, se transforma esta imagen una matrix nxm donde n es la anchura de la imagen y m la altura de la imagen. Así, obtenemos una imagen donde los ceros, será el fondo de la imagen y los 1s, definiran los elementos contendidos en la imagen.



Aquí se ve como los 1s forman tres figuras, tres circulos. Ahora, con el algoritmo de etiquetado secuencial, se etiqueta cada figura, dando lugar a la extracción de la información de cada figura, lo que ocupa en ancho y algo en la imagen y su etiqueta asociada. Asi, el numero de figuras en la imagen, nos daría el numero de olivos aproximados.l



Aunque, claro, las figuras etiquetadas, pueden ser otra cosa que no sean olivos, como casas, o zonas osucaras de carreteras, y entonces, habría que pasar las matrices que forman las figuras, por otra fase, que detecte que figuras son olivos.

-Determinar si el elemento extraído es un olivo.


Aquí se puede usar redes neuronales la cuales, habrán sido entrenadas para reconocer patrones de imágenes de olivos. Como una imagen de un olivo puede estar en 20x15 pixeles, o en 15x17 pixeles, se realiza una transformación de la imagen a una conocida, por ejemplo a 5x5, Y asi, entrenaremos la red neuronal con imágenes de olivos de 5x5 pixelesy también de no olivos con esta resolución. Y también importante, entrenar a esta red neuronal contra el fraude, por si pusiesen en el campo olivos de cartón para que en la ortofoto se cuente como un olivo. Pero esta parte, ya se realizará en otro post.



CounterOlives


CounterOlives es el programa de testeo para probar la primera fase de esta implantación de contar olivos. 










En este link esta un fichero comprimido con el ejecutable y algunas ortofotos en formato .bmp.


En el siguiente ejemplo, se ve como cuenta como olivos, figuras que no son olivos. Aquí, es donde un segundo algoritmo (redes neuronales por ejemplo) debería de clasificar cada figura y asi contar verdaderamente los olivos que hay en la imagen.





Conclusión

Con unas pocas modificaciones, se podría contar el número de piscinas en un municipio, el numero de estrellas, número de personas en una concentración...lo mismo he pecado de optimista con 'unas pocas modificaciones'..pero se podría intentar.

Noticias relacionadas:

"Google Earth es utilizada para encontrar piscinas ilegales": 
http://www.marketingdirecto.com/actualidad/digital/google-earth-es-utilizada-para-encontrar-piscinas-ilegales/



miércoles, 15 de julio de 2015

Redes Bayesianas : Simulación Accidentes petroleros

Introducción


Hace ya un tiempo, en la máquina del café de mi trabajo, charlando, se comento los escenarios de no-masa, es decir, escenarios donde hay muy pocos datos para hacer uso de métodos estadísticos. Por ejemplo, los accidentes de barcos, aviones, cohetes,...

También, quería meterme con este tema de las redes bayesianas, ya que en su día, me metí con los Naives Bayes classifier (clasificador bayesiano ingenuo ¿?)

Entonces, ví que con redes bayesianas se podría simular escenarios de no masa, y escogí el escenario de los accidentes de los petroleros.

Red Bayesiana Accidentes Petroleros

No soy ningun experto en las causas que pueden provocarlos, ni mucho menos la probabilidad de cada uno de ellos, pero aquí está la red que use.




Aquí supuse que el Fuego (Fire) depende de si la tripulación no tiene experiencia, es junior y si el casco es de tipo casco simple.
Después, en daños estructurales (Structural Damage) supuse que si un barca sufre fuertes olas, mayor probabilidad de que sufrir daños, y las fuertes olas (strong swell) dependen de donde este el barco, el que mar u océano esté.

Las tablas de probabilidad para los nodos dependientes fueron:




Simulación


Lanzamos 1000 simulaciones, con una probabilidad baja de tener tripulacion junior y que el barco esté en el océano atlántico y con baja probabilidad que el barco tenga un casco simple.


Esto nos da que el fuego y daños estructurales están a la par, entre 30-40 accidentes.




Cambiamos la probabilidad de la tripulación junior a más alta, esto nos dará más incendios.




Ha subido hasta del orden de 500 incendios.

Aquí se ve, que cambiando las probabilidades, los resultados de la simulación varia. Aquí es donde los expertos en el dominio, en este caso los accidentes de petroleros, deben de crear el modelo con las variables y dependencias adecuadas, y las probabilidades más o menos correctas. Aunque a medida que se van conociendo datos, este modelo se actualidad, tanto con variables nuevas como con actualizar las probabilidades.

Conclusión


Aunque este método podría ayudar en este tipo de problemas, no sé si en la comunidad actuarial, al no ser un método estadístico, sería muy aceptado o tendrían sus reticencias. Pero, es aquí donde esta su fortaleza, la información estadística la guarda en las probabilidades dadas por el experto o conjunto de expertos.

Por otra parte, también este tipo de escenarios, se podría resolver con lógica difusa. Como por ejemplo, en un programa que desarrolle que usaba lógica difusa para frenar los coches (como lo hace, salvando las distancias claro, el metro de Japón).



Si te interesa el código fuente, envíame un correo.

Félix Romo
felix.romo.sanchezseco@gmail.com


miércoles, 17 de junio de 2015

Threading: Actualizando Winforms

Introducción

Es muy posible que estando en proyecto de gráficos y al inicio de él, las prioridades serán que el gráfico se visualice correctamente en la ventana, con la información correcta, que se pueda manipular el objeto que se saca por pantalla, y dejando otras funcionalidades para la siguiente iteración.

Para ilustrar este post, imaginemos un proyecto software de tipo SIG (Sistema de Información Geográfica) donde hay muchas entidades geográficas a visualizar,
tantas, que se almacenan en una base de datos, y solo se pintan las entidades que corresponden con el área que se visualiza en pantalla.

Bien, en un principio...era la nada...luego el big bag..ok..al tema. Se visualizarían las entidades de una región en pantalla, pero luego el usuario, va moviendo esa región, o se aleja, esto generará que haya más entidades de mapa a visualizar, como no están en memoria, se piden a la base de datos,
la base de datos las retorna, y una vez retornadas se invalidará (Invalidate()) la ventana para que se repinte el mapa con la nueva información.

Threading

Entonces, llega el cliente o jefe..en fin un stakeholder del proyecto y dice:
"¿Y no se puede dibujar las entidades a la vez que las va leyendo de la base de datos?". Y en ese momento, empieza la cabeza a meterse en el código y ver que modificaciones habría que hacer, cual sería el nivel del impacto, y el resultado al cabo de un segundo es.."uff..no es inmediato..".

Solución


En el pequeño ejemplo que me he inventado, parece muy simple, pero cuando estas en un proyecto real, las cosas no son tan simples, pero hay que intentar reducir la complejidad al mínimo posible.

Aquí se ha intentado reducir la complejidad o ocultarla en la clase BackgroundPainter, que su responsabilidad sería la de leer de la base de datos, y pintar las entidades del mapa leídas, además de añadirlas al mapa. Aunque el leer de la base de datos estarías en la clase EntitiesDDBB y el dibujar en las clases hijas de MapEntity. Es decir que BackgroundPainter sería una clase controlador.


Se ha derivado de la clase BackgroundWorker, para de estar forma hacer la concurrencia más fácil, ya que cuando se termina de pintar todas, se lanzará
el evento RunWorkerCompleted, donde se invalidará la ventana y se repintará con la nueva información.


Se sobreescribe el método OnDoWork para que en este método se haga el trabajo de obtener las entidades de base de datos, añadir al mapa y dibujarlas.

En la aplicación, el botón "Get entities from DDBB", simula que el usuario a cambiado de región o alguna circunstancia que haga que se tenga que cargar nuevas entidades de base de datos. 
Se puede ver mientras se pinta las entidades, como se puede interactuar con el UI:


El código fuente se puede descargar aquí.

Conclusión


Habrá mucha soluciones, pero esta me ha parecido curiosa por el hecho de crear una clase que derive de BackgroundWorker y así, crear un worker en background donde ocultar
la complejidad de la aplicación y no llevar esta complejidad en MainForm.cs o en otra clase existente. He incluso para complicarlos más, esta clase BackgroundPainter podría recuperar
la textura del terreno en background con otro thread.