Bastante complicada red de sensores

Question

Yo estaba trabajando en un proyecto recientemente y fue el primero que estuvo involucrado lo suficiente como para hacer que el sensor de redes complicado. En fin, creo que la comunicación era el cuello de botella en términos de rendimiento general y me pregunto cómo las personas más experimentadas habría resuelto este problema. Esta es una lectura larga, pero creo que es bastante interesante, así que por favor, palo con ella. El problema fue el diseño de un autónomas dirigible, capaz de navegar un curso de obstáculos y soltar pelotas de ping pong en marrón cuadro de objetivos. Aquí va:

Los sensores

• 4D Sistemas de la uCAM-TTL de la cámara de módulo UART interface
• HMC6352 Brújula Digital - de la interfaz I2C
• Maxbotix Sonar ez4 - 1 pin interfaz analógica

Actuadores

• 2x L293D motor controladores (conectado a simple hobby motores) - Estos fueron utilizados para la unidad 6 motores de forma bidireccional. Se requiere PWM entradas para variar la velocidad. Ahora 3 de nuestros motores siempre estaban haciendo la misma cosa (los que controlaban el movimiento arriba/abajo) para que sólo se requiere de 2 salidas PWM de nuestros controladores para el control de todos los 3 motores. Los otros 3 motores que controlan el movimiento lateral de todos los necesarios de control individual (omni-direccional de movimiento) por lo que fue otro de 6 salidas PWM requiere de nuestros controladores.
• Motor Servo - PWM interfaz

Los controladores

Por razones que serán evidentes después, terminamos utilizando 2x ATmega328Ps. Hemos usado un Arduino Uno para el programa de ellos (que no tienen acceso a un ISP), pero nos fab había un encargo del PWB, así que no tiene el uso de placas arduino, ya que acaba de añadir peso innecesario a nuestro dirigible. En cuanto a por qué se eligió el ATmega328P, yo estaba muy familiarizado con el entorno de arduino y creo que eso hizo que el desarrollo de código mucho más rápido y más fácil.

Comunicación Y Procesamiento De La

• 2x Xbee Básicos
• 2x ATmega328P
• Equipo de escritorio que ejecutan C++ w/ openCV

Así como usted puede decir a partir del módulo de la cámara, la mayor parte de nuestro proyecto se basó en la visión por ordenador. Los patrioteros sólo podía llevar tanto peso y no nos sentimos cómodos aplicación de visión por computador de un microcontrolador. Así que lo que terminé haciendo fue mediante XBee para retransmitir los datos de imagen a una computadora de escritorio. Así que en el lado del servidor que hemos recibido los datos de la imagen y utilizar openCV para procesar la imagen y figura de las cosas de ella. Ahora el lado del servidor también se necesita saber la altura de información (de la sonda) y la información de la brújula.

La primera arruga fue que no eran capaces de tener la cámara controlada por un microcontrolador para un par de razones. El principal problema era la memoria interna en la que no podía lidiar con el almacenamiento de toda la estructura. Puede haber maneras de evitar esto a través de una astuta de codificación, pero para el propósito de esta pregunta, vamos a suponer que era imposible. Así que para resolver este problema, hemos tenido el lado del servidor enviar los comandos de la cámara a través de la XBee transceptor y el XBee receptor (a bordo del dirigible) tuvo su salida de cable a la cámara de entrada.

El próximo arruga fue que no hay suficientes PWM en una sola ATmega328P para el control de todos los motores DEBIDO a que la interfaz I2C utiliza uno de los pines PWM (maldito ellos...). Es por eso que hemos decidido utilizar un 2do. El código que realmente se prestaba perfectamente para el procesamiento en paralelo de todos modos debido a que el control de altura de la era completamente independiente del movimiento lateral de control (para 2 micros fue probablemente mejor que uno conectado a un controlador PWM). Por lo tanto, U1 fue el responsable de 2 salidas PWM (arriba/abajo) y la lectura de la sonda. U2 fue el responsable de la lectura de la brújula, el control de 6 salidas PWM (los motores laterales), y también la lectura de la Sonda. U2 también era responsable de recibir comandos desde el servidor a través del XBee.

Que llevó a nuestro primer problema de comunicación. El XBee DOUT línea estaba conectado al microcontrolador y la cámara. Ahora, por supuesto, hemos diseñado un protocolo para que el micro de comandos sería omitir los comandos de la cámara y los comandos de la cámara sería ignorar micro comandos, de modo que estaba bien. Sin embargo, la cámara, cuando se ignoran el micro de comandos, enviaría NAK datos en su línea de salida. Ya que la orden era para la micro necesitábamos alguna manera, para desactivar la salida de la cámara para el XBee. Para solucionar esto, tomamos el micro de control 2 Fet que estaban entre la cámara y el XBee (que es la primera FET) y también entre U2 y el XBee (que es la segunda FET). Por lo tanto, cuando la cámara estaba tratando de enviar información al servidor la primera FET fue 'on' y el segundo FET fue 'off'. Por desgracia, no parecía ser algún tipo de cruz hablar con este método y, a veces, cuando el servidor estaba tratando de recibir los datos de altura de, por ejemplo, se podría leer un NAK del XBee.

Para darles una idea de cómo funcionaba aquí un par de ejemplos:

1. Las solicitudes del servidor de una imagen - PIC_REQUEST pasa a través de XBee y llega a U2 y a la cámara. U2 la ignora y la cámara envía los datos de la imagen.
2. Servidor acaba de terminar el procesamiento de una imagen y es el envío de datos del motor de decirle dirigible a girar a la derecha - MOTOR_ANGLE(70) gies a través de XBee y llega a U2 y a la cámara. U2 reconoce como un micro comando y por lo tanto se apague la Cámara FET (pero tal vez la cámara ya respondió con un NAK?? quién sabe...). U2, a continuación, responde al mandato por el cambio de motor de salidas PWM. Se recurre entonces de la Cámara de la FET (esta fue la configuración por defecto ya que los datos de la imagen era lo más importante).
3. El servidor se da cuenta de que hemos llegado a un punto en la carrera de obstáculos donde nuestro defecto hover altura ahora debe ser de 90 pulgadas en lugar de 50 pulgadas. SET_HEIGHT pasa a través de XBee y ocurre lo mismo que en el ejemplo 2. U2 reconoce la SET_HEIGHT comando y activa una interrupción en U1. U1 ahora sale de su altura lazo de control y espera a recibir datos en serie a partir de U2. Eso es correcto, más datos en serie. En este punto, el de U2, el FET es (y de la cámara de la FET está apagado), por lo que el servidor recibe la altura que U2 es también el envío a U1. Que era para fines de verificación. Ahora U1 restablece la variable interna para height2HoverAt. U2 ahora apaga es la FET y la cámara se vuelve FET de nuevo.

Definitivamente me dejó una buena cantidad de información, pero creo que es suficiente para entender algunas de las complicaciones. Al final, nuestros problemas eran sólo la sincronización de todo. A veces hay que ser datos en los buffers, pero only3 bytes (todos nuestros comandos de 6 secuencias de bytes). A veces queremos perder la conexión con nuestra cámara y tener que volver a sincronizar.

Así que mi pregunta es: ¿Qué técnicas ustedes sugieren que han hecho que la comunicación entre todos los componentes más fiables/robusto/simple/mejor?

Por ejemplo, sé de uno que hubiera sido para agregar un circuito de retardo entre la placa XBee y la cámara de modo que el micro que tenía una oportunidad para apagar la cámara a hablar de la línea antes de que se responda a las micro comandos con NAKs. Otras ideas como que?

Gracias y estoy seguro de que esto va a requerir muchas modificaciones, así que estad atentos.

---

Edit1: Empalme de la cámara de la UART de datos a través de uno de los micros no parece que sea posible para nosotros. Hay dos opciones para los datos de la cámara, primas de mapa de bits o JPEG. Para una materia de mapa de bits, la cámara sólo envía datos a usted tan rápido como puede. El ATmega328P solo tiene 128 bytes para un buffer de serie (técnicamente esto es configurable, pero no estoy seguro de cómo) y no pensamos que nos gustaría ser capaces de salir de la búfer y a través de los XBee lo suficientemente rápido. Que la izquierda JPEG método en el que se envía cada paquete y espera a que el controlador de ACK (poco apretón de manos protocl). El más rápido que esto podría ir a 115200 baudios. Ahora, por alguna razón, el más rápido de nosotros era capaz de transmitir grandes cantidades de datos a través de XBee fue 57600 baudios (esto es, incluso después de que hicimos el nodo/red de vinculación para permitir la auto-reenvío de capacidad). La adición de la parada adicional en nuestra red (cámara micro para XBee como lo opuesto a la cámara para XBee) para la micro, simplemente, ralentizado el tiempo que se tomó para transferir una imagen demasiado. Necesitábamos una cierta frecuencia de actualización de imágenes en orden para que nuestro motor de algoritmo de control para el trabajo.

Answer 1

Entiendo que usted quería elegir un entorno de desarrollo que estaban familiarizados con tal que usted puede golpear el suelo corriendo, pero creo que el hardware/software de comercio puede tener en caja en al seguir con el Arduino y no escoger una parte que tenía todos los componentes periféricos de hardware que usted necesita y escribir todo en interrumpir impulsado por C en su lugar.

Estoy de acuerdo con @Matt Jenkins sugerencia y le gustaría ampliar.

Yo he elegido una uC con 2 UARTs. Uno conectado el Xbee y uno conectado a la cámara. La uC acepta un comando desde el servidor para iniciar una cámara de lectura y una rutina puede ser escrito para la transferencia de datos desde la cámara de la UART del canal para el XBee UART canal en un byte por byte, por lo que no tampón (o en la mayoría de sólo una muy pequeña) es necesario. Yo he tratado de eliminar al otro de la uC todos juntos tomando una parte que también incluya todos sus PWM necesidades (PWM de 8 canales?) y si quería seguir con 2 diferentes uC está tomando el cuidado de su respectivo eje, a continuación, tal vez una diferente interfaz de comunicaciones que hubiera sido mejor como todos sus otros UARTs sería tomado.

Alguien más también sugirió trasladar a un linux embebido plataforma para ejecutar todo (incluyendo openCV) y creo que hubiera sido algo para explorar así. Yo he estado allí antes, aunque, de 4 meses de proyecto de la escuela y usted sólo tiene que conseguir que se haga lo antes posible, no puede ser detenido por la parálisis por el análisis - espero que todo salió bien para usted, sin embargo!

---

EDICIÓN #1 En respuesta a los comentarios de @JGord:

Hice un proyecto en el que se implementaron UART de reenvío con un ATmega164p. Dispone de 2 UARTs. Aquí hay una imagen de un analizador lógico de captura (Saleae USB del analizador lógico) de que el proyecto mostrando la UART de reenvío:

La línea superior es la fuente de datos (en este caso sería el de la cámara) y la línea inferior es la UART canal remitido a (XBee en su caso). La rutina escrito para ello manejado la UART de la interrupción de la recepción. Ahora, ¿usted cree que mientras este UART de reenvío que está pasando usted podría fácilmente configurar sus canales PWM y manejar su I2C rutinas así? Me explico cómo.

Cada UART periférica (para mi AVR de todos modos) se compone de un par de registros de desplazamiento, un registro de datos, y un control/registro de estado. Este hardware se hacen las cosas en su propia (suponiendo que ya se haya inicializado la velocidad en baudios y tal) sin que ninguno de su intervención, si bien:

1. Un byte viene en o
2. Un byte está colocado en el registro de datos y marcado para la salida

De importancia aquí es el registro de desplazamiento y el registro de datos. Supongamos que un byte es que viene en UART0 y queremos avanzar que el tráfico a la salida de la UART1. Cuando un nuevo byte se ha desplazado hacia la entrada del registro de desplazamiento de UART0, se transfiere a la UART0 registro de datos y un UART0 la interrupción de la recepción es disparado. Si usted ha escrito un ISR para ello, usted puede tomar el byte en la UART0 registro de datos y mover a la UART1 registro de datos y, a continuación, establezca el registro de control para la UART1 para iniciar la transferencia. Lo que hace es que le dice a la UART1 periférica a tomar lo que acaba de poner en su registro de datos, puesto que en su salida del registro de desplazamiento, y empezar a mover. Desde aquí, usted puede volver de su ISR y volver a cualquier tarea que su uC estaba haciendo antes de que fuera interrumpido. Ahora UART0, después de que acaba de tener su registro de desplazamiento se borra, y tener su registro de datos desactivada puede empezar a mover en los nuevos datos si aún no lo ha hecho ya durante el ISR, y UART1 está cambiando el byte que acaba de poner en él - todo lo que sucede en su propio sin su intervención, mientras que su uC está haciendo otra tarea. Todo el ISR toma microsegundos a ejecutar ya que sólo estamos moviendo alrededor de 1 byte de memoria, y esto deja un montón de tiempo para salir y hacer otras cosas hasta que el siguiente byte en la UART0 viene (que es de 100 microsegundos).

Esta es la belleza de tener un hardware periféricos - que acaba de escribir en la memoria asignada registros y él se encargará del resto a partir de ahí y de la señal para su atención a través de las interrupciones como la que acabo de explicar arriba. Este proceso va a suceder cada vez que un nuevo byte viene en UART0.

Observe cómo hay sólo un retraso de 1 byte en la lógica de captura como que sólo "buffering" 1 byte si quieres pensar de esa manera. No estoy seguro de cómo he llegado con su O(2N) estimación - voy a suponer que usted ha alojado el Arduino serie de funciones de la biblioteca en un bloqueo de bucle de espera de los datos. Si se toman en cuenta la sobrecarga de tener que procesar una "lectura de la cámara de comandos" en la uC, la interrupción impulsado método es más como O(N+c) donde c abarca el único byte demora y la "lectura de la cámara" de la instrucción. Esto sería muy pequeña teniendo en cuenta que usted está enviando una gran cantidad de datos (datos de la imagen a la derecha?).

Todos los de este detalle acerca de la UART periférica (y todos los periféricos en la uC) se explica a fondo en la hoja de datos y se puede acceder a todas ellas en C. no sé si el entorno de desarrollo de Arduino te da la baja de acceso de tal manera que usted puede empezar a acceder a los registros - y esa es la cosa - si no estás limitado por su implementación. Usted está en control de todo, si has escrito en C (más aún si se hace en asamblea) y usted puede realmente empujar el microcontrolador a su verdadero potencial.

Answer 2

¿Por qué no canalizar los datos de la cámara a través de la µC? No me refiero a que el búfer de las fotos, pero la retransmisión de la UART de datos a través de la µC para que pueda decidir lo que debe ser enviado de vuelta y qué no?

Es más fácil si tienes un µC con dos UARTs, pero podría ser emulado por software.

Answer 3

Otra opción que me ha ocurrido, pero esto podría ser algo voluminoso y pesado para su proyecto :-

• ¿Por qué no usar un USB inalámbrico servidor, vinculado a un pequeño hub USB con USB->RS232 adaptadores para varios canales de control para las diferentes partes del sistema?

Sí, voluminosos, pero si usted tira de ellos hacia abajo, y tal vez de usar USB en lugar de RS232 donde sea posible, usted podría salirse con la suya...