Mostrando entradas con la etiqueta programación. Mostrar todas las entradas
Mostrando entradas con la etiqueta programación. Mostrar todas las entradas

martes, 28 de mayo de 2013

Programando Baby Orangutan con AVR Studio 5.1

Al diseñar nuestro robot, normalmente necesitamos un driver para controlar al menos un par de motores y un microcontrolador para controlar la lógica que gobierna el robot. Si utilizamos un Arduino y un driver externo esto nos puede costar entre 35 y 80 euros según los elementos utilizados. La placa que os presento hoy es una placa compacta que integra un Atmega 328P, el mismo microcontrolador que utiliza Arduino UNO, y un driver de dos canales de 3A de pico por canal, con lo que podemos controlar un par de motores de una potencia relativamente alta.

Este controlador tiene múltiples ventajas, es barato, compacto, ligero, integra un microcontrolador AVR junto a un driver de 3A de pico por canal e incluye un potenciometro para poder realizar ajustes online en nuestro robot sin necesidad de añadir nada nuevo a la placa electrónica de nuestro robot. Sin embargo, a la hora de comprar este controlador hay que tener en cuenta una serie de detalles. En primer lugar esta placa no incorpora un bootloader preinstalado, el bootloader es un código residente en el micro que permite cargar un programa través del puerto serie como ocurre en el caso de Arduino. Al no tener este código residente, no es posible enviarle un programa a través del puerto serie y es necesario utilizar un programador externo como nuestro USBtinyISP para poder cargar los programas. Con un programador externo también es posible cargar el bootloader de Arduino y a partir de ese momento si es posible programar a través del puerto serie como con cualquier otro Arduino. Otra opción, es programar directamente a través del puerto de programación con el mismo IDE de Arduino, o con IDEs avanzados como el que vamos a utilizar hoy que es AVR Studio.

Hoy me voy a centrar en contaros como programar esta placa con AVR Studio. AVR Studio es un entorno de programación de Atmel basado en Visual Studio, por lo que aquellos que tengan experiencia con programación en .Net se sentirán muy cómodos utilizando este entorno. Una de las ventajas de programar con un entorno como este, es la posibilidad que ofrece el entorno de simular el micro y ejecutar el programa en modo el debug lo que permite realizar trazas de una forma muy cómoda  De esta manera es posible ver el valor que irían adquiriendo los registros en tiempo de ejecución, deteniendo el programa y pudiendo incluso ejecutarlo paso a paso, lo que nos permite depurar errores de una forma mucho mas eficiente.

El primer paso es instalar el entorno Atmel Studio o AVR Studio dependiendo de la versión que instalemos. Es importante instalar la versión 4.0, 5.1 o bien la 6.0 ya que son las versiones compatibles con el paquete de librerías de pololu, AVR development bundle, que incluye librerías varias para la programación de microcontroladores AVR.

A continuación hay que instalar el driver de tu programador para AVR, si utilizas Windows 8 tendrás que seguir los pasos descritos en esta entrada que explica como instalar los drivers de Arduino DUE en Windows 8 pero el mismo procedimiento puede utilizarse con muchos otros dispositivos como por ejemplo es este caso. 

Una vez instalados los drivers del programador tenemos que configurar nuestro USBtinyISP, para ello lo primero es instalar la herramienta WinAVR que incorpora diferentes herramientas para la programación de dipositivos ATmega, en concreto la que nos interesa a nosotros es AVRdude. Posteriormente hay que configurarlo en el entrono de AVR Studio, para ello os dejo un vídeo en el que explican como configurarlo ya que es complicado de explicar y viéndolo se hace mucho más sencillo.


Tras instalar WinAVR, se instalan en la carpeta C:\WinAVR-20100110 multitud de herramientas. En esta carpeta se encuentra la carpeta bin donde están todos los ejecutables y ahí podemos encontrar AVRdude que es el programa que tenemos que configurar en el entorno como programador. En el entorno de AVR Studio hay que utilzar la opción Tools --> External Tools que permite añadir un programador como herramienta externa. Al utilizar esta opción, aparecerá un formulario done hay que configurar en primer lugar el nombre de nuestra herramienta, por ejemplo USBTiny. El segundo argumento se refiere al ejecutable de nuestra herramienta que será avrdude, por lo que hay que poner la ruta hasta el ejecutable que por defecto será C:\WinAVR-20100110\bin\avrdude.exe. Los siguientes argumentos dependerán de la solución que hayamos creado. Cuando creamos un nuevo proyecto hay que elegir la librería de Pololu y dentro de la librería elegir BabyOrangutan 328P, lo que creará una solución para este dispositivo. Como se puede ver en el ejemplo, hay que seleccionar el nombre del proyecto, el nombre de la solución y el directorio donde estará la solución.


Una vez creada la solución, podemos consultar estos parámetros a la derecha en el explorador de soluciones como se ve en la imagen siguiente. Al generar el proyecto, según si hemos elegido Release o Debug, se generará una carpeta dentro del directorio de la solución con ese nombres y dentro de dicho directorio, estará el archivo nombreProyecto.hex que es el archivo binario generado que hay que cargar al controlador Baby Orangutan.


Al crear el proyecto por defecto, se creará con un archivo con el código del ejemplo blink que enciende y apaga un Led. A partir de aquí, hay que rellenar el resto de parámetros en la configuración de la herramienta externa de programación. Hemos añadido el nombre y el ejecutable que realizará las tareas de grabación en el Baby Orangutan, pero ahora debemos rellenar los argumentos donde según el vídeo hay que utilizar la linea -c usbtiny -p m328p -U flash:w:$(ItemFileName) pero lo que hay que hacer es ver el nombre con el que se generea el archivo con extensión .hex y utilizar este nombre. Para ello, hay que generar la solución con la opción Build->Build Solution y luego navegar hasta la carpeta de la solución. Si hemos compilado en Release habrá que mirar en la carpeta con este nombre y si hemos compilado en Debug habrá que mirar en la carpeta con este otro nombre. Allí encontraremos un archivo generado con la extensión .hex y ese es el que hay que utilizar en la linea de comando anterior. Por defecto este nombre será el mismo del del proyecto por lo que si nuestro proyecto se llama nombreProyecto se deberá usar la sentencia  -c usbtiny -p m328p -F -U flash:w:nombreProyecto.hex. Puede verse que en la linea anterior se ha añadido el parámetro -F que soluciona algunos problemas que pueden aparecer al intentar cargar código al microcontrolador utilizando avrdude.


Es importante tener en cuenta que el Baby Orangutan utiliza los pines PB4 y PB5 para la programación por lo que si utilizamos estos pines en nuestros proyectos podemos encontrar problemas a la hora de programarlo. En concreto, no debería haber problema a no se que se conecte en dichos pines un condensador que impediría programar el microcontrolador sin quitarlo del zócalo. Otra cosa a tener en cuenta a la hora de programarlo es la posición del conector, en la placa del Baby Orangutan puede verse marcado con una flecha el pin 1 del conector ISP. El pin 2 es el que se encuentra encima de este y corresponde con VCC y por lo tanto el lado con una franja roja del conector del programador debe conectarse en ese lado.


Por último, en el cuarto parámetro hay que indicar el directorio donde se encuentra este archivo ejecutable, indicando la carpeta Release o Debug según corresponda. Con esto, aparecerá un nuevo ítem en el menú Tools con el nombre de nuestra herramienta. Si conectamos el programador USBTiny al PC y le conectamos nuestro Baby Orangutan, al pulsar el botón Tools -> USBTiny compilará el código de ejemplo y lo cargará en nuestro Baby Orangutan. Después de esto podremos ver como el led se enciende y se apaga intermitentemente, a partir de aquí ya podemos comenzar a crear nuestro propio código, basándonos en las librerías de pololu y con la ayuda de InteliSense que nos sugerirá código a medida que vamos programando.



Espero que os sea de ayuda, y si necesitáis aclarar alguna cosa no dudéis en poner un comentario e intentaremos ayudaros en todo lo posible.




domingo, 14 de abril de 2013

Conclusiones de Alcabot

Bueno, ya estamos en casa. En realidad llegamos el miércoles, pero nada más llegar nos pusimos manos a la obra para aplicar los conocimientos que nos traemos con nosotros. Allí pudimos conocer a mucha gente, por lo que ha sido un viaje interesante. Conocimos a Xavi Puigmal, subcampeon de la categoría de velocistas con el robot Smith Black y a Daniel Giménez campeón y subcampeón de las categorías de rastreadores. Abajo os dejo un vídeo con los cuartos de final de la prueba de velocistas. En el vídeo no da la impresión de que los robots vayan tan rápido porque el circuito es muy grande, pero os aseguro que cuando los ves en directo impresiona muchísimo.



Xavi consiguió ser subcampeón en velocistas. El campeón fue el robot Gadgetocoptero de la escuadra Inspector Gadget. Xavi y Dani nos explicaron la importancia de hacer que el robot velocista sea ligero. El límite parece estar en unos 100 gramos, ya que con este peso o inferior, es posible conseguir un robot que a velocidad constante se mantenga en las curvas. En caso de no estar en estos pesos, la velocidad limite del robot es muy inferior, ya que obliga a frenar antes de las curvas para que el robot no se salga del circuito y esto solo se puede conseguir de forma eficiente sacando las telemetrías del circuito y dándoselas al robot.

Otra ventaja de utilizar un robot ligero es que con motores de menos par, y por tanto menos reducción se puede controlar correctamente el robot, mientras que cuanto más pesado es el robot más fuerza se requiere y por tanto más potentes deben ser los motores. Además, por lo general los motores más potentes suelen pesar mas, por lo que tenemos un pez que se muerde la cola, motores más potentes implican más peso y por tanto se requieren motores más potentes para mover el robot. La escuderías Smith e Inspector Gadget utilizan motores pololu HP de 10:1 y de 5:1 para sus robots velocistas, esto les permite conseguir unas velocidades máximas muy altas. Este tipo de motores tienen una velocidad punta del orden de 1000 rpm y un par relativamente alto para su tamaño y peso, pero por otro lado tienen el problema de tener bastante inercia lo que hace que una vez acelerado sea difícil reducir la velocidad. Por este motivo, para poder frenar a tiempo el robot con este tipo de motores es imprescindible que el robot poco, o bien, poder predecir la curva con unos 20cm de antelación. Otro factor importante es tener poco peso en el morro del coche, de hecho, lo ideal es que el centro de gravedad esté entre los dos motores ya que así, con menos aporte de par de los motores es más fácil hacer girar el robot, de lo contrario se requiere más par para girar el robot y esto en motores de baja reducción se consigue cambiando dramáticamente la velocidad de los motores lo que hace que se pierda capacidad de control. Respecto al controlador que utiliza esta escudería, principalmente es un Baby orangutan, que es un controlador que incorpora un chip Atmega328P como el de arduino y un driver TB6612FNG, esto demuestra que para ganar no es necesario usar un controlador de 32 bits, aunque nunca viene mal tener mayor potencia de computo.

Con todo lo que hemos aprendido ya hemos diseñado un nuevo robot prototipo para evaluar el tema de los pesos, aquí os dejo una foto y mas adelante os guiaré para poder construir uno similar a aquellos que esteis interesados.



En la prueba de rastreadores Daniel Giménez consiguió ser campeón y subcampeón de la prueba. Él nos estuvo enseñando como conseguir un algoritmo para sacar la telemetría del circuito online, con tu robot, es decir, poner a tu robot a rodar en el circuito a baja velocidad y que te envíe los datos del circuito por bluetooth. También nos dio una importante lección respecto a los robots rastreadores, y consiste en que la placa de sensores debe estar en forma de U invertida, es decir formando un arco. Esto, tiene su principal fundamento en que el robot para centrarse en el camino utiliza un algoritmo PID. Si los sensores están en forma de linea, cuando el robot llega a una intersección con forma de angulo recto, cuando se salen los primeros sensores no se tiene información del circuito, mientras que si tienen forma de U, cuando el morro sale de la linea otra parte de los sensores siguen viendo una linea y aplicando un PID se puede volver a centrar en el camino.

Por último el campeón indiscutible de la prueba de sumo fue Xavi nuevamente, consiguió el primer, segundo y tercer premio de esta prueba y de la prueba de mini sumo. Pese a que nuestro robot tenía una inteligencia bastante buena, sus robots conseguían movernos con relativa facilidad, parecíamos un trocito de corcho. Xavi nos explicó como construyó sus robots y nos dio las claves principales para que tu robot pueda ser competitivo. Para empezar, todos los materiales utilizados son de pololu  y como controlador utiliza Picaxe. Los motores utilizados en los mini sumo son los motores de pololu HP 50:1 o el pololu HP 30:1. Sin embargo, llevar el peso al limite es imprescindible para que el robot tenga un buen agarre. Además, otro de los puntos más importantes son las ruedas utilizadas. Por lo que hablamos con Xavi y con otros constructores, las siliconas son de los materiales más recomendables. La silicona más empleada ultimamente es la llamada Mold Max cuya dureza 10A hace que la superficie de contacto del robot con el suelo sea enorme. A continuación os dejo el vídeo resumen de la clasificación de Fatbot-mini para que veáis lo robots en pleno funcionamiento.

En el primer combate podéis ver nuestro robot contra el robot Toxic de la escuadra Smith. En este caso, pagamos en el primer combate la novatada de poner el robot demasiado cerca del borde... cosas que pasan :) de todas formas en el segundo podéis ver como el robot de Xavi nos saca del Dojo como si no pesásemos nada.  Para que os podáis hacer una idea, nuestro robot pesa unos 350 gramos y el robot de Xavi pesa casi 500 gramos. En el siguiente combate podéis ver un combate que conseguimos ganar, gracias a encontrar al otro robot por detrás antes que el a nosotros. En la segunda manga nos terminamos enfrentando cara a cara y no pudimos hacer nada. La conclusión que extraemos es que tenemos que aumentar el peso de nuestro robot y mejorar el material de contacto con el suelo, la idea que nos dieron unos compañeros con los que hablamos allí, es recubrir las orugas con neopreno, más adelante os contaremos el resultado.






domingo, 13 de enero de 2013

Arduino Shield List: Lista de placas para Arduino

Arduino se ha convertido en una de las plataformas más populares para el desarrollo de electrónica en el hogar a nivel aficionado. Muchas universidades han incluido esta placa de hardware y software libre en sus clases prácticas, por la facilidad de programación que ofrece su entorno, donde es posible programar directamente en C ó C++ y cargar los programas a través del USB.

Pero esto no es todo, hay infinidad de posibilidades para la creación de nuevas ideas a partir de una placa Arduino. Una de las formas más fáciles de añadir nuevas funcionalidades a la placa Arduino es a través de las Shields de Arduino. Pero, ¿que es un shield?. Pues un shield no es más que una placa electrónica que puede ser conectada en la parte superior de Arduino y que normalmente permite a su vez conectar más placas encima de ella y que incorpora una determinada funcionalidad.

Jonathan Oxer ha creado y mantiene desde hace tiempo Arduino Shield List una interesante página sobre este tema. Su cometido, creo entender, que consiste en recopilar toda la información de utilización de los pines originales de Arduino de cada placa, a modo de poder determinar fácilmente que shields son compatibles con que otros.

Diferentes Arduino Shields Apiladas


Entre otras muchas cosas, muestro a continuación algunas de las funcionalidades más populares de los Shields de Arduino que pueden encontrarse por ahí:


  • Módulo de Relés: Un relé permite controlar con una salida de Arduino, la activación de dispositivos que tengan altos consumos de corriente. Cada salida de Arduino no puede emitir más de 20mA por lo que ciertos elementos como por ejemplo motores u otros elementos actuados con bobinas, no pueden ser activados directamente desde una salda de Arduino. En estos casos es util utilizar un modulo de Relés para poder activar dichos elementos. A continuación podéis ver un vídeo donde se utiliza un Módulo de relés para encender una bombilla, aquí tened cuidado ya que hay relés de características diferentes, por lo que esto no se debe hacer con cualquier tipo de relé, comprobad antes que el relé es capaz de conducir la intensidad correspondiente.

  • Módulo Ethernet: Con estos módulos es posible conectar Arduino a nuestra red local de cada. De manera que podemos hacer que acceda a cualquier información o bien que actúe como un pequeño servidor Web o de directorios, aunque su uso más útil es poder conectar a Arduino un dispositivo actuador o sensor, y acceder a su control o monitorización a través de la red local de casa. En este otro vídeo se muestra como controlar un módulo de relés a través de un PC utilizando para ello un módulo Ethernet para publicar el servicio.

  • Expansores de I/O: En muchas ocasiones, nos encontramos con determinados tipos de aplicación, donde podemos encontrar que Arduino no tiene suficientes entradas o salidas para controlar todos los elementos necesarios. En estos casos, se puede recurrir a Shields específicos para aumentar la cantidad de entradas salidas de nuestro Arduino. Generalmente estos Shields utilizan un bus de comunicaciones I2C o SPI para controlar desde el Arduino las nuevas I/O por lo que hay que fijarse en que bus utiliza el shield en concreto ya que según cual sea dejará sin poder utilizar unas determinadas entradas de Arduino. En el vídeo incluido a continuación, se muestra como con uno de estos expansores de entradas, es posible utilizar hasta 8 entradas como entradas de interrupción. Esto se consigue ya que cada puerto del expansor (8 entradas/salidas) tiene asociada una patilla de generación de interrupción (de manera que si hay un cambio en cualquier entrada del puerto se genera una señal de interrupción). Por lo tanto, es tan sencillo, como conectar esta salida de interrupción a una entrada de interrupción de Arduino y cuando se produzca una señal leer el puerto completo para detectar cual ha sido la que cambió. Trabajar de esta forma, con interrupciones  evita tener que chequear el puerto en cada ciclo de programa.


domingo, 18 de noviembre de 2012

GUÍA ESTÁNDAR DE PROGRAMAÓN DE AUTOMATISMOS GENERAL APLICADA A AUTOMATAS OMRON EN LENGUAJE LADDER (GEPAG)


Cuando realizamos un proyecto de automatización, lo ideal siempre es realizar un análisis previo en el que se debería incluir un diagrama de estados del funcionamiento del sistema. Si el sistema es muy sencillo quizá con solo un diagrama sea suficiente para plasmar todo los estados. En cambio, si el sistema no es suficientemente sencillo lo aconsejable es dividir el problema en subproblemas más pequeños de manera que se aíslen unas partes del problema de otras. Esto además de facilitar la trazabilidad del código y reducir enormemente los errores que se cometerán en la programación, también evitará generar diagramas de estados demasiado grandes y que muchas veces en lugar de permitir manejar mejor el problema (como es su finalidad) acaban consiguiendo todo lo contrario. De esta forma lo que se obtendría es un autómata general más grande que corresponde al diagrama de estados principal y en cada uno de los estados de este diagrama se tendrá un nuevo pequeño automatismo para gestionar cada uno de estos estados.

A continuación se va a mostrar un ejemplo de esto en el caso de autómatas Omron y utilizando lenguaje Ladder, ya que por ejemplo en el caso de autómatas de bajo coste como es la familia CP1 es el único lenguaje que en el que se puede desarrollar. El ejemplo empleado corresponde al de una práctica de la asignatura Sistemas de Control Automático del Máster en Automática y Robótica de la Universidad de Alicante. En este caso tenemos que controlar la gestión de 4 bombas que dan suministro para conseguir una presión estable en la impulsión. Dejando a un lado las particularidades del sistema, el funcionamiento se puede dividir en los siguientes tres estados según la guía Gemma que a su vez pueden ser tratar como cuatro estados en los que no entraremos en detalles:

Diagrama de estados que representa el funcionamiento del sistema General de la práctica


 Cuando se desarrolla software, lo mismo se puede programar de infinitas formas y se tiende a pensar que cualquiera de ellas es igual de buena si realiza su función. Para empezar la eficiencia de los diferentes programas tanto espacial como temporal no es la misma, pero dejando al margen este detalle que puede no ser decisivo existe un motivo más importante para hacer las cosas correctamente. Un código debe ser mantenible, fácilmente trazable, orientado a la extensión y no al cambio y lo más estándar que sea posible, es decir hay que establecer una metodología para la creación de código. El objetivo es que la parte de ingeniería resida en el análisis del problema y en el diseño de la solución en papel (a través de un diagrama de estados grafcet o similar) pero no en el código que se escribe. Para conseguir esto, se debe utilizar una guía de implementación, que dado un análisis del problema siempre termine generando el mismo código sea quien sea el programador, por lo menos en lo esencial. Este tutorial pretende ser una pequeña guía introductoria de cómo hacer esto en autómatas Omron, para una pequeña parte de los programas. En futuras guías, se mostrará como explotar estos estados y realizar pequeñas máquinas de estados secuenciales para cada caso aplicando nuevos métodos.

 Para implementar esto con autómatas Omron, hay muchas formas pero sin duda alguna la forma más eficiente es desactivar completamente la ejecución de los estados que no se estén utilizando. Esto permite ahorrar tiempo y evita que posibles casos no contemplados en estos estados (cuando no deberían estar siendo ejecutados) afecten al correcto comportamiento del sistema. Para conseguir esto hay que dividir la solución en programas diferentes, en la parte izquierda del entorno de CX-Programer se puede ver que en la última opción (programas) permite crear diferentes bloques de código a los que CX-Programer llama programas. Al añadir un nuevo programa se obtienen una pantalla donde se muestran las opciones de Nombre, Tipo de tarea y una opción de chequeo llamada Inicio de operación. El nombre es tan solo un identificador, y el tipo de tarea debería estar ordenado según el orden de ejecución que queramos, por ejemplo, en el caso expuesto tendríamos 5 programas. Un primer programa que gestionará el cambio de estados entre programas. Y cuatro programas más, uno por cada estado de la máquina de estados. Por tanto el orden de tareas que yo recomendarías sería el programa que gestiona el cambio de estados como el de mayor prioridad (por ejemplo tarea 3) y el resto consecutivamente según el orden en que entran en funcionamiento: PARO tarea 4, MARCHA tarea 5, etc.  Nótese que el estado de mayor prioridad se le asigna la tarea 3, esto es porque previo a este programa se han añadido otra serie de programas para realizar la gestión de otras características como comunicaciones, inicialización de variables u otros detalles comunes a todos los estados.


Para realizar el cambio entre estados lo que se debe hacer es detener la ejecución de los programas que no correspondan al estado que está en el instante actual en ejecución. Para ello hay que deshabilitar la casilla de chequeo de las ventanas de propiedades de los programas correspondientes a las tareas 4, 5, 6 y 7 (PARO, REPOSO, SERVICIO y PARANDO). Esto se hace así, porque así los programas permanecerán detenidos a no ser que sean activados de forma explícita utilizando la función TKON, de lo contrario en cada estado habría que apagar todos los que no estuviesen activos ya que por defecto estarían en ejecución. 
                 
                    

De esta manera, el código de cambio de estados se puede expresar de forma muy simple como una variable entera que almacena el estado entre 0 y 3 y que según el estado si se cumple la señal de transición cambia el valor de la variable por el valor del estado siguiente como se muestra a continuación:


Existe un mecanismo  óptimo para los sistemas secuenciales puros que se verá en nuevas guías. Sin embargo para sistemas que contienen transiciones cruzadas entre estados, este es el mecanismo que yo recomiendo.
Como se comentaba anteriormente, utilizando la función TKON es posible habilitar el código (programa) correspondiente al estado en que se encuentra el sistema como se muestra en la imagen. En caso de no haber desactivado la casilla Inicio de operación en los programas que contienen el código de los estados, todos estarían inactivos y habría que desactivar todos aquellos no correspondientes al estado activo utilizando la función TKOF. Esta solución es menos intuitiva y más complicada de gestionar, porque en la mayoría de casos habría que detenerlos en más de un lugar del código lo que complicaría la gestión del sistema y aumentaría la probabilidad de cometer un error. Lo que se propone en esta práctica es que cuando se produce una transición se active el nuevo estado y se desactive el estado o estados de los que se pueda proceder, este no es el único modo de hacer esto, ya que según el caso podría haber formas más optimas de hacer lo mismo.

Es importante tener en cuenta que TKOF congela el programa en el estado exacto en que se quedó, esto quiere decir que sus salidas quedan activas y su estado al salir es el último estado que se ejecutó. Por lo tanto es conveniente, reiniciar el estado en la sección de control de la máquina anterior, como se muestra en la figura. Es decir, si se va a un nuevo estado cuyo subestado depende de una variable que almacena el estado es conveniente reiniciar el valor de esta variable (iniciarlo a cero) para que el subestado se ejecute correctamente.

Un detalle a tener en cuenta es utilizar como memoria para almacenar el estado (variable Estado) una palabra del área DM ya que esta memoria está reservada para datos y es posible escribirla desde diferentes partes del código sin que el programa se queje. En caso de emplear una dirección de memoria normal, se obtendría una advertencia diciendo que la escritura de las bobinas está duplicada.

Este sistema es fácilmente extensible a diagramas generales de muchos más estados y permite la aplicación GEMMA de una forma cómoda y sencilla. En este ejemplo como sólo se pretende implementar tres estados GEMMA (diagrama MARCHA/PARO) se ha incluido en el ejemplo el desglose de dos subestados del estado F1. Esto no deja de ser una particularidad del problema concreto, pero suele ser una buena costumbre dividir F1 en entre 2 y 5 macroestados según la complejidad del problema y gestionar este nivel de F1 con este mismo método, de esta manera se simplificará la definición de los subestados del problema principal (F1).


Referencias: