Archivo de la categoría: Didáctica

Robots: Visión estereoscópica en tiempo real por medio de una cámara única

Este escueto artículo, basado en un original en inglés de Nelson Bridwell (Mirage Robotics, LLC). Lamentablemente su artículo ya no está en internet, o no lo encuentro en el enlace que tenía), aporta, creo yo, algunos conceptos interesantes, y nos muestra una idea aplicable a nuestros trabajos.

Una de las dificultades de la visión estereoscópica en tiempo real, para nada trivial, es lograr la adquisición simultánea de imágenes sincronizadas a partir de dos cámaras en dos posiciones separadas.

La posibilidad de lograr esto con una cámara única y un espejo, ubicados en una disposición de geometría simple, es una solución poco conocida.

Vista lateral de la distribución geométrica del espejo y la cámara

Vista lateral de la distribución geométrica del espejo y la cámara

Estéreo cabeza abajo

Debido a que los obstáculos y objetos de interés por lo general no están ubicados por encima de un robot móvil, puede ser una buena idea montar la cámara en la parte superior, debajo de un espejo cuya parte reflectora apunta hacia el piso. Esto nos aportará una visión estéreo despejada del espacio de navegación.

Imagen de ejemplo

Imagen de ejemplo

Esta disposición puede tener el beneficio adicional de aislar la cámara del resplandor de la luz del ambiente, lo que resultará en un mayor rango de intensidades en los objetos de alrededor.

También debería minimizar el oscurecimiento del espejo a causa de la acumulación de polvo en su superficie.

Vista lateral del montaje sobre un robot

Vista lateral del montaje sobre un robot

Visión estereoscópica múltiple

Visión múltiple

Existiendo una variedad de bibliotecas de procesamiento de imagen, la determinación de distancia y posición no debería ser una gran dificultad si se programa en un microcontrolador con capacidad suficiente para recibir los cuadros de video y compararlos. Por ejemplo, habría que echarle una mirada a MATLAB_Arduino. Otra opción (mucho más simple porque la cámara ya se ocupa del procesamiento de las imágenes) sería utilizar una cámara Pixy para medir distancia, ya que solo es necesario comparar valores aportados por la Pixy en formato texto, con las posiciones XY de un polígono; o un par de cámaras para obtener posición en el entorno y distancia. Todo en tiempo real.

La cámara Pixy es provista con un cable especial para enchufarla directamente en un Arduino, y un cable USB para conectarla a una Raspberry Pi, para que se pueda comenzar rápidamente. Y si no trabaja con Arduino o Raspberry Pi, no hay problema. La Pixy tiene varias interfaces (SPI, I2C, UART y USB), y sus comunicaciones son simples, por lo que en poco tiempo se logra la comunicación de la cámara con el microcontrolador elegido.

Más adelante publicaré un artículo con mis experiencias y diseños realizados en base a la cámara Pixy.




Novedades sobre App Inventor y Play Store

Google lanzó recientemente una nueva política de Play Store que afectará a algunas aplicaciones de App Inventor.

Todas las aplicaciones que utilizan el componente de mensajes de texto o llamada telefónica y se publican en Play Store deben reconstruirse. El equipo de MIT App Inventor está realizando un cambio en PhoneCall y Texting para ayudar a nuestros usuarios a lidiar con esta política de Google.

¿Cómo afectará esto a mis aplicaciones de App Inventor y qué debo hacer?

Con el cambio de Google, si crea una aplicación App Inventor que utiliza componentes de teléfono o mensajes de texto, no podrá enviarla a Google Play.

El equipo de MIT App Inventor está cambiando los componentes de Texting y PhoneCall para que las aplicaciones recién creadas cumplan con las restricciones de Google y puedan enviarse a Play como antes. Actualmente estamos probando los cambios y los lanzaremos en App Inventor pronto, en febrero de 2019.

Google también planea eliminar de Play las aplicaciones que violan su política. Si eso te sucede, deberás esperar el cambio a App Inventor, y luego reconstruir tu aplicación y volver a enviarla a Play.

¿Cuál es el cambio de política de Google Play Store?

El cambio de Google es que ya no permitirán aplicaciones en Play Store que envían directamente mensajes de texto (SMS) o hacen llamadas telefónicas. En su lugar, debe invocar la aplicación integrada de mensajes de texto (o llamada telefónica) del dispositivo. Por ejemplo, ya no será aceptada en Play Store una aplicación que envíe periódicamente mensajes de texto sin notificar al usuario del teléfono, y Google también puede eliminar las aplicaciones que se encuentran actualmente en Play Store. Google también ha creado un proceso en el que los desarrolladores pueden completar un formulario solicitando que se permita su aplicación como una excepción a la política.

Busque aquí la información que Google ha proporcionado:

https://support.google.com/googleplay/android-developer/answer/9047303

¿Se comportarán mis aplicaciones de manera diferente después de que se cambie App Inventor?

Sí, habrá un cambio. Cuando use Texting.SendMessage, el teléfono ahora dirigirá el mensaje a la aplicación normal de envío de mensajes de texto del teléfono. Del mismo modo para Phone.MakePhoneCall.

¿Puedo seguir utilizando App Inventor para crear aplicaciones que violen la política de Google para Play?

Sí.

El cambio de MIT a App Inventor incluirá versiones alternativas de Texting.SendMessage y Phone.MakePhoneCall que envían directamente mensajes de texto y hacen llamadas telefónicas. Puede crear aplicaciones con estas versiones alternativas y compartirlas con sus amigos y familiares. Pero necesitaría pedirle a Google una excepción de política para publicar esas aplicaciones en Play Store.

El MIT publicá un aviso cuando estas funciones estén en la página de App Inventor.

Más información sobre posibilidades de desarrollo con App Inventor

Imprimen en 3D partes mecánicas útiles con polvo similar al de la Luna

Un futuro en la luna

Para respaldar una base lunar futura y potencial, los investigadores de la Agencia Espacial Europea (ESA) imprimen en 3D y hornean polvo similar al de la Luna para formar tornillos, engranajes e incluso una moneda.

Tanto las agencias espaciales privadas como las gubernamentales han expresado serias intenciones y comenzaron a desarrollar planes para construir una base habitada por humanos en la Luna. Pero se necesita mucho combustible, capacidad de carga y dinero para lanzar cosas al espacio y bajarlas en la luna. Y construir una base lunar desde cero requerirá una gran cantidad de materiales. Por lo tanto, sería extremadamente caro llevar todas estas partes de la Tierra a la Luna, especialmente porque el mantenimiento requerirá piezas de respaldo para las reparaciones.

Es por esto que los investigadores están investigando una opción más sostenible. En lugar de llevar cosas, podríamos hacerlas usando polvo de Luna o regolito, como alimentación para una impresora 3D. De esta manera podrían crear materiales de construcción de forma económica y sencilla en la propia Luna.

Para practicar, el equipo de la ESA imprimió en 3D artículos como tornillos y engranajes con polvo lunar falso. Aunque sus propiedades difieren de las del suelo terrestre, el regolito lunar no es demasiado difícil de simular, y se le puede dar forma de objetos utilizables a los óxidos de silicio, aluminio, calcio y hierro presentes.

Cómo imprimir en 3D con polvo lunar

Para imprimir en 3D con polvo de luna falso, el equipo comenzó con un regolito hecho por el hombre. El polvo se trituró hasta el tamaño de partícula y los granos resultantes se mezclaron con un agente aglutinante que reacciona a la luz. Luego, una impresora 3D colocó la mezcla en capas hasta que tomó forma el objeto deseado. Luego se expuso el artículo a la luz para que se endureciera, y se coció en un horno para solidificarlo por completo.

El producto terminado es como una pieza de cerámica de polvo de Luna, dice la ESA en un comunicado. Estas piezas iniciales han demostrado que es probable que se impriman con el regolito real de la Luna en una base lunar, y son parte del proyecto URBAN, más grande, que examina cómo la impresión 3D podría ayudar a la colonización lunar.

VER VIDEO

«Si uno necesita imprimir herramientas o piezas de maquinaria para reemplazar las piezas rotas en una base lunar, la precisión en las dimensiones y la forma de los elementos impresos será vital», dijo el ingeniero de materiales de la ESA Advenit Makaya en el comunicado.

Esta será una ventaja crítica para futuras misiones con destino a la Luna. Especialmente, para estadías prolongadas proyectadas en el satélite terrestre, aquellas cosas están destinadas a romperse o fallar. Si un solo tornillo se pierde o se rompe, es posible que la cuadrilla no tenga tornillos adicionales con la forma y el tamaño exactos necesarios. Al crear la pieza exacta requerida usando el regolito que los rodea, la tripulación podría mantener de manera sostenible las reparaciones en una base lunar.


Algunas notas sobre programación del robot didáctico programable

En esta publicación: Robot Programable: Diagrama Básico en Bloques prometo, al final, que voy a continuar con los detalles de circuito y de programación. En la entrada: El microcontrolador «cerebro» del robot programable (básico) hay mucho de circuito (hardware), ya que el artículo contiene una descripción bastante detallada de las secciones del chip microcontrolador que utilizamos por ahora, y también detalles de configuración y uso del chip que tienen una enorme relación con la programación.

Concretamente, que algo he cumplido de la promesa.

Los artículos hasta ahora venían más o menos sincronizados con el avance de las clases, pero para esta fecha obviamente estamos en receso de verano y no hay actividad, ni la habría aunque me lo propusiera, ya que por suerte los chicos asisten a una colonia de verano. A mí tampoco el calor me favorece mucho para mover las neuronas, por eso estuve dedicando algunos artículos a la mecánica, a la búsqueda de soluciones para abaratar la construcción de la base mecánica del robot.

De eso aún falta, me quedan algunas cosas por solucionar, y me dedico casi diariamente al tema. Ya les contaré.

El robot programableRobot programable

Pero hay un programa básico ya escrito con el que hemos trabajado en clase, haciendo mover al robot. Este programa (escrito en assembler, o ASM) permite ordenar una secuencia de movimientos al robot. El programa tiene tres niveles: 1) las instrucciones básicas para mover los motores en el lenguaje del microcontrolador (son las mismas para toda la familia PIC16F, y se podrían utilizar en todos los modelos disponibles, si bien nuestro chip elegido es el PIC16F876A), 2) la inclusión posterior de las instrucciones básicas dentro de subrutinas a las que se puede llamar programando con palabras en castellano en lugar de con los mnemónicos de la programación ASM, lo cual facilita la comprensión, y finalmente 3) la conversión de estas subrutinas en macros.




Utilizando macros se programa directamente con la palabra que hemos definido para el comando; ni siquiera hace falta utilizar la instrucción CALL de ASM que se necesita para hacer correr una subrutina.

Voy a explicar poco a poco la programación, en todos los pasos.

Primero que nada: la configuración inicial del chip

Recordemos primero el diagrama en bloques, ya que hay que definir las funciones de las patas del chip teniendo en cuenta este circuito.

Diagrama básico en bloquesDiagrama en bloques
Veamos las instrucciones ASM en la parte de configuración:

 

Es conveniente que vayamos explicando las líneas de instrucciones por partes:

La indicación list P es muy directa, con ella se le dice al programa de compilación que vamos a trabajar en un programa para el PIC16F876A.

La indicación include incluye en el programa, en el momento de compilarlo, todo el texto que se encuentra dentro del archivo que se indica a continuación P16f876a.inc. En estos archivos (provistos por el fabricante) se definen nombres en letras para todas las partes del microcontrolador, que de otro modo deberían estar indicadas en el programa con números hexadecimales. Esta práctica evita el trabajo de estar memorizando o buscando en una tabla estos números, y facilita la comprensión al leer el programa, y permite un fácil intercambio de programas (migración) entre diferentes microprocesadores.

Por ejemplo, dentro de P16f876a.inc define así al puerto A: PORTA EQU H’0005′. Podríamos cambiar la declaración dentro de este archivo y llamar al puerto con un nombre en español, por ejemplo: PuertoA EQU H’0005′. Luego podríamos programar utilizando este nombre y funcionaría correctamente.


Esta línea no es imprescindible y se utiliza para evitar molestas indicaciones de aviso cuando se cambia de banco de RAM en el programa. Las indicaciones no son necesarias si en el programa hemos realizado correctamente los cambios de banco.


Los microcontroladores poseen una serie de configuraciones que se fijan por única vez al principio de la operación y definen ciertas partes esenciales de su funcionamiento. En el ejemplo:

_CP_OFF (Code Protection) define que no protegeremos el código de ser leído desde la memoria de programa del chip. Es posible definir _CP_ON cuando ya tenemos un programa totalmente probado en un equipo que vamos a entregar y no deseamos que alguien se lo copie leyéndolo desde la memoria de programa del microcontrolador.

_XT_OSC define el modo de oscilador de reloj del chip. En este caso, la opción _XT_OSC indica que se utilizará un cristal o resonador conectado al chip para definir la frecuencia de trabajo.

_WDT_OFF está relacionado con la función de «Despertador» («Watchdog timer» en inglés) que se utiliza en aquellos casos en que se desea que el microcontrolador sea «despertado» de posibles estados en que haya quedado detenido, sea porque quedó esperando una señal de activación externa o porque falló su programa o porque se lo puso intencionalmente en ese estado por programa. El watchdog timer (WDT) puede producir un reinicio del microcontrolador PIC cada cierto período de tiempo, y recomenzar la ejecución del programa. Esto es para evitar que el dispositivo entre en un lazo infinito (se «cuelgue»), o se quede en una espera muy prolongada por un determinado evento que no ocurre. Durante la operación normal, el watchdog timer (en español «perro guardián» o «despertador») genera un reinicio del microcontrolador PIC después del final de su período WDT. También cumple la función de sacar al dispositivo del modo Sleep («Dormir»). En este caso el watchdog timer ocasiona que se despierte el microcontrolador PIC y continúe con la operación normal (sin producir reinicio), lo que se conoce como despertar WDT. No lo utilizamos en este programa en particular, de modo que fijamos _WDT_OFF, o sea, Watchdog Timer apagado.

_PWRTE_ON (Power-up Timer) Habilita un temporizador que se dispara en el encendido y permite que, durante su espera, se estabilicen todos los circuitos antes de comenzar a correr el programa.

_LVP_OFF define el modo en que se puede programar el chip. Esta definición en OFF determina que no se puede programar el chip utilizando un sistema de programación de bajo voltaje. Los programadores de PICs utilizan un voltaje de 12 volts en la pata MCLR del chip para poder escribir en su memoria de programa. Al definir el estado OFF de esta configuración se previene una programación accidental (que modificaría el programa y dejaría no operativo al microcontrolador) con los voltajes estándar de funcionamiento en sus patas.

_BODEN_OFF El bit BODEN (Brown Out Reset) en la configuración define la activación o no de una detención del microcontrolador por un descenso de voltaje de alimentación. Puede ser útil, pero no lo utilizamos en este diseño, por eso lo definimos en OFF.


En este bloque se declaran las variables que necesitaremos utilizar (y se reservan sus espacios en la memoria RAM). Por defecto, las variables son bytes (8 bits).


Las líneas de inicialización en este bloque están ampliamente explicadas con comentarios. En la última parte, debo aclarar que los registros TRIS son los que definen si una pata de entrada/salida es una entrada o una salida. Hay un registro TRIS para cada puerto: TRISA, TRISB y TRISC. Un 0 las define como salidas, un 1 las define como entradas. Por último, los microcontroladores con puertos cuyas patas se pueden definir como entradas al módulo Convertidor Analógico Digital (Analog/Digital Converter, o ADC, en inglés) tienen un registro de configuración en el que se debe definir si se utilizarán o no esas patas como entradas analógicas. Esto lo define el registro ADCON1 y el valor a definir para utilizar todas las patas como entrada/salida digital (tal como las utilizaremos por el momento) es 0x06 (hexadecimal 06).

Esencial: La parte del programa en sí

Observando el diagrama en bloques del robot programable, y con una lectura al artículo de apoyo sobre el chip de manejo de motores, podemos determinar que uno de los motores, el derecho, se maneja a través de dos patas del puerto A, RA0 y RA1, y el otro (izquierdo) a través de las patas RA2 y RA3 del puerto A.

La tabla de señales de control para los motores es como sigue:

     MOTOR DERECHO     
|
       MOTOR IZQUIERDO       
    RA0     RA1     ACCIÓN | RA2 RA3 ACCIÓN
    1     0     AVANCE | 0 1 AVANCE
    0     1     RETROCESO | 1 0 RETROCESO
    0     0     DETENIDO | 0 0 DETENIDO
    1     1     DETENIDO | 1 1 DETENIDO


Por lo tanto, las instrucciones de manejo de los motores se pueden definir del siguiente modo:

Para realizar un movimiento necesitamos definir tiempos, y para eso, para empezar, podemos utilizar un simple rutina de «pérdida de tiempo» (el microcontrolador se queda «perdiendo tiempo» dentro de esta subrutina, y no hace ninguna otra cosa). La rutina la calculé utilizando los servicios del sitio Delay Code Generator donde se puede crear un código de retardo para PICs definiendo algunos parámetros (en el futuro usaremos un módulo TIMER del microcontrolador, pero cada cosa a su tiempo).

La rutina de pérdida de tiempo es:


Veamos entonces cómo es un programa que utilice estas subrutinas para ordenar al robot un movimiento en L.


El programa completo en ASM con el método de llamado a subrutinas es el que sigue. Más abajo encontrarán un enlace para bajarse el archivo en formato TXT con el programa completo en ASM listo para compilar. En el próximo artículo presentaré la conversión del programa al método de programación con MACROS y una serie de ejemplos de programas con distintas rutinas de movimiento.


El archivo ASM se puede bajar de AQUÍ.

Base robótica

Construir un robot sobre un chassis comprado, que ya tiene los elementos necesarios, es mucho más fácil que crear su mecánica: se necesita habilidad de manipuleo, las herramientas correctas y precisión en el trabajo

Si queremos crearlo a partir de materiales de desarme, ya es otra cosa. Un robot necesita una base donde montar la estructura. La plataforma en sí no es un gran problema, se puede recortar de partes de cajas de monitores, impresoras, frentes de PCs, bandejas de CR-ROM, chassis y tapas de discos rígidos, etc. No necesita tener tantas perforaciones y ranuras como tienen las plataformas comerciales. Agujereamos según las necesidades.

La imagen lo ilustraChassis comprado

El problema cuando se busca obtener todos los materiales desde la recuperación de elementos de equipos descartados son las otras tres partes: dos motores con reducción, sus ruedas y una rueda de giro libre, o rueda loca.


En la serie de artículos de los últimos tiempos estuve tratando sobre la recuperación de motores con reducción que puedan adaptarse a un robot didáctico. Quien los haya leído, se habrá dado cuenta de que no es tan fácil como parece, ya que la mecánica de las unidades de CD-ROM, de discos rígidos y de disketteras suele ser muy variada. Cuesta mucho conseguir los pares para cada robot. Deben ser idénticos en lo mecánico y también eléctricamente, aunque compensar las diferencias en la parte eléctrica es más fácil.

Los artículos hasta ahora fueron:

Así que los próximos movimientos deben estar orientados a conseguir ruedas que se adapten a los mecanismos de motor y engranaje que he rescatado de unidades de CR-ROM. No deberían ser compradas (aunque sí pueden provenir de donaciones), o entramos a la situación de crear un robot que no esté formado de partes rescatadas; y este es el programa propuesto.

Otro elemento a lograr es la rueda libre, o rueda loca. El tercer punto de apoyo del robot. Luego vienen los portapilas, y finalmente la electrónica. Son los temas que iré tratando en unas pequeñas notas que seguirán. Hay diversas opciones, pero la elegida no debe hacernos muy esclavos en tiempo de trabajo: las horas-hombre tienen valor cuando no se tiene un mecenas que te mantenga.

Ejemplo de rueda loca compradaRueda loca

Próximamente, un elemento que por simple no se aleja de ser crítico: Ruedas para el robot didáctico.

Ejemplo de base y rueda loca caserasBase y rueda loca caseras