Hoy me
llegó un email de Strava, me invitaban a revisar mi año con la bicicleta, no me
di tiempo para leer el contenido, directamente lo borré. Este año no fue de los
mejores, comencé con mucho ánimo, tratando de superar ese miedo inicial que uno
tiene al transitar por las calles paceñas, ese miedo que a medida que se van
recorriendo kilómetros va disminuyendo lentamente, aunque nunca desaparece.
Enero, febrero y marzo fueron buenos, cumplí con los retos que Strava
publicaba, todo estaba bien, la bicicleta con algunas pequeñas dificultades mecánicas,
pero bien. Ya para el segundo trimestre la cosa se complicó, la medicación para
contrarrestar la gastritis degradó mi ánimo, y entré en un estado de letargo,
así permanecí gran parte del año, una que otra salida esporádica. Por agosto,
Intenté llegar al Chacaltaya, pero aún no estaba listo, abandoné a la mitad del
trayecto y la bicicleta ya comenzaba a pedir atención, con ruidos extraños que
se emitían al pedalear. El día del peatón acompañé a unos amigos hasta Calamarca,
140 km de pedaleo, lo logré pero me duró una semana reponerme. Intenté
Tahupalca – Molino Andino, antes del Yolosa la Cumbre, del que no participé, y
tampoco lo logré, me quedé en Mallasa. Ese fin de mes llevé mi bicicleta al
mecánico y yo fui al doctor para mi evaluación, me sentía mejor, pero la bici
no, requería partes o un reemplazo de todo el sistema de tracción. Una tienda
cochabambina que contacté por Internet, tenía la solución, pasar del Shimano
Acera al Deore, pasar 3x8 a un 3x10, sonaba tentador, aunque el precio
desalentador. Estuve un mes con esa duda, y mientras me decidía, volví a la
rutina del Spinning; comencé a ver vídeos de entrenamiento y a leer algunos
libros, pero aún no me sentía listo para volver a las carreteras. A inicio de octubre me llamó el vendedor, preguntando si aún estaba interesado en el
Deore, le dije que sí y realicé el depósito, a los dos días estaban los
repuestos en casa y listos para ser instalados. Con la ayuda de un técnico amigo
pude concretar el cambio tecnológico y ese fin de semana, salí nuevamente a
pedalear, nuevamente los miedos, pero esta vez ganaron las ansias, los deseos
de sentir una pasión. Es noviembre, aumenté la frecuencia del Spinning, lástima
que Strava no lo registre, pero ya me sentía mejor y fui un par de veces a
Pongo, desde Kalajahuira. Hace dos semanas leí la convocatoria tradicional de
fin de año, pedaleo hasta Copacabana. Ya son dos años que no llegó a
Copacabana pedaleando, sea por fallas mecánicas o físicas, pero no he vuelto a
completar el recorrido, pero más me sorprendió la cantidad de ciclistas que
querían participar, hasta el martes eran 60 y para el día domingo bordeamos los
100. El recorrido hermoso, como siempre, la carretera vacía, solo el ruido de
las cubiertas contra el asfalto, el espléndido lago Titicaca a la derecha, fenomenal,
fueron tres horas intensas, un muy buen tiempo para 70 km desde la escuelita de
Achacachi hasta Tiquina, aunque los últimos tres kilómetros tuve que pedalear
contra el viento y la lluvia, esa lluvia que nos impediría cruzar el estrecho y
continuar con el camino hacia el Santuario de Copacabana. Cierro este 2016 sin
poder completar el recorrido, aunque muy feliz, por encontrar lentamente mi
ritmo, en sentir que el cambio de sistema mecánico fue el acertado y sobre todo
de poder superar, de a poco, ese letargo en el que te sumerges después de
tantos meses de inactividad. Espero volver a pedalear este fin de semana, ya
casi comienzan mis vacaciones y tengo planes de volver a la pista de BMX,
volver… volver… y volver.
martes, 6 de diciembre de 2016
jueves, 27 de octubre de 2016
PROYECTOS “PLUG AND PRAY”
Con el
lanzamiento de Windows 95, se introdujo un innovador concepto, el denominado
“Plug and Play”, donde se intentó potencial al sistema operativo con la
capacidad de configurar automáticamente los dispositivos al momento de ser
conectados a la computadora, buscando que la nueva tarjeta pueda ser utilizada
inmediatamente después de ser instalada, aspecto que no debe confundirse con
que se requiera la instalación de programas controladores, los que, en la
mayoría de los casos, podrían ser instalados y configurados automáticamente por
el sistema operativo.
Antes de la
aparición de este concepto del “Plug and Play” o PnP, se debían realizar una
serie de pasos previos para que la nueva tarjeta pudiera ser identificada por
el sistema operativo, y si esto era satisfactorio, se procedía con la instalación
de los controladores; si salía bien, recién era posible la configuración de la
aplicación que sería empleada para su utilización.
La
configuración del hardware consistía, casi siempre, en una definición de la dirección
de interrupción IRQ, que a veces, ya estaba reservada para otro dispositivo
previamente conectado entonces, se tenía que definir en la nueva tarjeta otra
dirección de interrupción, lo que se realizaba generalmente a través de Jumpers o Dip Switch que disponían. Se
repetía el proceso hasta que la tarjeta no ocasionara conflictos de
interrupción. Esos tiempos ya son historia, y hoy en día solo es necesario
conectar el dispositivo a la computadora y esperar a que el BIOS y el Sistema
Operativo hagan su trabajo.
Al igual que
la tecnología PnP, se fueron desarrollando otros nuevos recursos, a los cuales
los estudiantes tienen acceso, dispositivos que les permiten realizar sus
proyectos de fin de semestre, proyectos a ser presentados en las ferias de
tecnología o quizás para sus proyectos de grado. Una de esas placas de
desarrollo es Arduino.
Con Arduino,
llegaron al mercado muchos otros productos como son: sensores, sistemas de
comunicación, transductores y dispositivos de registro de datos, todo un
universo diseñado para esta revolucionaria placa de desarrollo, con lo que las
posibilidades, para realizar los proyectos más ambiciosos, se hacen posibles
gracias a la disponibilidad de estos recursos, los cuales son relativamente
accesibles en nuestro medio.
En los últimos
años, el uso Arduino se fue volviendo más frecuente, gracias a
esta placa de desarrollo, es posible realizar una serie de trabajos que van
desde un simple sistema de registro de temperatura hasta otros muchísimos más
complejos dentro del campo de la robótica, el control electrónico y también en
las telecomunicaciones, dependerá de la iniciativa que tenga el estudiante.
Desde todo
punto de vista, el empleo de Arduino como herramienta educativa y demostrativa
es ventajosa. “Hasta tesis de doctorado se han desarrollado con Arduino” indicó
un docente colega, no estoy seguro de que llegue hasta ahí pero, vale la pena
darle el crédito.
Aunque no todo
lo que brilla es oro, debemos también resaltar los aspectos negativos que trajo
consigo la utilización de estas nuevas herramientas electrónicas y
lamentablemente está el hecho de que los estudiantes desarrolladores de
proyectos, ahora se conforman con solo conectar las piezas que conforman el
esquema que encontraron en la red y luego transferir el programa que
seguramente, también estuvo disponible en el mismo sitio de donde descargaron
el experimento, lo que se ha convertido en una especie de ritual, el que inicia
con la compilación del código fuente, donde con los dedos cruzados esperan que
el IDE no muestre un mensaje de error y que este proceso se realice de la forma
esperada, ya que, los estudiantes, no todos obviamente, desconocen el
funcionamiento del algoritmo, las características de las señales que recibirá
Arduino, su tratamiento ó conversión si fuese el caso, al final se esperaría
que sea una suerte de Conectar y Usar, como el Plug and Play de los años 90, con la salvedad de que ahora es un
Conectar y Rezar (Plug and Pray),
rezar por que compile, rezar porque transfiera, rezar porque funcione como
indicó el video en YouTube o la página encontrada en Google, rezar porque el
docente no pregunte cómo y por qué, al final un rosario de súplicas para que
Arduino y todos los sensores conectados hagan lo que alguien en el otro lado
del mundo dice que lo logró, para de esa manera salvar la materia, el semestre
y quizás hasta la carrera.
No estoy en
contra de la consulta de las fuentes o la reutilización de recursos disponibles
en la red, lo que no comparto es esa simpleza de copiar y pegar, de descargar y
mostrar, de ver y repetir. Debería existir una etapa intermedia, la cual no
está, por ahora, disponible en Internet, que es el razonamiento, esa etapa tan
importante para un Ingeniero Electrónico esa de emplear los modelos
matemáticos, ecuaciones de transferencias, los diagramas de estado y tanto
recurso necesario para entender, razonar y sustentar lo que se pretende
demostrar.
El Plug and Pray no alcanza, no es
suficiente, aún los libros y las ecuaciones matemáticas están de moda y por
ahora habrá que realizar algunos cálculos previos que, validen el código
empleado, los dispositivos seleccionados y sobre todo la lógica de
funcionamiento.
miércoles, 18 de mayo de 2016
Alarma de proximidad de vehículos
Me gusta pedalear, disfruto de pedalear pero pedaleo muy de mañana por mi seguridad. Lamentablemente La Paz, es una ciudad que aún carece de educación vial; los ciclistas somos vistos, por la mayoría de los chóferes, como personas quienes invadimos su espacio, es así que, se aproximan con sus automóviles, nos cierran el paso, tocan sus bocinas y hasta nos gritan indicando que la calzada es sólo para vehículos y que la acera es para las bicicletas, una idea totalmente equivocada.
El año pasado sufrí un accidente, con mucha suerte, esa mañana me encontró un vehículo que sobrepasaba el límite de velocidad y me golpeó, lanzándome al pavimento, gracias a Dios no pasó otro automóvil por detrás, pero lo más triste fue que el conductor no se detuvo tras el incidente, simplemente siguió su camino. Esto sucedió a tan solo metros de una estación de Policía, los uniformados tampoco hicieron nada al respecto.
Me esta costado superar el incidente, aun pedaleo con temor, trato de ir por lugares menos transitados o me uno a las pedaleadas que planifican mis amigos ciclistas, también mi familia se vió afectada, y sé que se preocupan cuando demoro en mi retorno.
Hace un par de meses, leí un artículo en Internet, sobre los sistemas de alarma de proximidad para motocicletas, dispositivos que se utilizan principalmente en las competencias a campo traviesa, como es el Dakar, y es a través de estos equipos, que se informa al piloto sobre la cercanía de un vehículo y que debe hacerse a un costado para evitar un accidente. Inspirado en ese artículo, decidí diseñar un sistema que cumpla con un objetivo similar, indicar la proximidad de un vehículo cuando el ciclista se encuentre pedaleando en una calle, avenida o carretera.
Durante varias semanas estuve diseñando, programando y ensamblando mi primer prototipo, el cual constaba de un sensor ultrasónico, que brinda una cobertura de 5.5 metros y un microcontrolador el que estaba encargado de generar las alarmas, no funcionó de forma correcta, faltaba más precisión, los reportes eran aleatorios y otros inconvenientes, entonces recurrí a una pequeña placa Arduino y para poder verificar el funcionamiento mientras pedaleaba, acoplé un módulo Bluetooth, y a través de este enlace inalámbrico podría conocer la distancia de un vehículo en la pantalla del celular.
Fueron varios días de pruebas, corrección de errores, cálculos y recálculos los que me llevaron al prototipo funcional que tengo ahora, además, desarrollé una aplicación para el celular, por ahora, solo disponible en equipos con sistema Android, donde no solo se despliega la distancia del vehículo próximo sino que también, se envía una alarma sonora al audífono, esto es muy útil para aquellos ciclistas quienes escuchan música mientras realizan sus recorridos. Un amigo me escribió indicando que sería bueno que el dispositivo tome una foto, quizás lo haga más adelante.
El fin de semana saldré a pedalear con el prototipo instalado en mi bicicleta y en algunos días más, construiré otros dos dispositivos para entregarles a mis amigos de ruta, con el objetivo de que puedan probarlo, deseo conocer sus impresiones y recomendaciones, las que me ayuden a mejorar el prototipo y contar con un equipo óptimo que nos alerte de la proximidad de vehículos, y de esta manera, retirarnos de su paso, tratando de evitar algún accidente en la carretera.
El año pasado sufrí un accidente, con mucha suerte, esa mañana me encontró un vehículo que sobrepasaba el límite de velocidad y me golpeó, lanzándome al pavimento, gracias a Dios no pasó otro automóvil por detrás, pero lo más triste fue que el conductor no se detuvo tras el incidente, simplemente siguió su camino. Esto sucedió a tan solo metros de una estación de Policía, los uniformados tampoco hicieron nada al respecto.
Me esta costado superar el incidente, aun pedaleo con temor, trato de ir por lugares menos transitados o me uno a las pedaleadas que planifican mis amigos ciclistas, también mi familia se vió afectada, y sé que se preocupan cuando demoro en mi retorno.
Hace un par de meses, leí un artículo en Internet, sobre los sistemas de alarma de proximidad para motocicletas, dispositivos que se utilizan principalmente en las competencias a campo traviesa, como es el Dakar, y es a través de estos equipos, que se informa al piloto sobre la cercanía de un vehículo y que debe hacerse a un costado para evitar un accidente. Inspirado en ese artículo, decidí diseñar un sistema que cumpla con un objetivo similar, indicar la proximidad de un vehículo cuando el ciclista se encuentre pedaleando en una calle, avenida o carretera.
Durante varias semanas estuve diseñando, programando y ensamblando mi primer prototipo, el cual constaba de un sensor ultrasónico, que brinda una cobertura de 5.5 metros y un microcontrolador el que estaba encargado de generar las alarmas, no funcionó de forma correcta, faltaba más precisión, los reportes eran aleatorios y otros inconvenientes, entonces recurrí a una pequeña placa Arduino y para poder verificar el funcionamiento mientras pedaleaba, acoplé un módulo Bluetooth, y a través de este enlace inalámbrico podría conocer la distancia de un vehículo en la pantalla del celular.
Fueron varios días de pruebas, corrección de errores, cálculos y recálculos los que me llevaron al prototipo funcional que tengo ahora, además, desarrollé una aplicación para el celular, por ahora, solo disponible en equipos con sistema Android, donde no solo se despliega la distancia del vehículo próximo sino que también, se envía una alarma sonora al audífono, esto es muy útil para aquellos ciclistas quienes escuchan música mientras realizan sus recorridos. Un amigo me escribió indicando que sería bueno que el dispositivo tome una foto, quizás lo haga más adelante.
El fin de semana saldré a pedalear con el prototipo instalado en mi bicicleta y en algunos días más, construiré otros dos dispositivos para entregarles a mis amigos de ruta, con el objetivo de que puedan probarlo, deseo conocer sus impresiones y recomendaciones, las que me ayuden a mejorar el prototipo y contar con un equipo óptimo que nos alerte de la proximidad de vehículos, y de esta manera, retirarnos de su paso, tratando de evitar algún accidente en la carretera.
domingo, 10 de abril de 2016
SIMULINO CONECTADO A LABVIEW VÍA ETHERNET.
Ing.
Ramiro Vladimir Mora Miranda
RESUMEN:
Son diversos los prototipos que actualmente
emplean placas tipo Arduino, como instrumento principal para su desarrollo. Estas
placas, también son empleadas en la adquisición de datos reales, con el fin de
ser evaluados o tratados por un programa CAD, como Labview. Es posible simular
un dispositivo Arduino, en el programa Proteus, mediante la librería denominada
Simulino y que este circuito simulado, se conecte de forma remota y virtual con
otra aplicación desarrollada en Labview, lo que permitirá la evaluación a
distancia, de una propuesta, sin la necesidad de adquirir componentes
electrónicos adicionales, reduciendo significativamente el costo y tiempo
empleado en un proceso de diseño, que en algunos casos, requiere de
dispositivos reales que no siempre se encuentran disponibles.
PALABRAS CLAVE: Arduino, Labview,
Proteus, Simulino, Ethernet.
1 INTRODUCCIÓN
Trabajar con programas
para el Diseño Asistido por Computadora (Computer
Aided Design – CAD) Electrónicos, ofrece muchas ventajas; una de las más
significativas es la disponibilidad de contar con un grupo innumerable de
instrumentos y dispositivos, a los que no se acceden fácilmente, ya sea por su
carencia en el laboratorio o la ausencia del producto dentro del mercado local,
sin mencionar la cantidad de recursos económicos que demandarían su
adquisición. Es por esta razón que, tanto estudiantes como docentes de las
carreras de Ingeniería de Sistemas Electrónicos, Telecomunicaciones, Mecatrónica
y otras, realizan los diseños de sus circuitos electrónicos empleando estos
programas informáticos, que hoy en día, alcanzaron una mayor precisión y
confiabilidad.
Por otra parte, está
Arduino, que es una plataforma de hardware de código abierto, basada en una
sencilla placa con entradas y salidas, analógicas y digitales. Es un
dispositivo que permite la conexión entre el mundo físico con el mundo virtual,
o el mundo analógico con el digital. Arduino, se está convirtiendo en uno de
los instrumentos, cada vez más, utilizado en las actividades académicas y
profesionales dentro del campo de la Ingeniería Electrónica. Arduino, en sus
diferentes versiones, aporta de una manera importante al desarrollo de un
proyecto y si a esto se añade la disponibilidad de una gran cantidad de
sensores, actuadores y otros dispositivos, acondicionados especialmente para
este tipo de placas, se obtienen prototipos con altas prestaciones de calidad,
confiabilidad y rendimiento.
Los sistemas CAD
electrónicos no podían ignorar este avance tecnológico en base a Arduino, y es
por eso que programadores independientes, desarrollaron librerías para simular
estas placas. Es el caso de la librería Simulino para Proteus, que pone a
disposición del usuario, una gama amplia de placas Arduino (Nano, Uno y Mega),
además de proporcionar el simulador para el sensor ultrasónico HC-SR04.
Son diversas las
universidades que adquieren licencias del programa Labview y las ponen a
disposición de los estudiantes y docentes para el desarrollo de sus actividades
académicas y proyectos de investigación. LabVIEW (acrónimo de Laboratory
Virtual Instrumentation Engineering Workbench) es una plataforma y entorno de
desarrollo para diseñar sistemas, con un lenguaje de programación visual
gráfico, recomendado para sistemas hardware y software de pruebas, control y
diseño, simulado o real y embebido.
Existen varias
experiencias en cuanto a la adquisición y procesamiento de datos empleando
Labview y placas Arduino. Sin embargo, algunos proyectos requieren de dispositivos
específicos y, en ocasiones, complica el desarrollo de estos proyectos las
limitaciones técnicas y tecnológicas de los laboratorios. Es a este
inconveniente que el presente trabajo pretende dar una solución; a través de la
simulación, en Proteus, de un circuito electrónico que emplee Arduino, para la adquisición
y procesamiento de datos a cargo de un programa Labview, que radicará en una
computadora distinta y distante; ambas computadoras estarán conectadas vía
Ethernet.
2 SIMULACIÓN DE ARDUINO EN PROTEUS
Una etapa importante en
el desarrollo de un proyecto, es la del diseño. Proteus, es una de las muchas
herramientas informáticas que existen para este efecto. Se seleccionó Proteus,
debido principalmente a que el programa permite la simulación de placas
Arduino, a través de la instalación previa de las librerías adecuadas, en este
caso las denominadas Simulino.
El procedimiento para la
instalación de Simulino, en Proteus, es muy sencillo, solo se deben copiar los
archivos Arduino.lib y Arduino.idx en la carpeta Library, en el lugar donde se instaló el programa Proteus, de esta
manera Arduino, estará disponible dentro de la enorme lista de componentes
virtuales que ofrece Proteus.
En
http://www.instructables.com/id/How-to-add-Arduino-Library-in-to-Proteus-7-8/
se explica con detalle el procedimiento para la instalación de Simulino en
Proteus.
El circuito de prueba,
para el presente trabajo, consideró el sensor ultrasónico HC-SR04, el cual
también está disponible dentro la librería Simulino, para Proteus. El código del programa Arduino puede ser
descargado del Anexo.
Fig. 1. Circuito para la
medición de distancia.
Para simular el
circuito, se requiere compilar del programa que, en su formato ya compilado,
normalmente tiene una extensión HEX, y contiene el lenguaje de máquina para que
el microcontrolador de Arduino, ejecute las instrucciones. El archivo se lo
genera en el programa específicamente desarrollado para Arduino, y este, lo
deposita en una ubicación temporal.
En
http://geekelectronica.blogspot.com/2015/01/simular-arduino-con-proteus.html
encontrará una descripción detallada de este proceso.
Una vez compilado el programa,
se procede a su cargado en el simulador. Basta con realizar un doble clic sobre
el símbolo representativo de la placa Arduino, para obtener la ventana de
configuración y dentro del campo Program
File se indica la ubicación del programa compilado.
Fig. 2. Definición del
programa compilado para Arduino.
Antes de iniciar la
simulación, se debe considerar que el sensor ultrasónico HC-SR04, también
requiere de un programa para su ejecución. El archivo UltraSonicsensor.HEX fue
el empleado para el proyecto y está disponible junto con la librería Simulino.
Fig. 3. Identificación
del programa compilado para el HC-SR04.
Al momento de simular el programa, se
obtuvieron mediciones de distancia dentro la pantalla de la terminal virtual,
en la figura 4 se presentan estos valores.
Fig. 4. Lecturas de
distancia generados por Arduino.
El sensor ultrasónico
entregó datos a Arduino, el cual los interpretó e imprimió mediante la
comunicación serial, valores que representan la distancia a la que se
encontraría un objeto real; con la variación del potenciómetro es posible
obtener lecturas diferentes, serán precisamente estos datos los que sean
recibidos por Labview.
3 ADQUISICIÓN DE DATOS EN LABVIEW A TRAVÉS
DE ARDUINO
LabVIEW, por medio de
complementos tales como MakerHub o NI-VISA, permiten conectarse con plataformas
embebidas comunes como chipKIT, Arduino y NI myRIO, o transductores comunes
incluyendo acelerómetros, sensores de temperatura y sensores ultrasónicos de
distancia. Para conectar Labview, con una placa Arduino, es necesario instalar
lo que denominan el Firmware, que no
es nada más que un programa intermedio entre Labview y las prestaciones de
Arduino.
En la página web:
http://www.instructables.com/id/Arduino-and-LabVIEW/ se encuentra un
procedimiento detallado acerca de la instalación y configuración de NI-VISA
para la adquisición de datos por medio de Arduino.
En las figuras 5 y 6, se
presentan los circuitos programados en Labview, para la adquisición de datos a
ser enviados por Arduino, vía puerto serial. Recordando que esto se
desarrollará en un entorno simulado.
Para lo opción True.
Fig. 5. Circuito de
adquisición de datos para la opción True.
Para la opción False.
Fig. 6. Circuito de
adquisición de datos para la opción False.
A continuación, se
realizará la comunicación entre Simulino (Arduino simulado en Proteus) y los
programas Labview, a través de puertos seriales virtuales.
4 COMUNICACIÓN ENTRE LABVIEW Y SIMULINO
Es posible realizar la
comunicación de dos aplicaciones diferentes, ambas instaladas en una misma
computadora y es a través de un par de puertos seriales virtuales, no físicos.
En este trabajo, se empleó una comunicación virtual tipo null modem.
Fig. 7. Configuración de
dos puertos seriales virtuales en Eltima Software.
El programa Virtual
Serial Port Driver de Eltima, permitió comunicar, a través del puerto serial
virtual, el circuito simulado en Proteus, el cual contaba con una placa virtual
Arduino, y Labview. Existen otras aplicaciones similares y gratuitas, sin
embargo el programa de Eltima, en su versión de prueba fue suficiente como para
lograr una comunicación efectiva entre Simulino y el circuito en Labview.
En la página web
http:/perso.wanadoo.es/pictob/rs232virtual.htm se tiene un tutorial para la
configuración del programa de Eltima.
Fig. 8. Esquema de
comunicación entre Proteus y Labview.
Una prueba de
conectividad, entre los puertos seriales virtuales (COM1 y COM2), se realizó
empleando el programa Mttty, que es una aplicación gratuita tipo Hyperterminal.
Confirmada la
posibilidad de envío y recepción de datos entre las aplicaciones Mttty, por
medio de los dos puertos seriales virtuales, se procedió a la simulación del
circuito en Proteus, y la adquisición de los datos, representativos de la
distancia, por parte de Labview. El resultado se presenta en la figura 9.
Fig. 9. Lectura en
Labview de valores de distancia generados por Simulino
Con esta experiencia fue
posible realizar la lectura de datos de un entorno simulado, con ambas
aplicaciones residentes en una misma computadora; el paso siguiente es poder
lograr la lectura de datos, pero esta vez, con las aplicaciones instaladas en
dos computadoras diferentes, las que se encontrarán conectadas a una red de
área local.
5 COMUNICACIÓN LABVIEW CON SIMULINO VÍA
ETHERNET
Si bien, el empleo de
dos aplicaciones CAD, instaladas en la misma computadora, permite su conexión a
través de puertos seriales virtuales, muchas veces es necesario recurrir a un
par de computadoras, una para la simulación del circuito (Proteus) y la otra el
tratamiento de los datos (Labview). Esto mejoraría las prestaciones de
rendimiento, superando las limitaciones de Hardware, o quizás por cuestiones de
licencia de uso, sin descartar la posibilidad de la realización de trabajos a
distancia.
La conexión, entre el
circuito simulado en Proteus, el que cuenta con una placa Arduino, y Labview,
se realizó a través de puertos seriales virtuales conectados a Ethernet, esto
se consiguió mediante la aplicación Network Serial Port Kit de Fabulatech.com,
en su versión de evaluación. Existen otras aplicaciones similares disponibles
en Internet.
En la página web oficial
del producto, se tiene un resumen de la configuración necesaria para su
funcionamiento. Visite: http://www.fabulatech.com/network-serial-port-kit.html
Figura 10. Esquema de
comunicación entre Proteus y Labview vía Ethernet
Fue necesario definir
una de las computadoras como Cliente y a la otra como Servidor, además de
configurar a los puertos seriales virtuales como tipo null modem.
Una prueba de la
configuración cliente – servidor de los puertos seriales virtuales, para el
envío y recepción de datos, fue a través de la aplicación Mttty instalada en
ambas computadoras.
|
|
Figura 11. Prueba de
conectividad del cliente y servidor, a través del puerto virtual.
En una computadora, definida
como servidor, se ejecutó Labview con el programa desarrollado anteriormente y
un puerto serial COM1. En la otra computadora, definida como cliente, se
ejecutó Proteus, con el circuito de adquisición de datos desarrollado
anteriormente y un puerto serial COM2.
Una vez verificada la
conectividad, se procedió a la comunicación entre Simulino y Labview.
Figura 12. Envío y recepción de datos virtuales a través
de Ethernet.
Como se puede apreciar,
la lectura de datos por parte de Labview fue exitosa, lo que permitió enviar
información simulada e interpretada a distancia.
6 CONCLUSIÓN
Con este trabajo se
logró conectar dos aplicaciones (Proteus y Labview), instaladas cada una en computadoras
diferentes, una encargada de la captura de la información y la otra responsable
del procesamiento los datos generados a distancia, sin embargo, la experiencia
también posibilita que dos circuitos simulados de un mismo programa puedan
transferir datos el uno con el otro a través de una conexión remota, en este
caso Ethernet.
El trabajar con sistemas
CAD electrónicos, demanda recursos hardware que, de acuerdo a la complejidad
del circuito, estos serán simulados con mayor o menor velocidad, lo que en
casos particulares se torna en un problema, ya que las capacidades de la
computadora se ven sobrepasadas por las necesidades del programa de simulación.
Es precisamente en este escenario donde se podría recurrir al empleo de dos o
más computadoras que atiendan una misma necesidad de simulación, de esta
manera, la demanda del recurso físico, por parte del programa CAD, se
repartiría entre ellas.
ANEXO.
Programa para Arduino. USProteus
#define Pecho 6
#define Ptrig 7
long duracion, distancia;
int lejos, cerca;
void setup() {
Serial.begin (9600); // inicializa el puerto seria a 9600 baudios
pinMode(Pecho, INPUT); // define el pin 6 como entrada (Echo)
pinMode(Ptrig, OUTPUT); // define el pin 7 como salida (Triger)
Serial.flush();
}
void loop(){
Serial.flush();
distancia = leedistancia(); // Lee la distancia
if (distancia >= cerca && distancia <= lejos){
do{
Serial.print(distancia); // envía el valor de la distancia por el puerto serial
Serial.println("cm");
distancia = leedistancia(); // Lee la distancia
} while(distancia >= cerca && distancia <= lejos);
}
delay(1000); // La información se actualiza cada 1 seg.
}
// Función para la lectura de la distancia
long leedistancia(){
delayMicroseconds(2); // Inicia el sensor
digitalWrite(Ptrig, HIGH); // genera el pulso de triger por 10ms
delayMicroseconds(10); // Espera 10 microsegundos
digitalWrite(Ptrig, LOW);
duracion = pulseIn(Pecho, HIGH);
distancia = (duracion/58); // calcula la distancia en centimetros
return distancia;
}
ANEXO.
Programa para Arduino. USProteus
#define Pecho 6
#define Ptrig 7
long duracion, distancia;
int lejos, cerca;
void setup() {
Serial.begin (9600); // inicializa el puerto seria a 9600 baudios
pinMode(Pecho, INPUT); // define el pin 6 como entrada (Echo)
pinMode(Ptrig, OUTPUT); // define el pin 7 como salida (Triger)
Serial.flush();
}
void loop(){
Serial.flush();
distancia = leedistancia(); // Lee la distancia
if (distancia >= cerca && distancia <= lejos){
do{
Serial.print(distancia); // envía el valor de la distancia por el puerto serial
Serial.println("cm");
distancia = leedistancia(); // Lee la distancia
} while(distancia >= cerca && distancia <= lejos);
}
delay(1000); // La información se actualiza cada 1 seg.
}
// Función para la lectura de la distancia
long leedistancia(){
delayMicroseconds(2); // Inicia el sensor
digitalWrite(Ptrig, HIGH); // genera el pulso de triger por 10ms
delayMicroseconds(10); // Espera 10 microsegundos
digitalWrite(Ptrig, LOW);
duracion = pulseIn(Pecho, HIGH);
distancia = (duracion/58); // calcula la distancia en centimetros
return distancia;
}
sábado, 9 de abril de 2016
EL TRABAJO DE GRADO, ¿PREOCUPACIÓN O MOTIVACIÓN?
Dentro
de las modalidades de graduación que contempla la Escuela Militar de Ingeniería,
se encuentra el Trabajo de Grado, y de acuerdo al Reglamento de Graduación de
Grado, RAC-02 se define como: “el resultado genérico que plasma aquella
Modalidad de Graduación elegida por los estudiantes, en función de la temática
a investigar y de la metodología a aplicar, sobre problemas emergentes de la
realidad Nacional, Regional o Local, así como su aporte al conocimiento
científico-tecnológico” [1].
Durante
los semestres que estuvieron a mi cargo las asignaturas de Trabajo de Grado I y
II, correspondientes al noveno y décimo semestre respectivamente, pude ser
testigo de diversas situaciones por las que atraviesa un estudiante mientras
desarrolla su Trabajo de Grado, donde lamentablemente, no todos llegan a
completar sus expectativas con las que iniciaron aquellos últimos dos semestres
dentro la Carrera de Ingeniería de Sistemas Electrónicos.
La
etapa final hacia la titulación, inicia con la presentación del perfil;
personalmente creo que todo lo que inicia bien, termina bien y lo que inicia
mal, en muy pocos casos termina bien, donde la variable para el éxito se denomina
motivación.
Si
bien, para la presentación del perfil es tan importante conocer la problemática
y definir de forma puntual el problema, en la práctica generalmente no ocurre
esto. El estudiante, en muchos casos, llega a esta instancia final con algún
prototipo, sistema o programa predefinido, ya sea a partir de: una recomendación
por parte del docente tutor, sugerencias del entorno social o, como pasa a
menudo en estos últimos años, vio o leyó un artículo en Internet y pretende
replicarlo. Considero que no hay nada peor que hacer algo que uno no quiere o
que no sabe, puesto que, el desarrollar esa solución predefinida, demandará
varias semanas tortuosas, en las que el estudiante tendrá que dedicarse al
trabajo con la preocupación de lograr los objetivos planteados, contando con
información, herramientas y recursos escasos, limitados o desconocidos, y la
solución requerirá aspectos que no fueron considerados durante la inspección
inicial, por lo tanto, el Trabajo de Grado, de a poco, se torna un reto muy
complicado.
Cuando
el estudiante tiene una idea inicial de solución y no el problema, el docente
tutor trata de recorrer el camino contrario al que propone el método científico
de investigación, entonces, intentarán hallar ese problema que pueda ser solucionado
en la propuesta, algo así como autorecetarse una aspirina esperando tener un
dolor de cabeza, que en muchos casos ese dolor de cabeza nunca se manifiesta.
Por
otra parte, están aquellas propuestas donde los estudiantes, identifican una
problemática relacionada con la especialidad, pero muchas veces la solución cae
dentro del campo económico, es decir, tratar de solucionar aspectos que hacen
más bien a la administración de los recursos disponibles, principalmente los
económicos, aclarando que, si para algunos es caro o costoso, para otros puede
que no lo sea, depende de cada bolsillo. Como generalmente el estudiante no
cuenta con los recursos económicos que puedan solventar la adquisición de algunos
dispositivos, artefactos o equipos, éste pretende construirlos para dar
solución a una necesidad puntual, donde el problema es el dispositivo
electrónico y la solución se concentraría más bien en la manera de lograr los
recursos económicos para adquirir el equipo necesario. Particularmente, no
recomiendo el desarrollo de este tipo de trabajos, por muchas razones, entre ellas
esta el conocimiento por parte del estudiante, ya que dentro del Diseño
Curricular de la Carrera, no se abordan con profundidad materias de
administración, contabilidad, economía o finanzas, es así que realizar un flujo
de caja, proyecciones, estados financieros y otros, hasta llegar a la
evaluación económica, tratando de demostrar la rentabilidad del producto o
servicio propuesto, aspectos que para el estudiante le resultarán complicados,
demandándole un tiempo en el aprendizaje y lamentablemente tiempo es lo que
menos se tiene.
Una
vez que se identifica el problema y se logra separar las limitaciones del tipo
económico, el estudiante alcanza la verdadera motivación para la realización de
su proyecto, que resulta en desarrollar una solución clara y concreta a
problemas emergentes de la realidad nacional, regional o local, como indica el
reglamento
RAC-02, así como su aporte al conocimiento científico-tecnológico, a partir del empleo de los recursos que propone la ingeniería electrónica.
RAC-02, así como su aporte al conocimiento científico-tecnológico, a partir del empleo de los recursos que propone la ingeniería electrónica.
Cuando
se divisa el destino, recorrer el camino resulta menos complicado. Es así que,
pude percibir la motivación en aquellos estudiantes quienes comenzaron el
proyecto, sabiendo exactamente lo que querían realizar, conocían a cabalidad el
tema, y los docentes quienes acompañaron este recorrido, se convirtieron en un
apoyo efectivo, aportando con experiencia, recomendaciones y quizás opiniones que
pudiesen favorecer o fortalecer la solución planteada, resultando el desarrollo
del trabajo de grado en una experiencia motivadora. Ver como una persona va
persiguiendo sus objetivos y de a poco los va logrando, es algo que llena de
satisfacción a cualquier docente.
Otro
aspecto que recalcar es el hecho de que ni el docente de la asignatura, ni el
docente tutor, peor aún los docentes revisores, son los responsables de las
calificaciones obtenidas durante las diferentes etapas consideradas dentro del
desarrollo del Trabajo de Grado, estas ponderaciones son resultado del
esfuerzo, la dedicación y el compromiso que pone el estudiante para lograr alcanzar
sus objetivos planteados. Está por demás indicar que todo el tribunal designado
para la supervisión del trabajo, es conformado por profesionales expertos en el
campo de investigación propuesto y que ellos, aportarán para que se pueda
desarrollar un trabajo con un nivel académico excelente y en ningún momento
estarán ahí para obstaculizar el desarrollo del mismo.
Antes
de comenzar un trabajo de investigación, recomiendo que primero el estudiante
realice una profunda reflexión acerca de sus fortalezas y debilidades, es
incorrecto pensar que existen profesionales que conocen absolutamente todos los
temas que aborda la Ingeniería Electrónica, lo ideal es alcanzar una
especialidad, así que, el desarrollo del Trabajo de Grado, debe ser el primer
paso, y el más importante, ya que, puede marcar el inicio de una carrera
exitosa para el nuevo profesional.
[1].
Reglamento de graduación de grado RAC-02, RSCA No. 201/2013 del 19 de diciembre
de 2013.
Suscribirse a:
Entradas (Atom)