0

RPAS y sistemas de suma cero

Se denomina “juego de suma cero” como aquel en el que la ganancia o pérdida que experimenta un participante se equilibra con las ganancias o pérdidas del resto de participantes. Si se suman todas las ganancias y se les restan todas las pérdidas, el resultado es siempre cero. Ejemplos típicos son: ajedrez, póker, bingo, loterías, baloncesto, fútbol y, en general, todos los enfrentamientos donde un jugador se lleva lo que pierden los otros jugadores o donde se requiera que una parte pierda para que la otra gane.

Cuando se diseña un RPAS, debe estar totalmente focalizado hacia un tipo de misión concreto con el fin de garantizar la viabilidad de las misiones que desempeñe.

Igualmente podemos considerar sistemas de suma cero a aquellos entornos en los que se dan los mismos principios de los juegos de suma cero, es decir, aquellos entornos que exigen que todas las ganancias que se introducen en una parte del sistema se vean automáticamente traducidas en pérdidas en otra parte del sistema.

Por definición, los UAV/RPAS/drones son perfectos ejemplos de sistemas de suma cero. Es decir, toda mejora que se intente introducir en un sistema aeronáutico cerrado significa que generará una contrapartida negativa o no deseada en alguna otra parte del sistema.

El motivo por el que un RPAS es automáticamente un sistema de suma cero es debido a que está inmerso de manera crítica en el influjo de la permanente atracción terrestre. Esto es crítico porque para poder operar inmerso en la gravedad debe vencerla, o como mínimo neutralizarla, de manera constante. En el momento en que deje de hacerlo, el sistema se colapsa y es arrastrado inevitablemente por la gravedad, hasta que su estructura y la superficie del planeta coincidan en el mismo punto de manera más o menos violenta.

Para ilustrarlo veamos algunos ejemplos:

Para mejorar un RPA haciendo que tenga más capacidad de carga, lo normal es aumentar su superficie alar o aumentar la potencia de sus motores. Ambos cambios acarrean como contrapartida consecuencias adversas. Aumentar la superficie alar conlleva varios efectos secundarios negativos como el aumento de peso (debido al aumento de estructura) y el aumento de la resistencia al avance de la aeronave (debido al aumento de superficie). Por su lado, el aumento de potencia de los motores significa un aumento de consumo y, por lo tanto, hay que añadir más peso en combustible o baterías al despegue o, en su lugar, aceptar una reducción en tiempo de vuelo.

Si se pretende mejorar un RPA haciendo que sea más rápido, hay que aumentar la potencia de sus motores (con los mismos efectos negativos vistos más arriba). En el caso de ala fija también se puede reducir el espesor del perfil alar para disminuir la resistencia, pero con ello se eleva su velocidad de pérdida, y por tanto también la velocidad de aterrizaje y despegue. Todo ello hace que esa maniobra sea más complicada y que su envolvente de vuelo sea más crítico, etc.

Esta situación de suma cero en RPAS en la que todo lo que se mejora por un lado obliga a empeorarlo por otro, tiene una consecuencia directa: Cuando se diseña un RPAS debe estar totalmente focalizado hacia un tipo de misión concreta. Si no se hace así acabaremos teniendo un sistema con tantos efectos negativos que su viabilidad para llevar a cabo la misión estará gravemente comprometida. Cuanto más concreto y cerrado sea el diseño, mejor será llevada a cabo la misión.

Al final, podemos concluir que todos los RPAS deben estar diseñados con una tarea específica en mente (asumiendo las limitaciones que impongan los recursos y tecnologías disponibles en ese momento).

En general, no existe un RPAS que sea bueno para hacer diferentes tareas. O es muy bueno para hacer una tarea específica (porque fue específicamente diseñada para esa tarea) o es mediocre para desempeñar varias tareas.

En los casos en que se habla de un RPA “multipropósito” o en los que se menciona que un RPA es “versátil”, realmente se está haciendo uso de un recurso comercial o de comunicación. Un sistema “versátil” no es más que un compromiso entre la parte técnica y la parte económica de un RPAS, que supone el ahorro en el diseño de un solo sistema para un desempeño mediocre en varias aplicaciones para las que no está focalizado su diseño. Sin embargo, esta “versatilidad” es aceptable en aquellos casos en los que la contrapartida de ahorro económico en su adquisición compense un desempeño mediocre en varios tipos diferentes de misiones. Esta aceptación se da especialmente cuanto mayor sea el coste global del sistema. Dicho de otra manera, cuanto más caro sea el sistema, más compensa que tenga un diseño no específicamente adaptado a la misión, a cambio de la posibilidad de ser empleado en una mayor variedad de misiones. Este aspecto se demuestra concretamente en diseños, no solo de RPAS, sino también de aeronaves tripuladas comerciales y militares de alto coste en las cuales se intenta desesperadamente que todos los programas tengan un gran abanico de usuarios, aunque ello haga que realicen de manera mediocre algunas de las misiones para las que se destinan. Obviamente, y por extrapolación, también aplica que cuanto menor sea el coste relativo del RPAS, más importancia adquiere que este se haya diseñado específicamente para una misión concreta. Por ejemplo, un pequeño RPAS diseñado para agricultura tendrá un desempeño previsiblemente mediocre en otros trabajos como el de vigilancia y, además, por su coste, vale la pena tener una aeronave dedicada en exclusiva a cada tipo de misión.

Como el coste de un RPAS, por regla general, suele mantener una relación bastante directa con el tamaño o peso de su RPA también podemos finalizar concluyendo que cuanto más pequeño sea un RPA, más específico y focalizado debe ser su diseño, porque el coste económico de diseñarlo para un tipo de misión específico es menos importante que su rendimiento en esa misión.

 

Notas:
RPA: Remotely Piloted Aircraft (aeronave pilotada remotamente)
RPAS: Remotely Piloted Aerial System (sistema aéreo pilotado remotamente)

 

 

Share Button
10/06/2019

Leave a Reply