Comunicación inalámbrica con robot

Estoy haciendo un robot simple y estoy usando un transmisor y receptor de RF relativamente barato para enviar comandos a mi robot. Esencialmente, el extremo del transmisor enviaría datos desde una MCU AVR a través de su UART al transmisor de RF, y una configuración similar en el robot recogería los datos.

Entonces, lo que me confunde es cómo funciona todo este proceso. Quiero decir, supongamos que tengo cuatro motores en mi robot que necesitan ser controlados individualmente y al mismo tiempo. ¿Cómo lograría esto? ¿Codificaría mi información en un byte (digamos, 1111000) donde los primeros cuatro bits representan la posición de encendido o apagado de los cuatro motores, y el receptor lo decodificaría y llevaría a cabo la tarea necesaria? ¿O hay otra manera mejor de hacer esto?

Esto lleva a mi siguiente pregunta relacionada con esto. Supongamos que se usa el método que acabo de describir, entonces, ¿cómo se programa típicamente el robot para manejar los comandos? Digamos que recibe el paquete 11110000 y enciende los cuatro motores. ¿Dejo que el robot mantenga los motores encendidos hasta que se reciba un nuevo paquete de información? Esencialmente, si quiero una comunicación continua con mi robot (una forma está bien en este caso), ¿cómo lo haría si toma una cierta cantidad de tiempo entre cada señal que se envía para ser procesada y ejecutada antes de que llegue la siguiente? ¿en? ¿Tal vez el tiempo que lleva enviar, procesar y ejecutar la señal es tan pequeño que el impacto es imperceptible?

EDITAR: Aquí hay un enlace al RF Tx/Rx que compré.

¿Alguna hoja de datos / enlace al transmisor y receptor que está utilizando? Algunos de los tipos que no incluyen ningún manejo de paquetes pueden ser un poco más complicados de lo que parece para usarlos de manera confiable.

Respuestas (2)

Un desafío al usar esos tipos de módulos de RF es que los receptores pueden recibir mucho ruido aleatorio entre transmisiones. También les gusta que la señal transmitida sea DC balanceada, largas cadenas de ceros y unos pueden causar distorsión en la salida del cortador de datos en el receptor.

La forma habitual de lidiar con el ruido aleatorio entre transmisiones es introducir un preámbulo para que el receptor sepa que un paquete válido está en camino y sincronizar el UART listo. Mantener el equilibrio de CC requiere el uso de un esquema de codificación que mantenga el número de bits 1 y 0 en cada byte lo más cerca posible de la igualdad.

He usado la siguiente nota de aplicación de Radiotronix que incluye un ejemplo de código fuente en el pasado para implementar un sistema que funcionó bien usando módulos similares a los que está usando. El único cambio que tuve que hacer fue introducir un retraso antes de transmitir y aumentar la longitud del preámbulo, aunque eso fue principalmente necesario porque estaba apagando el transmisor entre transmisiones, por lo que es posible que no necesites lo mismo.

Nota de aplicación de Radiotronix AN-401

Una vez que haya ordenado los aspectos básicos, deberá considerar qué hacer cuando se pierde una transmisión, le recomiendo enviar los datos varias veces y luego tener un tiempo de espera que detendrá el robot después de un tiempo predeterminado. También puede considerar usar algunos comandos relativamente largos (digamos 4 bytes) que son esencialmente aleatorios (es decir, no use 1,2,3) para que pueda determinar la diferencia entre un comando válido y un error de datos.

Probablemente comenzaría con una tasa de baudios de 2400 bps para esos módulos. Usando el esquema anterior que dará un tiempo de transmisión de alrededor de 40 mS, por lo que si tuviera que transmitir cada comando dos veces, una latencia por debajo de 100 mS debería ser realista.

Si sus comandos son pocos, puede usar un empaque binario simple como su propuesta. Sin embargo, una vez que sus comandos excedan un byte de tamaño, si hay alguna posibilidad de falta de confiabilidad en el canal, se enfrenta al problema de enmarcar, es decir, determinar qué byte cae en qué lugar de un comando de varios bytes. Hay soluciones estándar para eso, todas ellas un poco poco elegantes (códigos ilegales, relleno de bits, etc.), aunque la mayoría son de uso común.

Dado eso, otra posibilidad que vale la pena considerar (si tiene el ancho de banda) son los comandos de texto ASCII legibles por humanos, con un terminador como una nueva línea. Por supuesto, esto es un desperdicio de bits, pero tiene dos ventajas: primero, puede abrir una terminal y escribir comandos al robot mientras prueba o experimenta (también puede hacer que proporcione respuestas de estado legibles). En segundo lugar, el carácter de nueva línea final delimita los mensajes de forma fácil y limpia.

En cuanto a su pregunta sobre cómo hacer que responda, puede hacer que continúe haciendo lo último que se le preguntó, pero otra posibilidad que vale la pena considerar sería que se detenga automáticamente después de unos segundos sin comunicación a través del canal, o después de algunos indicación de pérdida de señal del propio módem de radio.