Comunicación entre procesadores para brazo robótico


13

Estoy construyendo un brazo robótico de 6 DOF y me pregunto cuál es la mejor manera de comunicarse entre los procesadores (3-4 AVR, separación máxima de 18 pulgadas). Me gustaría que el bucle de control se ejecute en la computadora, que envía comandos a los microprocesadores a través de un USB Atmega32u4 a - ??? puente.

Algunas ideas que estoy considerando:

  1. RS485
    • Pros: todos los procesadores en el mismo cable, señal diferencial más robusta
    • Contras: requiere chips adicionales, ¿necesita escribir (o buscar?) Protocolo para evitar que los procesadores transmitan al mismo tiempo
  2. Bucle UART (es decir, TX de un procesador está conectado a RX del siguiente)
    • Pros: firmware simple, los procesadores tienen UART incorporado
    • Contras: la última conexión tiene que recorrer la longitud del robot, cada procesador tiene que pasar ciclos retransmitiendo mensajes
  3. CANbus (sé muy poco sobre esto)

Mis consideraciones principales son la complejidad, el rendimiento y el precio del hardware y el firmware (no puedo comprar un sistema costoso listo para usar).

Respuestas:


13

Desea usar USB para las comunicaciones con la computadora. Si tiene varios microcontroladores, probablemente solo conectará uno de los microcontroladores directamente a la computadora. Los otros microcontroladores necesitarán obtener sus comandos del microcontrolador principal.

La comunicación que elija dependerá de varios factores:

  • ancho de banda requerido (asumiremos que los está ejecutando a 16MHz)
  • complejidad (cableado y codificación)
  • bidireccional o maestro-esclavo

Casi todas las opciones tienen soporte incorporado en el microcontrolador AVR. No hay una opción que pueda preferir razonablemente sobre las opciones integradas que requerirían hardware adicional. Debido a que tienen soporte incorporado, la complejidad del software es muy similar, ya que solo configura el puerto (usando registros), coloca los datos para transmitir en otro registro y luego activa la transmisión configurando un bit en otro registro. Cualquier dato recibido se encuentra en otro registro y se activa una interrupción para que pueda manejarlo. Cualquiera que sea la opción que elija, la única diferencia es el cambio en las ubicaciones de los registros y algunos cambios en los registros de configuración.


Un bucle USART tiene las siguientes características:

  • Velocidad de transmisión máxima de CLK / 16 = 1MHz (a un reloj de 16MHz), que es una velocidad de transferencia de alrededor de 90KB / s
  • Comunicaciones totalmente bidireccionales (sin designación de maestro o esclavo)
  • requiere cables separados entre cada par de microcontroladores: el Atmega32u4 admite dos puertos USART de forma nativa, lo que limita la cantidad de microcontroladores que puede conectar en una red en la práctica (o de lo contrario terminará con una larga cadena de microcontroladores, es decir, conectado en una lista vinculada conducta)

Nota: esto también es lo que usaría para obtener la comunicación RS232, excepto que debido a que RS232 requiere 10V, requiere un controlador para obtener esos niveles de voltaje. Para la comunicación entre microcontroladores, esto no es útil (solo se cambian los niveles de voltaje).

RS485:

  • Esencialmente, usa el puerto USART en un modo diferente: no hay ventaja en el ancho de banda, y puede que solo simplifique un poco el cableado, pero también lo complica. Esto no es recomendable.

Interfaz de dos hilos:

  • Esto también se conoce como I2C. Esto significa que todos los dispositivos comparten los mismos dos cables.

  • Necesita una resistencia pull-up en ambos cables

  • Es lento (porque las resistencias pull-up tienen un valor limitado y aumenta la capacitancia a medida que aumenta el número de dispositivos y aumenta la longitud del cable). Para este microcontrolador AVR, la velocidad es de hasta 400 kHz, más lenta que la USART (pero esta velocidad depende de limitar su capacidad). La razón es que, aunque un dispositivo baja el cable de datos, la transición opuesta se logra dejando que el cable flote de nuevo (la resistencia pull-up).

  • Es aún más lento cuando considera que TODAS las comunicaciones comparten el mismo ancho de banda limitado. Debido a que todas las comunicaciones comparten el mismo ancho de banda limitado, puede haber demoras en la comunicación donde los datos deben esperar hasta que la red esté inactiva antes de poder enviarse. Si se envían constantemente otros datos, también puede bloquear el envío de datos.

  • Se basa en un protocolo maestro-esclavo, donde un maestro se dirige a un esclavo, luego envía un comando / solicitud, y el esclavo responde después. Solo un dispositivo puede comunicarse a la vez, por lo que el esclavo debe esperar a que el maestro termine.

  • Cualquier dispositivo puede actuar como maestro y / o esclavo, lo que lo hace bastante flexible.

SPI

  • Esto es lo que recomendaría / usaría para la comunicación general entre microcontroladores.

  • Es de alta velocidad, hasta CLK / 2 = 8MHz (para CLK a 16MHz), por lo que es el método más rápido. Esto se puede lograr debido a su cable separado únicamente para el reloj.

  • Los cables de reloj MOSI, MISO y SCK se comparten en toda la red, lo que significa que tiene un cableado más simple.

  • Es un formato maestro-esclavo, pero cualquier dispositivo puede ser maestro y / o esclavo. Sin embargo, debido a las complicaciones de la selección de esclavos, para el cableado compartido (dentro de la red), solo debe usarlo de manera jerárquica (a diferencia de la interfaz de dos cables). ES DECIR. Si organiza todos los dispositivos en un árbol, un dispositivo solo debe ser maestro para sus hijos y solo un esclavo para sus padres. Eso significa que en modo esclavo, un dispositivo siempre tendrá el mismo maestro. Además, para hacer esto correctamente, debe agregar resistencias a MISO / MOSI / SCK al maestro en sentido ascendente, de modo que si el dispositivo se comunica en sentido descendente (cuando no se selecciona como esclavo), las comunicaciones no afectarán las comunicaciones en otras partes de la red (tenga en cuenta que el número de niveles que puede hacer esto usando resistencias es limitado, vea a continuación para una mejor solución usando ambos puertos SPI).

    El microcontrolador AVR puede configurar automáticamente la señal MOSI cuando se selecciona como esclavo y cambiar al modo esclavo (si está en maestro).

    Aunque puede requerir una red jerárquica, la mayoría de las redes se pueden organizar de forma similar a un árbol, por lo que generalmente no es una limitación importante

  • Lo anterior se puede relajar un poco, porque cada microcontrolador AVR admite dos puertos SPI separados, por lo que cada dispositivo puede tener diferentes posiciones en dos redes diferentes.

    Dicho esto, si necesita muchos niveles en su árbol / jerarquía (más de 2), la solución anterior que usa resistencias es demasiado complicada para funcionar. En este caso, debe cambiar la red SPI entre cada capa del árbol. Esto significa que cada dispositivo se conectará a sus hijos en una red SPI y a su padre en la otra red SPI. Aunque significa que solo tiene un solo árbol de conexiones, la ventaja es que un dispositivo puede comunicarse con uno de sus hijos y sus padres al mismo tiempo y no tiene resistencias difíciles (siempre es difícil elegir los valores correctos) .

  • Debido a que tiene cables MOSI y MISO separados, tanto el maestro como el esclavo pueden comunicarse al mismo tiempo, lo que le da un factor potencial de dos aumentos en la velocidad. Se requiere un pin adicional para la selección de esclavos para cada esclavo adicional, pero esto no es una gran carga, incluso 10 esclavos diferentes requieren solo 10 pines adicionales, que pueden acomodarse fácilmente en un microcontrolador AVR típico.

CAN no es compatible con el microcontrolador AVR que ha especificado. Como hay otras buenas opciones, probablemente no sea importante en este caso de todos modos.


La recomendación es SPI , porque es rápido, el cableado no es demasiado complejo y no requiere resistencias pull-up complicadas. En el raro caso en que SPI no satisface completamente sus necesidades (probablemente en redes más complicadas), puede usar múltiples opciones (por ejemplo, usar ambos puertos SPI, junto con la interfaz de dos cables, así como emparejar algunos de los microcontroladores usando un bucle USART!)

En su caso, el uso de SPI significa que, naturalmente, el microcontrolador con conexión USB a la computadora puede ser el maestro, y solo puede reenviar los comandos relevantes de la computadora a cada dispositivo esclavo. También puede leer las actualizaciones / medidas de cada esclavo y enviarlas a la computadora.

A 8MHz, y 0.5m de longitud de cable, no creo que se convierta en un problema. Pero si es así, trate de tener más cuidado con la capacitancia (mantenga los cables de tierra y señal demasiado cerca, y también tenga cuidado con las conexiones entre diferentes conductores), y también la terminación de la señal. En el improbable caso de que siga siendo un problema, puede reducir la velocidad del reloj, pero no creo que sea necesario.


Pulgares arriba para SPI de mi parte
georgebrindeiro

2
También soy fanático de SPI, aunque quizás también valga la pena considerar I2C (evita la necesidad de líneas CS separadas para cada dispositivo). Pero CAN no debe descartarse tan fácilmente, después de todo, es el autobús automotriz de elección, ¡así que no lo descartaría por la robótica de hobby!
Andrew

¿El bus SPI realmente requiere líneas CS separadas del maestro a cada esclavo? Si es así, ¿cómo llamaría a ese otro bus que requiere exactamente 4 conexiones al maestro, sin importar cuántos esclavos estén conectados, eso se menciona en el artículo de Wikipedia sobre el bus SPI ?
David Cary

1
+1 Por la gran respuesta, soy de la vieja escuela y me encantan los 485 y, en general, los autobuses con dirección de software, pero en este caso, los componentes de velocidad y consumo de recursos, elegiría el SPI. Aunque prestaría mucha atención a la distancia y al ruido eléctrico, especialmente si su bus coesiste otro IC, con diferente velocidad de transmisión: memorias, NIC, etc., que podrían sufrir caídas de voltaje y amplitud de pérdida de reloj
RTOSkit

3
Sus comentarios sobre CAN no son precisos. CAN no es cualquier bus de 2 hilos. Creo que lo estás confundiendo con I2C, que tiene una velocidad máxima de 400 kbps. La velocidad máxima de CAN es 1Mbps.
Rocketmagnet

5

Puedo recomendar CAN para las comunicaciones entre procesadores. Lo usamos en nuestros robots, con hasta 22 procesadores en el mismo bus. Con un buen diseño de protocolo, puede usar aproximadamente el 90% del ancho de banda disponible (aproximadamente 640 kbps si tiene en cuenta todas las comprobaciones de errores y el espacio entre cuadros). Podemos servo 10 motores a 1000Hz en un bus CAN. Esto se acerca al límite. Probablemente podría exprimirlo a 20 motores si empaqueta los datos con mucho cuidado.

Generalmente, CAN necesita tener un chip transceptor para cada procesador (es solo un pequeño dispositivo de 8 pines). El transceptor le brinda la agradable señal diferencial que emite muy poca interferencia, y también lo hace inmune a la interferencia si está trabajando en un entorno eléctricamente ruidoso (motores, solenoides y transmisores de radio).

Conexiones de bus CAN

Sin embargo, en circunstancias limitadas, en realidad es posible usar CAN sin transceptores .


EtherCAT

Si alguna vez tiene ganas de implementar un bus con ancho de banda serio, le sugiero que pruebe EtherCAT . Es un bus de 100Mb, que se puede conectar al puerto Ethernet de su PC. Hay dos partes importantes para el autobús:

  • El puente. Esto convierte la capa física de Ethernet en una capa física de LVDS más simple y de menor costo, que no requiere los conectores grandes, el chip Phy y muchos componentes que Ethernet sí necesita.
  • Los nodos Cada nodo solo necesita un chip ET1200 y un microcontrolador.

La PC puede transmitir y recibir grandes cantidades de datos hacia y desde los nodos a 1kHz o más rápido. Puede controlar muchas cosas en un solo bus EtherCAT.

Adicional:

Shadow Robot Company ahora vende un útil sistema EtherCAT Bus llamado Ronex . Le permite agregar una gran cantidad de E / S, y pronto introducirán muchos otros tipos de placa, como controladores de motor y ADC de alta calidad.


¿Cuál es la fuente de esa imagen? Tiene CAN Highpara cables rojos y azules.
Ian

1

Sé que estoy desenterrando un hilo viejo y esto está fuera de tema, pero no creo que puedas obtener los chips ET1200 de Beckhoff. Les envié un correo electrónico hace un tiempo y me aconsejaron que debía unirme al grupo Ethercat. Para hacer esto, tuve que demostrar que iba a contribuir de nuevo al grupo, es decir, mediante la construcción y venta de dispositivos que usaran el material Ethercat. En ese momento (y en este momento), todavía estoy creando prototipos de mi dispositivo (un controlador de motor sin escobillas para aplicaciones de robot, actualmente usando CAN), por lo que no pude ofrecer nada (no puedo dar un tiempo sólido para completarlo, todavía estoy trabajando en mi pregrado). Les expresé mi decepción. ¡Dijeron que no se decepcionen! ¡Cosas muy divertidas! Yo realmenteles gusta entrar en Ethercat, pero los ASIC parecen ser intocables para los aficionados o aquellos sin una compañía. Además, esta es mi primera publicación, así que disculpen si he enojado a los dioses desenterrando una publicación anterior.


Bienvenido. Resucitar una publicación anterior está bien, si la respuesta es relevante. Y tu comentario me parece relevante ...
Andrew

Gracias amigo. Este es un gran foro! Por interés, ¿tiene alguna experiencia con Ethercat? ¿Conoces algún otro método para obtener un dispositivo esclavo adecuado para la creación de prototipos en PCB? Estoy dispuesto a pagar, pero por el momento simplemente no cumplo con los requisitos para unirme al grupo para comprar los ASIC de Bechoff. ¡Frustrante!
Ley

No EtherCat, no. Uso CAN (una buena opción), LIN (no tan bueno en mi humilde opinión) y ciertamente puedo recomendar SPI o I2C
Andrew

¿Se las arregló para obtener el chip ET1100 o ET1200? Si no existía, ahora hay otra opción disponible: microchip LAN9252, es compatible con el ET1100 y funciona bastante bien. Use los saludos de la biblioteca SOES
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.