Depuración de programas (y II)

Hemos visto que la depuración de programas consiste en corregirlos hasta que funcionen de acuerdo con las especificaciones de nuestros proyectos. Habíamos dividido esta depuración en 4 niveles:

• corrección del código
• depuración de problemas con el algoritmo
• conexionado y funcionamiento correcto de los componentes
• problemas derivados de la interacción con el mundo exterior

Vimos en la primera parte los dos primeros niveles. Pasamos a analizar el tercer nivel y cuarto niveles.

Nivel 3. Entradas y salidas bien cableadas. Funcionamiento correcto de componentes

Todos sabemos lo primero que tenemos que buscar si la tele no se enciende. En efecto, tenemos que ver si está enchufada. Incluso ver si les llega corriente (se ha podido ir la luz).

En nuestros proyectos debemos comprobar, uno a uno, el cableado de todos los sensores pines que vamos a usar en el programa. Debemos verificar que la fuente de alimentación (batería) está en las condiciones adecuadas. Este es uno de los problemas que suele dar mayores quebraderos de cabeza.

En este nivel hay que revisar qué es lo que hemos construido y cableado físicamente. Nuestras herramientas de depuración se transforman en un polímetro, un par de manos y un conocimiento lo más esmerado posible de cómo reaccionan nuestros sensores y los componentes electrónicos, junto con buenas dosis de paciencia.

Es recomendable seguir los siguientes pasos (nota: pin es el punto numerado de la placa donde conectamos los sensores y actuadores):

1. Verificar que los pines cableados en la placa se corresponden con los programados. Si encendemos un LED rojo y mandamos escribir nivel alto al pin 5, de este pin debe salir un cable que vaya a la pata larga del LED rojo, no del verde
2. Comprobar que nuestros componentes funcionan para poder descartar fallos, es decir, que el LED no está fundido, el motor no está quemado o el sensor de ultrasonidos está averiado. Hacer la verificación 1 a 1. En el caso de sensores se puede utilizar el monitor del sistema: cableamos, leemos el sensor y lo imprimimos en pantalla
3. Después de la verificación uno a uno, es interesante hacer un prototipo de todo el proyecto. Un proyecto completo «con las tripas al aire«. Por ejemplo, ponemos por separado las piezas del robot debidamente cableadas,  pero sin montar el robot.

Esto es un robot, aunque no lo parezca:

No hay manera de hacer funcionar un componente

La primera vez que usamos un sensor que requiere librerías por su complejidad, es posible que no funcione. Lo más probable en este caso es que no sepamos hacerlo funcionar aunque pasemos horas indagando. Para resolver el problema:

• utilizar ejemplos que suelen aparecer con la librería
• buscar ejemplos en Internet, copiar y pegar, haciendo, si es preciso, una adaptación de pines
• recurrir a los foros de internet en los que, con toda seguridad, encontraremos la solución. Eso sí, si la búsqueda en español no da resultados, conviene repetirla en inglés.
• siempre verificar que la alimentación de los distintos componentes es la correcta

Ejemplo: si tienes una pantalla LCD, el comportamiento en paralelo de la pantalla no ofrece ningún problema. Si quieres usar comunicación I2C para ahorrar cables puedes pensar que copiando cualquier programa de internet va a  funcionar. Pruebas y no va. Pruebas con varias pantallas y sigue sin ir. Algo «extraño» está ocurriendo.

Sigues investigando y encuentras que el programa debe conocer la dirección del componente I2C, que no coincide con la que has copiado de internet. ¿Cómo saber esa dirección? Vuelves a buscar y ves que existe un programa que te proporciona esa dirección. Problema resuelto, muy simple, que te ha llevado horas. En el enlace está explicado este caso concreto con todo detalle.

Nivel 4. «Welcome to the real world»

Bienvenidos al mundo real

Hemos compilado el programa. Perfecto. Hemos comprobado si hay errores de código y errores lógicos. Correcto. Hemos verificado el cableado y el funcionamiento de todo lo que tenemos. Ningún problema. Hemos hecho la simulación del prototipo y aparentemente todo funciona como debe.

Ya está todo, montaremos lo que sea que hayamos proyectado y a correr. No tan rápido. Acabamos de llegar al mundo real, a veces bastante traicionero.

Por ejemplo, imaginemos un prototipo de barquito: hemos comprobado que nuestros motores van, también las luces, el timón. Lo montamos, y va y se hunde.

«El mundo real» es el que da sentido a la robótica educativa. Ya sea para hacer un robot, preparar un experimento o hacer un sistema de riego automático, nuestros sensores tomarán datos de ese mundo real y en función de esos datos, haremos que nuestro proyecto provoque cambios en ese mundo real. Estos cambios modifican las entradas de nuestro proyecto que puede así variar su comportamiento.

Continuando con el ejemplo del barquito, que el desconsiderado mundo real ha hundido, deberemos analizar:

• Cuál será la base (casco) del barco
• Cómo calcular el peso máximo que puede soportar
• ¿Será estable?
• Cómo mejorar la estabilidad
• Cómo gobernar el barco (cómo instalar y controlar un timón)
• realizar un nuevo diseño. con elementos de menos peso, casco más estable. etc

Es decir, los problemas que encontramos en este nivel pueden obligarnos a cambiar por completo el diseño de nuestro robot, barco, experimento, proyecto en general. El cambio de diseño con toda seguridad obligará a replantearnos la programación de nuestro algoritmo.

Estoy seguro de que habéis oído hablar del submarino S-80. Pesaba mucho y se hundía. Tuvieron que alargarlo varios metros para que el volumen ganado proporcionara el empuje que falta (ya sabéis, el principio de Arquímedes).

Cuidado con la electrónica

Tranquilos, una pila de 9 V no suele dar calambre. Sin embargo, los pequeños voltios e intensidades de la electrónica sí que pueden dar dolores de cabeza a la hora de elaborar circuitos que funcionen sin hacer cosas raras.

Hace muchos años comencé a trabajar en robótica educativa con un robot basado en un microcontrolador PIC. En aquellos tiempos sabía programar, aprendí en la carrera. El lenguaje que utilicé (además de BASIC y FORTRAN) fue C. Una versión de C se utiliza ahora para programar las placas compatibles con arduino.

Este aspecto tenía aquel robot de hace años (en la foto se ve el chasis sin brazos ni ruedas):

Sin embargo, el lenguaje de los microcontroladores PIC es bastante árido, aunque todavía son ampliamente utilizados en la industria.

Ha pasado mucho tiempo. Hace unos años, un grupo de personas (el equipo que desarrolló arduino) se propuso hacer la programación y el diseño de circuitos lógicos mucho más fácil, para que fuera accesible a rangos de edad entre 5 y 99 años. Fue, sin lugar a dudas, una estupenda idea.

No obstante, la simplicidad tiene su contrapartida. Al igual que la evolución de la informática desde el MS-DOS a nuestros sistemas operativos actuales, la simplicidad en la robótica educativa ha alejado a los estudiantes de los fundamentos de la robótica, de la electrónica.

Esto, en apariencia negativo, permite un acercamiento a una tecnología que, de otra forma estaría vedada a los novatos, sean jóvenes o mayores.

El problema es que, en las etapas iniciales, el desconocimiento de conceptos básicos de electricidad y electrónica puede hacer que no sepamos por qué un circuito que parece correcto no funcione. Por ejemplo, no es evidente la necesidad de una resistencia de puesta a tierra (pull-down) cuando utilizamos un botón o un final de carrera.

Depuración de programas y el mundo real

La interacción con el mundo real obligará a realizar modificaciones en los programas para evitar los defectos de medición de nuestros sensores. Vamos a comentar algunos ejemplos.

1. Cuando un sensor de ultrasonidos llega a un obstáculo escorado, el reflejo del haz de ultrasonidos no será adecuado y dará medidas extrañas. Este problema puede corregirse:

• instalando otro sensor de distancia
• colocando el sensor encima de un servomotor para poder orientarlo
• mediante programación: rechazamos números no lógicos y modificamos el comportamiento

2. ¿Qué ocurre cuando una batería se descarga muy rápido por ser de baja calidad y no nos damos cuenta? Que fácilmente nos volvamos locos hasta que demos de la solución. Por ejemplo, si el sensor de ultrasonidos no tiene una alimentación de al menos 4,5 V dejará de funcionar.

3. Ya hemos comentado la necesidad del uso de resistencias (pull-down) con botones y con muchas entradas digitales similares (finales de carrera y en general contactos libres de potencial).

4. Un exceso de luz solar puede afectar al funcionamiento de un detector de infrarrojos. Cuando utilizábamos la rampa para estudiar la aceleración, los sensores no actuaban cuando situábamos la rampa cerca de una ventana con mucho sol.

En la imagen, el detector de infrarrojos está preparado para detectar obstáculos. En el experimento de la rampa medíamos el tiempo transcurrido del paso de una bola desde un detector al siguiente. Hay que tener en cuenta que el detector sigue «viendo» la pelota durante un tiempo desde que lo detecta por primera vez. Este efecto hay que tenerlo en cuenta cuando se realiza el programa.

(Fotografías de Federico Arroyo)