Es evidente que las cosas fallan, muchas veces por razones muy similares con independencia del ámbito que estemos tratando. Queremos hacer una selección de algunas de las razones por las que fallan los montajes de robótica.
Podemos estar convencidos de lo bien que hemos elaborado nuestro montaje de robótica, pero este no funciona como esperábamos. ¿Por qué?:
- Conexionado incorrecto. Incluyendo, por supuesto, «no enchufar las cosas»
- El programa realizado presenta errores porque no se utilizan bien las instrucciones o se escriben mal
- Estamos escrito un programa «perfecto» con unos elementos no tan perfectos
- Hay interferencias entre componentes o entre librerías y componentes
- Nos hemos olvidado de añadir «algo» a nuestro circuito
- Problemas con la alimentación
Analizamos algunos de estos puntos de forma breve, con algún ejemplo.
Fallos de Conexionado
– Oiga, no me funciona la televisión que acabo de comprar – dice el cliente enfadado, sujetando el teléfono y esperando respuesta
– ¿Ha conectado usted el televisor?
¿Tu circuito tiene conectados GND y Vcc? Pues eso. Este problema es más habitual de lo que parece.
Otra del estilo: cuando tienes placas de prototipo (protoboard): ¿estás seguro de que todas las líneas conectadas a tierra y a Vcc no están «cortadas»? (hay placas de prototipo que dividen en dos los circuitos de GND y Vcc):
Si se quiere, estos son los fallos más tontos. Los más normales son confundir los pines de los componentes electrónicos o bien conectar GND y Vcc al revés. Muchos elementos, por otra parte, requieren más de una conexión de entrada/salida, por lo que hay que vigilar que estas conexiones sean correctas.
En el caso de algunos componentes electrónicos, es necesario tener cuidado al cambiar la polaridad (las conexiones ‘+’ y ‘-‘). Si esta no es correcta, por ejemplo, en un condensador electrolítico, puede explotar.
Soluciones: son obvias. Habrá que revisar conexionado de componentes electrónicos, analizando su hoja de características.
El programa no llega a cargarse en el microcontrolador (arduino) porque el compilador da errores
En este caso habrá que leer atentamente el tipo de error que nos indica la pantalla para corregirlo. Este tipo de errores (como en cualquier disciplina) se reducen con la práctica. Algunos muy típicos:
- Alguna llave de más o de menos ({})
- Se olvida finalizar una instrucción con ‘;‘
- escritura incorrecta de una instrucción
- usamos una variable que no hemos definido o nos confundimos de nombre
- Se nos olvida escribir alguna librería
- aparecen inconsistencias al utilizar funciones
Soluciones:
Hay que leer muy bien los mensajes de error que aparecen en el compilador. Si son complejos o no se entienden: copiar y pegar en el buscador de google. Muchas personas se han encontrado con el mismo problema antes que tú y es seguro que encontrarás respuesta a tu problema.
Por otra parte, siempre es recomendable ir a la página de referencia de funciones de arduino, para aprovechar y aprender más de una instrucción concreta.
Ejemplo de fallo de compilación:
Errores en el programa
Es el fallo más habitual. Una vez subido el programa, no obtenemos el resultado esperado. No hemos pensado bien el algoritmo o este no está bien traducido en instrucciones. Así, tenemos:
- Utilización incorrecta de bucles
- Mal uso de condicionales
- no tener en cuenta cómo se comportan los componentes (ver siguiente apartado)
A veces, las diferencias son muy sutiles, como podemos ver en este ejemplo, que no funciona correctamente (ver aquí el porqué):
Utilizamos componentes «del mundo real»
Hemos hecho «bastante» bien el programa, pero no hemos tenido en cuenta las imprecisiones inherentes a los componentes electrónicos que estamos utilizando en nuestros montajes.
Ejemplo: el caso del pulsador
Cuando se activa un pulsador, se genera una entrada que puede ser de nivel alto o bajo, dependiendo de cómo esté montado. Si pretendemos contar el número de pulsaciones que damos y no tomamos las medidas adecuadas, al pulsar no sumará una, sino varias veces en el tiempo que mantenemos pulsado, aunque a nosotros nos parezca corto.
Esto se debe al efecto rebote del botón: el ciclo de programa se ha podido repetir muchas veces mientras tenemos pulsado el botón. Recordemos que se repite el bucle indefinidamente a gran velocidad.
El tener presente que la función loop() de nuestros programas se repite de forma indefinida es uno de los aspectos fundamentales a tener en cuenta al programar nuestra placa arduino.
La manera más inmediata de resolverlo es estableciendo un retraso (delay) para que dé tiempo a separar el dedo del botón. La manera más elegante es establecer una rutina (bloque de programa) de manera que solo deje medir una pulsación hasta que no cambie de estado. Es el algoritmo anti-rebote que se puede ver en el programa «debounce» de la lista de ejemplos del IDE de arduino (ejemplos->digital) o utilizar alguna librería.
Interacciones entre componentes o librerías y componentes
No hemos tenido en cuenta o desconocemos los efectos secundarios de utilizar ciertas librerías que pueden hacer, por ejemplo, que no funcionen correctamente otros sensores.
Un caso típico es el caso de la librería servo.h. En la página de arduino se explica el problema. Cuando utilizamos un motor servo hay que tener en cuenta que la librería desactiva la función PWM de los pines 9 y 10, esté o no conectado el servo. Es más, si utilizando un servo conectamos un sensor de ultrasonidos (HC-SR04) al pin 9 o 10 podemos tener problemas de funcionamiento.
Necesidad de incorporar algunos componentes electrónicos
Problemas derivados de la necesidad de incorporar en nuestros montajes algunos componentes electrónicos para que las lecturas de entradas y salidas sean las correctas
Es el caso de incorporar resistencias de pull-up o pull-down para nuestras entradas digitales.
(foto de portada de mediamodifier, pixabay)