10.08.2005

Proyecto fin de carrera

Hace unos meses que ya tengo asignado un PFC, pero hasta estos días no me he puesto en serio con él. El proyecto trata sobre algo que ha estado ligado a mi vida desde que era pequeño, la agricultura. Mis dos abuelos y mi padre han sido agricultores toda su vida y he visto miles de veces sacar el tractor del la "cesoria", ir con el remolque a buscar kilos y kilos de cebada con el sol dandonos en la colleja, llevar los arados de vertedera, el cultivador, la sembradora de girasol, la tolva del mineral... y una larguísima lista de aparejos propios de la labranza. Todos ellos son máquinas, a mi modo de ver, muy rudimentarias y basadas en la experiencia más que en la ciencia, sin embargo hacen su labor. Nunca me había parado a pensar en si con la informática u otras tecnologías se podría mejorar eso, sin embargo al ver la propuesta de proyecto del que he elegido y con las explicaciones de mi tutor me quedé asombrado de la aplicación que tiene la tecnología a la agricultura.

El proyecto trata sobre la creación de una herramienta de guiado para el agricultor en trabajos como abonar o echar fertilizante. Mediante un PocketPC, los datos aportados por un GPS y el software que yo debo crear el agricultor recibe información de la dirección que debe tomar así como del área de parcela ya tratada.

Actualmente me encuentro en la segunda fase, me he documentado y acabo de pasar a la acción y, como no, me encuentro con los primeros problemas. El primero es la petada del GPS que me habían dejado, de un día para otro dejó de darme datos sin ton ni son y así sigue :(. No dejaría de ser un problema menor si no fuera porque el otro GPS que me han dejado no permite otra alimentación que no sea de 12 voltios (la alimentación del mechero de un turismo). Con el que se ha roto podía ir por la calle andando ya que se alimentaba con la batería del PocketPC, pero con este no y esto significaba que no podría hacer pruebas.

Menos mal que he programado bien los interfaces y tengo in interface hacia la informaión del GPS, sin embargo nada me impide implementar ese interface con una clase que lea de otro dispositivo , como no, de un socorrido fichero. Manos a la obra, creo un "recorder", esto es, una clase que grabe en "disco" (en pocket PC decir disco es mucho decir) y la aplico a la clase reader del GPS. Posteriormente coloco el pocketPC y el GPS en mi "peugeot 205 mito diesel" (una joya de coche) y me voy a la plaza de mi pueblo a simular unas cuantas pasadas de tractor abonando. Tras hacer varias pasadas, marcar diferentes puntos en el fichero para tener referencias, ir más rápido, más despacio vuelvo a casa, saco los datos del pocketPC, los paso al emulador de PocketPC, cambio el interface GPS por el interface Fichero y voila, ya tengo una simulación fiel a la realidad.

De esta manera podré probar toda la semana que estoy sin coche sin tener que moverme de casa.

Por último dejo una imagen de la aplicación que he usado para guardar los datos.. :).



* creo que el verdadero término es accesoria, referido a que es una puerta grande por la cual pueden entrar de todo, sin embargo toda la vida lo he llamado cesoria.

7 comentarios:

Anónimo dijo...

es muy interesante. y un sector poco explotado. adelante!
lo unico que parece q vas un poco rapido. echale un ojo a los fundamentos de ing. de software de somerville y a algunos articulos de extreme programming. es poco tiempo ( 1 o 2 dias) y te ayudara un monton con la ingenieria de requerimientos

saludos

Javi Santana dijo...

Ok, gracias por las referencias, aunque no creo que vaya tan rápido, en estos meses me he docuemntado sobre el funcionamiento del GPS y he estado haciendo pequeñas pruebas.

El programa que he hecho no tiene demasiada complicación, símplemente tiene algunos interfaces definidos que son muy comunes (stream, streamreader, etc) y, aunque no sigo al pie de la letra UML, si que tengo los diagramas de la aplicación en mis hojas de apuntes de al lado del PC :).

Otro aspecto que tengo que destacar de la aplicación es que es muy similar a un videojuego en red. En un videojuego habitualmente se tiene un bucle en el que se toman entradas, se actualizan las entidades y se renderizan. En este caso es lo mismo, sin embargo tenemos una latencia debida a que el GPS solo se actualiza a 1 Hz. Es fácil ver que esto se asemeja a la latencia producida por la red. Por todo esto también puedo usar los patrones que se usan a la hora de programar videojuegos.

Es muy cierto que los telecos, a pesar de tener que hacer muchas veces software, apenas nos dan nociones de ing de software. En ese aspecto la carrera cojea.

un saludo

Anónimo dijo...

Con la ingenieria del software no me referia tanto a UML. De hecho el libro de Somerville apenas lo menciona, salvo los casos de uso en la parte de requerimientos. Es sobre todo por la calendarizacion, la distribucion del trabajo y la concrecion de requerimientos (muy importante tenerlos totalmente definidos al principio). Es poco esfuerzo de leer, pero merece mucho la pena. Solamente separar e implementar en orden los requisitos funcionales y no funcionales te va a venir muy bien, porque los proyectos fin de carrera a veces no es necesario terminarles. Si se alarga mucho pero ya has has hecho tu trabajo puede terminarlos otro.

Y la programacion extrema es porque al trabajar tu solo, si lo haces orientado a test seguramente te ahorraras tiempo de pruebas, que es aburrido-aburrido-aburrido.

Otra cosa. Que es eso de los patrones para videojuegos? son exclusivos, orientados a objetos,...? nunca me han interesado los vj,sobre todo porque no he sido jugador, pero con la pasta que se mueve en ese mundo no viene mal saber algo.

saludos

Javi Santana dijo...

En los videojuegos hay una serie de patrones que se repiten muchísimo, como por ejemplo el bucle principal de la aplicación, el tratamiento de las escenas (scenegraph), etc.

Por ponerte un ejemplo que viene bastante a cuento, el bucle principal de la aplicación. En un videojuego, como comentaba, siempre tienes una entidades que debes mover y renderizar y siempre se usan las mismas fórmulas. En este caso hay dos, la que usa el delta de tiempo transcurrido desde la última iteración o tener un tiempo fijo de iteración (http://www.iguanademos.com/Jare/Articles.php?view=FixLoop). Salvo cosas muy concretas siempre se usan las mismas técnicas (es la palabra correcta mejor que patrón).

Para casi todos los aspectos del juego hay una forma de hacerlo, supongo que cada área tendrá sus técnicas bien definidas que mejoran bastante la vida del programador. Quizás haya usado mal la palabra patrones donde tendría que haber ido la palabra técnica.

En cuando a lo del extremme programmging estoy echando un vistazo a la web y a ver si mañana miro algo del autor que me comentas. Parece muy interesante lo de programar orientado a test. Muchas gracias por la ayuda :)

Anónimo dijo...

Miguel, no se en que Universidad has hecho los pfc, pero en la mia no hay nada que se parezca a un pliego donde se especifiquen los requisitos y un posterior documento donde se detallen las especificaciones del producto, asi que es realmente dificil aplicar lo que comentas.

Anónimo dijo...

¿unas cuantas pilas y un enchufe adecuado no te solucionarían la papeleta del GPS?

Javi Santana dijo...

Sí, pero ya empieza a ser un rollo tener que andar con pilas y demás. Además con el mecanismo que he creado es mucho más ecológico, no gasto nada :)