Visita mi canal de youtube

domingo, 16 de julio de 2017

Proyecto: Balance de robot de equilibrio


Introducción 

El objetivo de este proyecto fue crear un balance balanceado de dos ruedas capaz de atravesar un entorno plano y ajustarse a los cambios de posición y peso, utilizando un circuito de control de retroalimentación Proporcional-Integral-Derivado (PID) para mantener el robot en posición vertical. El robot de equilibrio es esencialmente un segway controlado inalámbrico que se inclina su cuerpo hacia delante y hacia atrás para corregir el "error" en su posición, si es que existe.

Motivado por nuestra intriga en los bucles PID que se implementaron en el tacómetro y controlador de motor del laboratorio 4 y el deseo de integrar las capacidades de computación de los controladores de mircocontrollers, deseamos diseñar un robot móvil que requiere el uso de un bucle PID multidimensional. El resultado fue un dispositivo económico y divertido que satisfizo nuestro objetivo deseado.
Diseño de Alto Nivel top


Decidimos implementar un Controlador Proporcional-Integral-Derivativo (Controlador PID) como el principal mecanismo de retroalimentación para nuestro bot de equilibrio para corregir errores en la aceleración. Debido a que el eje del acelerómetro está paralelo al suelo cuando el balance está en posición vertical, la gravedad o las desviaciones del ángulo de referencia se registrarán como aceleración y producirán un error. Este error se introduce en el algoritmo PID y se utiliza para calcular los parámetros de control del motor.


Figure 1: Basic Structure of the Feedback Control System
Figure 2: PID Control Algorithm
En nuestro caso, PID es la cantidad de swing que el robot moverá para eliminar el error. A continuación se describe una descripción de cada término:

A * Error: Este término es proporcional al valor de error actual. Si el robot está inclinado de una manera, compensa el error y oscila su cuerpo en una dirección opuesta a, pero proporcional al error. Este término es una retroalimentación directa al acelerómetro. Si el coeficiente A es demasiado grande, la corrección de error se convierte en un bucle de realimentación positiva.

B * Integral: La contribución del término integral es proporcional tanto a la magnitud del error como a la duración del error. Este término corrige cualquier error de acumulación que compile si el primer término no lo ha corregido. Debido a que la integral es una acumulación de errores pasados, el coeficiente B no puede ser demasiado grande, o bien el robot seguirá ajustándose para errores pasados ​​incluso si finalmente se corrige a sí mismo.

C * Derivado: Este término es proporcional a la derivada del error. Este término se utiliza para predecir el error futuro y ajusta proactivamente el cuerpo del robot para evitar ese error. Un coeficiente masivo C resultará en un robot que es extremadamente sensible al ruido, y que hará ajustes erróneos.

Justificación y origen de nuestra idea de proyecto
La inspiración para esta idea vino de un problema que ocurra bastante a menudo cuando la carreras construyó los coches de encargo de RC. Cuando un coche RC viaja a altas velocidades e intenta girar, a veces se vuelca como resultado de la dirección de entrada, la velocidad y la fricción con el suelo. Los desplazamientos ocurren cuando las fuerzas en las curvas desestabilizan el vehículo. Cuando un automóvil hace un giro brusco, la fuerza centrípeta, los efectos inerciales y la gravedad actúan en el coche. Las fuerzas de curvatura del neumático actúan por debajo del centro de masa y empujan el coche hacia el centro de la curva. Además, la inercia actúa horizontalmente a través del centro de masa del coche lejos del centro del turno. Juntas, estas dos fuerzas hacen que el coche gire hacia el exterior de la curva. La fuerza del peso del coche actúa hacia abajo a través del centro de masa en la dirección opuesta. El coche comienza a girar como la combinación de las fuerzas inerciales y centrípeta derrotar la fuerza de la gravedad.

Inicialmente queríamos diseñar un sistema que pudiera combatir estas fuerzas e impedir el vuelco de un coche RC, pero optó por una idea más fácil, dadas las limitaciones de tiempo y espacio. Acelerar un coche de RC a velocidades lo suficientemente rápido como para dar lugar a rollover en un pequeño aula de laboratorio no sería posible y se ve obligado a salir a probar nuestro coche RC después de cada actualización incremental resultaría ser mucho tiempo. Después de investigar los pasados ​​proyectos ECE 4760 y navegar en línea, decidimos optar por un robot de equilibrio de dos ruedas que imita los movimientos de un segway. Al tener sólo dos ruedas, limitamos el número de fuerzas y, por tanto, los grados de libertad que necesitamos para contrarrestar con un bucle PID.

Matemáticas de fondo
La precisión de nuestros resultados se basa en unas pocas métricas que cuantifican el éxito de la transmisión de paquetes entre transceptores de RF. Para el cálculo de las medidas de pérdida de paquetes, hacemos que un transceptor transmita de 100 a 5000 paquetes. Debido a que estos paquetes tienen una carga útil conocida, la tasa de error de paquete se puede calcular en el módulo receptor. La pérdida de la trayectoria del espacio libre (FSL) es la pérdida en la intensidad de la señal de una onda electromagnética que resultaría de una trayectoria de la línea de vista a través del espacio libre, sin obstáculos cercanos para causar la reflexión o la difracción. La figura # muestra la ecuación utilizada para calcular el FSL. Lambda es la longitud de onda a 2,4 GHz y R es la línea teórica máxima de rango de visión obtenible en metros.

Figure 3: Calcualtion of the FSL
Además, Bit Error Rate (BER) es el número de bits recibidos de un flujo de datos a través de un canal de comunicación que ha sido alterado debido a ruido, interferencia, distorsión o errores de sincronización de bits. Paquete Error Rate (PER) es el número de paquetes de datos recibidos incorrectamente divididos por el número total de paquetes recibidos. El procedimiento para calcular el PER es el siguiente:
1. Transmitir una señal RF del módulo 1 que el receptor puede demodular.
2. Varíe el número de paquetes transmitidos desde el módulo 1 en un enfoque sistemático.
3. Contar el número de errores en los paquetes recibidos en el módulo 2.
4. Repita los pasos 1-3 para una variedad de distancias y paquetes con diferentes cargas útiles.

Estructura lógica
El robot de equilibrio se estructura en tres etapas diferentes: la etapa de comunicación inalámbrica, la etapa de Controlador Proporcional-Integral-Derivativo (Controlador PID) y la etapa de Modulación de Ancho de Pulso (PWM). El cambio de contexto entre etapas se completa con el kernel TinyRealTime que permite que varias tareas en tiempo real se ejecuten simultáneamente, con cada tarea que se comporta como si fuera el único programa en ejecución. La figura que muestra el diagrama de transición de estado anterior refleja el flujo de estos estados durante el funcionamiento normal. Cada uno de estos estados representa eventos tanto en hardware como en software y será segmentado en componentes de hardware y software.

Nuestro proyecto contiene dos CPUs que se comunican entre sí, ATMega16 y ATMega1284. La comunicación inalámbrica entre las CPUs se realiza mediante dos transceptores nrf24l01 +. El ATMega16, junto con un transceptor de RF, está conectado al Nunchuck Wii para transmitir comandos direccionales al segundo transceptor de RF y ATMega1284 para recibir e interpretar comandos para el bot de equilibrio. Para conseguir el control bidireccional del motor, una señal PWM oscila rápidamente la tensión aplicada al motor. Junto con el bucle de control PID y la información del acelerómetro, el robot de equilibrio se mueve con precisión y contrarresta eficazmente el error actual en postura vertical.

Compensaciones de hardware y software
Optamos por las grandes ruedas todo terreno 120x60mm en lugar de un par de ruedas más pequeñas porque una combinación más grande de rueda y neumático reduce la altura de los flancos del neumático. La pared lateral es la distancia entre los diámetros exterior e interior de un neumático, o la distancia desde donde el neumático se encuentra con el pavimento hasta donde el neumático se encuentra con la rueda. Las alturas cortas de los laterales mejoran el manejo, pero ofrecen un recorrido más duro. Además, las ruedas más grandes elevan el centro de gravedad del robot y hacen que el robot sea más sensible a los cambios de posición y de peso. Para demostrar la capacidad de nuestro robot para equilibrarse a sí mismo, es ventajoso tener un paseo suave y un centro de gravedad alto. Esto asegura que nuestro robot se ajuste continuamente a medida que se mueve a lo largo de un camino.

Además, hemos decidido utilizar la comunicación inalámbrica para controlar el equilibrio bot. Para implementar la comunicación inalámbrica, se eligieron los transceptores nRF24L01 +. La adición de dos transceptores amplifica el nivel de complejidad del proyecto porque ahora tenemos que programar y probar los transceptores y depurarlos si algo no sale como estaba planeado. Por ejemplo, durante la fase de pruebas de este robot, nos dimos cuenta de que el ruido causó un problema enorme en el reconocimiento exitoso de un paquete. Incluso después de aislar los transceptores y de quitarnos de tanto ruido como sea posible, los errores de transmisión todavía ocurrieron. Sólo después de leer la hoja de datos de este componente descubrimos y comprendimos el protocolo Enhanced ShockBurst (ESB) para combatir el problema del ruido. Enhanced ShockBurst es un protocolo que admite reconocimientos automáticos y retransmisión de paquetes para lograr una comunicación fiable a expensas de un rendimiento reducido.
En el extremo opuesto del espectro, si decidimos no utilizar los transceptores, nuestro balance bot estaría limitado en el alcance de la longitud de un cable conectado a la Nunchuck Wii. No sólo el amarrar el controlador hace que el transporte de nuestro robot sea más difícil, sino que también crea un peligro para la seguridad porque se desenrolla una longitud larga de alambre en el suelo y se puede tropezar fácilmente. La comunicación inalámbrica extiende el territorio que nuestro robot puede recorrer a 100 metros, y proporciona un aspecto pulido a nuestra composición.

Estándares
Para implementar la comunicación entre el PC, a través de PuTTY, y nuestro microcontrolador, serializamos datos de acuerdo con el estándar UART. Un circuito integrado que conecta el puerto serie al microcontrolador implementó el estándar RS-232, que establece los estándares sobre las configuraciones de los pines, así como las características eléctricas y el tiempo de las señales. UART es útil para imprimir las actualizaciones de estado durante el proceso de depuración. Los transceptores nRF24L01 + y el microcontrolador se comunican mediante el bus SPI (Serial Peripheral Interface), una implementación que ya existía en los controladores que seleccionamos.

Derechos de Autor Relevantes
No obtuvimos inspiración de productos comerciales para esta idea, pero más tarde descubrimos que existía un robot controlado por un smartphone y un gesto impulsado por WowWee (MIP). Tiene un comportamiento análogo a nuestro robot, por lo que las patentes que ya existen para el MIP sería pertinente a las extensiones en nuestro diseño original. Sin embargo, existe una diferencia integral en los mecanismos de control de MIP y nuestro balance bot. MIP se controla con los gestos de los dedos en un teléfono inteligente a través de Bluetooth y nuestro robot está controlado por un Wii Nunchuck.

Las bibliotecas Tiny Real Time (TRT) y las bibliotecas suplementarias trtUart están protegidas por derechos de autor bajo la muy relajada licencia "Beer-Ware" de Joerg Wunsch. No existen otros derechos de autor o marcas registradas que conozcamos.
Hardware arriba

Con el fin de crear un robot segway controlable de forma inalámbrica hay varios componentes de hardware clave que deben ser utilizados. Son los siguientes: (1) un acelerómetro, (2) un puente H, (3) una batería, (4) un regulador, (5) un transceptor, (6) un controlador remoto y finalmente (7) un Microcontrolador Además necesitábamos crear la estructura mecánica del Segway Robot para alojar estos componentes eléctricos.

Componentes eléctricos

El Acelerómetro MMA8452Q
Con el fin de tener una manera de medir la inclinación del Segway Robot decidimos usar un acelerómetro. El acelerómetro MMA8452Q nos permite medir la aceleración en tres ejes con una precisión de 12 bits. El MMA8452Q funciona en 3.3V sin embargo el tablero que pedimos de sparkFun tiene un regulador incorporado 3.3V de modo que poder incorporar el 5V de MCU para accionar el acelerómetro. El acelerómetro MMA8452Q tiene puerto I2C en el que podemos comunicarnos. Al leer desde el puerto I2C podemos obtener los datos de aceleración del Segway Robot a la MCU y responder apropiadamente. El MMA8452Q proporciona una forma económica de obtener los datos necesarios para equilibrar el robot.

El puente H L298N
Otra faceta importante de nuestro diseño es el puente H de L298N. Un puente en H nos permite conducir un motor en cualquier dirección dependiendo de la lógica de entrada. El L298N tiene cuatro pines de entrada, cuatro pines de salida y dos pines de habilitación. Usando el L298N podemos conducir dos motores al mismo tiempo ya que tiene dos canales de salida. Sin embargo, ya que esperamos que las corrientes altas sean extraídas de los motores y el L298 sólo puede soportar hasta 2 amperios de cada canal, decidimos dos usar dos L298 para impulsar nuestros dos motores, cada uno con sus canales funcionando en paralelo. El funcionamiento de cada L298 individual en paralelo nos da una corriente máxima de 4 amperios para cada L298, que es suficiente. Somos capaces de controlar nuestros motores enviando dos pines lógicos y un PWM a cada L298. Utilizando las dos clavijas lógicas podemos especificar la dirección en la que queremos que la corriente fluya a través del motor y enviando el PWM al pin de habilitación, también podemos convertir la salida del L298 en PWM. Usando el L298 podemos controlar lo rápido que queremos que nuestros motores vayan, así como su dirección.

La batería LiPo
Debido a los altos requerimientos de energía de nuestro sistema (hasta 6A de separación entre los motores después del convertidor de impulso, lo que podría dar lugar a picos transitorios de 9A cargas en la batería) optamos por un paquete Li-Po, de inmediato el establecimiento de una configuración 3S (11.1V) ya que esto sería un equilibrio justo en términos de precios y requisitos de voltaje para nuestro sistema. En general, las baterías de litio de alto rendimiento pero asequibles se venden en el dominio del coche RC y aficionados a los aviones, ya que esta es una industria relativamente grande que ha existido durante décadas. El tiempo de ejecución fue una consideración importante en nuestro proceso de selección, con la esperanza de lograr una operación de 45 minutos a una hora bajo condiciones habituales - a aproximadamente 2A tirada media, esto daría un requisito de un paquete de 2Ah - relativamente pequeño, en la escala completa de opciones disponibles . Nos instalamos en un paquete de Turnigy 2.2Ah 3S de HobbyKing, un popular distribuidor de electrónica para usos de hobby, ya que fue muy bien revisado pero quizás el paquete más barato por capacidad dentro de su rango.

Los reguladores de voltaje
Nuestro diseño original exigía la regulación de 5V para los microcontroladores y los periféricos primarios, la regulación de 3.3V para el nunchuk y el módulo de RF conectados, y un voltaje elevado de alrededor de 20V para los motores de impulsión primarios (para aumentar su velocidad de no carga a aproximadamente 180 RPM), todo ello a partir de un solo suministro de baterías a bordo. Una vez que la batería se instaló como un paquete 3S Li-Po 11.1V, estaba claro que se requeriría un regulador de conmutación escalonado para la línea de motor de alta tensión.

LDO lineal podría haber sido utilizado tanto para 3,3 V y 5 V, pero con una caída de hasta 7V desde un paquete de LiPo completamente cargado al riel de 5V, las pérdidas en un regulador lineal se vuelven no trivial y para nuestro robot móvil tiempo de ejecución fue Ciertamente una preocupación. Resolvimos comprar un regulador de dólar DC-DC de Amazon, una placa de marca RioRand basada en LM2596, ya que estos son paquetes de regulación baratos y totalmente integrados que se ajustan perfectamente a nuestras especificaciones de diseño. Este tablero se utilizó para regular 5V de la entrada de batería no regulada, funcionando a eficiencias mucho más altas de lo que habría sido posible con un LDO. Sin embargo, debido a que la caída de 5V a 3,3V es relativamente mínima, y ​​el consumo de corriente de los periféricos de 3,3V también fue bastante trivial, pudimos simplemente usar un LDO para la línea de 3,3V y tocar su entrada del carril 5V principal .
La adición de un convertidor de alto voltaje para los actuadores fue un proceso más complicado. Nos instalamos inmediatamente en el regulador de conmutación multiuso MC34063 de On Semiconductors, ya que teníamos experiencia previa con ella y, en general, es una opción muy popular para aplicaciones de alto consumo de corriente como la nuestra. Debido a que el regulador en sí sólo está clasificado para 1,5A, y esperábamos hasta 6A en la parada entre ambos motores, necesitábamos hacer uso de un circuito de interruptor externo usando el MC34063. Basamos nuestro circuito en el trabajo realizado por Kenneth Finnegan, que se muestra a continuación. El regulador de conmutación debía ajustarse inicialmente a unos 20 V, por lo que nuestro circuito de realimentación se modificó con los valores de resistencia apropiados, con un nMOS genérico de nivel lógico utilizado como conmutador externo. Nuestro prototipo inicial del circuito en una placa fue exitoso, pero desafortunadamente el circuito tuvo problemas de última hora con el cableado una vez que fue soldado a una perf. Placa para la instalación en el robot, forzándonos para dejar el convertidor del alza apagado completamente y utilizar la tensión de batería no regulada directamente para el carril del motor de alto voltaje.

El transceptor nRF24L01 +
El nRF24L01 + de Nordic Semiconductor es un transceptor económico capaz de comunicación por paquetes a largas distancias. El propósito de las radios son proporcionar el control remoto un medio de obtener datos al Robot Segway. La radio nRF24L01 + es supuestamente fácil de usar, ya que puede comunicarse con una MCU a través de SPI. Los nRF24L01 + radios que ordred vinieron en una tabla breakout en la que teníamos acceso a los pines de alimentación, así como sus pines SPI. Usando SPI podemos configurar la radio también transmitir y recibir datos.

El control remoto
Con el fin de proporcionar al usuario un medio de control del Segway Robot, hemos diseñado un mando a distancia. Este control remoto tiene tres componentes principales, el nRF24L01 +, el ATmega16, y un Wii Nunchuk. Elegimos el ATmega16 para el controlador porque el código no será muy intenso y nos proporciona todo lo que necesitamos hacer. Para proporcionar al usuario una interfaz familiar decidimos utilizar un Wii Nunchuk. El Nunchuk de Wii tiene un desglose que expone la potencia y los pines I2C. Usando las clavijas I2C podemos usar el ATmega16 para comunicarnos con el Wii Nunchuk para obtener los valores del joystick, así como los valores de botón y acelerómetro. Utilizando los valores de la palanca de mando, el usuario puede enviar datos a la MCU que a su vez la transmitirá al Segway Robot. Basándose en la información que el Robot Segway recibe, sabrá si girar a izquierda o derecha, avanzar o retroceder, o permanecer inmóvil.

El ATmega644
Para comunicarnos con todos estos dispositivos periféricos elegimos el ATmega644. Elegimos el ATmega644 porque es muy parecido al ATmega1284 en el que hemos estado trabajando en el laboratorio, pero tiene menos memoria. Utilizando el ATmega644 tenemos los medios para controlar todos estos dispositivos periféricos, ya sea sobre SPI, I2C, clavijas lógicas, etc. Al cargar hasta el software correcto tenemos los medios para controlar el Segway Robot en su totalidad
Diseño mecanico

Nuestra metodología de diseño de hardware mecánico fue impulsada principalmente por dos factores antagónicos - el presupuesto limitado de $ 100 y el deseo de crear un chasis robótico de calidad para la tarea a mano. Con el fin de lograr el éxito con ambos criterios, un medio terreno de minimalismo práctico era necesario.

Debido a que el presupuesto era una restricción tan estricta, especialmente para un sistema mecatrónico totalmente integrado como este, nos pareció más fácil cuidar de todas las compras primero, con sólo una idea aproximada de nuestro diseño en mente, con el fin de restringir nuestro espacio de diseño Un poco más (a proporciones más manejables) y asegúrese de que todos los componentes requeridos estarían a mano una vez que el proceso de diseño final comenzó. Con el fin de ajustarse al presupuesto, limitamos nuestra búsqueda principalmente a terceros revendedores - eBay, All Electronics, Marlin P. Jones, etc. Las combinaciones de las diversas opciones de parte disponibles fueron estudiadas para compensaciones y el presupuesto, mostrado abajo, fue compilado como Lo antes posible en el proceso de diseño.

Quizás la decisión de compra más crucial fue la selección de los dos motores de accionamiento. Nuestras especificaciones requerían motores de corriente continua cepillados, con una capacidad nominal de aproximadamente 12V con corrientes de estancamiento de 3A máx., Con velocidades sin carga de alrededor de 100 RPM. Aunque los requerimientos de torque no fueron calculados inicialmente debido a las muchas incógnitas restantes en el diseño, se esperaba un motor de engranaje era necesario para optimizar para velocidades de rotación bajas a pares altos debido a la naturaleza de este diseño de "péndulo invertido". Lamentablemente, los revendedores secundarios difícilmente proporcionan especificaciones adecuadas sobre cosas como motores eléctricos, por lo que el proceso de selección fue tedioso y en gran medida basado en el trabajo de conjetura y la esperanza de que una foto de producto dado incluirá un número de parte válida. Finalmente nos instalamos en dos motorreductores Merkle-Korff reutilizados de eBay, ya que el vendedor fue capaz de proporcionar un dibujo mecánico y especificaciones eléctricas antes de tiempo, lo que nos permitió proceder con el diseño como esperábamos el envío.

Las ruedas fueron encontradas de manera similar en eBay, aunque, naturalmente, eran mucho más fáciles de seleccionar dada su naturaleza pasiva. Desafortunadamente, el vendedor no anunció que estas ruedas no tenían ninguna spline o cubo, forzándonos a luchar con la fijación de las ruedas a los ejes de transmisión de los motores. Terminamos encontrando unos cubos de tornillo de ajuste del diámetro perfecto y epoxi a las ruedas - una solución improvisada, pero desafortunadamente la geometría simplemente no permitió nada más limpio dados los recursos disponibles para nosotros.

Una vez que se adquirieron las piezas disponibles en el mercado, se inició el proceso de diseño mecánico. Después de considerar una serie de posibles direcciones de diseño durante nuestras sesiones iniciales de lluvia de ideas, nos decidimos por lo que más tarde se convirtió en nuestro diseño final, ya que parecía ser nuestra mejor opción de crear un robot estéticamente agradable, pero mecánicamente sano y financieramente viable. El diseño, que se muestra en las representaciones CAD, podría describirse como un trapezoide de alto peso con una simetría de plano sagital. Esta orientación nos permite maximizar el momento de inercia alrededor del eje de la rueda organizando la mayor parte del hardware interno (electrónica, batería, etc.) hacia la "cabeza" del robot y dejando la zona media vacía, optimizando así la autoridad de control cuando Equilibrio

El chasis consiste casi enteramente en hojas de plexiglás cortadas por láser, con unos pocos acoplamientos impresos en 3D y los elementos de sujeción necesarios - roscado térmico para el plexiglás, tornillos a juego, arandelas de presión y separadores para crear un andamio metálico para el tren de aterrizaje que sostiene los motores .

La construcción final, mostrada en las fotos, fue construida sin demasiados problemas. Tolerancias deficientes en el plexiglás cortado con láser dieron como resultado unos componentes excesivamente limitados, pero en general la estructura se siente rígida. Desafortunadamente, el peso del sistema de propulsión realmente domina toda la estructura, por lo que el centro de masa es un poco inferior al ideal. En las iteraciones futuras, puede ser necesario estirar el cuerpo del robot más arriba y posiblemente añadir peso artificialmente a la región de la cabeza con el fin de distribuir la masa más apropiadamente. Los problemas de tolerancia también podrían ser fácilmente atendidos con iteraciones adicionales que optimizan la manufacturabilidad, pero tales procesos son sólo una cuestión de tiempo y recursos.




Software top

Nuestro software se puede dividir en cuatro secciones principales, el acelerómetro, el Wii Nunchuk, los transceptores y el control del motor. Sus descripciones son las siguientes:

Código del Acelerómetro
Para interactuar con el acelerómetro necesitamos usar un puerto I2C (TWI). Para configurar el I2C en el ATmega1284 decidimos usar la biblioteca I2C de Peter Fleury. En su biblioteca I2C tenemos la capacidad de inicializar, leer y escribir todo usando I2C. El uso de esta biblioteca proporciona un medio fácil de comunicarse con el acelerómetro. Primero para probar las comunicaciones, escribimos código para probar soley el acelerómetro. Utilizando el protocolo I2C que encontramos en la hoja de datos del acelerómetro, pudimos comunicarnos con el acelerómetro. Utilizando el código de prueba, pudimos leer y escribir en el acelerómetro y ver las medidas del acelerómetro impresas en serie.

Código Wii Nunchuk
Al escribir el código para el Nunchuk de Wii tomamos un acercamiento similar como hicimos con el acelerómetro. Primero escribimos código de prueba para probar soley el Wii Nunchuk. Nuestro código fue diseñado para leer datos de Wii Nunchuk y la impresión de esas lecturas a serie. Mientras que el Wii Nunchuk también se comunica usando I2C pudimos encontrar otra biblioteca en línea, escrita por Davide Gironi, que fue específicamente para comunicarse con el Wii Nunchuk. Esta biblioteca también estaba basada en la biblioteca I2C de Peter Fleury. Cuando intentamos por primera vez comunicarnos con el Wii Nunchuk no pudimos leer correctamente los datos de nuestro Nunchuk. Tras la depuración y la inspección posterior, encontramos que teníamos que poner un retraso de cinco milisegundos entre la escritura y la lectura de lo contrario los datos leídos se corrompería. Después de implementar este retraso, encontramos que el Wii Nunchuk funcionaba perfectamente.

Código RF
Una vez más, ya que nuestro enfoque estaba funcionando, nos acercamos al código RF de la misma manera. Hemos encontrado una biblioteca específicamente para el nRF24L01 +, escrito por Yi Heng Lee, y el código implementado para probar únicamente estos transceptores. Sin embargo esta vez encontramos que podríamos parecer conseguir el código que trabaja. Intentamos varias variaciones del código pero en vano. Hemos revisado dos veces para asegurarnos de que la configuración SPI en el ATmega1284 era correcta y que los pines coincidían pero nos dimos cuenta de que no podíamos comunicarnos usando estos radios. Incluso uno de nuestros miembros del equipo, Andre, escribió código simple usando un tutorial que encontró en línea para comunicarse usando SPI con el nRF24L01 + pero sin suerte (vea my_nRF desde el apéndice). El nRF24L01 + no mostró signos de funcionalidad y hasta el día de hoy no sabemos por qué no hemos podido comunicarnos con el nRF24L01 +.

Código de control del motor
Para controlar los motores tuvimos que usar dos señales PWM, y cuatro líneas lógicas. La configuración de estos PWM era muy similar al tacómetro del laboratorio 4 y por eso decidimos reciclar el control del motor desde el tacómetro. También del laboratorio del tacómetro reciclamos el bucle PID que estábamos usando y lo rediseñamos para que se ajuste a los propósitos de este proyecto. Desafortunadamente no tuvimos tiempo para probar este código, así que no vimos si funcionaría hasta que hubiéramos puesto el Segway Robot juntos.

Poniendolo todo junto
Ahora que habíamos escrito código para cada uno de los componentes clave, era el momento de ponerlo todo junto. Decidimos utilizar TinyRealTime ya que nos ayudaría a organizar mejor los tiempos de tarea de conjunto de códigos. Originalmente habíamos decidido poner cada una de las piezas de código en diferentes tareas, pero nos dimos cuenta de que nunca querríamos actualizar el bucle PID sin primero desde el acelerómetro. Puesto que cada componente individual funcionaba, poner el código en conjunto era fácil ya que sabíamos qué funcionaría y qué no, con excepciones de la tarea de control del motor.
Resultados top

Velocidad de ejecución
La velocidad de ejecución de nuestro diseño es bastante rápida. Al elegir amarrar el Nunchuck Wii directamente al ATMega1284, la cuestión de la latencia era casi inexistente. El tiempo que tarda la transmisión de comandos direccionales desde el Nunchuck de Wii al microcontrolador aumenta siempre ligeramente por cada pie adicional de alambre al que está conectado el Nunchcuk. Por suerte, la longitud de este cable es de 4 pies y el tiempo que tarda el microcontrolador para afinar el bucle PID de acuerdo con los nuevos parámetros se produce en una escala de milisegundos. Un milésimo de retraso es insignificante y no debería afectar la calidad de la interacción de un usuario con nuestro bot de equilibrio.

Exactitud
Aunque no pudimos implementar los transceptores nRF24l01 +, realizamos una gran cantidad de investigación con respecto a su exactitud. Estos transceptores tienen un alcance máximo de 100 metros y el aumento de la distancia entre dos transceptores de RF aumenta la probabilidad de ruido y errores de paquete. Por suerte, debido a que nuestro producto está destinado a ser utilizado en un entorno doméstico, la distancia media que los consumidores utilizan el equilibrio bot es de 30 metros, lo que garantiza no perturbación significativa del ruido.

Para aumentar el porcentaje de transmisiones de paquetes exitosas, la documentación nRF24L01 + recomienda que las direcciones de envío y recepción tengan múltiples transiciones entre 1 y 0 bits para evitar que se confundan ruidos con los paquetes. Por ejemplo, una dirección tal como 0xFFFFFFFFFF, o direcciones donde el nivel se desplaza sólo una vez (es decir, 000FFFFFFF) puede a menudo ser detectada en ruido y puede dar una falsa detección, lo que puede conducir a una mayor tasa de error de paquete (PER). PER es el número de paquetes de datos recibidos incorrectamente divididos por el número total de paquetes recibidos.

Antes de analizar las siguientes cifras para cuantificar las distintas mediciones de error, he aquí algunas definiciones de los términos utilizados. Como se define en "Definiciones Estándar de Términos para Antenas", IEEE Std 145-1983, Free-Space Path Loss (FSL) es "La pérdida entre dos radiadores isotrópicos en el espacio libre, expresada como una relación de potencia". De forma similar, la tasa de error de bits (BER) se define como el número de errores de bits dividido por el número total de bits transferidos durante un intervalo de tiempo estudiado, expresado como un porcentaje.

                              Figure 6: Graph of BER vs PER [Experimentation for Packet Loss]

Figure 7: Graph of Range vs FSL [Experimentation for Packet Loss]
 La seguridad
Una corriente de aproximadamente 50mA y encima a través de su corazón puede matarlo. Bajo las condiciones adecuadas, hay suficiente corriente en una batería de 9V para causar la muerte. Nos aseguramos de que todos los circuitos eran lo más compactos posible y que todas las baterías y conexiones eléctricas estaban bien separadas para minimizar la posibilidad de un cortocircuito eléctrico. Además, nuestro robot tiene un cuerpo cerrado que asegura que no hay componentes eléctricos en contacto directo con la piel.

Las condiciones de funcionamiento predeterminadas suponen que este robot está en el suelo. Sin embargo, debido al tiempo inclemente, la gente puede seguir el agua, la nieve, o el fango en el piso, que puede causar problemas al robot. Otras actualizaciones de este proyecto pueden incluir la impermeabilización del cuerpo del robot para evitar dañar al usuario y / o componentes eléctricos.

Otro riesgo posible es tropezar en el robot si no está consciente de su entorno. Desafortunadamente, esto es un riesgo inherente con cualquier dispositivo que se puede colocar en el suelo y puede convertirse en un obstáculo en su camino. La mejor resolución para este dilema es simplemente ser más conscientes al caminar.

Interferencia
Nuestros transceptores de RF operan en la banda de frecuencia de 2,4 GHz y tienen el potencial de interferir con otros transceptores inalámbricos que se ejecutan en la misma frecuencia. Debido a que nuestro producto está destinado a los consumidores en el entorno doméstico, la posibilidad de que el equilibrio de bot es en presencia de otros dispositivos que operan en este rango, como teléfonos, enrutadores inalámbricos o microondas es probable. Sin embargo, esta preocupación es bastante trivial porque los transceptores nRF24L01 + descartarán paquetes con un número de identificación incorrecto, lo que significa que sólo los paquetes correctos serán almacenados y procesados. Por último, durante nuestra demostración de proyecto, ningún otro grupo presente utilizaba los mismos transceptores de RF. Además, al activar el protocolo Enhanced ShockBurst (ESB), el problema del ruido fue mitigado. Enhanced ShockBurst es un protocolo que admite reconocimientos automáticos y retransmisión de paquetes para lograr una comunicación fiable a expensas de un rendimiento reducido.

Usabilidad
Nuestro objetivo era crear un equilibrio bot que imitaba un producto final listo para la producción en masa. Los consumidores de este producto no necesitan leer un largo manual de instrucciones para comprender cómo usar este robot. Simplemente enciéndalo y utilice el controlador para dirigir el robot. En caso de caídas y caídas, todos los módulos están montados sobre y encerrados en plexiglás que proporciona una construcción robusta capaz de absorber golpes. El sistema ya es relativamente ligero y compacto y se pueden obtener mejoras adicionales a las características antes mencionadas aumentando sustancialmente los costes de los componentes.

En cuanto al atractivo visual de nuestro producto, la calidad de la soldadura reduce ligeramente esto. Estábamos limitados por las limitaciones de tiempo y los consejos de soldadura voluminosos que no producen una precisa soldadura conjunta. Sin embargo, sólo bajo un estrecho escrutinio es este fallo notado y por lo tanto no debe ser considerado. La ergonomía de nuestro joystick es superior a otros controladores en el mercado porque utilizamos el Wii Nunchuck, un controlador que ha sido diseñado específicamente para la comodidad de los consumidores, después de años de investigación por el equipo de Nintendo.




Conclusiones arriba

Pensamientos finales
El resultado de nuestro balance bot ha satisfecho nuestras expectativas. Hemos creado un bot de equilibrio funcional que era sensible a su propio peso y posición y se ajustaba para alcanzar la máxima estabilidad. Recopilamos el conocimiento adquirido de los cursos, no sólo en ECE 4760, sino también en muchas clases anteriores e integramoslos en un solo producto. A pesar de que no pudimos implementar la comunicación inalámbrica con transceptores de RF, estábamos orgullosos de nuestra colaboración y esfuerzos de trabajo para ensamblar y finalizar el código para este proyecto en el marco de tiempo limitado que teníamos.

Para futuras iteraciones de este proyecto, nos gustaría asegurar la capacidad de atravesar un terreno no plano o inclinado. En este momento, sólo garantizamos la capacidad del robot para viajar sobre superficies planas. Esto puede hacerse ajustando aún más el bucle PID, adquiriendo un conjunto diferente de ruedas que son resistentes a los cambios en la topografía, o la obtención de un motor más potente. Además, podemos agregar un surtido de funciones al balance bot, como la definición de macros o el aumento / disminución de velocidad. Para utilizar estas nuevas características, tendremos que asignar los botones no utilizados en el Nunchuck Wii para realizar estas capacidades. Si la inclusión de estos nuevos elementos desorden el joystick actual, un joystick más avanzado como el controlador de Xbox 360 puede ser adaptado. Como se discutió en la sección de Usabilidad, una mayor asignación de tiempo nos permitirá soldar juntas lentamente para lograr una apariencia más profesional, o invocar el uso de máquinas automáticas de soldadura por ola para producir una junta de soldadura impecable. Otra forma en que podemos mejorar la apariencia de nuestro robot es añadir pequeñas revisiones mecánicas al diseño de nuestro cuerpo de robot. En este momento, las juntas de enclavamiento del cuerpo del robot son muy apretadas y producen una deformación visible que comprime el cuerpo y desvía las ruedas a un ángulo por encima del paralelo. Otra forma de reformar la apariencia del robot incluye intercambiar los convertidores de impulso soldados descuidadamente que fueron creados bajo estrictas limitaciones de tiempo y una planificación mínima del diseño de PCB. Estamos bajo el presupuesto de $ 100 y podíamos permitirnos reemplazar nuestro convertidor impulsado apresuradamente para un producto comercial.

Por último, nos encantaría utilizar un conjunto de transceptores de RF para permitir la comunicación inalámbrica. Debido a que los transceptores nRF24L01 + han dado a los individuos una gran cantidad de problemas de ruido, planeamos obtener transceptores de RF con una mayor gama y reducción de ruido más eficiente para aumentar la calidad general de este producto. Al incorporar transceptores de RF mejorados, existe una menor posibilidad de que no se reciban órdenes y la posibilidad de ampliar la base de consumidores a los entusiastas que compiten con estos vehículos que no hubieran podido hacerlo con el alcance limitado.

¿Nuestro diseño se ajustó a las normas?
Para facilitar el proceso de depuración, cumplimos con los estándares RS-232, definidos por la Electronics Industries Association (EIA), para permitir la comunicación entre la interfaz UART del microcontrolador y un emulador de terminal en un ordenador.

Consideraciones sobre propiedad intelectual
La información utilizada para crear este proyecto fue el conocimiento adquirido de las clases anteriores tomadas en la Universidad de Cornell, hojas de datos de componentes proporcionadas por los fabricantes de componentes, la sección de exposición de los foros en línea de Arduino y el blog "YBot - Balancing Arduino Robot" ¡Robots! sitio web.

La motivación para este proyecto y el diseño inicial del hardware se puede atribuir a un post de blog presentado en el Let's Make Robots! Sitio web de Dallaby y un foro en línea en los foros de Arduino por un individuo con el nombre de usuario "Kas". Su trabajo y código preliminar nos dio una buena comprensión de lo que necesitábamos hacer para conectar correctamente la MCU con los acelerómetros.

La sección de software de nuestro proyecto fue una combinación de varias bibliotecas. La biblioteca Tiny Real Time (TRT) permite que muchas tareas en tiempo real se ejecuten simultáneamente, con cada tarea que se comporta como si fuera el único programa en ejecución. Esto permite que la MCU cambie de contexto entre tareas en tiempo real. Esta biblioteca fue escrita por Dan Henriksson y Anton Cervin, pero modificada por Bruce Land exclusivamente para el curso ECO 4760. Además, trtUart facilitó el proceso de depuración de nuestro dispositivo mientras desarrollábamos nuestro código y hardware. Esta biblioteca fue escrita por Joerg Wunsch para permitir comunicaciones UART con un microcontrolador que utiliza el kernel TRT.
Además, la comunicación entre los transceptores nRF24L01 + se llevó a cabo utilizando los controladores escritos por Yi Heng Lee. Lee proporciona una API que se encarga automáticamente de muchas configuraciones de pin y tiene funciones para crear paquetes de una manera simplista. Además, Davide Gironi creó la biblioteca que nos permite acceder a los valores de joystick y acelerómetro de Wii Nunchuck. Al igual que la API de Lee, esta biblioteca también incluye funciones para hacer que la interfaz con el Nunchuck de Wii sea un proceso fácil.

Finalmente, para diseñar este sitio web, hemos adaptado una plantilla para el sitio web del proyecto Spring 2010, Human Tetris, de Adam Papamarcos y Kerran Flanagan. El sitio web del proyecto está incluido en la sección de referencias de este sitio. Las patentes enumeradas anteriormente sólo están relacionadas con nuestro proyecto y no usamos directamente ninguna de las ideas que se reivindican dentro de ellas. Nuestro diseño final es una colaboración de código escrito previamente y conceptos de diseño de una variedad de fuentes, por lo que no poseen la propiedad intelectual con respecto a la implementación de un robot de autoequilibrio. No hicimos ingeniería inversa en un diseño, por lo que no hay problemas de patentes o marcas registradas. No tuvimos que firmar ningún acuerdo de no divulgación para partes de muestra. A partir de ahora, no hemos considerado la posibilidad de cualquier patente o oportunidades de publicación.

Consideraciones éticas
El Código de Ética de IEEE fue rigurosamente respetado a lo largo de nuestro prototipo de diseño. Específicamente, hubo dos aspectos del código que resonaron con nuestro equipo. En primer lugar, el punto siete del código dice: "buscar, aceptar y ofrecer críticas honestas al trabajo técnico, reconocer y corregir errores, y acreditar apropiadamente las contribuciones de otros". Esto fue pertinente para nosotros durante las etapas de planificación inicial del proyecto final al discutir cada elemento de nuestro diseño con Bruce Land y los AT. Inicialmente sobreestimamos la cantidad de tiempo que cada uno de nosotros pudimos aportar y propusimos un proyecto con muchas más características de las que tenemos tiempo de implementar. Afortunadamente, hablando con Bruce Land y los TA nivelado nuestras amibtions y nos obligó a repensar sobre lo que era realmente posible durante el período de tiempo que nos dieron. Originalmente, queríamos dar a nuestro robot la capacidad de equilibrio sobre terreno irregular y inclinado, pero la escala de esta capacidad de nuevo a sólo incluyen terreno plano. En segundo lugar, el punto tres estados, "para ser honesto y realista en la declaración de las reclamaciones o estimaciones basadas en los datos disponibles". Esto fue relevante para nosotros cuando se redactó el sitio web final y se preparó para la demostración del proyecto. Debido a la enorme cantidad de interferencia presente en el laboratorio, los módulos RF que transmiten los comandos de Wii Nunchuck para mover el robot están limitados en la distancia. De acuerdo con las especificaciones de hoja de datos de los transceptores nRF24L01 +, la gama se supone que es de 100 metros. Al probar la gama de los transceptores, llegamos a la conclusión de que, si bien estos componentes pueden ser capaces de comunicarse en la gama antes mencionada, sin duda no está sin disturbios significativos ruido y puede operar sin ruido significativo en un rango de 20 metros. Por otra parte, la movilidad de nuestro equilibrio del bot era limitada debido al tamaño grande de la rueda que fue elegido. El radio de giro de nuestro robot es enorme y adeptamente itinerancia un evironment es complicado, especialmente un entorno con la existencia de los obstáculos. Como ingenieros morales que desean permanecer veraces durante todos los aspectos de nuestra escritura y demostración, no mentimos acerca de ningún componente no funcional de nuestro equilibrio bot y observamos los defectos que existían, es decir, el alcance limitado y la movilidad. El Código de Ética de la EEI fue una poderosa colección de reglas que impactaron significativamente la creación de nuestro robot.

Consideraciones legales
Nuestro proyecto, a nuestro conocimiento, no viola ninguna norma legal. Como advertencia, tenga en cuenta que los usuarios deben advertir precaución al utilizar este robot entre los niños pequeños. Los niños podrían ser capaces de romper un pedazo fuera del cuerpo del robot y tratar de comer. Además, nuestro proyecto no emite ningún EMF o sonido excesivo. Los transceptores de RF que planeamos utilizar funcionan en la misma frecuencia de 2,4 GHz que los enrutadores y teléfonos inalámbricos operan y no proporcionan más daño que estos dispositivos ya hacen a un individuo. Por último, algunos componentes de nuestro diseño se basaron en código fuente que está disponible gratuitamente para uso personal y / o educativo, por lo que no hay violación del robo de propiedad intelectual.

Appendix    top

A. Schematic


Figure 9: Schematic of the Segway Robot board (note that the PWM and control pins we used in our final project is different)


 Figure 10: Schematic of the Segway Robot controller board























0 comentarios:

Publicar un comentario