Autor:Angel Aedo Busto Competencia: Desarrollo de Software (Nivel 2) Palabras Clave: Java, BlueJ, FIbonacci, 4 Pasos, Algoritmo.
Se nos plantea en clases el determinar al menos un método del como calcular la sucesión de fibonacci, pero con la particularidad de que se debe implementar el método de los 4 pasos. El metodo de los cuatro pasos consiste en realizar ejemplos de entrada y salida, Analisis y diseño, diagrama de actividades y por ultimo la implementación en java.
Paso 1: Entrada-Salida
0 ->[Proceso]-> “El numero no debe ser menor a 1 ”
-1 ->[Proceso]-> “El numero no debe ser menor a 1”
uno ->[Proceso]-> "Debe ingresar exclusivamente numeros (ejem: 1,2,3,4....n)"
IX ->[Proceso]-> "Debe ingresar exclusivamente numeros (ejem: 1,2,3,4....n)"
Para la dar solución a una sucesión de Fibonacci, se usa el método en base a conocer el Fibonacci de uno, esto quiere decir que para cualquier valor de n, se representa en función de un fibonacci conocido. Por ejemplo, si se pide calcular la sucesión Fibonacci de 4. Se conoce Fibonacci(1) = 1, por lo que Fibonacci(4) es Fibonacci(3)+Fibonacci(2), ahora Fibonacci(3) es Fibonacci(2)+Fibonacci(1), siendo este último = 1 de esta forma ciclicamente cada sucesión de Fibonacci es expresada en Fibonacci(1) que es un valor conocido.
Matemáticamente es expresado: Fibonacci(n) = Fibonacci(n-1)+Fibonacci(n-2)
Paso 3:
Diagrama de Actividades
Paso 4:
Implementacion en Java
Esta actividad permite el abordar problemas de manera sistemática. Haciendo de esta mas sencilla.
Autor:Angel Aedo Busto Competencia: Desarrollo de Software (Nivel 2) Palabras Clave: Programación, NXC, robótica, Lego, Mindstorm, Multitask.
A continuación les relato mi experiencia realizando el primer proyecto en la asignatura de Proyecto de Robotica. Aca implementamos multitareas.
Estrategia de Trabajo
. Una vez dada la actividad se presenta la inquietud del como abordar el problema. Es evidente la división de tareas entre los integrantes del grupo, pero esta vez solo hicimios división en las tareas secundarias, tales como la obtención de videos, armado del robot, entre otras. La principal tarea, la construcción de un algoritmo que nos permita la construcción de un código limpio y eficiente, la realizamos en conjunto, pues la implementación de instrucciones nuevas dificulta la creación de éste código. Está el uso de arreglos (array) que permite el almacenamiento de múltiples datos en una variable. La aplicación de arreglos nos dio la posibilidad de almacenar el puntaje obtenido por el robot sin la necesidad de usar una variable por cada vez que requiera almacenar puntaje.
.En la descripción del proyecto se pide que cuente puntos negros asignando un puntaje en función del tiempo que se demora en encontrar un punto, además evitar colisionar siguiendo instrucciones dadas en un nivel de ruido. ¿Qué ocurre si el robot recibe una instrucción de evitar una colisión y durante pasa sobre un circulo negro?. La lógica de lo usado anteriormente podría llevar a perder ese circulo negro junto al puntaje que éste arroja. Para esto están las instrucciones Multitask, las cuales permiten ejecutarse al unísono. Ahora es posible ejecutar una tarea que le otorgue “oídos” al robot y otra tarea que le de “ojos” al robot, pero con la gran funcionalidad de ser usados al mismo tiempo.
.Con el conocimiento de los descrito pudimos en conjunto construir un código que faculta al robot de la posibilidad de contar puntos, esquivar obstáculos y además emitir un sonido durante la actividad, pero se generó un nuevo conflicto. ¿Que hará el robot si sus motores están en una instrucción de giro y una de las tareas entrega una instrucción de retroceso?. Para esta inquietud abordamos el uso de Mutex, instrucción que da la facultad de crear colas de trabajo. Así cuando se entrega una instrucción que da conflicto con otra, se realizará la primera que fue dada y solo una vez terminada esta, se realizará la siguiente.
.De este modo, como grupo abordamos el proyecto, cada uno de nosotros se convirtió en una tarea secundaria,obtención de material multimedia, armado, etc. Mientras realizábamos como grupo la tarea primaria, creación de código.
tarea Circulo() { ...Mientras sea Verdad ...{ ......SI SensorLuz ...... { .........Reproducir Sonido de encuentro .........Calcular variable t .........Si variable t es menor o igual a 10 .........{ ............Almacenar valor en un Arreglo .........} .........Si variable t es mayor a 10 .........{ ............Almacenar 0 en el Arreglo .........} .........Aumentar potencia en 10 .........Si potencia es igual o mayor a 100 .........{ ............potencia es igual a 100 .........} .........Girar sobre eje random grados .........tiempo_inicial = tiempo_actual ......} ...} }
tarea Final() { ...Apagar Motores ...Mostrar datos almacenados en Arreglo ...Mostrar total sumado de datos del arreglo ...Finalizar Todas las Tareas() }
tarea Main { ...Ejecutar tareas (Avanza, Circulo, Choque, Sonido) }
Conclusión
.La creación de una aplicación que ejecute labores simultáneas, permite, en este caso el poder mirar y escuchar a la vez. Sin esta implementación jamás se hubiese podido mirar un punto mientras se está girando por ejemplo. El uso de multirareas podrá facilitarnos el uso de multiples sensores que podrás ser usados al mismo tiempo. Sin embargo debemos ser precavidos y hacer uso de "Mutex", que nos permitirá armar colas de instrucciones, para que éstas no entren en conflicto. Un claro ejemplo de esta situación es en el uso de motores. Usando Mutex podremos crear tareas que hagan uso de los motores, sin que estos obtengan 2 instrucciones al mismo tiempo. .. Además implementamos el uso de Arreglos, que permite el almacenamiento de datos en una sola variable. Bastante útil cuando se requiere almacenar muchos valores, que al no ser usado en arreglo forzaría a la creación de demasiadas variables, que dependiendo del caso, puede que no sean suficientes o bien sean demasiadas.
Autor:Angel Aedo Busto Competencia: Desarrollo de Software (Nivel 1) Palabras Clave: Programación, NXC, robótica, Lego, Mindstorm, Pelea de Robot
Líder: Angel Aedo Busto
Multimedia: Angel Aedo Busto
Staff Apoyo: Felipe Leal Peña
Secretario: Felipe Leal Peña
Dado que nuestro grupo está compuesto por solo 2 integrantes las actividades fueron repartida solo en 2.
Introducción
Dada la temática del trabajo a realizar nos planteamos los desafíos a superar en estas 2 semanas. Se podría considerar que el uso de un robot pauteado facilita enormemente el avance en un trabajo, pues el armado está solo orientado a seguir un manual de instrucciones, como lo fue durante trabajos anteriores, sin embargo para esta actividad se propuso la libertad de armado del robot. Esta libertad presenta un gran número de desafíos puesto que durante el armado se debe evaluar el rol que cumplirá cada pieza lego en el robot, considerando su utilidad instantánea y las futuras. Además resulta muy complejo el armar un robot pensando que éste debe enfrentarse a otros con la misma característica de libertad de armado, lo queagrega otro factor de incertidumbrea la construcción.
Dejando de lado el armado, el siguiente desafío es la implementación de código.Para el desarrollo de esta actividad, creamos el pseudocódigo para dar pautas de creación del robot, sin embargo la implementación requiere de bastantes correcciones sobre todo en tiempos y potencias, pues en cada tipo de neumático la relación distancia/tiempo es distinta.
A continuación veremos en detalle, armado, código y las justificaciones de cada uno.
Diseño Del Robot, encargado Felipe Leal.
Una vez revisada la pauta del torneo decidimos que el robot debe tener una estructura sólida, que sea complicado de perder piezas pues esto descuenta puntaje. De muchos diseños que vimos, implementamos uno basado en la estructura de un huevo. Compacto pero muy resistente. Basados en esta idea se dio forma al robot.
Los motores fueron usados sin engranes porque la utilización de éstos, opuesto al concepto de engranes, reducían la potencia. Al ser expuestos a fuertes presiones solían desmontarse. Ambos motores fueron instalados en la parte superior del concepto huevo, sosteniendo la presión del Brick.
En la parte trasera se instaló el tercer motor para crear una garra, esto a modo de defensa por si un robot contrincante entraba en contacto con nuestro robot.Este motor garra estaba fuertemente ajustado a la estructura base del huevo a modo de no desprenderse. Se agregaron unas piezas de extensión para que el motor pudiera levantar al contrincante.
Frontalmente el robot fue armado con una plataforma diagonal para levantar a su oponente y éste perdiese tracción. En el extremo inferior usamos pequeñas piezas a ras de suelo que pudiesen penetrar estructuras a bajo nivel.
La posición de sensores fue en la cabeza, para detección de enemigo,sensor de luz en la base y sensores de impacto en la parte trasera.
Lateralmente solo usamos piezas de soporte para la estructura delantera, omitimos el agregado de artefactos pues al ser lucha sumo el primer encuentro era frontal, posteriores encuentro eran solo de empuje, y el robot estaría en constante movimiento como para considerar una parte débil el lateral.
Uso de Sensores, encargado Angel Aedo.
Nuestro robot usó 4 sensores.
1.Sensor de Luz: Este sensor era indispensable en el torneo de sumo, se encarga de detectar cuando el robot está a punto de salir de la arena. Mediante el sensor de luz ubicado en la parte inferior delantera del robot detectábamos cuando el robot estaba abandonando la superficie blanca y tomando posición en la superficie de riesgo que era la línea negra.
2.Sensor de Ultrasonido: Para nuestro robot la instalación del sensor de ultrasonido en la parte delantera del robot nos permitió reconocer cuando el robot contrincante estaba cerca. El no hacer uso de este sensor era hacer un robot ciego. Con el sensor puesto en la parte delantera permitió la aplicación de estrategia de ataque que más adelante es explicada.
3.Sensor de Impacto 1 y 2: La decisión de usar ambos sensores en la parte trasera del robot fue tomada considerando mayor precisión para la defensa. Es cierto que pudo usarse un solo sensor pero considerando el diseño de nuestro robot y su estrategia de defensa era más óptimo agregar ambos a modo de aumentar las probabilidades de detección de un contrincante.
Estos sensores permitían el accionar del tercer motor usado para una garra. Al activarse uno de estos sensores de impacto , se encendía la garra para dar comienzo a la rutina de defensa.
Patrón de Ataque y Defensa, encargado Angel Aedo
La estrategia usada para competir es bastante simple. Consiste en la detección usando el sensor de ultrasonido. Para esto al detectar un contrincante cerca, acelera de una potencia75 a una potencia 100, con esto comienza a empujar al contrincante. Si éste logra escapar del empuje, el robot nuestro vuelve a su potencia normal que es de 75. Mientras está empujando al oponente se espera que la barra diagonal instalada en la parte delantera del robot realice un levantamiento del oponente para que pierda tracción dejando que solo la masa de éste se interponga en el camino de llevarlo fuera de la arena de lucha.
Para la defensa se hizo uso de 2 sensores y un motor extra. Ambos sensores se encargaban de detectar la presencia del oponente mediante impacto. Una vez detectados se accionaba el motor extra, éste motor corría la suerte de brazo mecánico, el cual levantaba a su oponente con el mismo propósito del ataque, que el contrincante pierda tracción y que solo su masa se interponga en el arrastre, pues además de las acciones antes mencionadas, el robot al entrar en modo de defensa también retrocede a máxima potencia.
Explicación del código.
El código se compone de 3 subrutinas, las que permiten defender, atacar y reincorporar a la arena. Se asigna UMBRAL en 20 para que solo evalúe una superficie negra sin importar sombras.
El robot avanza en línea recta, al encontrarse en una superficie negra, retrocede por 0,4s, gira sobre su propio eje en 180º y vuelve a avanzar. Si mientras avanza detecta una presencia a menos de 10cm, avanza a máxima potencia mientras la presencia se encuentre a menos de 10cm. Si es impactado por atrás levanta la garra mientras retrocede. Cuando pierde contacto trasero reposiciona la garra a nivel del piso.
#define UMBRAL 20
sub defensa()
{
while(SENSOR_1 == 1 || SENSOR_4 == 1)//mientras el sensor impacto 1 o 4 se activa
{
OnRev(OUT_AC,75);
OnRev(OUT_B,100);
Wait(1000);//el robot retrocede y levanta la garra por1 segundo
}
OnFwd(OUT_B,75);
Wait(100); //se reposiciona la garra al salir del ciclo de levantar.
}
sub ataque()
{
if(SENSOR_2<10) //sin sensor detecta algo a menos de 10cm.
{
OnFwd(OUT_AC,100); //avanza a máxima potencia
}
}
sub reingreso()
{
Off(OUT_AC);//apaga motores
OnRev(OUT_AC,100);
Wait(400); //retrocede por 0,4s para tener espacio de giro
OnRev(OUT_C,100);
OnFwd(OUT_A,100);
Wait(720); //gira sobre propio eje en 180º
}
task main()
{
SetSensorLight(IN_3);
SetSensorTouch(IN_1);
SetSensorTouch(IN_4);
SetSensorLowspeed(IN_2);
while(true) //nunca acabará el ciclo
{
while (SENSOR_3 > UMBRAL)//hacer si esta en blanco
Análisis de Enfrentamientos, encargado Felipe Leal
Primer enfrentamiento.
Frente a nuestro primer rival nuestras ventajas se vieron bastante claras. El diseño usado para el ataque permitió que se hiciera uso de la barra diagonal, proporcionando pérdida de empuje en el oponente. El sensor de Ultrasonido al detectar presencia de un rival delante de él activó la instrucción de empuje a máxima potencia y una vez que el sensor de luz llegó al borde negro, se interpretó que no había más que empujar, pues el oponente ya estaba fuera de la arena de lucha.
Segundo enfrentamiento.
Con el segundo oponente no tuvimos oportunidad de implementar la barra diagonal dado que el ataque fue iniciado con el oponente apuntando a un borde nuestro, en el cualse encontraba desprotegido el motor de tracción. Sin embargo un error en la programación del rival nos dio la victoria, ya que éste era incapaz de dejar de empujar si llegaba al borde de la arena.
Recién en un segundo encuentro con este oponente se hizo uso de la rutina de defensa, la cual levantó al oponente dejando sin tracción momento en el cual el robot comenzó a retroceder para dejar fuera de la arena al oponente.
Tercer enfrentamiento.
Notablemente en el primer asalto vimos en desventaja nuestro robot, pues apostamos a que todo contrincante no haría uso de engranes en las ruedas, pero omitimos el diseño de éstas. Frente al robot oponente, capaz de una mayor aceleración y una masa de mayor magnitud no funcionó el concepto de barra delanteradiagonal para levantar al rival.
Durante nuestro segundo asalto, el hecho de realizar una estructura basado en un huevo nos dio la ventaja, pues al enredarse nuestro oponente con nuestra garra perdió un motor de ataque.Esta estructura solida y compacta frente a una estructura amplia pero poco solida dio frutos a favor nuestro.
Finalmente en el asalto 3, el diseño compacto y la cantidad de potencia en el ataque nos dio la desventaja. El realizar un ataque a máxima potencia sin haber agregado unas barras estabilizadoras generó que el robot se volcara quedando expuesto casi sin presentar resistencia al empuje del oponente.
Conclusión
General: Fue un gran desafío el hacer uso de todo lo aprendido hasta el momento, implementar el uso de múltiples sensores, uso de subrutinas, etc.
La libertad de modelación del robot agregó un factor sorpresa al desarrollo de la actividad, pues no tan solo hacía considerar que el desarrollo del robot debía ser considerando la libertad de los oponentes también.
Diseño del Robot: Si bien la creación de un robot puede ser asistida por manuales, es una enorme la cantidad de factores que influencian en esta creación. Para el caso de nosotros decidimos apostar por un diseño sencillo y compacto a modo de proteger la pérdida de piezas en la lucha de sumo. El posicionamiento de las piezas de ataque y defensa fueron fundamentales. Nuestro enfoque fue a ataque delantero y defensa trasera.El uso de sensores protegidos presentó un gran desafío, pues debían ser funcionales y además no perderse en un enfrentamiento.
El desempeño en este aspecto cumplió gratamente nuestras expectativas, sin embargo era demasiado amplio el rango de ataques y modos de defensa de los robots contrincante.
Uso de Sensores: Fueron usado los 4 sensores permitidos. El sensor de luz, para evaluar la condición de estar dentro de la arena, implementado en la parte inferior delantera. Además se usó el sensor de ultrasonido para darle vista al robot y sea capaz de ver al oponente delante de él. Y se usaron 2 sensores de impacto para que el robot se entere que hay un contrincante en su parte trasera y con esto activar su modo de defensa.
Patrón de Ataque y Defensa: Tanto el ataque como la defensa estuvieron orientados a que el contendiente perdiera tracción, para el ataque mediante una barra diagonal y para la defensa con una garra de levante. Ambos resultaron ser eficientes con rivales de similar tamaño, más no con un rival de mayor masa.
Análisis de Enfrentamientos: Tanto para nuestra primera y segunda batalla, la ventaja fue el diseño y estructura del robot y el código implementado.Ya que los 3 robot tenían una masa muy similar, y estructura de desplazamiento idéntica, motores paralelos, tracción delantera y ruedas del tipo All Terrain. Para estas 2 batallas el código se comportó según lo esperado.
Con el rival final vimos la desventaja de no usar más peso y no considerar otro diseño de ruedas y el no agregar barras estabilizadoras, lo que provocó el volcamiento de la derrota.
La sencillez del código facilitó que éste se comportara como teníamos presupuestado, sin generar instrucciones confusas.
