PicassoBOT: Memoria de Proyecto · 2020. 2. 6. · PicassoBot es un brazo electro-mec´anico de dos...

Sistemas Embebidos para Tiempo Real Memoria de Proyecto

UNIVERSIDAD DE LA REPUBLICA

FACULTAD DE INGENIERIA - INSTITUTO DE INGENIERIAELECTRICA

SISTEMAS EMBEBIDOS PARA TIEMPO REAL

PicassoBOT: Memoria de Proyecto

Daniel LopezPaola Massonnier

Lucıa Sirio

Tutor: Mauricio Gonzalez

Facultad de Ingenierıa 1 Universidad de la Republica


1. Resumen

PicassoBot es un brazo electro-mecanico de dos articulaciones compuesto por servos modelo DinamixelAX-12 de Robotis, y disenado por los autores del presente proyecto. El mismo se encuentra inspirado en “Paulthe robot” desarrollado por el artista Patrick Tresset, enmarcado en el proyecto AIKON desarrollado por elDepartamento de Computacion de la Goldsmiths College (Londres, UK). “Paul the robot” es un brazo roboticoque dibuja retratos humanos gracias a una capa de procesamiento invisible para el usuario.

El proyecto implica desarrollar un sistema de control de movimiento para los servos, tomando como entra-da un archivo .txt que contiene los comandos a ser ejecutados, en el lenguaje grafico de plotters e impresorasHPGL de Hewllet-Packard. La salida resultante: la ejecucion de movimientos mediante los cuales se represen-tan figuras basicas como rectas y cuadrados.

Las capas de procesamiento fueron implementadas en dos entornos: el programa Octave para calculosmatematicos, y en el software Code Composer Studio para interactuar con el microcontrolador MSP430, deTexas Instruments. Se implementa la interaccion entre los mismos mediante interfaces de puertos seriales.Octave se encarga del procesamiento de la sintaxis HPGL, mientras que el MSP430, conforma el mensajedestinado a los servos y lo transmite a traves de un modulo de comunicacion UART implementado por software.



Indice

1. Resumen 2

2. Introduccion 5

3. Objetivos 5

4. Alcance 5

5. Protocolo de comunicacion del servo Dynamixel AX-12 6

6. Breve introduccion al lenguaje grafico de plotters HPGL 7

7. Diseno 77.1. Descripcion del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87.3. Modulos software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

7.3.1. Ingreso de comandos HPGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107.3.2. Parametrizacion del plano de dibujo . . . . . . . . . . . . . . . . . . . . . . . . . . . 107.3.3. Adquisicion de datos desde el MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . 117.3.4. Comunicacion y procesamiento de datos en el MSP430 . . . . . . . . . . . . . . . . . 117.3.5. Sistema de comunicacion entre MSP430 y el servo Dynamixel AX-12 . . . . . . . . . 11

8. Implementacion 138.1. Modulos en Octave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

8.1.1. Lectura de HPGL y ajuste de los datos . . . . . . . . . . . . . . . . . . . . . . . . . . 148.1.2. Conversion a coordenadas cilındricas en la base del servo . . . . . . . . . . . . . . . . 158.1.3. Transmision por puerto serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8.2. Modulos en el MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168.2.1. UART hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168.2.2. Traductor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178.2.3. UART por software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

9. Pruebas 199.1. Testeo del modulo UART por software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199.2. Testeo del modulo “conformacion de mensaje” . . . . . . . . . . . . . . . . . . . . . . . . . 219.3. Testeo de parametrizacion de coordenadas de dibujo . . . . . . . . . . . . . . . . . . . . . . . 219.4. Prueba Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

10. Conclusiones 25

11. Anexo 2611.1. Contratiempos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

11.1.1. Problemas con el Level-Shifter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2611.1.2. Problemas de transicion del ultimo byte . . . . . . . . . . . . . . . . . . . . . . . . . 2611.1.3. Problemas de Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

11.2. Conceptos del curso aplicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2611.3. Planificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2711.4. Cuadro comparativo de lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28



11.5. Parametrizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3311.6. Lista de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

12. Referencias 38



2. Introduccion

Actualmente el ambito de la robotica se especializa en el desarrollo de dispositivos pequenos, con inteli-gencia artificial, de bajo costo y facil construccion. En esta lınea es que surgen varias iniciativas tecnologicasen areas muy variadas de intereses no solo mecanicos, computacionales y electricos, sino que tambien se hanincorporado a ambitos multidisciplinarios de otras especialidades para todas las edades y profesiones. A partirde esta variedad disciplinar y de la creciente tendencia hacia mecanizar dispositivos que repliquen comporta-mientos humanos, surge la idea de desarrollar un brazo robotico que simule el movimiento del ser humano enel dibujo al natural. En particular, relacionado con el proyecto de SISEM se introduce como antecedente eldispositivo desarrollado por el Proyecto AIKON.

El Proyecto AIKON surge de parte del artista Patrick Tresset quien decidio vincular sus dos pasiones: lacomputacion y el arte en un solo proyecto. En el Departamento de Computacion de la Goldsmiths College(Londres, UK) Patrick y su equipo desarrollaron satisfactoriamente un brazo robotico que dibuja trazos simu-lados de un humano a partir de una entrada de videocamara a tiempo real. El dispositivo, denominado Paul elrobot (Paul the robot) es una instalacion robotica que produce retratos observacionales de personas. Ademas, larealimentacion por camara le permite al robot mejorar iterativamente un dibujo que inicialmente se construyede un proceso silencioso de recuperacion de lıneas.

Es inspirado en este sistema que surge la idea del proyecto de grado, y tambien el objetivo del presenteproyecto final de SISEM: Disenar, desarrollar y armar un brazo robotico que ejecute movimientos sujetando unlapiz o lapicera contra el papel simulando un trazo, a partir de comandos de impresion ingresados al sistema.

3. Objetivos

Implementar el software de un prototipo robotico articulado conformado por dos servos Dynamixel AX-12de Robotis, estableciendo una comunicacion entre una computadora, el microcontrolador MSP430 y los servos,de forma tal que se pueda controlar el movimiento de ambos motores. El brazo robotico tiene por un lado unextremo fijo a la mesa, y por el otro un extremo libre con un lapiz o lapicera cubriendo un plano de dibujo a sualcance.

4. Alcance

En el marco del proyecto de la asignatura y de lo acordado con el tutor Mauricio Gonzalez, previo alinicio formal del proyecto, se construye un pequeno prototipo conformado por dos servos y ensamblado conlos propios brackets (soportes) de estos. Se aclara que las horas de montaje de este hardware y cualquier otroadicional que sea necesario estan comprendidas dentro de las horas de dedicacion al proyecto de grado, y node SISEM, si bien se explicara brevemente el funcionamiento de algunas piezas para la mejor comprension delsistema completo.

Posteriormente se implementara la comunicacion entre la computadora, el microcontrolador MSP430 y di-chos servos con el fin de configurar una comunicacion serial a traves de la terminal UART del microcontroladory el puerto USB de la computadora, teniendo en cuenta que los servos manejan un protocolo de tipo Half duplexAsynchronous Serial Communication (8bit, 1stop, No Parity).

Una vez establecida la comunicacion del sistema, se programara una primera capa en software donde semoveran los servos girando una cierta cantidad de grados. Luego, se programara una segunda capa de software,a partir de una biblioteca desarrollada por el grupo, y basada en el lenguaje grafico de plotters HPGL. Es decir,se espera que finalmente el prototipo sea capaz de realizar movimientos ejecutando comandos de un archivohpgl (es decir archivo de extension .txt de sintaxis HPGL) desde una computadora.

Se deja como meta opcional realizar una realimentacion de datos desde los servos, aprovechando que estospueden tomar datos tales como temperatura, velocidad o posicion, para procesarlos y comprobar que la acciones



de movimientos sean exitosas.

5. Protocolo de comunicacion del servo Dynamixel AX-12

Los servos utilizados para armar el brazo son modelo Dynamixel AX-12 de Robotis; estos reciben y trans-miten paquetes digitales por su pin DATA (ver Figura 1), mediante protocolo half duplex de comunicacionserial asıncrona de 8 bits, un bit de parada y sin bit de paridad.

Figura 1: Diagrama de pines de entrada y salida del servo Dynamixel AX-12. (Extraıdo de [1]).

La estructura de los paquetes de instruccion validos para el servo es la siguiente:

Figura 2: Formato del paquete de instruccion esperado por el Dynamixel AX-12 (Extraıdo de [1]).

Cada campo de la figura 2 indica un byte hexadecimal cuyo significado se describe a continuacion.

0xFF 0xFF: estos dos bytes indican el inicio de un mensaje valido.

ID: byte en el rango 0x00 a 0xFD. Numero que indica el servo destinatario del mensaje. 0xFE ID debroadcast.

LENGHT: largo en bytes del mensaje, el cual cuenta desde el byte de INSTRUCTION hasta el byte deCHECKSUM inclusive.

INSTRUCTION: la instruccion a ser ejecutada por el servo.

PARAMETERS1..N: usado si la instruccion enviada requiere de informacion adicional para su ejecu-cion.

CHECK SUM: este byte representa el fin del mensaje. Su calculo esta dado por la suma logica: CheckSum=∼(ID+LENGHT +INST RUCT ION+PARAMET ER1+ ...+PARAMET ERN).∼ representa la negacionlogica.

Debido a esta estructura es necesario un modulo de comunicacion UART para intercambiar datos con losservos. Sin embargo, el MSP430 posee un unico modulo de comunicacion UART configurable, el mismo quefue usado en los laboratorios del curso pero que no se encuentra disponible ya que es utilizado para ingresardatos y comandos desde el terminal del CCS (Code Composer Studio, la herramienta de desarrollo de Texas



Instruments utilizada en el curso). Por lo tanto, se procedio a implementar un nuevo modulo de comunicacionUART mediante software, al que llamaremos UART SW, el cual accede a pines del puerto 2, desde donde seenviaran los paquetes de instrucciones.

6. Breve introduccion al lenguaje grafico de plotters HPGL

El proyecto no pretende inventar un nuevo lenguaje grafico para “darle ordenes” al brazo, sino utilizaralguno estandarizado que se adapte a las caracterısticas esperadas del sistema. En esta lınea, se realizo unainvestigacion acerca de los lenguajes graficos mas comunes (ver cuadro comparativo de lenguajes en el Anexo11.4), concluyendo que Hewlett & Packard Graphics Language, HPGL es el que mejor representa el com-portamiento esperado del brazo. Se puede ver en el anexo 11.4 el cuadro comparativo como resultado de lainvestigacion de lenguajes.

HPGL es un lenguaje que se basa tanto en referencias fijas como relativas, representando posiciones encoordenadas cartesianas con configuraciones opcionales tales como estilos de lınea, grosor y curvaturas. Loscomandos tıpicamente comienzan con el prefijo LPRINT, seguido de la instruccion conformada por dos carac-teres, y los parametros necesarios para su ejecucion.

En el marco del proyecto se implementaron dos comandos:

LPRINT “PAX,Y;”: Plot Absolute traslada el lapiz desde su posicion actual hasta las coordenadas [X,Y] cartesianas dentro del espacio de dibujo.

END: Indica el final del archivo de comandos, y que ya no se ejecutaran nuevos comandos hasta norecibir otro archivo.

Como mencionamos, HPGL indica traslaciones en coordenadas cartesianas, mientras que los movimientosde los servos se corresponden con un angulo al cual se debe mover el .actuador”(tambor mecanico giratorio delservo). Por este motivo, es necesario realizar un procesamiento de dichos comandos, primero decodificando lasposiciones en angulos haciendo uso de geometrıa y funciones trigonometricas.

7. Diseno

7.1. Descripcion del sistema

El sistema toma como entrada a un archivo .txt conteniendo comandos en lenguaje HPGL. Esta opera-cion es llevada a cabo mediante una aplicacion generada en Octave que procesa cada comando obteniendo lascoordenadas cartesianas [X,Y] de cada instruccion Plot Absolute detectada. A su vez, se realizan los calculosgeometricos necesarios que resultaran en el angulo en el que debera posicionarse el actuador de cada servo,para trasladar el extremo del brazo sujeto al lapiz hacia las coordenadas ingresadas.

El angulo de posicionamiento y la ID del servo correspondiente se envıan al Launchpad del microcontrola-dor MSP430 a traves del puerto serial. Estos son adquiridos por el modulo de comunicacion UART configuradoen los laboratorios, al cual nos referiremos en adelante como “uart hardware”.

Posteriormente son enviados hacia el modulo Traductor representado en la figura 3. Este se encarga deconvertir los caracteres en sus respectivos numeros enteros, y conformar el mensaje dirigido hacia el servo.Cuando la conversion es realizada con exito, se invoca al modulo UART SW, siendo este ultimo el modulo decomunicacion UART a ser desarrollado por software que se encarga de transmitir el mensaje hacia el servo porel pin P2.4 (pin 4 del puerto 2).

Finalmente, el mensaje atraviesa dos componentes necesarios de hardware auxiliar desarrollados en laseccion 7.2 (componentes LEVEL SHIFTER y IOBUFF de la figura 3), hasta el prototipo donde unicamente elservo al cual corresponde su ID ejecuta la instruccion.



Figura 3: Diagrama del sistema completo.

A pesar de que los servos responden con paquetes de estado cuando los mensajes son correctamente ejecu-tados, se desactivo esta modalidad debido a que, por un tema de cronograma, no se implemento la recepcion dearreglos de bytes, es decir de mensajes.

7.2. Hardware

Se propuso desarrollar un modulo UART por software donde se accediera a un puerto de transmision y otrode recepcion. Sin embargo, el Dynamixel AX-12 posee un unico puerto de datos bidireccional, enfrentandonosa una incompatibilidad de hardware. Este problema de incompatibilidad para una implementacion como lanuestra es mas bien recurrente en arquitecturas de comunicacion de 2 canales, motivo por el cual el manual deusuario del servo provee una solucion. La misma consiste en dos buffers unidireccionales con habilitaciones yuna resistencia de pull-up de 10kΩ, como se puede observar en la figura 4.

Por otra parte, el enlace fısico de los servos maneja un protocolo TTL level, es decir un rango de voltajede 0V a 5V en su puerto de datos. Mientras que los puertos del MSP430 operan entre 0V y 3.3V. Esta segundaincompatibilidad, fue resuelta mediante un level shifter como el que se muestra en la figura 5 donde sus puertos“low level” reciben los datos del MSP430 a 3,3 V, y los mismos se obtienen elevados a nivel 5V por los puertos“high level” del dispositivo, que iran dirigidos hacia el servo. Fue necesario cortocircuitar sus “GND” en ambosniveles.



Figura 4: Solucion al problema de bidirec-cionalidad de datos del Dynamixel AX-12(Extraıdo de [1]).

Figura 5: Esquema de conexiones del LevelShifter usado.

Se dispuso en un protoboard el level shifter, y en el nivel de 5V, se conecto un integrado de buffers noinversor 74HCT 367, con un segundo circuito integrado de compuertas logicas basicas para la habilitacionnegada.

Por ultimo pero no menos importante, se construyo el prototipo de brazo electro-mecanico conformadopor dos servos Dynamixel AX-12 y sus propios soportes (brackets), los mismos conectados en daisy chain yalimentados mediante una fuente DC del laboratorio del Instituto de Ingenierıa Electrica. Como se observa enla figura 6.

Figura 6: Prototipo de brazo robotico ensamblado para el proyecto. Los servos Dynamixel AX-12 son losdispositivos en color negro que figuran en la imagen, mientras que los “brackets” se observan en gris claro.

7.3. Modulos software

El software disenado se puede desglosar en las siguientes etapas.



7.3.1. Ingreso de comandos HPGL

Se tiene como entrada un archivo de texto con comandos en sintaxis de HPGL, detallado en la seccion6. La primera instancia de procesamiento implica abrir por software el archivo de texto en modo de lectura,identificar los comandos Plot Absolut presentes, y extraer las coordenadas cartesianas X e Y de cada uno deellos hasta la lectura del comando END.

7.3.2. Parametrizacion del plano de dibujo

El plano de dibujo esta determinado por el cuarto de cırculo comprendido entre el radio maximo y el radiomınimo al que puede acceder el extremo libre respecto del vertice donde se encuentra colocado el extremo fijo.Su respectiva representacion se observa en la figura 7. Al igual que la anteriore, la siguiente etapa de progra-macion se implementara en Octave y atiende a hallar las cantidades matematicas que necesitamos comunicarlea cada servo para mapear un punto en el plano cartesiano.

En primer lugar, en nuestro sistema articulado con un extremo fijo, un extremo libre, dos articulacionesde largo fijo y un cierto rango de rotaciones posibles para cada articulacion, surge la necesidad de hallar unanotacion polar para la posicion de rotacion de cada servo en funcion del punto en el plano al que se deseaacceder con el extremo libre. En segundo lugar, para cada instruccion de giro los angulos de los servos estanreferidos al Dynamixel AX-12 mismo, no referidos al plano cartesiano. Por lo tanto, a partir de la notacion polarcon angulos medidos desde la horizontal surge la necesidad de reinterpretar cada uno de estos angulos polaresen la base movil de cada servo, donde se tiene que el movimiento esta restricto entre 0 a 300, referidos desdelos -60 en el caso del servo que opera como extremo fijo (el servo representado en el origen de la figura 7).

El diagrama de la figura 7 refleja en terminos generales la necesidad de parametrizar correctamente a losangulos en las bases moviles a partir del mapeo en el plano. Todos los calculos detallados que resultaron en laparametrizacion final estan disponibles en el anexo 11.5.

Figura 7: Esquema generico para parametrizar los angulos que seran transmitidos en el Instruction Packet decada servo. Los angulos polares θ1 y θ2 son medidos respecto de la horizontal y se calculan a partir de laposicion del extremo libre en los ejes cartesianos. Los angulos θ ′1 y θ ′2 son los relativos a cada servo y secalculan en funcion de θ1 y θ2.



7.3.3. Adquisicion de datos desde el MSP430

Los datos relevados del archivo de texto y procesados, se reciben a traves un puerto COM. El formato deesta entrada corresponde a “ ’ID’ ’ ’ ’a’ ’b’ ’c’ ’\r’ ”, el primer caracter simboliza la ID del servo al cuales destinado el movimiento, luego, un caracter de espacio, tres caracteres seguidos con el angulo que debetrasladarse el actuador y por ultimo, un caracter de fin de lınea. A modo de ejemplo, si se recibe “1 250\r”, elservo 1 se debe posicionar en 250 grados.

A su vez, al ser ingresados por el puerto de la terminal del CCS, estos datos son recibidos por la “uarthardware” (el modulo UART0 HW de la figura 3), dado que los pines de TX y RX que conectan la consolaen la MSP430, se conectan en cortocircuito permanente con los de RX y TX (respectivamente) de la “uarthardware”. Para terminar la operacion, los datos se guardan en variables auxiliares para su procesamiento porel modulo Traductor de la figura 3.

7.3.4. Comunicacion y procesamiento de datos en el MSP430

Una vez que la informacion de los calculos anteriores se encuentra guardada en la memoria del microcon-trolador, se traducen la ID y el angulo a valores enteros para pasarlos por el Instruction Packet.

El angulo efectivo de movimiento del actuador del Dynamixel AX-12 es entre 0 y 300 grados, donde esterango se codifica de 0 a 1024 [1]. En nuestro diseno, el angulo real de movilidad es de 45 a 250 grados, debidoa que los “brackets” utilizados en el ensamblado del prototipo limitan el movimiento del actuador.

Dado el formato del Instruction Packet de la figura 2, el mensaje destinado al servo para que este ejecuteel movimiento es FF FF ID 05 03 1E low byte high byte checksum. Mas alla de las banderas de iniciode mensaje, el identificador del servo y el largo del mensaje, 03 alude a una instruccion de escritura de datos,ya que es necesario escribir en su registro de movimiento, el byte 1E es la direccion del registro mencionado.Por ultimo, el angulo codificado es un entero entre 0 y 1024 que no es representable en un entero de 8 bits,por lo tanto se separa en 2 bytes refiriendose por un lado a su parte baja y por otro lado alta en low byte yhigh byte respectivamente.

7.3.5. Sistema de comunicacion entre MSP430 y el servo Dynamixel AX-12

Como ya fue mencionado, se concluye que la comunicacion entre el servo Dynamixel AX-12 y el micro-controlador MSP430 se debe implementar mediante un protocolo UART y dado que este Launchpad posee unsolo modulo de comunicacion UART configurable que ya es utilizado por otra aplicacion del sistema, es nece-sario disenar un modulo de comunicacion UART por software que configure pines de salida adicionales para latransmision de los datos al servo.

La base del funcionamiento de este protocolo es mediante interrupciones periodicas controladas por un ti-mer, tanto para la transmision de bytes como para la recepcion. Vale recordar que el protocolo de comunicacionde los servos es serial, con bit de parada y sin bit de paridad.

Primero evaluamos el sistema de transmision de bytes, donde el protocolo UART maneja puertos por defec-to en nivel alto (1 logico - 3.3 V) dando un flanco de bajada (a 0 logico - 0V) de un perıodo de duracion cuandose inicia la transmision de un byte. Posteriormente se envıan ocho datos binarios, uno en cada interrupcion deltimer, y se finaliza la transmision mediante un bit de parada en 1 devolviendo el puerto a su estado original. Parala recepcion se activan las interrupciones del puerto correspondiente, que tambien se encuentra por defecto ennivel alto. Por lo tanto, este interrumpe cuando un agente externo introduce un flanco de bajo nivel, a partir delcual se espera un tiempo conveniente menor o igual a la mitad del tiempo de bit (esto se justifica mas adelante,en la seccion 8.2.3) y se prosigue adquiriendo 8 bits en serie, uno por cada interrupcion periodica del timer.

La maquina de estados del programa a disenar se representa en el diagrama de la figura 8, donde se parteinicialmente de un estado de espera que aguarda a la necesidad de transmitir (desde la PC) o recibir (porinterrupciones detectadas en el puerto) un byte.



Si se desea transmitir se invoca a una funcion transmitir byte() (a desarrollar en la seccion de imple-mentacion de SW UART), la cual nos lleva a iniciar la transmision activando en primer lugar las interrupcionesdel timer elegido y desactivando temporalmente la interrupcion de recepcion. Motiva a esto el hecho que lacomunicacion de los servos es half-duplex, es decir que no es posible transmitir y recibir simultaneamente. Unavez activadas la cuenta y las interrupciones del timer, transmitimos un primer bit=’0’ por concepto de bit deinicio, luego controlamos mediante un contador la transmision periodica de 8 bits. Se finaliza la transmision de-volviendo el puerto a su estado original escribiendo un bit=’1’ (bit de finalizacion), desactivando la interrupciondel timer y retornando al estado de espera re-activando la interrupcion correspondiente a la recepcion.

Analogamente si detectamos una interrupcion (por nivel bajo) en el puerto de recepcion, configuramos eltimer a la mitad de su perıodo original, y desactivamos la interrupcion del puerto. Luego devolvemos el perıodocompleto al timer y muestreamos 8 bits en el puerto haciendo uso de un contador. Cuando se cuentan 8 lectu-ras y se recibe el bit de parada por nivel alto, entonces se finaliza la recepcion del byte desactivando el timer,re-activando la interrupcion de recepcion (la interrupcion del puerto), y retornando al estado espera inicial.

Figura 8: Maquina de estados del modulo UART creado por software.

Se aclara que la maquina de estados es una abstraccion del recorrido logico del sistema, pero a los efectosde la implementacion algunos estados se ejecutan mezclados entre funciones y subrutinas de atencion a lasinterrupciones.

Finalmente, ya habiendo comprendido esta estructura vale la pena senalar que, en terminos cualitativos,resulta extremadamente relevante la implementacion de la correcta transmision de datos ya que no hacerlo re-presenta un impedimento para el objetivo del proyecto, que es ejecutar movimientos. Sin embargo, la recepciondesde el punto de vista practico pasa a ocupar un segundo plano de prioridad y como meta opcional se pro-puso la posibilidad de extraer datos de estado de cada motor, con motivo de leer paquetes de estado que estosdevuelven. Valdrıa la pena aprovechar al maximo las capacidades computacionales que disponen estos servos



en particular (tales como actualizaciones de temperatura, torque y velocidad instantanea entre otras) pero alos efectos de lo necesario para el sistema final basta con confirmar visualmente que se ejecuta el movimientodeseado. Esto fundamenta que el desarrollo de la recepcion tiene menor prioridad que la transmision.

8. Implementacion

Todas las capas de software que conforman la cadena de procesamiento desde el comando en HPGL, suposterior procesamiento y la conformacion del mensaje hacia cada servo, excedıan la memoria disponible delmicrocontrolador del lauchpad MSP430. Debido a este percance, se dividio la estructura de software en dosambientes de desarrollo. La primera, a la que nos referiremos en adelante como“procesamiento de HPGL”,involucra desde la adquisicion y procesamiento del comando en HPGL en el archivo de texto hasta la extracciondel angulo en el que debe posicionarse cada servo para alcanzar la posicion deseada, utilizando comandosmatematicos que caracterizan a la parametrizacion descripta en la seccion 7.3.2. Una vez obtenidos el angulo yla ID (indicador de a que servo del brazo va dirigido el mensaje) se pasa a la segunda capa de implementacion.Esta se encarga de recopilar la ID del servo al que va dirigido el mensaje y los respectivos grados en los quedebe posicionarse el actuador. En esta capa se procesa esta informacion, se conforma el mensaje y se lo envıaefectivamente hacia el puerto de datos del prototipo. A esta etapa nos referiremos como “conformacion demensaje”.

La solucion sugerida por el tutor y finalmente implementada, fue realizar la etapa de “procesamiento deHPGL” en Octave, como se aclara en el diseno del sistema ya que esta capa implica calculos trigonometricosde una complejidad computacional mucho mayor a la soportada por el microcontrolador. Comunicando Octavecon el MSP430 mediante el mismo puerto serial que utiliza el terminal del CCS, se envıa hacia el MSP430 laidentificacion ID del servo y los grados en los que debe posicionarse este (en formato ascii). Por otro lado, es elmicrocontrolador del MSP430 el encargado de la “conformacion de mensaje”. Traduciendo los datos anterioresse conforma el mensaje a ser enviado hacia el servo en su respectivo formato y se transmite por otro puertoserial.

8.1. Modulos en Octave

Desde la lectura de parametros en el archivo de texto en HPGL hasta la obtencion del mensaje a transmitir,la aplicacion de Octave cuenta con 3 capas de procesamiento de datos. El flujo entre estas capas se puedeobservar a grandes rasgos en la figura 9.

En paralelo se implemento un motor grafico que permite realizar una simulacion en tiempo real de lasposiciones del servo y, una vez completado el movimiento, muestra las representacion teorica del dibujo alapiz. Hacia las secciones siguientes, donde amerite una representacion del movimiento el diagrama se importadesde esta aplicacion. El codigo del simulador queda disponible en el anexo de este documento dentro de laseccion (11.4).



Figura 9: Flujo conceptual de la aplicacion de Octave.

8.1.1. Lectura de HPGL y ajuste de los datos

Para la lectura de datos se implementaron dos modos de entrada de datos dentro de la aplicacion. La primera,como fue notado previamente en la seccion de diseno, es la opcion de leer desde un archivo .txt con sintaxisHPGL. Mientras que la segunda, es un tıpeo manual de los vectores de posicion cartesianos. La operativadescripta se controla con las variables uso-HPGL y uso-manual respectivamente.

Una vez los datos son adquiridos y guardados dentro de su vector correspondiente (X o Y), se procedea realizar una discretizacion de la recta que une ambos puntos con el objetivo de aproximar el trazo lo masposible a una recta real. La fidelidad de la representacion de la misma se puede controlar mediante el parametropuntos-recta; si aumenta esta cantidad entonces se obtienen mas puntos generados entre las coordenadasoriginales de traslacion sobre la recta, y por lo tanto mas similar a una recta sera el resultado. Este proceso seaprecia en la figura 10.



Figura 10: Comparacion de fidelidad para una recta segun cantidad de puntos intermedios se agreguen en larepresentacion del trazo que nos traslada desde una coordenada a otra.

8.1.2. Conversion a coordenadas cilındricas en la base del servo

Antes de aplicar la ecuacion de transformacion que lleva de las coordenadas cartesianas a las cilındricas,es necesario hacer un ajuste segun el cuadrante en que se encuentran los puntos. Si bien en la seccion 7.3.2esta planteado en el diseno de la parametrizacion en una unica solucion, en realidad esa expresion se cumplesolo para representaciones en el primer cuadrante. Para ampliar nuestro plano de dibujo a otros cuadrantes, esnecesario realizar un ajuste de signo de la expresion. Ademas es necesario ajustar el signo de los angulos quese obtienen del calculo, dado que, dependiendo del cuadrante, para que sean positivos es necesario invertirlos.Esto sucede porque Octave al resolver la ecuacion, realiza una aproximacion al angulo mas cercano pero nonecesariamente con signo positivo, tal como es necesario transmitirlo hacia el MSP430. Intervienen ademas enel despeje de los angulos polares la propiedad de paridad del coseno, lo cual implica que es posible obteneren teorıa el mismo resultado para abscisas opuestas. Como se aclaro anteriormente, esto implica una instanciade identificacion del cuadrante y replanteo de la ecuacion por zonas, teniendo especial cuidado en los casosfrontera.

Una vez los puntos fueron convertidos a las coordenadas cilındricas fijas, se calculan los angulos en la basemovil. Para ello se realiza un simple calculo aritmetico como se puede observar en el anexo 11.2, obteniendolos angulos validos de cada servo. Cabe destacar el hecho que para trabajar con la MSP430 se requiere hacer



un redondeo, dado que los angulos deben ser numeros enteros lo cual provoca que se pierda cierto nivel deprecision en los mismos.

8.1.3. Transmision por puerto serial

Para la transmision por puerto serial se implementaron dos configuraciones de envıo de mensajes. En elmarco de Sistemas Embebidos nos enfocaremos en la comunicacion con el MSP430, pero para algunas prue-bas se aprovechara la comunicacion con Arduino DUE. Primero se carga el paquete Instrument control

package, para configurar el baudrate en 9600 (el baudrate por defecto es de 1MHz). Luego, se seleccionael puerto serial COM del modulo UART0 HW del MSP430, y se le permite a la aplicacion enviar y recibirmensajes por este puerto.

En cuanto al formato de los mensajes, el miso se debe adaptar al que espera el MSP430 como fue vistoen la seccion 7.3.3. Utilizando la division entera implementada con la funcion idivide se dividen los dıgitosasociados a cada potencia de 10, asegurando que cada angulo se represente con 3 caracteres. Luego, en funciondel servo destinatario del mensaje se asigna el ID correcto, y se escribe el mensaje en el puerto con la funcionsrl-write().

8.2. Modulos en el MSP430

El diseno del software implementado en el microcontrolador se corresponde a una arquitectura de RoundRobin con interrupciones. La misma fue elegida por su simplicidad de entendimiento sumado al hecho quenuestra aplicacion no tiene grandes restricciones de tiempo de procesamiento. Es posible repensar el sistemapara que se corresponda a una arquitectura de encolado de funciones, pero esto agregarıa complejidad innece-saria en el sistema que bien se puede resolver con Round Robin con interrupciones. Ademas, la escalabilidaddel sistema no es una propridad en el diseno. Si lo fuera, quizas sı se verıa fundamentada la eleccion de unaarquitectura mas robusta pero no es el caso.

8.2.1. UART hardware

El modulo UART hardware, tiene como cometido establecer una comunicacion bidireccional con la apli-cacion Octave, a traves del puerto serial COM, el mismo utilizado por el terminal del CCS. La tarea se realizahaciendo uso de las interrupciones del modulo UART configurable del microcontrolador.

Implementado en el archivo uart 0.c, contiene las siguientes funciones:

void config ACLK clock(void); Configura el ACLK clock del microcontrolador en 32768 Hz.

void config uart 0(void); Inicializa los puertos destinados a la transmision y recepcion de estemodulo UART. Selecciona ACLK como reloj. Configura las interrupciones a 9600 baudios. Activa lasinterrupciones de recepcion, y desactiva la interrupcion pendiente de transmision.

void set flag RX HW(uint8 t* flag RR); Asigna dos punteros a flags, para que cualquier cambioen la flag del modulo pueda ser visto desde la aplicacion principal.

void copy to tx(uint8 t size); Transmite el mismo mensaje que se envıa al servo DynamixelAX-12, hacia el terminal en caso de que se desee visualizar. Para esto, carga el primer caracter del bufferen el registro UCA0TXBUFF y habilita la interrupcion de transmision.

void error to tx(void); Transmite el mensaje “ANGLE FAIL”, hacia el terminal cuando se pideejecutar un movimiento hacia un angulo que no es alcanzable por el actuador del servo. Nuevamente, secarga el primer caracter del buffer en el registro UCA0TXBUFF y habilita la interrupcion de transmision.



Dentro del archivo tambien se ubican los vectores de interrupcion correspondientes a la transmision y re-cepcion del modulo, #pragma vector = USCIAB0TX VECTOR y #pragma vector = USCIAB0RX VECTOR

donde se transmite o recibe el contenido de arreglos auxiliares respectivamente.

8.2.2. Traductor

El modulo Traductor que se observa en la figura 3, fue implementado en dos archivos fuente: translate.cy dynamixel.c. A grandes rasgos, translate.c se encarga de realizar conversiones de caracteres ascii anumeros enteros y viceversa de la informacion recibida y transmitida en el modulo UART hardware. Ademas,calcula los bytes de los campos low byte y high byte (ver seccion 7.3.4), traduciendo el valor del anguloque ingresa desde Octave como ascii de 3 caracteres a su respectivo entero entre 0 y 1024.

Por otra parte, dynamixel.c se encarga de conformar el buffer a ser transmitido hacia el servo, conteniendoel mensaje en el formato que este espera y, posteriormente, invoca al modulo UART por software para que envıeel arreglo.

Funciones de translate.c:

void interpret terminal(void); Copia el caracter de ID (recibido a traves de la UART hardware)en la variable auxiliar char ascii id, y los tres caracteres conteniendo la informacion del angulo en elarreglo char angle ascii[3];, para su posterior traduccion.

uint16 t translate angle(void); Invoca a la funcion int atoi(const char *st); de la bi-blioteca de C < stdlib.h>, para traducir angle ascii[] a su respectivo valor entero. Si angle ascii[]=’1’’2’’3’,entonces atoi(angle ascii)= 123.

uint16 t movement to hexa(uint16 t angle); Evalua si el valor del angulo traducido por la fun-cion anterior esta dentro del rango de movilidad permitido por el actuador del servo. Es decir 45 <angle < 250. Si se cumple la condicion, entonces calcula el numero num entre 0 y 1024 correspondienteal valor del angulo, mediante la operacion num = angle×1024

300 . Retorna num como un entero sin signo de16 bits.

int bytes to move(uint16 t theta); Dentro de esta funcion se invoca a la funcion anterior dondeprimero se obtiene el valor de num mediante movement = movement to hexa(theta); en la variableinterna movement, y se separa en dos enteros sin signo de 8 bits cada uno. El low byte de movement seguarda en la variable auxiliar thetaL, mientras que el high byte en la variable thetaH.

int ascii to terminal(uint8 t size); Para visualizar el mensaje que se transmite hacia el servoen la terminal del CCS, es necesario traducir el arreglo en sus respectivos caracteres ascii. La funcionsepara los bytes en sus 4 bits menos significativos y los 4 mas significativos, en variables auxiliares. Luegoinvoca a la funcion int lut hexa 2 asci(uint8 t byte); (la cual se describira a continuacion),convirtiendo cada variable auxiliar en su respectivo caracter ascii.

uint8 t lut asci 2 hexa(char letra); La funcion recibe codigo hexadecimal de ’0’ a ’F’ en for-mato caracter, y retorna su valor entero en 8 bits. Es utilizada para traducir el caracter asociado a la IDdel servo, en su respectivo valor numerico.

int lut hexa 2 asci(uint8 t byte); Toma un numero entero de 8 bits de 0 a 15, y retorna su res-pectivo valor en codigo hexadecimal de ’0’ a ’F’. La funcion es invocada por int ascii to terminal(uint8 t

size); de manera de traducir el arreglo de datos que conforman el mensaje hacia el servo, para visualizarfacilmente los datos en el terminal del CCS.

Funciones de dynamixel.c:



int move arm( uint8 t thetaH, uint8 t thetaL); Traduce el caracter ascii de la ID del servo,invocando a la funcion del modulo traductor uint8 t lut asci 2 hexa(char letra);. Luego, utili-za la funcion int move dynamixel(uint8 t ID, uint8 t thetaH, uint8 t thetaL); pasando-le los parametros ID, thetaL y thetaH, para conformar el arreglo del mensaje a ser enviado hacia elservo. Finalmente “da la orden” al modulo UART por software de transmitir el mensaje mediante int

transmit array(int buff size);. La funcion devuelve 1 si el arreglo se transmitio correctamen-te. Ademas, dentro de la misma se guarda el tamano del arreglo del mensaje en la variable auxiliarcopy bu f f , para poder mostrar el mismo en el terminal de CCS.

int move dynamixel(uint8 t ID, uint8 t thetaH, uint8 t thetaL); Se utiliza dentro de laejecucuon de int move arm( uint8 t thetaH, uint8 t thetaL); cuando se tienen todos los parame-tros traducidos y en su debido formato para conformar el mensaje. La funcion toma la ID del servo,thetaL y thetaH, y dispone el mensaje a ser enviado hacia el servo en el buffer de transmision del modu-lo UART por software. Por este motivo, tambien calcula el byte de la suma de comprobacion del mensajeo ckecksum, mediante uint8 t cheksum gen(void);, y lo adjunta al final del mensaje. Al final, de-vuelve el tamano del arreglo del mensaje.

uint8 t cheksum gen(void); Cumple el proposito de generar el byte de suma de comprobacion delmensaje y realiza la operacion descripta en la seccion 5. Recorre el buffer de transmision del moduloUART por software, y devuelve el resultado en un byte.

8.2.3. UART por software

El modulo UART por software (o UART SW) pretende implementar un modulo UART de transmision,resolviendo el sistema de comunicacion (unidireccional) entre el servo Dyamixel AX-12 y el microcontroladorMSP430. Su diseno fue detallado en la seccion 7.3.5.

La operacion se realiza seleccionando un puerto para implementar la transmision hacia el “exterior”. Elpuerto 2, mas especıficamente el pin P2.4 es el elegido para esto modificando su estado en la interrupcionperiodica.

Para programar la interrupcion periodica en la que se transmite de a 1 bit, se activo como reloj el SubmasterClock (SMclk), steando este en 1MHz. Dado que, si definimos el tiempo de bit como BitTime= 104, configura-mos el TimerA para que funcione en modo Capture and Compare y escribimos en su registro CRR0 = BitTime(ver [1]), por lo visto en el curso, el TimerA nos interrumpe cada vez que su cuenta de flancos de reloj llegue a104. Logrando, una velocidad de transmision de 1MHz

104 = 9615baudios.La arquitectura del codigo se implemento como una “maquina de estados” de dos estados Transmitir y

Standby. Modificando la variable Estado se controla si se transmite o no cuando el Timer interrumpe.Las funciones del modulo se desarrollaron enteramente en el archivo fuente sw uart.c y se describen a

continuacion:

void inic ports(void); Inicializa el puerto 2 del Launchpad, mas especıficamente los pines P2.4 yP2.5. Como se menciona, P2.4 es por el cual se transmiten los bits hacia el servo, mientas que P2.5 esutilizado para debuggeo, produciendo pulsos en cada entrada a #pragma vector=TIMER0 A0 VECTOR.

void config SM clock(void); Configura el SubMaster clock como reloj del sistema, y setea el mis-mo a 1MHz.

void config new timerA(void); Se encarga de configurar el modulo TimerA del microcontroladorMSP430 seleccionando al SMclk, su modo de operacion “Up to CRR0”, y cargando en el registro CCR0la constante BitTime, de forma de que el mismo funcione tal como se describe al inicio.



void transmit byte(void); La funcion puede ser invocada cuando se tiene un byte para transmitircargado en la variable T XByte. La misma opera modificando la variable Estado = Transmitir, inicializaun contador de bits para controlar las activaciones del pin P2.4, y habilita la interrupcion del modo Cap-ture and Compare del timer, de modo que la aplicacion entre a la subrutina de atencion a la interrupciondel timer #pragma vector=TIMER0 A0 VECTOR.

int transmit array(int buff size); La funcion recibe como parametro el tamano del buffer quecontiene el mensaje para el servo. Implementa un loop en el que se recorre dicho buffer cargando ca-da uno de sus bytes en la variable T XByte e invocando a void transmit byte(void); para que seatransmitido. Una vez que se “enciende” la bandera fin tx byte que indica que el byte anterior fue transmi-tido con exito, se avanza al siguiente byte del arreglo. Se libera el loop cuando todos los bytes del bufferfueron enviados, y si fueron transmitidos con exito la funcion devuelve 1. De lo contrario devuelve 2.

En la aplicacion principal main.c se invoca a la funcion de inicializacion de puertos, ası como a las fun-ciones encargadas de configurar relojes y timer, necesarias para el funcionamiento de las interrupciones. Luegose habilitan interrupciones, y se implementa un bucle infinito mientras se espera por una interrupcion de da-tos recibidos desde Octave. La interrupcion de recepcion del modulo UART HW “enciende” el flag, donde elprograma entra en un condicional a atender el handler.

Primero de identifica la informacion relevante con interpret terminal();, posteriormente se obtiene elangulo como numero entero en angle = translate angle();, la variable anlge es pasada como parametroa angle ok = bytes to move(angle);, si el angulo leıdo es alcanzable por el servo, entonces angle ok =

1. Evaluando esto en un condicional move ok = move arm(thetaH, thetaL);, la funcion conforma el buf-fer con el mensaje y ordena su transmision al modulo UART SW. Si move ok = 1, el mensaje fue transmitidocon exito. En caso de que angle ok = 0, se retorna un mensaje de error. De lo contrario, se muestra el mensajedel servo en el terminal. Y se retorna al loop, por el proximo mensaje recibido por el MSP430.

9. Pruebas

9.1. Testeo del modulo UART por software

Dada la dependencia del resto del diseno a que la UART por software sea lo suficientemente robusta,la primera prueba tiene como objetivo comprobar su funcionamiento. La forma mas sencilla de realizarlo eshaciendo una escritura o lectura en memoria de un caracter. La prueba esta disenada para que la validez de latransmision se verifique en la consola del Arduino DUE, quien actua como receptor, ası como en la forma deonda que circula por el canal de un osciloscopio. El diagrama del diseno de la prueba se observa en la figura 11.Para la verificacion de recepcion del modulo UART SW, Arduino DUE actua de transmisor, y el byte recibidose almacena en la variable RXByte del microcontrolador.

Con el objetivo de observar el comportamiento de la forma de onda se elige el caracter ’A’, para la pruebaya que no es simetrico, y tiene cambios cercanos al bit de inicio y de parada. Su representacion binaria es01000001b, y la misma invertida es 10000010b.



Figura 11: Sistema de prueba de la UART por software.

La figura 12 muestra por un lado la transmision de ’A’ desde el modulo en el canal 1 (en color amarillo).Se concluye que el comportamiento del modulo es el correcto, dado que se tienen los flancos de inicio y finde byte en la posicion correcta, y el resto de los bits respecto a estos se corresponden con el inverso de los delcaracter ’A’ como era de esperarse. Luego, Arduino DUE copia el caracter entrante y lo envıa hacia el puertode recepcion para su testeo. En la figura se representa a esta senal con el canal 2 (color purpura). En la variableRXByte recibio un byte con el valor 01000001b.

Se puede concluir entonces que la prueba fue satisfactoria en cuanto al estudio del comportamiento delmodulo, tanto en transmision como en recepcion.

Figura 12: Forma de onda de transmision (Izquierda) y recepcion (Derecha), del modulo UART software.



9.2. Testeo del modulo “conformacion de mensaje”

El diseno de la operacion se basa en ingresar manualmente desde el terminal del CSS la ID del servo y elangulo en que este debe posicionarse, con el formato descripto en la seccion 7.3.3. Se observara, el mensajerecibido por Arduino DUE.

El proposito de la prueba es testear la cadena de procesamiento; desde la conversion de la informacion deascii a numeros enteros, hasta la conformacion del mensaje en el arreglo de transmision como se especifica enla seccion 7.3.4, pasando por el calculo del angulo y su codificacion en low byte y high byte. La pruebafinaliza y verificando si, efectivamente, se envıa al mensaje conformado por el puerto P2.4.

Figura 13: Sistema de prueba de conformacion de mensaje y transmision del mismo por el puerto P2.4.

En Arduino DUE se visualizo el mensaje conformado por las dos banderas de inicio FF, un byte correspon-diente a la ID que se escribio en el terminal, los bytes de largo del mensaje, instruccion y direccion del registro05 03 1E, seguidos de los dos bytes correspondientes a la conversion del angulo, y finalizando el mensaje conun byte de suma de comprobacion. Esto lleva a concluir que la prueba fue exitosa.

El calculo de la suma de comprobacion fue testeado, realizando la cuenta en una calculadora con modoprogramador. Ademas, se observo mediante un osciloscopio que luego del final de mensaje el canal vuelve a suestado de 5V, como se muestra en el diagrama de la prueba, figura 13.

9.3. Testeo de parametrizacion de coordenadas de dibujo

Al igual que el modulo de la UART SW, se busca probar que la parametrizacion por sı sola es suficiente-mente robusta e independiente del hardware del MSP430. Para ello realizamos una simulacion de la posicionde los servos en Octave y observamos si la composicion que generan los angulos, es la indicada para los puntosque queremos representar. Si bien se aclaro que unicamente se iba a usar un cuadrante, para testear este disenose decidio utilizar la representacion de una figura que cubra al menos dos cuadrantes, de manera de observar sila transicion es la adecuada. Con estas consideraciones la figura a realizar debe pasar por los puntos:

Punto 1 Punto 2 Punto 3

X L1 0 -L1Y L2 L1+L2 L2



Siendo L1 y L2 el largo del segmento de brazo, correspondiente a cada servo. Estos valores se puedenencontrar dentro del codigo y fueron medidos una vez implementado el modelo completo.

La configuracion del cuadro asegura que el angulo entre los servos debe ser perpendicular en varias de lastransiciones, y en parte se eligieron estas coordenadas porque en caso de querer transmitirlo a las articulacioneses facil realizar un seguimiento visual de su trayectoria. Con estos puntos se obtiene la simulacion de la figura14.

Figura 14: Simulacion del movimiento para los puntos del cuadro con 10 puntos entre los mismos.

Como se puede observar la parametrizacion devuelve una configuracion para los angulos de los servosque representa correctamente los puntos de la trayectoria esperada, y la transicion entre cuadrantes no es tandrastica. Para observar las restricciones mecanicas que los brackets aplican sobre los servos se puede observaren la figura 15 que el total de los angulos se encuentra dentro del rango permitido.



Figura 15: Angulos asociados a cada servo durante el movimiento.

9.4. Prueba Final

La prueba de exito disenada para el proyecto final consiste en lograr que el sistema represente un cuadrado.Esto representa un desafıo para todo el sistema ya que esta figura pone a prueba el movimiento conjunto deambos servos para lograr representar lıneas rectas, el trabajo en conjunto de todas la capas de procesamientoque integran el sistema y comprobara la precision deseada si el lapiz es capaz de volver al punto de origen.

El prototipo debe ser capaz de representar una figura cerrada delimitada por sus vertices, cuyas coordenadasse leen desde un archivo .txt en sintaxis HPGL. Se decide representar un cuadrado de 2cm de lado, y centradoen el punto (7.5,7.5). La simulacion del resultado esperado esta dada por el motor grafico implementado enOctave, y se puede observar en la figura 16.

Para comparar la prueba con el resultado en la realidad, se extrajo una nueva simulacion en la cual se visua-liza la trayectoria teorica del lapiz. Dicha simulacion se observa en la figura 17. Sin embargo, una consideracionno contemplada en las simulaciones, es que los servos no se mueven a la vez debido a que cada mensaje se lees envıado 5 veces, como consecuencia de una imprecision de copia del mensaje en el level shifter, detalladaen el Anexo 11.1.1. Como resultado, dado que el lapiz se encontrarıa permanentemente apoyado, el tiempo quedemora en actualizar el angulo de cada servo provocara que algunas lıneas rectas se asemejan a un “diente decierra” en la realidad.

El comportamiento del brazo robotico se puede observar en la figura 18. La misma, es una serie de recortesde una grabacion del movimiento, con el objetivo de mostrar que los servos se posicionan correctamente ysiguen la lınea marcada. En este caso se representa el cuadrado de 2cm de lado, usando el sistema completoexplicitado en la figura 3.



Figura 16: Simulacion del movimiento para los puntos del cuadrado, parametrizado con una precision de 10puntos entre cada vertice.

Figura 17: Trayectoria teorica del lapiz, dada por la simulacion en Octave.



Figura 18: Capturas del movimiento en Vıdeo

10. Conclusiones

Si bien la magnitud del trabajo realizado no era la que se esperaba originalmente, encontramos que se pudoatender a solucionar muy satisfactoriamente todas las problematicas impuestas. A lo largo del desarrollo detodo el proyecto fue posible repasar la gran mayorıa de los conceptos adquiridos en curso, tanto teoricos comodel laboratorio. Cabe destacar que la posibilidad de desarrollar un proyecto de tal magnitud nos permitio experi-mentar en la frontera de los sistemas embebidos con otras areas de la ingenierıa electrica, lo cual consideramoscomo un valor agregado en toda la experiencia.

Se sacaron adelante varias etapas que a nuestro criterio resultaron de alta complejidad, tales como: la ne-cesidad de desarrollar una UART por SW completa, el hardware adicional que hubo que implementar para lacompatibilidad del sistema, y el procesamiento que hubo que considerar por fuera de la memoria del microcon-trolador (porque el sistema completo excedıa el espacio disponible en la memoria).

A los efectos de los resultados que se obtuvieron en comparacion con los objetivos propuestos original-mente, queda comprobado que se cumplieron satisfactoriamente. Se logro controlar cada articulacion de ma-nera individual y se pudo implementar el software para establecer una comunicacion entre una computadora,el microcontrolador MSP430 y los servos. Fueron cubiertas las capas de implementacion para el movmientopor angulos de los servos, y tambien se pudo implementar una capa de procesamiento a partir de una entradade comandos HPGL. Quedaron pendientes algunas implementaciones opcionales que se habıan considerado,tales como la posibilidad de recibir realimentacion de datos por parte del servo o profundizar en la bibliotecade comandos disponibles de HPGL.

Desde el punto de vista del movimiento que se logro, no se contaba con el hecho que el hardware adicionalinterviniera tan significativamente en la ejecucion de movimientos, refiriendonos sobre todo al level shifterquien introduce la perdida aproximada de varios comandos enviados. Vale aclarar que esta conclusion surgedel hecho que la prueba final de movimiento con nuestro diseno implementado en la MSP430, proporcionala misma tasa de error que si se hace pruebas de movimiento utilizando un Arduino DUE y su biblioteca deAX-12 en lugar del Launchpad. Sin embargo, extraer una estadıstica de error aproximada en el movimiento nospermitio llegar a la conclusion de enviar mensajes repetidos tantas veces, como el promedio de veces que huboque repetir un mensaje para que se enviara correctamente. Enviar mensajes repetidos no perjudica en terminosde movilidad pero exige el compromiso de tener un sistema de reacciones lentas, sobre todo considerando quela conexion es daisy chain, y que el tiempo total de demora en la ejecucion de un movimiento es la suma de lostiempos de ejecucion de cada articulacion.

Estas ultimas consideraciones hicieron posible que nuestro brazo robotico con dos articulaciones pudieraconquistar el movimiento a lo largo de una figura geometrica cerrada en un tiempo que igualmente esta muypor debajo de nuestras restricciones de 30 segundos por trazo. Por este motivo y los anteriormente descriptos,se considera que la experiencia fue muy exitosa y que los objetivos se alcanzaron ıntegramente.



11. Anexo

11.1. Contratiempos del proyecto

11.1.1. Problemas con el Level-Shifter

Surge de la prueba final que el brazo en algunos casos no respondıa a los mensajes que se le enviaban.Enicialmente se supuso era un defecto similar a un glitch de transmision de la UART SW visto en una pruebaanterior que utilizaba un Arduino UNO como receptor. Sin embargo, luego de un analisis estadıstico del errorllegamos a la conclusion que tomarlo como un error aleatorio con probabilidad 0.4 era de las mejores conside-raciones. Con el objetivo de arreglar superficialmente el error se decide enviar cada mensaje 5 veces tal que laprobabilidad de que finalmente sea ejecutado por el servo tienda a 1. Se encontro visualmente, que 5 veces eransuficientes para obtener una respuesta visual de movimiento en el servo.

Se sospechaba que el error estaba implicado en alguna etapa de hardware puesto que, si realizabamos lamisma prueba intercambiando el MSP430 por Arduino DUE, y probando transmitir unicamente con el levelshifter de por medio (pues Arduino DUE funciona a nivel 3.3V) se encontraba exactamente el mismo problema.

Como fue introducido en la seccion 7.2 de hardware el level shifter se suponıa como un componente queno deberıa causar problemas con su implementacion, pero en la experiencia resulto ser todo lo contrario. Sedispuso una investigacion poco fructuosa dado que no se encontro la hoja de datos del dispositivo. Encontrandoen algunos foros de Arduino, y asesorados por nuestro tutor de proyecto de fin de carrera Juan Pablo Oliver, seaclaro que estos dispositivos pueden retrasar las senalas que los atraviesan. La teorıa, es respaldada medianteotra prueba, involucrando la transmision desde el MSP430 y un Arduino UNO, interconectados mediante ellevel shifter. Se observa que, se bien la senales por el canal eran correctas (verificadas por un osciloscopio), enla recepcion del Arduino se muestreaba mal un bit, cambiando completamente el valor del mensaje.

11.1.2. Problemas de transicion del ultimo byte

Durante la prueba de “conformacion de mensaje”, se observo en el osciloscopio que el modulo UART SWmantenıa por un tiempo considerable el puerto de transmision en cero, antes de enviar el ultimo byte de datos.El problema fue resuelto en la funcion int transmit array(int buff size);, forzando el puerto a 3.3V,luego de que se transmite la suma de comprobacion.

11.1.3. Problemas de Memoria

Un contratiempo que implico un replanteo del sistema final, es el hecho que los calculos requeridos para pa-sar de coordenadas cartesianas a los angulo moviles excedıan el espacio en memoria disponible en el MSP430.Por lo tanto, se tuvo que migrar hacia otro entorno de desarrollo, Octave. Sobre el mismo de desarrollo, final-mente, la etapa de procesamiento de HPGL (ver seccion 8.1).

11.2. Conceptos del curso aplicados

En primera instancia, se valorizo mucho, el aprendizaje en el manejo de interrupciones del microcontrola-dor. Dado que en la resolucion de los sistemas de comunicacion de nuestro proyectos, las interrupciones jugaronun papel fundamental.

En este sentido, la arquitectura de software elegida para la aplicacion que opera en el MSP430, fue RoundRobin con interrupciones, debido a su simplicidad de sintaxis, y la organizacion de prioridades de las interrup-ciones. A pesar de que en el curso analizamos sus desventajas, los datos compartidos no fueron un problema, yaque nuestro software coexiste con el mismo, e incluso se utiliza a nuestro favor en la concatenacion de modulosde software. El tiempo de ejecucion de los handlers, se observa como otra desventaja, sin embargo, nuestrosistema no requiere velocidades de procesamiento elevadas, por lo cual no fue un problema.



La configuracion de perifericos tales como relojes y timers, tambien fue ampliamente aplicada en el pro-yecto. Dado que las interrupciones del modulo UART SW, funcionan transmitiendo bits en cada interrupciondel TimerA, logrando una velocidad de transmision de 9600 baudios.

Por ultimo, el modulo de comunicacion entre el microcontrolador y la aplicacion Octave, fue desarrolladomediante un puerto serial, atendido por las interrupciones del modulo UART implementado en el laboratorio 3.

11.3. Planificacion

Inicialmente el cronograma planificado fue el siguiente:

Semana 1 - 8/5:

Estudio del lenguaje grafico a utilizar como entrada al sistema.

Investigacion acerca del modo de comunicacion entre el MSP430 y el servo.

Analisis de soluciones disponibles de UARTs por software para otros modelos de MSP430.

Semana 2 - 13/5:

Implementacion del modulo de comunicacion entre el MSP430 y los servos.

Desarrollo y prueba de un modulo de comunicacion UART por software para un byte.

Semana 3 - 20/5:

Presentacion del hito 1.

Diseno e implementacion del sistema para un arreglo de bytes.

Semana 4 - 27/5:

Diseno de la parametrizacion del plano de dibujo y algunas simulaciones.

Diseno y prueba del modulo “conformacion de mensaje”.

Primeras pruebas de moviemintos de servos desde el MSP430.

Semana 5 - 3/6:

Desarrollo de la capa de procesamiento de HPGL, en Octave.

Desarrollo del simulador de movimientos en Octave.

Prueba final del sistema completo.

Semana 6 - 10/6:

Entrega de documentacion.

Semana 7 - 17/6:

Presentacion final del proyecto.



11.4. Cuadro comparativo de lenguajes

Previo a elegir que el lenguaje de entrada mas adecuado para nuestro sistema se realizo una investigacioncomparativa entre lenguajes graficos. El siguiente cuadro refleja las conclusiones extraıdas respecto a cada unode los mismos.



G-Code HPGL HPGL2 DMPL PostScript

Caracterısticas1. El G-code, tam-

bien conocidocomo RS-274, esel nombre quehabitualmenterecibe el lenguajede programacionmas usado encontrol numerico(CN), el cualposee multiplesimplementacio-nes, tales comoSiemens Sinu-meric, FANUC,Haas, Heidenhaino Mazak.

2. Es usado princi-palmente en auto-matizacion, formaparte de la inge-nierıa asistida porcomputadora.

3. En terminos ge-nerales, G-codees un lengua-je mediante elcual, los usuariospueden coman-dar maquinaso herramientascontroladas porcomputadora,diciendoles quehacer y como ha-cerlo. Esos ”que 2

como.estan defini-dos mayormentepor instruccionesde desplazamien-to, cuan rapidomoverse y quetrayectoria seguir.Las maquinastıpicas que soncontroladas conG-code sonfresadoras, cor-tadoras, tornos eimpresoras 3D.

1. Lenguaje graficode Hewlett-Packard. Formatode archivo degraficos vecto-riales de HP quefue desarrolladocomo un lenguajeestandar para tra-zadores (plotters).La mayor partede los trazadoressoportan losestandares HPGLy DMPL.

2. El HPGL tieneuna segunda ver-sion, el HPGL/2,con mas ins-trucciones y quefunciona con uni-dades metricas,mientras que elHPGL funcionacon el SistemaAnglosajon deUnidades.

3. HPGL como len-guaje de descrip-cion grafica fuedisenado original-mente para plot-ters.

4. HP-GL es un co-mando de controlde ploter graficodesarrollado porHewlett-Packard(HP). HP-GL eraoriginalmenteun sistema decomandos paracontrolar plotersde HP, aunqueahora se utiliza enmuchos plotersy aplicacionesCAD como elcomando masestandar.

1. HP-GL/2 es uncomando decontrol de ploterde rasterizaciondesarrollado porHP.

2. Es usado princi-palmente en auto-matizacion, formaparte de la inge-nierıa asistida porcomputadora.

3. La rasterizaciones el procesopor el cual unaimagen descritaen un formatografico vectorialse convierte en unconjunto de pıxe-les o puntos paraser desplegadosen un medio desalida digital, co-mo una pantallade computadora,una impresoraelectronica o unaImagen de mapade bits (bitmap).

4. A diferencia deHP-GL, que sedesarrollo a partirde ploters grafi-cos, HP-GL/2ofrece funcio-nes de dibujoavanzadas quepresuponen la in-clusion de plotersde rasterizacion.

1. DMPL,or DigitalMicro-processorPlotterLanguage,es unformatode archi-vos devectoresgraficos,desarro-llado porHoustonInstru-ments,para elcontrol deplotters, ycortadorasautomati-cas.

1. PostScript esun ”lenguaje dedescripcion depagina”, es decir,es un lenguaje deprogramacion quese usa para decirlea una maquinadestinada a impri-mir como y quedebe imprimir.

2. Para ser “adapta-ble”, PostScriptes un lenguaje delos denominados“interpretados”.Es decir, no lehabla directamen-te a la maquina,sino que necesitaun procesador(un dispositivofısico o un pro-grama residenteen el ordenador)que actue comointerprete tra-ductor entre elcodigo PostScriptuniversal 2 lamaquina. Eso eslo que se llama“interprete PostS-cript”. Tambiense le denominaRIP por las siglasinglesas de RasterImage Processor.El hecho es quePostScript no esel unico Lenguajede Descripcion dePagina (LDP) queexiste, pero es elque ha tenido masexito y el que seha convertido enun estandar de lasartes graficas.



G-Code HPGL HPGL2 DMPL PostScriptCaracterısticas 5. Asimismo, HP-

GL/2 ofrece lassiguientes fun-ciones ampliadas,que no propor-ciona HP-GL:Reduce espec-tacularmente elvolumen de datosde salida median-te la funcion decompresion deinstrucciones dedibujo de vectoresy recorta signi-ficativamente eltiempo de esperadel ordenador.Admite datos encolor y permitela impresion encolor o escalade grises. Lainformacion quecontiene datosde vectores y deimagenes puedeimprimirse auna alta velo-cidad, ya queHP-GL/2 puedeconmutarse a HPRTL medianteun comando.Dispone de unagran variedad dedistintos rellenossolidos (color,escala de grises,trama, etc.). Pue-den especificarsevarios ajustes (an-chura, extremosde lıneas, unionesde lıneas, etc.)mediante unapluma virtual.

3. El lenguaje Pos-tScript es tan“universal” quesu forma mas sen-cilla son simplesinstrucciones es-critas como textos(siguiendo, eso sı,una sintaxis muyrigurosa). Basica-mente un ficheroPostScript contie-ne instruccionesque, traducidas allenguaje humano,dicen cosas deltipo ”traza uncırculo de 3 cm.de radio, dibujauna lınea de 4,5cm. en un angulode 45 grados,etc. . . ”Por eso esportable, porquedepende del RIP ointerprete PostS-cript comunicarlea la maquinaen su codigoparticular comotomar esas ins-trucciones basicasy ejecutarlas unadetras de otrahasta imprimir lapagina.



G-Code HPGL HPGL2 DMPL PostScriptCantidad de biblio-grafıa disponible

ALTA ALTA ALTA BAJA MEDIA

Creador MIT Hewlet-Packard Hewlet-Packard Houston Ins-truments

Adobe

Ventajas Muy utilizadoen automa-tizacion eingenierıa.Satisface lasnecesidadesdel problema.

Esta muy estandari-zado. Satisface lasnecesidades del pro-blema.

El lenguaje originalHP-GL no admitıala definicion deancho de lınea, yaque este parametrofue determinado porlas plumas cargadasen el ploter. Conla llegada de losprimeros trazadoresde chorro de tinta,el ancho de lıneapara los “bolıgrafos”especificados en losarchivos HP-GL tuvoque configurarse enla impresora para quesupiera que anchode lınea se debeimprimir para cadabolıgrafo, un procesoengorroso y propen-so a errores . ConHewlett-PackardGraphics Language/ 2 tambien cono-cido como HP-GL/ 2, la definicionde ancho de lınease introdujo en ellenguaje y permitiola eliminacion deeste paso. Ademas,entre otras mejoras,se definio un formatode archivo binarioque permitıa archi-vos mas pequenos ytiempos de transfe-rencia de archivosmas cortos, y seredujo la resolucionmınima.

Esta muy es-tadarizado.



G-Code HPGL HPGL2 DMPL PostScriptDesventajas Muy orienta-

do a maquinasCNC e impre-sion 3D concomandosde tracciony velocidadpara filamen-to. Comandosmuy pocointuitivos.

Solo hace lıneas rec-tas.

Este lenguajeno es com-patible conHPGL.

No se encon-traron formasde adaptarlo aC online, solointerpretes dePostscript.

Compatibilidad conentornos y lenguajesde programacion

No he encon-trado. Solosimuladoresde CNC ymaquinasCNC progra-mables.

Los archivos .HPGLse pueden integrar encodigos de C .

Los archivos .HPGLse pueden integrar encodigos de C .

Compatiblecon Eagle(SW)

Interpretesdisponibles:Ghostscript,Xpost

Comandos relevantes G0 , G1: Mo-ve G2 , G3:ControlledArc MoveG4: DwellG6: DirectStepper MoveG10: Set toolOffset and/orworkplacecoordinatesand/or tooltemperaturesG10: Re-tract G11:UnretractG12: CleanTool G17..19:Plane Selec-tion (CNCspecific) G20:Set Units toInches

Pen Control and PlotInstructions Instruc-tion Function PU PenUp PD Pen Down PAPlot Absolute PR Re-lative Coordinate PenMove AA AbsoluteArc Plot AR RelativeArc Plot CI Circle

Resumen Muy util paraimpresion 3Dpero no esmas aprove-chable queHPGL paradibujos en2D. La sin-taxis es pocointuitiva. Nosabemos si sees integrablea un sistemaen C.

Parece tener todoslos comandos quenecesitarıamos paramovimiento: cree-mos que es posibleintegrarlo a un pro-grama en C. EstaMUY estandarizado.

Es compatible conHPGL.

No se puedeusar con nues-tra tecnologıa.

No se en-contraronejemplos deincorporaciona SW.

Cuadro 5: Cuadro comparativo de lenguaje graficos.Facultad de Ingenierıa 32 Universidad de la Republica


11.5. Parametrizacion

θ1: Angulo respecto de la horizontal en el plano cartesiano xy del servo 1.

θ2: Angulo respecto de la horizontal en el plano cartesiano xy del servo 2.

Los servos Dynamixel AX-12 tienen a su plano de movimiento restricto segu la dimension del mismo mo-tor. Sus movimientos se encuentran comprendidos entre 0 y 300. El rango de 300 a 360 no esta accesible.

θ ′1: Angulo en el plano de movimiento de los servos, medido en sentido antihorario a partir de la referenciaa 0 del servo 1.

θ ′2: Angulo en el plano de movimiento de los servos, medido en sentido antihorario a partir de la referenciaa 0 del servo 2.

El paquete de instruccion de movimiento para cada servo maneja la nomenclatura de angulos referido a sımismo, que en la figura 19 alude a los angulos θ ′1 y θ ′2 para los servos 1 y 2 respectivamente.

Se despejan en primer lugar los angulos cartesianos θ1 y θ2 (medidos desde la horizontal) a partir de laposicion (x,y) del extremo libre de la articulacion.

L1 cos(θ1)+L2 cos(θ2) = xL1 sin(θ1)+L2 sin(θ2) = y

(1)

Figura 19: Analisis de plano de trabajo con 2 articulaciones.



Sumando los cuadrados x2 + y2:

L21 +L2

2 +2L1L2 cos(θ1)cos(θ2)+2L1L2 sin(θ1)sin(θ2) = x2 + y2

(2)

Si se analiza unicamente el termino en 2L1L2 usando las igualdades trigonometricas de cos(θ1)cos(θ2) ysen(θ1)sen(θ2) :

2L1L2

[cos(θ1)cos(θ2)+ sin(θ1)sin(θ2)

]=

(3)

2L1L2

[12

cos(θ1−θ2)+12

cos(θ1 +θ2)+12

cos(θ1−θ2)−12

cos(θ1 +θ2)]= 2L1L2 cos(θ1−θ2)

(4)

Sustituyendo en la expresion de suma de los cuadrados:

cos−1[

x2+y2−L21−L2

22L1L2

]= θ1−θ2

θ1 = θ2 + k(5)

Sustituyendo en la ecuacion de x2:

x=L1 cos(θ2 + k)+L2 cos(θ2)(6)



La anterior es una expresion del tipo acos(x+ c)+bcos(x) = d que se puede interpretar como:

12 ae−ic−ix + 1

2 aeic+ix + 12 be−ix + 1

2 beix

Cuya solucion para la variable x provista por el programa Wolfram alpha es:

x=-cos−1(−√

a4 sin(c)+2a3bsin2(c)cos(c)+a2b2 sen2(c)−a2d2 sin2(c)+ad cos(c)+bda2 sen2(c)+a2 cos2(c)+2abcos(c)+b2

)(7)

Siendo a = L1, b = L2 y c = k de la ecuacion 11.5 se despeja la incognita x = θ2 y luego θ1 = θ2+k, dondeθ1 y θ2 son los angulos absolutos referidos al sistema cartesiano.

Falta despejar los angulos θ ′1 y θ ′2 en funcion de θ1 y θ2 para poder referirnos a los angulos relativos a cadaservo, que es el que se le comunica digitalmente al sistema de comunicacion del mismo. Los angulos θ ′1 y θ ′1estan referidos segun el 0 del servo 1 y del servo 2 respectivamente.

Para plantear la idea de lo que se quiere llegar se propone estudiar en primer lugar la parametrizacion ne-cesaria para el caso generico de la siguiente figura.

Figura 20: Caso generico en el primer cuadrante para el calculo de θ ′1 y θ ′2 en funcion de θ1 y θ2. Los angulosθ1 y θ2 se definen desde la horizontal y se determinan por las operaciones anteriores.

Se observa en primer lugar que el servo 1 esta sujeto al extremo fijo, y por lo tanto se puede expresar a θ ′1como:

θ′1 = θ1 +60 (8)



Por otro lado, teniendo en cuenta que el angulo comprendido entre se puede encontrar una expresion parael angulo comprendido entre 90−θ1 y θ2 es un angulo recangulo, se puede expresar alangulo que definen L1y L2 de la siguiente forma:

L1L2 = 30+θ ′2 = 90−θ1 +90+θ2θ ′2 = 90−θ1 +90+θ2−30

=⇒ θ′2 = 150+θ2−θ1 (9)

Caso de ejemplo 1: Sean θ1 = 45, θ2 = 25 los angulos obtenidos para una posicion dada, se desea hallarlos angulos de escrira en los servos para que se logre la posicion deseada.

En otras palabras, hay que hallar θ ′1 y θ ′2 para que cada servo alcance esta posicion.

Siguiendo el razonamiento anterior, se obtienen:

θ ′1 = θ1 +60 = 45+60 = 105

θ ′2 = 150+θ2−θ1 = 150+25−45 = 130

♠

La resolucion planteada satisface las soluciones en el primer cuadrante, pero vale la pena comprobar siverifica tambien a las soluciones en el segundo cuadrante. Por un lado, como el servo 1 esta referido al extremofijo es claro que la relacion 8 se va a seguir verificando para los demas cuadrantes. A los efectos mantener gene-ralidad en el estudio de θ ′2 se propone realizar una rotacion del servo 1 (unicamente), manteniendo incambiadoel servo 2 (ver figura 21).



Figura 21: Rotacion del servo 1 en el caso de la figura 20. Servo 2 incambiado. Se obtienen nuevos ϕ1 y ϕ2medidos respecto de la horizontal. Se desea comprobar la consistencia de la parametrizacion halladapara lasbases moviles, verificando que para este caso ϕ ′2 = θ ′2.

Ejemplo 2: Sean ϕ1 = 135,ϕ2 = 115. Se resuelve ϕ ′1 = ϕ +60. Por otro lado, ϕ ′2 deberıa ser igual a θ ′2del ejemplo 1 ya que no se hizo ninguna rotacion en el servo 2.

ϕ ′2 = 150+ϕ2−ϕ1 = 130

Tambien se puede hallar el caso con mas generalidad donde se plantee a θ1 y θ2 como el arcotangente desen(θi)cos(θi)

, de donde para el cambio de cuadrantes se aprovecha que el arcotangente es una funcion impar, es decirque arctan(−x) =−arctan(x).

11.6. Lista de archivos

Archivos en lenguaje C, para la aplicacion del modulo desarrollado en el MSP430.

main.c

uart 0.c y uart 0.h

sw uart.c y sw uart.h

translate.c y translate.h

dynamixel.c y dynamixel.h

Archivos para la aplicacion desarrollada en Octave.



12. Referencias

Referencias

[1] Dynamixel AX-12 User’s Manual, Robotis, 14-06-2006.

[2] http://cstep.luberth.com/HPGL.pdf

[3] https://sourceforge.net/p/octave/instrument-control/ci/default/tree/

[4] https://sites.google.com/site/aikonproject/


PicassoBOT

Proyecto de asignatura:

Sistemas Embebidos para Tiempo Real

10 de junio de 2019

Daniel Lopez CI: 4.935.931-5 [email protected] Massonnier CI: 4.537.170-7 [email protected]ıa Sirio CI: 5.094.912-5 [email protected]

1

Indice

1. Introduccion 3

2. Nombre del proyecto 3

3. Integrantes y tutores 3

4. Descripcion del problema 3

5. Antecedentes 4

6. Objetivo del proyecto 4

7. Alcance 4

8. Descripcion del sistema 58.1. Descripcion Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58.2. Diagrama de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

9. Requerimientos y restricciones 6

10.Diseno preliminar 610.1. Plataforma de hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610.2. Arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

11.Planificacion 811.1. Actividades y tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811.2. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911.3. Hito intermedio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911.4. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2

1. Introduccion

El proyecto correspondiente a la asignatura Sistemas embebidos para tiempo real (en adelanteSISEM) se enmarca en el contexto del proyecto de fin de carrera PicassoBOT de los estudiantesque integran el grupo. El objetivo de dicho proyecto es construir y programar un brazo roboticoque sea capaz de dibujar.

Para esta asignatura se pretende hacer una implementacion exploratoria del proyecto anterior,integrando las herramientas del curso con algunos dispositivos de lo que finalmente constituira albrazo robotico completo.

2. Nombre del proyecto

PicassoBOT

3. Integrantes y tutores

Estudiantes:

Lopez, Daniel

Massonnier, Paola

Sirio, Lucıa

Tutores del proyecto de fin de carrera:

Monzon, Pablo

Muse, Pablo

Oliver, Juan Pablo

Tutor asignado del proyecto de SISEM:

Gonzalez, Mauricio

4. Descripcion del problema

Al finalizar el proyecto de fin de carrera se espera haber construido e implementado un brazorobotico articulado con servos modelo Dynamixel AX-12 y sus soportes. Se busca entonces podercontrolar cada articulacion de manera individual logrando que el mismo sea capaz de reproducirmovimientos similares a los humanos, con el proposito de controlar un lapiz o birome y dibujarsobre papel a tiempo real. Para la propuesta del Proyecto de SISEM se contara con una versionintermedia del sistema final. Se supondra como provisto y ensamblado el hardware necesario.

Uno de los primeros obstaculos presentes en este sistema es que surge la necesidad de definir laforma en la que interactuan los servos y la placa MSP430. Para la comunicacion entre los motores yla placa, que funcionan unos por valores de tension y la otra mediante programacion digital, no estrivial la estructura de traduccion que dirige los movimientos de los motores segun los movimientosque se desean realizar. El desarrollo del proyecto de SISEM busca atender a esta problematica.

3

5. Antecedentes

Actualmente el ambito de la robotica se centra en desarrollar dispositivos pequenos, con inte-ligencia artificial, de bajo costo y facil construccion. En esta lınea es que surgen varias iniciativastecnoloicas en areas muy variadas de intereses no solo mecanicos, computacionales y electricos, sinoque tambien se han incorporado ambitos multidisciplinarios para todas las edades y profesiones.En particular, relacionadas con el proyecto de SISEM se presentan a continuacionlos dispositivosdesarrollados por Line-us y el Proyecto AIKON.

Line-us es un brazo robotico que se produce a mediana-gran escala y se comercializa para uti-lizar su interfaz como medio de comunicacion visual, disponible en dispositivos portatiles. Esteinvento esta orientado sobre todo a la comunicacion de las personas a traves de dibujos personales,implicando una suerte de red social. El sistema ofrece la posibilidad de enviar una imagen sencilladibujada en un dispositivo movil (tablet, smartphone, etc) y enviarla por internet a un receptorde Line-us, cuyo brazo robotico dibuja en un papel la imagen que recibio. Ademas, el sistema esparcialmente abierto, en el sentido que la web de Line-us ofrece ademas una plataforma online quepermite la puesta a punto de posibles implementaciones programables adicionales para aficionados.Este dispositivo es muy portatil, funciona sobre superficies horizontales y verticales, procesa unaentrada relativamente sencilla de imagenes poco elaboradas y produce una salida con buena preci-sion y trazos estables cuyos resultados son muy satisfactorios.

Por otro lado, el Proyecto AIKON surge de parte del artista Patrick Tresset quien decidiovincular sus dos pasiones en un solo proyecto: la computacion y el arte. En el Departamento deComputacion de la Goldsmiths College (Londres, UK) Patrick y su equipo desarrollaron satisfac-toriamente un brazo robotico que dibuja trazos simulados de un humano a partir de una entradade videocamara a tiempo real. El dispositivo, denominado Paul el robot (Paul the robot) es unainstalacion robotica que produce retratos observacionales de personas. Ademas, este implemento derealimentacion por camara le permite al robot mejorar iterativamente un dibujo que inicialmentese construye de un proceso silencioso de recuperacion delıneas.

Es inspirado en sistemas como estos que surge el objetivo del Proyecto de Grado: disenar, desa-rrollar y armar un brazo robotico que dibuje al natural, sujetando un lapiz o lapicera contra el papelsimulando el procedimiento de un dibujo a mano alzada, a partir de una imagen a la entrada. Sepropone disenar un robot que pueda dibujar del natural: naturalezas muertas, paisajes, retratos, etc.

6. Objetivo del proyecto

Implementar el software de un prototipo robotico articulado conformado por dos servos, esta-bleciendo una comunicacion entre una computadora, el microcontrolador msp430 y los servos, deforma tal que se pueda controlar el movimiento de ambos motores, con el objetivo de cubrir unplano de dibujo con el extremo libre.

7. Alcance

En el marco del proyecto de la asignatura y de lo acordado con el tutor Mauricio Gonzalez, seconstruira un pequeno prototipo conformado por 2 servos y ensamblado con los propios brackets(soportes) de estos. Las horas de montaje de este hardware estan comprendidas dentro de las horasde dedicacion al proyecto de fin de carrera, y se cuenta con que estara armado antes de comenzarla etapa de programacion del sistema, netamente comprendida en el proyecto de la asignatura.

4

Posteriormente se implementara la comunicacion entre la computadora, el microcontroladormsp430 y dichos servos con el fin configurar una comunicacion serial a traves de la terminal UARTdel microcontrolador y el puerto USB de la computadora, teniendo en cuenta que los servos manejanun protocolo de tipo Half duplex Asynchronous Serial Communication (8bit, 1stop, No Parity).

Una vez establecida la comunicacion del sistema, se programara una primera capa en softwa-re donde se moveran los servos una cierta cantidad de grados, haciendo uso de las bibliotecasya proporcionadas por Texas Instruments. Luego, se programara una segunda capa de software, apartir de una biblioteca desarrollada por el grupo, y basada en el lenguaje grafico de plotters HPGL.

Es decir, se espera que el prototipo sea capaz de realizar movimientos ejecutando comandos deun archivo de extension .hpgl desde una computadora.

Se deja como meta opcional la de realizar una realimentacion de datos desde los servos, aprove-chando que estos pueden tomar datos como temperatura, velocidad o posicion, para procesarlos ycomprobar que la acciones de movimientos se estan realizando con exito.

8. Descripcion del sistema

8.1. Descripcion Funcional

El sistema debera recibir como entrada un archivo .hpgl que contenga comandos en el len-guaje grafico elegido, HPGL, y realizar el procesamiento correspondiente. Es decir: decodificar elcomando, enviar la informacion de la accion que corresponda a los servos, ejecutar el movimiento,y esperar al siguiente comando.

8.2. Diagrama de bloques

El siguiente esquema explica a grandes rasgos la estructura del sistema y la interaccion de laarquitectura entre HW y SW.

Figura 1: Diagrama de bloques del sistema.

Se atendera principalmente al desarrollo del modulo de comunicacion que es parte del software

5

del sistema. Luego, nos encargaremos de la interpretacion de los comandos .hpgl de la entrada yel procesamiento necesario para traducirlo a las necesidades de la interfaz de comunicacion.

9. Requerimientos y restricciones

Cantidad de comandos: Se busca implementar como maximo 5 comandos en HPGL. Es esencialque exista al menos un comando para inicializar el sistema en algun estado conocido, uncomando para ejecutar algun movimiento basico para probar efectivamente los servos, y uncomando para finalizar la ejecucion y regresar a algun estado conocido.

Espacio de dibujo: Dado que el prototipo puede alcanzar un radio de unos 20 cm, la ventanade dibujo tomada debe ser tal que su diagonal este incluida en este radio de dibujo. Ademasse tiene presente que probablemente, por el mismo volumen del prototipo, los movimientosposibles en torno al extremo fijo del prototipo van a ser restringidos. En virtud de lo anteriorse propone entonces trabajar en una ventana de trabajo no mayor a 12×12 cm2, cuya diagonalmide casi 17 cm.

Caracterizacion del trazo: para los movimientos de dibujo se espera un trazo ligero de velocidadde trazo constante.

Tiempo de ejecucion de software: de momento se desconoce el volumen que va a ocupar elprograma en memoria, la longitud del codigo y, por lo tanto, se desconoce tambien el tiempo deejecucion del programa. Se propone entonces una cota a criterio de unos 5 minutos de tiempode procesamiento por computadora, por cada comando debugeado. En esta consideracion seentiende por tiempo de procesamiento por comando al tiempo que le lleva a una computadoraejecutar internamente un comando en HPGL, desde el comienzo de la ejecucion del comandohasta que el servo reciba efectivamente la instruccion procesada y empiece su movimiento.El tiempo de trazo (o bien, tiempo de ejecucion de movimiento) no se considera en esterequerimiento.

Tiempo de ejecucion de movimientos: Se espera que el tiempo de ejecucion de un movimientobasico no sobrepase los 30 segundos. Para esta consideracion y la anterior se entiende que noconviene que los servos queden bloqueados por mucho tiempo, ya que podrıan quemarse.

Tamano de los comandos en HPGL: A modo de ejemplo, uno de los comandos que mascaracteres tiene, es el que une dos puntos mediante una recta, llamado Plot Absolute, elcual consta del prefijo LPRINT para indicar que es una instruccion de dibujo y no de seteo,seguido de “PA[X,Y]”, es decir 6 caracteres, un espacio, comillas, dos caracteres, parentesis,parametro 1, coma, parametro 2, parentesis y comillas. Por lo tanto se requiere un buffer demınimo 16 caracteres, donde los caracteres se interpretan como ASCII de 1 byte de largo.

10. Diseno preliminar

10.1. Plataforma de hardware

En primer lugar, aclarar que los insumos necesarios para el montaje del hardware ya estan enposesion del grupo. A continuacion, una breve presentacion del hardware que constituye una de lasprincipales herramientas de trabajo.

Esta prevista la construccion de un prototipo compuesto por dos servos Dynamixel AX-12, ymontado mediante brackets plasticos, los cuales vienen incluidos con los mismos servos, ası como

6

tornillos, tuercas y cables conectores 3P. Ademas, se preve que el prototipo se sostenga a una basefija en una tabla a traves de un suporte de tornillo, pinza o prensa. Se obtiene entonces un brazorobotico con posibilidad de movimientos en un plano horizontal X-Y, como el de la figura 2, peroconformado unicamente por los primeros dos servos senalados.

Figura 2: Paul the robot [4]. Brazo robotico conformado por 4 servos.

El soporte del lapiz se montara en el extremo del brazo, al final del segundo servo de la cadena.

Por otra parte, los servos estaran cableados en una estructura de Daisy Chain considerando elservo 1 como master. Es decir, el servo 1 va conectado directamente al puerto serial del Launchpadutilizado en el curso.

Cabe aclarar que los servos Dynamixel AX-12, funcionan tıpicamente a un voltaje de 11 V,consumiendo una corriente de 1.5 A, por lo tanto se prevee resolver la alimentacion de los mismosutilizando una de las fuentes del laboratorio del instituto o, en ultima instancia, mediante unafuente ATX comercial de 12V.

Como ultimo componente de hardware se tiene el LaunchPad de Texas Instruments utilizado enel curso, el cual cuenta con un microcontrolador msp430 que estara a cargo tanto del procesamientode los comandos como de controlar los servos, traduciendo dichos comandos en movimientos, ysobre el cual se configurara al sistema de comunicacion.

10.2. Arquitectura de software

A grandes rasgos se tienen dos modulos de software definidos, en primer lugar la biblioteca delsistema de comunicacion entre el microcontrolador y los servos, y por otro lado, el procesamientode los comandos en HPGL.

7

El sistema de comunicacion, se implementara configurando el puerto UART de transmision delLaunchpad msp430, debido a que los servos interpretan un protocolo de comunicacion de tipo halfduplex de comunicacion serial en la terminal de control. Es ası como se le transmite a los servos losmovimientos a ejecutar.

El modulo de procesamiento debera interpretar como maximo 5 comandos. Los comandos quea nuestro criterio son los mas relevantes en un sistema sencillo se mencionan a continuacion:

DF [ , ], Default Set Instruction, setea el brazo en un estado conocido de pocicion absoluta.

LPRINT “IN [ , ]”, Initialize Set Instruction, estara encargada de setear parametros de ini-cializacion como el tamano de la ventana de dibujo, y la posicion absoluta del sistema.

LPRINT “PA [X,Y]”, Plot Absolute, el cual traslada el extremo del brazo desde la posicionactual hasta las coordenadas X,Y.

END, indica que la secuencia de comandos finalizo y lleva el brazo al estado establecido enDF.

Se desarrollara una ”traduccion” de esta serie de comandos a codigo en C, interpretable por elmicrocontrolador msp430, para que este los envıe por el puerto UART hacia los servos.

En conclusion se implementaran las dos bibliotecas correspondientes a los modulos ya mencio-nados.

11. Planificacion

11.1. Actividades y tareas

Actividad DescripcionDuracion es-timada

Funciones decomunica-cion

Implementar comunicacion serial half duplexentre el puerto de transmision UART del mi-crocontrolador y ambos servos

6/5 al 17/5

Biblioteca decomunica-cion

Crear la biblioteca integrando las funciones delsistema de comunicacion implementado

17/5 al 19/5

Script en CProgramar movimientos sencillos para ser eje-cutados por los servos mediante un script enlenguaje C

19/5 al 30/5

Funcionesde procesa-miento

Implementar funciones que traduzcan cada co-mando en HPGL a lenguaje C interpretablepor el microcontrolador

30/5 al 10/5

Bibliotecade procesa-miento

Crear biblioteca de funciones de procesamien-tos de comandos en HPGL

10/5 al 11/5

Cuadro 1: Actividades a realizarse.

8

11.2. Pruebas

Para testear que el modulo de comunicacion esta configurado correctamente se va a debuggearel codigo de las herramientas para ver registros del msp430, brindadas por el CCS. En simultaneo aeste chequeo, se intentara enviar movimientos sencillos e individuales, en principio valiendonos deun solo servo, para luego concatenar ambos servos y coordinar los movimientos.

Para el testeo de las funciones de procesamiento se cargara el comando a enviar hacia el servo(decodificado) en un buffer auxiliar, y se observara si el mismo es correcto antes de ser enviado porel puerto.

11.3. Hito intermedio

Se espera tener el protocolo de comunicacion entre los servos y el microcontrolador completa-mente configurado, con la respectiva biblioteca practicamente terminada. De esta forma sera posiblerealizar algun movimiento sencillo, a partir de instrucciones en C, para mostrar que efectivamentela comunicacion es exitosa.

11.4. Cronograma

Se aclara que no esta determinada la dificultad relativa de las tareas intermedias. Uno de losriesgos del proyecto es la posibilidad de subestimar acciones crıticas.

Semana Tarea Descripcion

Semana 29/4Previo al comienzo formal del proyecto: defi-nicion del lenguaje de comandos

Se hizo una investigacion de lenguajes de represen-tacion grafica para sistemas roboticos que preferi-blemente estuvieran estandarizados. Las principalesopciones que se tuvieron en cuenta fueron GCode,Postscript y HPGL. Basandonos en el volumen debibliografıa disponible, la compatibilidad con las tec-nologıas a utilizar y los principios de cada lenguajese concluyo que el lenguaje de comandos mas senci-llo y estandarizado que satisface las necesidades delproyecto es HPGL.

Semana 6/5Semana 13/5Semana 20/5

Modulo de comunicacionDesarrollo del modulo del comunicacion UARTserial half-duplex

Hito intermedio 24/5: presentacion del sistema de comunicacion propuesto, resultados preliminares de comunicacionentre el microcontrolador msp430 y los servos.

Meta opcional para el hito intermedio: incorporacion de algunos movimientos a partir de codigo en lenguaje C.Semana 27/5Semana 3/6Semana 10/6

Sistema completoIncorporacion de comandos de movimiento para 2articulaciones

17/6: Hito final y defensa del Proyecto.

Cuadro 2: Planificacion del proyecto

9

Referencias

[1] ”Portrait drawing by Paul the robot”, Tresset, Patrick. Fol Leymarie, Frederic. Department ofComputing, Goldsmiths College, 25 St James, London, United Kingdom.

[2] Sitio de The AIkon Proyect : https://sites.google.com/site/aikonproject/

[3] Sitio del dispositivo Line-us: https://www.line-us.com/

[4] Imagen de Paul the robot by Patrick Tresset:

https://www.tn2magazine.ie/algorithms-steel-bolts-and-a-biro/

10

PicassoBOT: Memoria de Proyecto · 2020. 2. 6. · PicassoBot es un brazo electro-mec´anico de dos...

Documents

Transcript of PicassoBOT: Memoria de Proyecto · 2020. 2. 6. · PicassoBot es un brazo electro-mec´anico de dos...