Repository navigation
Conclusiones
En este apartado se relatara los inconvenientes aparecidos durante la realización de este proyecto y que deben de servir como lección para futuros proyectos. El autor de este documento reconoce, que debido a ser el primer proyecto al que se enfrentaba, el modo de actuación a la hora de ejecutar el proyecto no ha sido de los más correctos.
Para empezar, el autor de este proyecto una vez con una idea en la mente, pero no demasiado desarrollada, empezó con la realización de pruebas y la adquisición de algunas materiales para probar su validez en el proyecto. Se empezó a programar una aplicación modelo y se ideo como se complementaria.
Recuerdo al lector, que se trata de un proyecto con fines didácticos, por lo tanto el autor del proyecto y el que lo recibe (en cierto modo) es el mismo. Esto hace que la tarea de elaboración del proyecto sea lenta y este en constante evolución. Aquí es donde reside el primero fallo del autor. El autor debería haber trazado un modo de ejecución, es decir, investigar y elaborar un calendario, comprobar de un modo más extenso las futuras herramientas usadas.
El sensor HC-SR04 del que se ha hablado y aportado documentación técnica en este proyecto, como ya se ha mencionado, se trata de un sensor de ultrasonidos, que a niveles prácticos, es ideal en varios sentidos, tanto económico, sencillez de manejo, tamaño y fácil montaje. Pero que posee un problema grave debido a que se tratan de ondas mecánicas. En el caso de la maqueta del parking, si se estacionaba un vehículo con una formas determinadas, esto podía provocar un rebote de las ondas erróneo o mal dirigido a otros sensores, por lo que es un factor a tener en cuenta, además, de que se necesita de un objeto que tenga una gran superficie para el correcto funcionamiento. Por supuesto, a nivel de maqueta se solventa sabiendo exactamente la altura a la que se encuentra el sensor y por lo tanto, obligando a dar como ocupada la plaza en el momento que no se de esa medida exacta.
El sensor TCRT 5000/5000L usado como sensor de plaza también, al igual que el HC-SR04, en la maqueta funciona correctamente, pero si se quiere extrapolar a otra situación, se trata de un sensor de poca capacidad, llegando solo a los 2mm de detección. Además, al tratarse de un sensor de IR, su comportamiento varía con ciertos colores, como el blanco o el negro, dando unas lecturas distintas.
El cableado en este proyecto, no tiene demasiada importancia en cuanto a estructura u ordenación, pero hubo ciertos momentos en los que se volvió tedioso debido a que un simple fallo, se volvía muy complejo de encontrar debido al gran volumen de conexiones. Uno de estos casos lo provoco el conexionado de la pantalla LCD, que cuenta cerca de 8 cables solo para su funcionamiento.
La elaboración de la interfaz fue relegada a las últimas semanas, el autor asumía que no supondría ninguna dificultad (grave error). Si nos ponemos en situación y recordamos que la aplicación usada para la creación de la interfaz es C++ Builder 6, una aplicación del año 2002 junto a la librería CPortLib, gratuita pero desatendida desde el 2004, nos encontramos en un punto que no preví. Para empezar, la falta de documentación para complementar la librería provoco complicada la realización de la comunicación serie. Esto provocó que el autor del proyecto, tuviera que mal decir al cielo y hacer herejías con el lenguaje de programación que usaría la interfaz para conseguir medianamente un resultado satisfactorio.
Se va a mencionar ciertas alternativas que se pensaron, aunque podría haber mejorado las prestaciones del proyecto y otras se desecharon por reducir la saturación.
Empezare por las opciones que se desecharon. Hay varios sensores que se barajaron para incluir en el proyecto, entre ellos se encuentran los siguientes:
- Sensor de humo o CO2
- Sensor de proximidad
- Sensor de movimiento
- Sensor de presión
- Sensor de sonido
- Motor para elevación de la barrera
En el caso del sensor de humo o C02, siendo una maqueta, se hubiera ideado algún método de introducción de humo para la comprobación de datos, pero la principal causa de desecharlo, es su baja complejidad y sobre todo similitud con el sensor DHT-11 de temperatura.
En el caso de los sensores de proximidad, movimiento y presión, no tenían cabida en este proyecto, debido a que se trataba de detectar un objeto inmóvil, de gran tamaño y que fuera viable su exportación a la vida real.
Para la mejora del sistema de detección de las plazas, se pensó en un principio en sensores IR de haz, donde la detección seria de mayor calidad, aunque este sistema era caro, aunque sería una gran opción si se decidiera trasladarlo a la vida real.
Las alternativas a la placa Arduino eran varias. El motivo por el que se optó por Arduino fue por su precio económico y por haberse utilizado en el grado, lo que ayudaba a ampliar los conocimientos adquiridos.
-
Raspberry Pi se trata de una diminuta placa base de 85 x 54 milímetros (un poco más grande que una cajetilla de tabaco) en el que se aloja un chip Broadcom BCM2835 con procesador ARM hasta a 1 GHz de velocidad, GPU VideoCore IV y hasta 512 Mbytes de memoria RAM.
-
BeagleBone tienen un procesador ARM A8 cortex a 700 Mhz y una memoria RAM de 256 MB. Mide 9 cms de largo y 5,5 cms de ancho, lee tarjetas microSD, tiene un puerto USB para conectar un periférico o utilizarlo como fuente de energía, un micro USB para conectarlo a otro ordenador, un conector Ethernet y un conector RJ45. En estos momentos hay dos modelos de placa, la BeagleBone Clásica, de 89 dólares, y la BeagleBone Black, algo más barata. Como BeagleBone funciona con Linux, cualquier desarrollador puede hacer su propio software en una gran variedad de lenguajes: C, C++, Java, Python, Ruby, PHP, Javascript, Node.js… Además es compatible con otros sistemas operativos como Android, Ubuntu o Debian. Las posibilidades son enormes.
