Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones


logo robotica1 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

En este nuevo paso de la construcción del robot, vamos a comprobar que las conexiones eléctricas entre la tarjeta y los servos son correctas. Es preciso que nos aseguremos de que el servo de la derecha gira cuando recibe señales procedentes de P13 y que el servo de la izquierda hace lo propio cuando recibe señales de P12 según el montaje realizado en el paso anterior.

En la siguiente imagen vemos nuestro robot con las indicaciones de posición que se seguirán de ahora en adelante para evitar confusiones:


323 watermark 320x240 robotica 083 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

5.1 Comprobando el funcionamiento de las ruedas

Vamos a ejecutar un sencillo programa para probar el servo conectado a la rueda derecha. Hará que la rueda gire en la dirección de las agujas del reloj durante 3 segundos, parará durante un segundo y, después, girará en sentido contrario durante otros 3 segundos.

  1. ‘ Programa de prueba de servos.  Pruebaservoderecho.bs2
  2. ‘ El servo derecho gira en sentido horario 3s, se para 1s
  3. ‘ y vuelve a girar 3s en sentido antihorario
  4. ‘ {$STAMP BS2}
  5. ‘ {$PBASIC 2.5}
  6. Counter VAR Word
  7. FREQOUT 4, 2000, 3000                ‘señal de inicio/reset
  8. FOR counter = 1 TO 122                 ‘giro horario durante 3s
  9.                 PULSOUT 13, 650
  10.                 PAUSE 20
  11. NEXT
  12. FOR counter = 1 TO 40                   ‘parada 1s
  13.                 PULSOUT 13, 750
  14.                 PAUSE 20
  15. NEXT
  16. FOR counter = 1 TO 122                  ‘giro antihorario durante 3s
  17.                 PULSOUT 13, 850
  18.                 PAUSE 20
  19. NEXT
  20. END

Para ponerlo en marcha, cargaremos el programa en el editor de Basic Stamp y lo introduciremos en la tarjeta del robot como hemos visto en pasos anteriores. Acto seguido colocamos el interruptor de energía en la posición 2 (que alimenta los servos) y ejecutamos el programa.


324 watermark 320x240 paso 005 01 001 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Los mismos pasos daremos con el servo de la rueda izquierda:

  1. ‘ Programa de prueba de servos.  Pruebaservoderecho.bs2
  2. ‘ El servo derecho gira en sentido horario 3s, se para 1s
  3. ‘ y vuelve a girar 3s en sentido antihorario
  4. ‘ {$STAMP BS2}
  5. ‘ {$PBASIC 2.5}
  6. Counter VAR Word
  7. FREQOUT 4, 2000, 3000                ‘señal de inicio/reset
  8. FOR counter = 1 TO 122                 ‘giro horario durante 3s
  9.                 PULSOUT 12, 650
  10.                 PAUSE 20
  11. NEXT
  12. FOR counter = 1 TO 40                   ‘parada 1s
  13.                 PULSOUT 12, 750
  14.                 PAUSE 20
  15. NEXT
  16. FOR counter = 1 TO 122                  ‘giro antihorario durante 3s
  17.                 PULSOUT 12, 850
  18.                 PAUSE 20
  19. NEXT
  20. END


326 watermark 320x240 paso 005 01 002 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Vemos cómo la única diferencia entre estos dos programas es que hemos sustituido el punto de enganche del servo derecho (P13) por el servo izquierdo (P12) en el segundo programa.

Ahora vamos a comprobar como el robot se mueve según las indicaciones de la programación: la rueda derecha girará en sentido horario durante tres segundos, se detendrá un segundo, y volverá a girar en sentido antihorario otros 3 segundos (lo mismo sucederá con la rueda izquierda).


325 watermark 320x240 robotica 084 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

5.2 Detector acústico de baja tensión y reinicio

Cuando el suministro de voltaje eléctrico cae por debajo del nivel que el dispositivo necesita para funcionar correctamente se produce un apagón parcial. La tarjeta se protege a sí misma de esta situación haciendo que el procesador y los microchips de memoria permanezcan en estado de reposo hasta que el suministro de energía vuelva a niveles normales.

Una bajada de tensión en Vin por debajo de 5,2 V provoca un voltaje inferior a 4,3 V en el regulador interno de la tarjeta, valor insuficiente que origina una anomalía y que provoca, como hemos señalado, que se ponga en marcha un mecanismo de autoprotección del sistema en el que tanto el procesador como la memoria pasan a un estado de reposo que detiene la ejecución de instrucciones. Cuando el voltaje vuelve a niveles adecuados, la tarjeta se pone en funcionamiento de nuevo pero no donde había quedado ejecutándose el programa, sino desde el principio del mismo. Es lo mismo que sucede cuando pulsamos el botón de reinicio del sistema.

Cuando las baterías están bajas, es posible que estas bajadas de tensión hagan reiniciarse al robot cuando menos lo esperamos, haciendo que tome direcciones erróneas, dé vueltas sobre sí mismo etc.

Esto hace que un programa que indique la posibilidad de reinicio del robot sea muy útil (de esta forma sabemos claramente cuál ha sido la causa del funcionamiento incorrecto de nuestro robot). Una forma para avisar de un posible reinicio es incluir una señal inconfundible al comienzo de todos los programas del robot. La señal se produce cada vez que se conecta el suministro de energía y cuando se produce un reinicio debido a una bajada de tensión.

En este ejercicio vamos a colocar un dispositivo llamado zumbador piezoeléctrico que se puede usar para generar diferentes tonos en función de la frecuencia de las señales que se envíen desde la tarjeta.

El programa que vamos a cargar a continuación produce un pitido a través del zumbador. Utiliza el comando FREQOUT para enviar las señales de la frecuencia que se deseemos por una patita de la tarjeta. Su sintaxis es como sigue:

                FREQOUT Pin, duración, frecuencia1, {Frecuencia2

Un ejemplo sería FREQOUT 4, 2000, 3000: envía una señal de 3000 hercios (3 kHz) durante 2000 ms (2 segundos) por el pin 4.

En este punto debemos tener presente que la frecuencia es una magnitud que mide el número de repeticiones por unidad de tiempo de cualquier fenómeno o suceso periódico. Nuestro zumbador funciona gracias a la piezoelectricidad: es un fenómeno presentado por determinados cristales que al ser sometidos a tensiones mecánicas adquieren una polarización eléctrica en su masa, apareciendo una diferencia de potencial y cargas eléctricas en su superficie. Este fenómeno también se presenta a la inversa, esto es, se deforman bajo la acción de fuerzas internas al ser sometidos a un campo eléctrico. El efecto piezoeléctrico es normalmente reversible: al dejar de someter los cristales a un voltaje exterior o campo eléctrico, recuperan su forma.

De esta forma, cuando aplicamos cambios de voltaje a gran velocidad hacemos que el cristal piezoeléctrico cambie de forma rápidamente. Esto provoca una vibración. Los objetos que vibran hacen que el aire que los rodea vibre también, y esta vibración es lo que nuestros oídos detectan como sonido y tonos.

La frecuencia se mide en hercios (Hz). Un hercio representa un ciclo por cada segundo, entendiendo ciclo como la repetición de un suceso. De esta forma, un kHz representa mil ciclos por segundo.

Más abajo se muestra el símbolo del zumbador y el esquema de conexión del terminal positivo del zumbador a la patita P4 de E/S.

zumbador Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones


331 watermark 320x240 diagrama zumbador Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Para el montaje tomamos el zumbador y lo colocamos sobre la tarjeta. Vemos que una pegatina indica cuál de las dos patas es de signo positivo así que solo tenemos que presionar y listo. Para dejar más espacio para el resto de componentes, y dado que este elemento quedará fijo de forma permanente, es mejor colocarlo lo más esquinado posible.


327 watermark 320x240 robotica 085 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Una vez colocado, sólo tenemos que realizar la conexión de los cables, uno conectando el polo positivo del zumbador a P4 (cable azul) y el otro al conector de energía (Vss)


328 watermark 320x240 robotica 086 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones


329 watermark 320x240 robotica 087 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones


330 watermark 320x240 robotica 088 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Programa ejemplo

El siguiente programa emite un pitido del zumbador al iniciarse su ejecución y luego envía mensajes visualizadores de DEBUG cada medio segundo dentro de un bucle infinito. Se puede simular una bajada de tensión presionando el botón de reinicio o bien desconectando la batería del robot; entonces el programa se reiniciará, emitiendo un pitido de nuevo. Cada vez que se produce un pitido sabemos que el programa se ha iniciado desde el principio.

  1. ‘ Programa de reinicio.  Indicadorinicioreinicio.bs2
  2. ‘ Prueba del altavoz piezoeléctrico.
  3. ‘ {$STAMP BS2}
  4. ‘ {$PBASIC 2.5}
  5. DEBUG CLS, “Beep!!!”                         ‘visualiza el mensaje mientras suena
  6. FREQOUT 4, 2000, 3000                      ‘señal sonora
  7. DO                                                         ‘bucle DO…LOOP
  8. DEBUG CR, “Esperando el reinicio”      ‘visualiza el mensaje
  9. PAUSE 5000                                          ‘cada medio Segundo
  10. LOOP                                                     ‘hasta que se reinicie el sistema



332 watermark 320x240 paso 005 02 001 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

El programa comienza mostrando el mensaje (en la pantalla del ordenador) “Beep!!!” cuando se inicia su ejecución. Inmediatamente envía una señal de 3 kHz al zumbador durante 2 segundos. Como la tarjeta ejecuta muy rápidamente las instrucciones dará la sensación de que el mensaje se muestra al mismo tiempo que el zumbador comienza a pitar.

Cuando cesa el pitido, el programa entra en un bucle infinito mostrando una y otra vez el mensaje “Esperando el reinicio”. Cada vez que se produzca un reinicio, bien porque se aprieta el botón o porque se desconectan las baterías o pierden tensión, el programa se reiniciará.


333 watermark 320x240 paso 005 02 002 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

De ahora en adelante vamos a usar este programa cada vez que escribamos otro. Lo consideraremos parte de la rutina de inicialización de cada programa.

5.3 Probando el control de velocidad del robot

En este paso de comprobación vamos a dibujar las curvas que relacionan la velocidad de giro de los servos con la amplitud de los pulsos que se aplican desde la tarjeta Home Work. Este gráfico nos resultará muy útil ya que cuando queramos obtener una velocidad concreta de las ruedas del robot sólo tendremos que consultar éste para saber la amplitud del pulso que se debe aplicar a cada una. Para ello vamos a utilizar el panel de transmisión del terminal DEBUG del programa de edición para enviar valores al programa de ejecución de la tarjeta.


334 watermark 320x240 paso 05 03 001 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Empleo del comando DEBUGIN

Ya hemos visto en anteriores ocasiones que gracias al comando DEBUG se visualizan los mensajes en la pantalla del ordenador que manda la tarjeta al ejecutar un programa determinado. El terminal DEBUG del programa de edición Basic Stamp también tiene una ventana de transmisión que nos permite enviar información al microcontrolador mientras se está ejecutando un programa. Esto lo hacemos a través del comando DEBUGIN, que toma el valor que introducimos con el teclado y lo envía al programa que está ejecutando la tarjeta para que una o más variables queden fijadas por dicho valor. Es decir, con este comando se introducen valores de variables que se usan en los programas de la tarjeta Home Work.

En el siguiente programa de ejemplo, utilizaremos la variable pulseWidth (amplitud de pulso) para almacenar los valores que el comando DEBUGIN recibe. Evidentemente, tendremos que declarar previamente esta variable al programa

                pulseWidth        VAR       Word

Ahora, el comando DEBUGIN captura los valores decimales que introducimos con el teclado a través del panel de transmisión y los almacena en la variable pulseWidth:

                DEBUGIN            DEC        pulseWidth

De esta forma podemos programar el microcontrolador para que use este valor. En el siguiente ejemplo se utiliza la variable pulseWidth como el argumento Duración del comando PULSOUT:

                PULSOUT 12, pulseWidth

Programa ejemplo

Este programa nos va a permitir establecer el argumento Duración del comando PULSOUT introduciéndolo a través del panel de transmisión del terminal DEBUG del programa de edición.

  1. ‘ Programa de control de velocidad. Pruebavelocidadservo.bs2
  2. ‘ Introducir la amplitud del pulso y contar el número de vueltas
  3. ‘ que gira la rueda durante 6 segundos. Multiplicando por 10
  4. ‘ este valor conocemos las revoluciones por minuto (RPM)
  5. ‘ {$STAMP BS2}
  6. ‘ {$PBASIC 2.5}
  7. counter                       VAR       Word
  8. pulseWidth                 VAR       Word
  9. pulseWidthComp       VAR       Word
  10. FREQOUT 4, 2000, 3000                ‘ señal de inicio/reinicio
  11. DO
  12.                 DEBUG “Indicar la amplitud del pulso:”
  13.                 DEBUGIN DEC pulseWidth
  14.                 pulseWidthComp = 1500 – pulseWidth
  15.                 FOR counter = 1 TO 244
  16.                                PULSOUT 12, pulseWidth
  17.                                PULSOUT 13, pulseWidthComp
  18.                                PAUSE 20
  19.                 NEXT
  20. LOOP

Nota importante: cuando en un programa se definen variables, tanto el tipo como la dirección hay que colocarlas alineadas para su correcta ejecución.


335 watermark 320x240 paso 05 03 002 Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Pasos a seguir

  1. Haremos una pequeña marca en la rueda del robot para tener un punto de referencia.
  2. Colocamos el interruptor de encendido del robot en la posición “2” (que envía energía a los servos).
  3. Ejecutar el programa Pruebavelocidadservo.bs2
  4. Introducir el valor 650 en el panel de transmisión del terminal DEBUG y pulsar ENTER
  5. Contar las vueltas que da la rueda izquierda (el servo habrá girado durante 6 segundos en el sentido de las agujas del reloj, por lo que si multiplicamos el número de vueltas por 10 obtendremos el número de RPM).
  6. Escribimos el valor en la tabla que reproducimos más abajo junto a la celda de 1300 ms.
  7. Introducir el valor 655.
  8. Contar las vueltas que da la rueda.
  9. Multiplicar el valor por 10 y escribirlo junto al valor 1310 ms de la tabla.
  10. Ir incrementando los valores de 5 en 5 (0,01 ms) hasta llegar a 850 (1700 ms).
  11. Repetir el proceso para el otro servo (para ello tendremos que modificar el comando PULSOUT del programa de forma que los pulsos se envíen a P12).

¿Cómo trabaja el programa?

Se declaran tres variables: counter para el bucle FOR…NEXT, pulseWidth para los comandos DEBUGIN y PULSOUT, y pulseWidthComp, que almacena un valor que se usa en un segundo comando PULSOUT.

               counter                   VAR       Word

               pulseWidth               VAR       Word

               pulseWidthComp       VAR       Word

El commando FREQOUT (como vimos en el paso 5.2) lo utilizamos para indicar mediante un pitido del zumbador que el programa se ha iniciado.

El resto del programa se incluye dentro del bucle DO…LOOP lo que indica que se ejecutará una y otra vez. El programa le pide al operador del terminal DEBUG (nosotros) que introduzcamos un valor decimal que determinará la duración del pulso que se va a guardar en la variable pulseWidth. Para lograr una medición del tiempo más exacta se envían dos comandos PULSOUT cuyos argumentos Duración sumarán 1500 entre los dos

                pulseWidthComp = 1500 – pulseWidth

Así se consigue que el bucle FOR…NEXT tarde siempre el mismo tiempo en ejecutarse independientemente del valor del argumento Duración que hayamos introducido y, por tanto, que las mediciones de las RPM que hagamos sean más exactas. Este bucle FOR…NEXT envía pulsos al servo izquierdo (P12) durante 6 segundos. El valor de la variable pulseWidthComp se envía al servo derecho (P13), haciendo que gire en la dirección contraria.

En el paso 4 vimos cómo se calculaba el tiempo: recordemos que el argumento Duración del comando PULSOUT se expresa en unidades de 2 millonésimas de segundo por lo que un valor de 650 envía pulsos de 1,3 ms de duración (a lo que es lo mismo 1300 ms).

Con los datos que vayamos obtenido vamos a completar la siguiente tabla para obtener nuestra propia curva de transferencia (debemos tener en cuenta que nuestro programa de ejemplo controla la rueda izquierda con los valores que introducimos. La rueda derecha gira en dirección contraria).


336 watermark 320x240 tabla de control de velocidad Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Con la idea de facilitarles el trabajo he creado la tabla en formato excel para manejar mejor los datos y poder trasladarlos luego a cualquier programa de generación de gráficos. Puede descargarse aquí (la contraseña para abrirla es “afanporsaber”).

Una vez completada la tabla para la rueda izquierda, debemos modificar el comando PULSOUT para enviar el pulso a la rueda derecha, cambiando los parámetros como se indica

                PULSOUT 13, pulseWidth

                PULSOUT 12, pulseWidthComp

realizando a continuación las mismas mediciones.


337 watermark 320x240 curva de transferencia Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

Debemos tener en cuenta que los valores positivos de RPM se dan cuando la rueda gira en el sentido de las agujas del reloj, mientras que los valores negativos indican un giro de las ruedas en sentido antihorario. Recordar igualmente que, dada la disposición de los servos, para que el robot ande hacia adelante la rueda derecha tendrá que girar en sentido de las agujas del reloj, mientras que la izquierda en sentido antihorario.


One thought on “Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones

  1. Pingback: Pasos 5.1, 5.2 y 5.3 Diversas comprobaciones | …

Deje un comentario