En general, diría que es perfectamente factible, una excelente elección de prototipos, pero una opción bastante mediocre para un producto a largo plazo. Existen innumerables beneficios para la creación de prototipos con hardware de bajo costo como el RPi. El RPi es razonablemente liviano (ciertamente lo suficientemente liviano para un quad que probablemente tenga una cámara que es mucho más pesada) y razonablemente compacto. Probablemente no podrá encontrar una mejor plataforma barata, razonablemente bien soportada y disponible con características similares. Sin embargo, está lejos de ser ideal por algunas razones.
El problema principal que encontrará es que el RPi es una sola computadora en el fondo. Esto significa que si lo va a usar para controlar sus motores, será un tiempo compartido entre todos los otros programas de software que su tablero de control de vuelo debe ejecutar, como algoritmos de navegación, comunicaciones y cualquier cálculo de misión específico para sensores.
Para que eso funcione, sería obligatorio usar un kernel en tiempo real, que existe para RPi. La mayoría de los paneles de control de vuelo dividen el trabajo en al menos dos procesadores físicos. Uno que lee los valores del sensor, integra el resultado, el error de la computadora y luego calcula los comandos … y solo esas tareas. Ese procesador, típicamente denominado “controlador” porque implementa un bucle de control, tiene un requisito de rendimiento muy alto. Cuanto más rápido se pueda ejecutar, más estable será su plataforma debido a [las matemáticas van aquí]. La razón por la que es necesario un kernel en tiempo real es que si el kernel decidiera asignar tiempo a otros procesos en lugar de los controladores, fallaría al azar al recalcular los valores de comando para algún conjunto de motores. Eso sería como apagar aleatoriamente sus controladores durante un período de tiempo arbitrario. Piense en ello como cuando Windows / MacOS hace una pausa al azar y hace algo que no comprende, a veces con un ícono giratorio del mouse. Realmente no quieres eso cuando el procesador es responsable de mantener el avión en el aire. Si bien es posible escribir su software y configurar su kernel de una manera que no tenga este problema, sería muy difícil hacerlo correctamente. Para evitar este desafío, los controladores generalmente se dividen en otro procesador dedicado que acepta los objetivos de un procesador principal. Esto significa que el procesador del controlador dedicado solo necesita hacer cuatro cosas: aceptar comandos del procesador principal (probablemente a través de un enlace serie), leer desde sensores, multiplicar y agregar, y escribir comandos.
- ¿Podría usar 4 unidades flash en una matriz RAID en mi Raspberry Pi 2?
- ¿Puedo instalar cualquier sistema operativo en un Rapsberry Pi? ¿Cómo?
- ¿Podemos usar Raspberry Pi para fines industriales sin infringir ninguna ley de la empresa?
- ¿Qué versión de Raspberry PI debo comprar para aprender sobre IoT?
- ¿Es mejor trabajar en LEGO Mindstorm o Arduino como novato?
Dividir el trabajo dejaría un procesador principal, que se ocupa de la navegación y comandos de muy alto nivel para determinar los objetivos a los que los controladores deberían apuntar. Aquí es donde una Raspberry Pi sería una opción perfectamente adecuada. Dado que no importa si la lógica de control de nivel superior toma el orden de un segundo para volver a calcular, es mucho menos crucial que sea una pieza de hardware de alto rendimiento. Dado que aquí es donde desea poder iterar y probar rápidamente, usar un entorno amigable para el desarrollador con una salida de monitor, como un RPi, es una gran opción.
Una vez que finaliza la etapa de creación de prototipos, el valor del RPI desaparece en gran medida. En ese punto, desearía transferir su código a una placa mucho más compacta por espacio, peso y velocidad de arranque. Sugeriría mirar algo como un Teensy. Si bien los Arduinos son populares, descubrirá rápidamente que necesita más memoria para sus programas que los 32k que normalmente se proporcionan en las placas Arduino más pequeñas. Cuando importe algunas bibliotecas de sensores, llegará a 32k, y es una pérdida de tiempo jugar trucos estúpidos del compilador para que se ajuste al límite de 32k.
Si quisieras lograr un equilibrio, siempre podrías hacer tu propio tablero muy compacto con dos tableros Teensy. Uno se dedicaría a los lazos de control, y uno se ocuparía de todo lo demás. Esto preservaría el beneficio de hardware básico del RPi, al tiempo que le daría una configuración más confiable. Perdería la capacidad de hacer cosas arbitrarias en un entorno Linux y monitorear los resultados de las placas. Puede que le importe o no.
