Sensor de profundidad. Pan&Tilt 2

Estaba yo pensando… ¿Cómo controlamos esto?

Para generar el tren de pulsos descrito en el post anterior se puede usar el PWM (Pulse Width Modulation) que suele incorporar como periférico prácticamente cualquier microcontrolador orientado al entorno industrial.

Conozco bien la familia de procesadores ColdFire de Freescale, ahora incorporada a NXP, por haberla usado muchas veces en mi trabajo. Tenía por casa una Tower del MCF54418 y esto me permitió poner en marcha el invento rápidamente. Es una lástima que estos procesadores, herederos de la arquitectura del 68000 de Motorola se hayan visto desplazados por los ARM.

Hace ya tiempo que Freescale empezó a comercializar las tarjetas de evaluación de la familia Tower. Consiste en una serie de tarjetas que montan sus procesadores y que pueden ser instaladas junto con otras que incluyen periféricos formando una torre de tarjetas conectadas a través de unos buses trazados en las tarjetas laterales. De esta manera, se pueden montar distintos equipos compuestos por una tarjeta de procesador y por una, o varias, tarjetas de periféricos.

Lo verdaderamente interesante de este prototipo es el sistema operativo, MQX. Hace ya tiempo que Freescale, poco después de la compra de WindRiver por parte de Intel (¿casualidad?), empezó a promover el uso de MQX en sus micros. Lo distribuye en código fuente y puede ser usado de manera gratuita con sus herramientas de desarrollo para la mayor parte de sus micros. Está orientado al tiempo real y muy bien estructurado, yo diría que a la altura de los buenos. Otro día hablaremos de MQX.

Explicar los detalles del programa que hice para esta ocasión y de la configuración del PWM sería un poco aburrido y tampoco es el objetivo. El PWM es un dispositivo ingenioso basado en simples contadores y comparadores hardware que puede dar mucho juego. Se basa en la capacidad de cambiar los estados de alguna señal de salida o generar alguna interrupción cuando algún contador coincide con el valor configurado en algún registro. En un controlador potente, como es éste, hay varias salidas, varias entradas, varias interrupciones, varios contadores, varios registros, … y muchísimas posibilidades de configuración.

El programa que he generado en esta tarjeta me va a servir para probar los servos, es decir, verificar cómo funcionan, probar su rango de movimiento, hacer pruebas a distintas velocidades, identificar sus restricciones mecánicas o de la plataforma, etc

Para esto, he programado varios comandos que se pueden teclear a través de una consola desde un ordenador que ejecuta un programa como el HyperTerminal (aún le soy fiel, igual que a mi máquina Windows XP) y se conecta a la tarjeta a través de una conexión RS232.

Para manipular los servos he montado en la Tower una tarjeta TWR-PROTO. En esta tarjeta he conectado dos salidas asociadas a los PWMs A y B del micro a través de un buffer para adaptar los niveles de tensión a dos conectores de astas donde conecto los cables de los servos. Las salidas de este micro son de 3,3V y los servos se alimentan a 5V y esperan en la señal de control también 5V. Además incluyo unas resistencias en serie de 200 Ohm para proteger las salidas del micro y del buffer.

He usado las señales que salen del micro en los pines A10 (función alternativa 1 PWM_A0) y C11 (función alternativa 1 PWM_B0) a través de los pines del conector principal de la TWR-PROTO A40 y A39 respectivamente. Cada pin de Entrada/Salida del procesador MCF54418 en encapsulado 256 MAPBGA que monta la tarjeta de evaluación TWR-MCF5441X permite ser usado para varias funciones: como GPIO o como otras dos funciones alternativas dependientes de cada pin. En este caso hay que configurar el micro para que internamente conecte estos dos pines a las salidas 0 de los PWM A y B respectivamente.

Así es como ha quedado la tarjeta TWR-PROT y la TOWER completa.

Tower_protoTower_y_sensor

Acabo de describir el interface entre esta tarjeta, que hace de controlador de la plataforma de pan&tilt, y los servos. Ahora hablaré sobre el interface entre el software que controla el sensor de profundidad y este controlador de la plataforma.

Es muy sencillo. Conecto el PC Linux que corre el programa que adquiere las instantáneas de profundidad con la Tower a través de un cable serie como si éste fuera una consola. El programa antes de tomar la foto posiciona la plataforma componiendo un comando que envía por el dispositivo “/dev/ttyUSB0” tras haber sido convenientemente configurado.

Esta no es la mejor manera, desde luego, de comunicar dos dispositivos pero sí me permite resolver la comunicación de una manera rápida y dedicar mis esfuerzos y mi tiempo a lo que realmente es el objetivo del experimento. Además, está por definir una arquitectura para un equipo integrado que realice estas dos funciones que ahora estoy implementando en dos equipos. Hablaremos de esto en el último post de esta serie.

Para manejar la tarjeta he generado varios comandos de consola:

  • pwminit. Inicializa los PWM y genera la salida de los servos que corresponde a la posición de reposo de la plataforma.
  • pwmbseta y pwmsetb. Estos comandos toman como argumento el ancho del pulso en microsegundos y configuran el PWM correspondiente para que genere el pulso del ancho indicado. Estos comandos los he usado desde la consola para tener control completo de los servos y así poder verificar el correcto funcionamiento de hardware y software, caracterizar los servos, identificar restricciones mecánicas en el movimiento y ajustar límites para proteger los servos y la plataforma.
  • pwmsetpos. Este comando toma dos argumentos en “unidades de ingeniería”, es decir: grados. Está orientado a ser usado desde la aplicación, que necesita apuntar el sensor hacia un punto determinado de la escena sin necesidad de conocer el funcionamiento interno del controlador o de los servos. Cada uno de los argumentos puede ser positivo o negativo y especifica, en grados, el giro que debe imprimirse a la plataforma en sus movimientos de pan y tilt respecto a una posición de referencia establecida como el punto 0,0.

De esta manera, para hacer el barrido de la escena que queremos escanear, se configuran en la aplicación las posiciones desde las que se tiene que tomar la foto. El programa posiciona el sensor haciendo uso del comando pwmsetpos, espera un segundo para evitar vibraciones que puedan afectar a la calidad de la medida, toma una instantánea que graba en un fichero como ya he explicado en un post anterior y se posiciona en el siguiente punto. Tras cubrir toda la ruta configurada, tendremos la colección de ficheros que se usaran para componer la escena completa. La composición de esta escena será el objetivo del siguiente post.

Para ilustrar el movimiento de la plataforma, he grabado un video en el que se ve el movimiento de los dos servos. Podéis descargarlo del siguiente enlace.

Antes de dar el post por acabado, me gustaría comentar alguna cosilla:

  • Los movimientos de la plataforma son un poco bruscos. Acostumbrado a ver los movimientos de los robots industriales con una velocidad, suavidad y precisión asombrosas, confieso que me sentí un poco decepcionado cuando vi que con los servos seleccionados no era fácil controlar la velocidad del movimiento por tramos desde el punto inicial hasta el final. Para mejorar esto creo que habría que trabajar en dos aspectos:
    1. Sustituir los servos cásicos que yo he usado por servos digitales que admiten, de manera nominal, un tren de pulsos de 300Hz con lo que la resolución en el tiempo se multiplica por 6.
    2. Si la posición del servo estuviera realimentada con un encoder, se podría cerrar un bucle de control e implementar un PID
  • Si el objetivo hubiera sido controlar un servo, o varios, desde un PC, se podría haber usado alguno de los controladores por USB que podéis encontrar en Robotshop. Lo que yo quería era tener control directo sobre la señal de control de los servos desde un dispositivo ágil, con latencias máximas predecibles y ajeno a la carga de proceso de otros subsistemas. En el último post de esta serie hablaré sobre la arquitectura de un posible producto.
  • También se podría haber pensado en ir grabando frames en un movimiento continuo del sensor y luego procesarlos pero, por un lado, no tengo datos sobre la capacidad del sensor de adquirir información mientras se mueve y, por otro, tener parado el sensor en una posición conocida facilita el tratamiento de la integración de una instantánea sobre otra, como veremos en el siguiente post.

About Juan Serrano

Juan Serrano es especialista en ingeniería eléctrica y en el diseño y desarrollo de equipos de telecontrol
This entry was posted in Broadcasting, Depth sensors, Sensors and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *