ES2913173T3 - Ordenador de control para un vehículo no tripulado - Google Patents

Ordenador de control para un vehículo no tripulado Download PDF

Info

Publication number
ES2913173T3
ES2913173T3 ES12752630T ES12752630T ES2913173T3 ES 2913173 T3 ES2913173 T3 ES 2913173T3 ES 12752630 T ES12752630 T ES 12752630T ES 12752630 T ES12752630 T ES 12752630T ES 2913173 T3 ES2913173 T3 ES 2913173T3
Authority
ES
Spain
Prior art keywords
vehicle
state
control computer
data
states
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12752630T
Other languages
English (en)
Inventor
Bradford Yelland
Glen Logan
Paul Riseborough
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BAE Systems Australia Ltd
Original Assignee
BAE Systems Australia Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2011900735A external-priority patent/AU2011900735A0/en
Application filed by BAE Systems Australia Ltd filed Critical BAE Systems Australia Ltd
Application granted granted Critical
Publication of ES2913173T3 publication Critical patent/ES2913173T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B64AIRCRAFT; AVIATION; COSMONAUTICS
    • B64CAEROPLANES; HELICOPTERS
    • B64C13/00Control systems or transmitting systems for actuating flying-control surfaces, lift-increasing flaps, air brakes, or spoilers
    • B64C13/02Initiating means
    • B64C13/16Initiating means actuated automatically, e.g. responsive to gust detectors
    • B64C13/18Initiating means actuated automatically, e.g. responsive to gust detectors using automatic pilot
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/0088Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots characterized by the autonomous decision making process, e.g. artificial intelligence, predefined behaviours
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B64AIRCRAFT; AVIATION; COSMONAUTICS
    • B64CAEROPLANES; HELICOPTERS
    • B64C13/00Control systems or transmitting systems for actuating flying-control surfaces, lift-increasing flaps, air brakes, or spoilers
    • B64C13/02Initiating means
    • B64C13/16Initiating means actuated automatically, e.g. responsive to gust detectors
    • B64C13/20Initiating means actuated automatically, e.g. responsive to gust detectors using radiated signals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B64AIRCRAFT; AVIATION; COSMONAUTICS
    • B64UUNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U2201/00UAVs characterised by their flight controls
    • B64U2201/10UAVs characterised by their flight controls autonomous, i.e. by navigating independently from ground or air stations, e.g. by using inertial navigation systems [INS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Game Theory and Decision Science (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Medical Informatics (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Control Of Position, Course, Altitude, Or Attitude Of Moving Bodies (AREA)
  • Control Of Driving Devices And Active Controlling Of Vehicle (AREA)

Abstract

Un ordenador de control (100) para un vehículo no tripulado, que incluye: una interfaz de sensor (250) para recibir datos de sensor de los sensores del vehículo, dichos datos de sensor que incluyen valores de datos asociados con el movimiento del vehículo; una interfaz de control del actuador (252) para enviar datos del actuador para controlar los actuadores del vehículo, dichos actuadores que controlan partes del vehículo asociadas con el control del movimiento del vehículo; y caracterizado porque el ordenador de control (100) incluye un componente de gestión del sistema (204) para ejecutar una máquina de estados que tiene estados correspondientes a una o más fases de dicho movimiento y para determinar una transición entre un estado actual de dichos estados y otro de dichos estados con base en al menos una condición asociada con dicha transición, dicha al menos una condición se determina con base en al menos uno de dichos datos del sensor, dichos datos del actuador y el estado de dicho ordenador en donde dicha al menos una condición asociada con dicha transición representa la finalización de una fase de movimiento de dicho estado actual.

Description

DESCRIPCIÓN
Ordenador de control para un vehículo no tripulado
Campo
La presente invención se refiere a un ordenador de control para un vehículo no tripulado que puede utilizarse para permitir que el vehículo funcione de forma autónoma.
Antecedentes
Los vehículos no tripulados, tales como los vehículos aéreos no tripulados (UAV), son controlados de forma remota por un operador que utiliza un controlador de vehículos terrestre. El operador utiliza el controlador terrestre y diversa información proporcionada por los sensores del vehículo para guiar el vehículo a través de diferentes etapas de movimiento y operación. El vehículo puede incluir circuitos de procesamiento de control para permitirle realizar algunas operaciones de forma autónoma, tal como el aterrizaje. Sin embargo, es necesario que el operador determine en qué etapa de movimiento se encuentra actualmente el vehículo y tome el control del vehículo cuando sea necesario. Por ejemplo, el operador puede necesitar controlar el vehículo durante el vuelo hasta que decida que el vehículo está en una posición adecuada para permitir que el vehículo aterrice de forma autónoma.
El documento US 2006/058928 A1 (BEARD RANDAL W [US] Y OTROS) 16 de marzo de 2006 especifica un sistema de piloto automático programable para el vuelo autónomo de vehículos aéreos no tripulados. El documento US 2007/093946 A1 (GIDEONI IFTAH [IL]) del 26 de abril de 2007 especifica métodos y aparatos para el comando, control y comunicación de vehículos no tripulados.
Eliminar la necesidad de una intervención manual continua y permitir que el vehículo funcione de forma autónoma daría lugar a una serie de ventajas significativas. Un vehículo autónomo podría funcionar de manera efectiva si la comunicación con el controlador remoto del vehículo se interrumpe o se desactiva. Los errores humanos asociados con las decisiones del operador también podrían eliminarse, particularmente si el vehículo pudiera discriminar entre una amplia variedad de situaciones de movimiento y navegación por sí mismo. Una dificultad principal y significativa es permitir que el vehículo determine cuándo cambia el control entre diferentes etapas o fases de movimiento o, en particular, poder cambiar entre ellas y reaccionar como una persona en el vehículo.
En consecuencia, se desea abordar esto o al menos proporcionar una alternativa útil.
Resumen
Las realizaciones descritas en este documento proporcionan un ordenador de control para un vehículo no tripulado, que incluye:
una interfaz de sensores para recibir datos de los sensores del vehículo, dichos datos de los sensores que incluyen valores de datos asociados con el movimiento del vehículo;
una interfaz de control del actuador para enviar datos del actuador para controlar los actuadores del vehículo, dichos actuadores controlan partes del vehículo asociadas con el movimiento de control del vehículo; y un componente de gestión del sistema para ejecutar una máquina de estado que tiene estados correspondientes a una o más fases de dicho movimiento y para determinar una transición entre un estado actual de dichos estados y otro de dichos estados con base en al menos una condición asociada con dicha transición, dicha al menos una condición se determina con base al menos en uno de dichos datos del sensor, dichos datos del actuador y el estado de dicho ordenador en donde dicha al menos una condición asociada con dicha transición representa la finalización de una fase de movimiento de dicho estado actual.
Dibujos
A continuación se describen realizaciones de la presente invención, únicamente a modo de ejemplo, con referencia a los dibujos adjuntos, en donde:
la Figura 1 es un diagrama de arquitectura de una realización de un ordenador de control para un vehículo no tripulado;
la Figura 2 es un diagrama de bloques de los componentes del ordenador de control;
la Figura 3 es un diagrama de la relación entre los componentes del ordenador de control;
la Figura 4 es un diagrama de fases de movimiento controlado por el ordenador;
la Figura 5 (A, B y C) es un diagrama de una máquina de estado del ordenador; y
La Figura 6 es un plano de un área operativa gestionada por el ordenador.
Descripción
Un ordenador de control de vuelo (FCC) 100 de un vehículo aéreo no tripulado (UAV), como se muestra en las Figuras 1 y 2, acepta y procesa los datos del sensor de entrada de los sensores 250 a bordo del vehículo. El FCC 100 también genera y emite datos de comando para una unidad de control de actuadores (ACU) 250 para controlar varios actuadores a bordo del vehículo con el fin de controlar el movimiento del vehículo de acuerdo con un plan de misión o vuelo validado. La ACU 250 también proporciona datos de respuesta o estado, en relación con los actuadores y las partes del vehículo que controlan los actuadores, de vuelta al ordenador 100 para que los procese como datos de sensor. El ordenador 100 incluye los componentes de Navegación, Gestión de Puntos de Ruta y Guía 206, 208 y 210 para controlar un vehículo durante las fases del plan de vuelo. El ordenador 100, como se muestra en la Figura 1, incluye una tarjeta de CPU de placa única 120, con Power PC e interfaces de entrada/salida (tales como RS232, Ethernet y PCI), y una tarjeta de E/S 140 con memoria flash 160, un Receptor GPS 180 y puertos UART. El ordenador 100 también aloja una unidad de medición inercial (IMU) 190 y el receptor GPS (por ejemplo, un Novatel OEMV1) 180 se conecta directamente a las antenas del vehículo para un sistema de posicionamiento global.
El FCC 100 controla, coordina y monitorea los siguientes sensores 250 y actuadores en el vehículo:
(i) un sensor de datos de aire (ADS) que comprende transductores de presión de aire,
(ii) un sensor de altura precisa (AHS), por ejemplo, proporcionado por un láser o sonar dirigido desde el suelo,
(iii) un sensor de peso sobre ruedas (WoW),
(iv) un transpondedor, que maneja las comunicaciones con un controlador de vehículos terrestres (GVC), (v) el sistema de energía eléctrica (EPS),
(vi) controles de vuelo primarios, tales como controles para superficies (por ejemplo, alerones, timón, elevadores, frenos de aire), frenos y acelerador,
(vii) sistema de propulsión, que incluye
(a) una unidad de control del turbo del motor (TCU),
(b) un sistema de gestión del motor (EMS),
(c) un interruptor de apagado del motor,
(d) calentador de carburador,
(e) ventilador de motor,
(f) ventilador de aceite
(viii) sistema de combustible,
(ix) sistema de control ambiental (ECS) que comprende un sensor de temperatura de la aeronave, válvulas de flujo de aire y ventiladores,
(x) calentamiento con sonda Pitot,
(xi) iluminación exterior y
(xii) detectores de congelación.
Los actuadores de (v) a (xi) están controlados por datos del actuador enviados por el FCC 100 a al menos una unidad de control de actuador (ACU) o procesador 252 conectado a los actuadores.
El FCC 100 almacena y ejecuta un sistema operativo en tiempo real (RTOS) incorporado, tal como Integrity-178B de Green Hills Software Inc. El RTOS 304 maneja el acceso a la memoria por parte de la CPU 120, la disponibilidad de recursos, el acceso de E/S y la partición de los componentes de software integrados (CSC) del ordenador mediante la asignación de al menos un espacio de direcciones virtuales a cada CSC.
El FCC 100 incluye un elemento de configuración del sistema informático (CSCI) 302, como se muestra en la Figura 3, que comprende los componentes de software informático (CSC) y el sistema operativo 304 en el que se ejecutan los componentes. Los CSC se almacenan en la memoria flash 160 y pueden comprender un código de programa informático integrado C++ o C. Los CSC incluyen los siguientes componentes:
(a) Monitor de Estado 202;
(b) Gestión del sistema 204 (crítico y no crítico para el vuelo);
(c) Navegación 206;
(d) Gestión de puntos de ruta 208;
(e) Guía 210;
(f) Aumento de estabilidad 212;
(g) Carga de datos/Instrumentación 214; e
(h) Interfaz del sistema 216 (crítico y no crítico para el vuelo).
El CSC del Monitor de Estado 202 está conectado a cada uno de los componentes que componen el CSCI 302 de modo que los componentes puedan enviar mensajes al Monitor de Estado 202 cuando completan con éxito el procesamiento.
El CSC de la interfaz del sistema 216 proporciona una interfaz de hardware de bajo nivel y abstrae los datos en un formato utilizable por los otros CSC.
El CSC 206 de navegación utiliza una combinación de datos IMU y datos GPS y calcula continuamente la posición actual de la aeronave (latitud/longitud/altura), velocidad, aceleración y orientación. El CSC de navegación también realiza un seguimiento de los errores de inclinación de la IMU y detecta y aísla los errores de la IMU y del GPS. Los datos generados por el CSC de navegación representan coordenadas WGS-84 (tierra redonda).
El CSC de gestión de puntos de Ruta (WPM) 208 es el principal responsable dentro del FCC de generar un conjunto de 4 puntos de ruta para enviar al CSC de Guía 210 que determina el trayecto previsto del vehículo a través del espacio 3D. El CSC del WPM 208 también
(a) suministra datos de eventos o estados al CSC de gestión del sistema 204 para indicar la ocurrencia de ciertas situaciones asociadas con el vehículo.
(b) Comprueba la validez de los planes de vuelo o misión recibidos
(c) Gestiona las interacciones con un Sistema de Misión (MS) aerotransportado 254 del vehículo. El MS envía solicitudes de ruta al WPM 208 con base en los puntos de ruta y el plan de misión activo actual. El CSC de Guía 210 genera datos de requerimientos de orientación del vehículo (que representan las tasas de balanceo, cabeceo y guiñada) para seguir un trayecto tridimensional definido especificado por los cuatro puntos de ruta. Los requerimientos de tasa de orientación se proporcionan al CSC de Aumento de Estabilidad 212. Los cuatro puntos de ruta utilizados para generar estos requerimientos se reciben del CSC de Gestión de Puntos de Ruta 208. El CSC de Guía 210 guía de forma autónoma el vehículo en todas las fases del movimiento.
El CSC de Aumento de Estabilidad (SA) 212 convierte los requerimientos de velocidad angular del vehículo en requerimientos de superficie de control y permite que cualquier requerimiento de velocidad manual que pueda recibir el GVC controle el vehículo durante las operaciones en tierra cuando sea necesario. El CSC de SA 212 también consolida y convierte las lecturas del sensor de datos de aire en velocidad del aire y altitud de presión para el resto de los componentes.
El CSC de infraestructura es un componente de software común que se utiliza en varios CSC. Este maneja funciones, tales como la generación y decodificación de mensajes, la interfaz de capa de IO, funciones de administración de tiempo y protocolos y comunicaciones en serie tales como UDP.
El CSC de Gestión del Sistema 204 es responsable de gestionar una serie de funciones del FCC, incluidas las comunicaciones internas y externas.
Se puede considerar que un UAV que funciona de acuerdo con un plan de vuelo se mueve o funciona a través de siete fases diferentes de vuelo, como se muestra en la Figura 4. Las siete fases de vuelo se describen a continuación en la Tabla 1.
Tabla 1
Figure imgf000004_0001
La gran dificultad para los vehículos autónomos es poder determinar cuándo el vehículo se encuentra en una de estas fases, y también la transición entre las fases. Para conseguirlo, el CSCI del FCC 302 incluye una máquina de estado que establece uno o varios estados para cada una de las fases de movimiento del vehículo. Cada uno de los estados corresponde a una operación contenida específica del vehículo, de modo que la máquina de estado debe gestionar cuidadosamente las transiciones entre estados para evitar daños o choques del vehículo. La máquina de estado controla el funcionamiento del CSCI junto con las operaciones que ordena al vehículo que realice. Los estados y sus correspondientes fases se describen a continuación en la Tabla 2.
Tabla 2
Figure imgf000005_0001
El Componente de Gestión del Sistema 204 define, establece y ejecuta la máquina de estado determinando el estado existente y efectuando los cambios entre los estados en función de las condiciones y las transiciones disponibles para cada estado, y en función de los datos proporcionados por los CSC, tal como el aumento de la Guía, la Navegación y la estabilidad y la Gestión de Puntos de Ruta que dependen del estado actual. Los datos proporcionados por los CSC que afectan a los estados dependen a su vez de los datos del sensor y son recibidos por el FCC 100. En las Figuras 5A, 5B y 5C se muestra un diagrama de estado de la máquina de estado. Los estados están representados por los cuadros, las líneas representan las transiciones y las condiciones de transición, analizadas a continuación, se indican en las líneas de transición o adyacentes a ellas. Las condiciones de transición están definidas por parámetros (por ejemplo, banderas, comandos, requerimientos, etc.) de los CSC que tienen ciertos valores de datos, como se indica y analiza a continuación.
El Commence_Status 502 es el primer estado al que se entra cuando se inicializa el Componente de Gestión del Sistema 204. En este estado, el componente realiza verificaciones del estado del sistema para determinar el estado general del ordenador de control de vuelo 100. Una vez que un circuito de prueba incorporado continuo (CBIT) del vehículo indica que los sensores de IMU, el GPS y los sensores de datos aéreos y otro hardware y software están en buen estado, la administración del sistema establece una bandera de Commence_Status en un valor de aprobación. En el Commence_Status, el ordenador 100 también configura los sistemas del vehículo para:
(a) establecer todos los frenos de las ruedas en posición totalmente acoplados
(b) establecer las superficies de control en control de velocidad angular cero
(c) establecer el requerimiento de aceleración del motor en inactivo
(d) desactivar el acelerador automático
Una vez que la bandera Commence_Status está configurado con un valor aprobado, la máquina de estado pasa a Nav_Align_State 504 y el CSC 206 de Navegación del FCC 100 realiza un análisis adicional sobre el estado y el rendimiento de los sensores GPS e IMU. El FCC asume que la aeronave está estacionaria mientras se encuentra en este estado y, por lo tanto, no se espera que los datos recibidos de estos sensores varíen más allá de los límites de ruido de sensor aceptados. Cualquier variación en los datos de ángulo, velocidad angular y aceleración de la IMU 190 o los datos de posición y velocidad del GPS 180 que excedan estos límites de ruido se marcan como defectuosas. Además, el FCC verifica las banderas de estado de los sensores IMU y GPS y analiza la velocidad del sensor para asegurarse de que los sensores emitan datos válidos a la frecuencia del sensor requerida.
Dentro de Nav_Align_State, el CSC 206 de navegación analiza adicionalmente los datos GPS para garantizar que los datos de al menos dos antenas diferentes utilizadas por el vehículo indiquen la separación correcta y la idoneidad para la estimación del rumbo del vehículo. El FCC también genera un promedio de los datos de posición del GPS y los datos de ángulo de los sensores de inclinación de la IMU utilizando la suposición de que no hay movimiento. Este promedio se realiza durante un período de 60 segundos para reducir los efectos del ruido del sensor sobre el promedio. Esta posición promedio y los ángulos de balanceo y cabeceo se utilizan con una estimación de rumbo derivada de la diferencia de posición de la antena GPS dual para proporcionar una estimación inicial de posición y actitud. El CSC de Navegación 206 completa el estado con éxito cuando los valores de los datos de posición y velocidad se han determinado correctamente, incluidos los valores de datos de cabeceo y balanceo (a partir de los datos de inclinación de la IMU), guiñada (a partir de la diferencia de posición de las antenas GPS), latitud, longitud y altura (a partir de los datos del GPS) y valores de inclinación para giroscopios y acelerómetros del IMU 190.
El E-Test_State 506 se utiliza para probar diagnósticos. El FCC pasa a este estado desde Commence_State o Nav_Align_State si se genera y recibe algún mensaje de orden de prueba. Esto puede generarse y enviarse desde el controlador remoto de vehículos terrestre (GVC).
El FCC entra en Start_Engine_State 508 si Nav_Align_State ha sido completado con éxito por el CSC de Navegación 206 (indicado por una bandera de Nav_Align_Status que se configura con un valor de aprobado) y se ha recibido un mensaje de comando Prepare_To_Start_Engine. El mensaje Prepare_To_Start_Command puede generarse y recibirse desde el GVC o generarse por el Componente de Gestión del Sistema 204 una vez que Nav_Align_State se ha completado con éxito.
En Start_Engine_State 508, el FCC genera y envía un comando de arranque de motor para la Interfaz de Sistema 216 que, a su vez, envía datos del actuador a la ACU 252 para arrancar el motor. El fCc monitorea el estado del motor analizando las RPM del motor durante un período de 10 cuadros. El FCC se puede configurar para que se ejecute a 100 Hz, por lo que los CSC ejecutan 100 bloques de ejecución cada segundo, donde cada bloque se puede considerar como un cuadro de 10 ms de duración. Una vez que las RPM del motor han excedido un umbral predeterminado durante este período de 10 cuadros, se considera que se ha iniciado y se establece una bandera Engine_Status en iniciado. Un plan de vuelo o misión también debe haberse cargado, aprobado y aceptado correctamente antes de que el fCc pueda realizar la transición al TAXI_State 510. También puede ser un requisito que el GVC indique que no controlará manualmente el vehículo, por lo que establecerá una bandera de Manual_Control en falso. El GVC también puede enviar un comando Prepare_To_Shutdown_Engine para hacer la transición del FCC al Engine_Shutdown_State 530.
En el Taxi_State 510, el FCC controla el movimiento en tierra del vehículo para moverlo desde su posición actual a una posición en la pista desde la cual puede pasar al Estado de Despegue 512.
Durante el Taxi_State, es posible que las condiciones cambiantes hagan que el vehículo supere la velocidad (lo que podría provocar que el vehículo despegue accidentalmente). Para mitigar este modo de falla, el FCC monitorea las velocidades en el aire y en el suelo y reducirá la aceleración a inactiva y desplegará los frenos neumáticos cuando se exceda un umbral de velocidad en el suelo o en el aire. Si esta acción no es efectiva y la velocidad sigue aumentando, el FCC requerirá el frenado de las ruedas.
Para hacer la transición al Estado de Despegue 512, el FCC debe determinar que el vehículo:
(a) dentro de los 5 metros lateralmente de la línea central de la pista (especificado a través de la línea entre el punto de espera y el punto de despegue en el plan de misión);
(b) no está a más de 10 metros del punto de espera en la dirección de la pista;
(c) está dentro de los 10 metros de la altura de un punto de espera;
(d) tiene un rumbo dentro de los 5 grados de un rumbo del vector de la pista;
(e) se mueve a menos de 2 m/s; y
(f) el estado de CBIT es saludable.
Este también puede ser un requisito que se reciba un comando de despegue del GVC.
Al recibir un mensaje Prepare_To_Shutdown_Engine_Command del GVC, el FCC pasará a Engine Shutdown State 530 desde Taxi State 512.
En el estado de Despegue 512, el FCC genera y emite requerimientos del actuador, incluidos los datos del actuador para:
(a) acelerar el vehículo;
(b) lograr una trayectoria horizontal definida por una trayectoria de despegue o trayecto del plan de misión; y
(c) realizar una rotación de despegue cuando el EAS es igual a un umbral mínimo para el despegue. Otros requerimientos pueden incluir:
(c) mantener el vehículo en el suelo hasta que se alcance un umbral de velocidad efectiva del aire (EAS) para levantar la(s) rueda(s); y
(d) seguir un perfil de orientación de cabeceo de despegue definido para un EAS mayor que el umbral de EAS, lo que resulta en la elevación de la(s) rueda(s)
Cuando inicia el despegue, el FCC 100 ordena una aceleración del motor al 100 % (o un máximo permitido por el plan de la misión) y libera los frenos de aire y de las ruedas.
El FCC también puede generar comandos específicos para una aeronave en particular. Por ejemplo, el FCC puede ordenar que la cola de la aeronave se levante una vez que supere el 70 % de la velocidad de pérdida y luego ordenará una rotación una vez que la velocidad supere el 115 % de la velocidad de pérdida. Esta maniobra tiene por objeto reducir la resistencia aerodinámica de la aeronave durante el recorrido en tierra y proporcionar una rotación limpia para el despegue, en lugar de dejar el vehículo con las ruedas en el suelo y dejar que el vehículo se eleve solo del suelo cuando haya suficiente elevación disponible (lo que podría resultar en un vuelo en o muy cerca de la condición de entrada en pérdida).
El FCC establece un parámetro de Despegue Completo en verdadero y pasa a Climbout_State 514 cuando se cumplen dos de las siguientes tres condiciones:
(i) EAS es mayor que un umbral, digamos 30 m/s;
(ii) El peso sobre las ruedas es cero la mayoría de las veces para ambas ruedas durante los últimos 11 cuadros, es decir, 110 ms
(iii) La velocidad vertical es superior a 1 m/s
Estas condiciones están diseñadas para aliviar los problemas de detección de despegue con WOW o sensores de presión defectuosos.
El FCC pasa al Estado de Lanzamiento 528 si se recibe una orden de cancelación de despegue del GVC. También se puede decidir pasar a este estado si se pierden las comunicaciones con el GVC antes de una velocidad de decisión de despegue (por ejemplo, el 80 % de la velocidad de pérdida estimada).
En Climbout_State 514, el FCC genera datos del actuador para requerir la aceleración máxima (es decir, el 115 % de la aceleración) y sigue una trayectoria o trayecto horizontal definido por una porción de ascenso del plan de misión. El FCC también emite comandos para mantener un ángulo de cabeceo de ascenso, por ejemplo, de 7 grados. Esto garantiza que el vehículo ejecute un ascenso más robusto que proporcionar un trayecto de ascenso específico que puede resultar en condiciones de baja velocidad y una posible condición de pérdida o grandes velocidades angulares cuando está muy cerca del suelo. El FCC cambia a Scenario_State 516 cuando recibe datos del sensor que indican que una de las siguientes condiciones es verdadera:
(a) la altitud del vehículo ha alcanzado un umbral de altura especificado;
(b) el EAS del vehículo es mayor que el EAS a alcanzar para el ascenso; y
(c) la posición horizontal del vehículo ha alcanzado un punto de ruta de ascenso que se especifica en la parte de ascenso del plan de la misión.
Las condiciones tienen en cuenta las diferentes prestaciones de ascenso de la aeronave y evitan que se produzca un exceso de velocidad o una aceleración retenida.
En Scenario_State 516, el FCC mueve la aeronave a través de los puntos de ruta del bosquejo definidos en el plan de misión y sigue los trayectos horizontales y verticales especificados por los puntos de ruta mientras mantiene la velocidad del aire especificada por la Gestión de los puntos de ruta CSC 208. El FCC genera datos del actuador para hacer que el vehículo siga una trayectoria definida por una parte del bosquejo del plan de la misión. El FCC modifica la trayectoria del bosquejo del plan de misión cuando el CSC de Gestión de puntos de ruta 208 genera un GOTO_Waypoint_Command. Cuando el Sistema de Misión Aerotransportado (AMS) 254 proporciona al FCC una serie de puntos de ruta válidos que definen una ruta, el trayecto entre dos puntos de ruta del plan de misión se define mediante puntos de ruta que proporcionan un trayecto alternativo entre dos puntos de ruta en lugar de una línea recta. El FCC 100 acepta una ruta del AMS 254 una vez que el CSC de Gestión de Puntos de Ruta 208 determina que la ruta es aprobada según las comprobaciones de rendimiento del vehículo y geometría de puntos de ruta y no se han recibido más de 2 rutas incorrectas seguidas del AMS.
El FCC pasa de Scenario_State a Loiter_State 510 cuando se genera un Comando de Deambulación, que puede ser enviado por el GVC. El FCC cambia a INBOUND_State 520 cuando el vehículo pasa el último punto de ruta del bosquejo en el plan de la misión o se recibe un Inbound_Command. El FCC también se puede configurar para que la transición al Inbound_State 520 se produzca si el vehículo detecta una pérdida de comunicación con el g Vc .
Se entra en Heading_Hold State 540 desde Scenario_State 516, Loiter_State 518, Inbound_State 520, Circuit_State 522, Approach_State 524 y Landing_State 526 si el FCC 100 genera y recibe un comando Mantener el Rumbo. El comando Mantener el Rumbo puede ser generado por un operador del GVC en respuesta a una dirección emitida por el control de tráfico aéreo. El comando Mantener el Rumbo incluye datos que representan un rumbo direccional particular que el vehículo debe seguir y, en consecuencia, el FCC 100 genera datos del actuador para que el vehículo siga ese rumbo direccional, por ejemplo, 90° en relación con el norte verdadero. En Heading Hold State 540, la aeronave continuará manteniendo el rumbo a una altitud fija, hasta que el FCC pase a otro estado. El FCC cambia a Loiter_State 518 si se genera y recibe un comando Cancel_Heading_Hold o se alcanza una extensión de vuelo horizontal. El FCC 100 también pasará a Inbound_State 520 si se pierden las comunicaciones con el GVC. En Loiter_State 518, el FCC 100 genera datos del actuador para que el vehículo siga una trayectoria definida por una parte del vuelo sin rumbo definido del plan de misión, lo que hace que el vehículo haga vueltas de un plan de vuelo de patrón de vuelo sin rumbo definido. En LOITER_State, el FCC puede aceptar y operar sobre la base de un nuevo plan de misión.
Cuando el FCC está en Loiter_State 518 y recibe un Resume_Scenario_Command (que puede ser enviado por el GVC), y el estado anterior era Scenario_State 516, el FCC cambiará su estado a Scenario_State al completar la vuelta actual del patrón de vuelo sin rumbo definido. En este caso, una vez que cambie a Scenario_State, el vehículo reanudará los puntos de ruta del bosquejo desde donde se quedaron al entrar al Loiter_State.
Cuando el FCC está en Loiter_State 518 y recibe un Enter_Scenario_Command (que puede ser enviado por el GVC), el FCC cambiará su estado inmediatamente a Scenario_State si el trayecto generado para volar a un Punto de Ruta de Entrada al Bosquejo proporcionado no viola un área de vuelo permitida (según lo definido por las extensiones de vuelo del plan de misión).
Cuando el FCC está en Loiter_State 518 y recibe un Resume_Inbound_Command (que puede ser enviado por el GVC) y el estado anterior era Inbound_State, el FCC cambiará su estado a Inbound_State 520 al completar la vuelta actual del patrón de vuelo sin rumbo definido. En este caso, una vez que cambie a Inbound_State 520, el vehículo reanudará un trayecto de entrada desde donde se quedó cuando entró en el patrón de vuelo sin rumbo definido. Cuando el FCC está en Loiter_State 518 y recibe un Enter_Inbound_Command del GVC, el FCC cambiará su estado a Inbound_State inmediatamente, realizando una entrada como se describe a continuación.
Si el FCC está en Loiter_State 518 y se acepta y activa un nuevo plan de misión, el bosquejo de reanudación y las transiciones de entrada de reanudación se desactivan. El único estado aerotransportado donde se puede activar un nuevo plan de misión es Loiter_State. La reanudación de la transición de entrada también está deshabilitada si el FCC está en Loiter_State desde la entrada y se cambia la pista de aterrizaje.
Se entra al Inbound_State 520 cuando, como se analizó anteriormente, la parte del bosquejo del plan de misión está completa o se emite o recibe un comando para regresar a la base. El Inbound_State 520 es un estado de seguridad al que pasan los otros estados si ocurre un error o una condición de peligro, y el vehículo debe recuperarse de forma segura y devolverse a la base. Por ejemplo, si se pierden las comunicaciones con el GVC, el Scenario_State 516, el Loiter_State 518, el Heading_State 540 pueden pasar directamente al Inbound_State 520. En Inbound_State 520, el ordenador 100 genera datos del actuador para seguir una trayectoria definida por una parte de entrada del plan de misión. En este estado, el FCC puede aceptar y cambiar su retorno activo a los puntos de ruta base o actualizar la trayectoria de entrada. Esto permite que Inbound_State consista en una entrada generada dinámicamente en un trayecto de entrada definido estáticamente a un aeródromo.
El FCC selecciona un punto de entrada (los puntos de entrada del plan de misión se designan como de entrada o no entrada) que brinda el trayecto de vuelo más corto (siguiendo los puntos de ruta de entrada desde el punto de entrada) de regreso al aeródromo de aterrizaje que no viola una extensión de vuelo. El FCC 100 realiza verificaciones estáticas del plan de misión para garantizar que desde todas las posiciones dentro de la extensión del vuelo sea posible llegar al menos a un único punto de entrada, desde donde se garantiza un trayecto seguro para regresar al aeródromo de aterrizaje. Como se muestra en la Figura 6, si el vehículo se encuentra actualmente en un punto 602, el FCC 100 selecciona un punto de ruta de entrada 604 de la trayectoria de entrada 606 que está más cerca de la pista 608 y al que el vehículo puede volar sin violar el alcance del vuelo que definen una zona de exclusión aérea 610. Si el vehículo está en una posición 612 y ningún alcance de vuelo prohíbe la entrada, el FCC 100 se unirá a la trayectoria de entrada 606 en un punto de ruta de entrada 614 mucho más cerca del punto de ruta de entrada final antes de la pista 608.
Si el FCC está en Inbound_State 520 y el vehículo viola las extensiones de vuelo (una posible razón de esto incluye un rendimiento degradado de ascenso/inmersión del vehículo), el CSC de Gestión de Puntos de Ruta 208 forzará una transición al Loiter_State 518 con la altitud requerida (en lugar de la alcanzada). Esto obligará al vehículo a ascender (o descender) por debajo del alcance del vuelo según sea necesario. Al alcanzar la altitud requerida, el FCC generará un Resume_Inbound_Command. Si se encuentra en una situación de pérdida de comunicaciones, la transición de comunicaciones perdidas fuera de Loiter_State se desactivará para evitar que el vehículo vuelva a entrar antes de alcanzar la altitud. Esta desactivación de comunicaciones perdidas solo se aplica si se ingresó a Loiter_State desde Inbound_State.
Al completar el último punto de ruta de entrada, según lo determinado por el CSC de Gestión de Puntos de Ruta 208, en función de los datos del CSC de Guía 210, el FCC 100 pasa del Inbound _State 520 a Circuit_State 522 En el Circuit_State 522, el FCC maniobra el vehículo alrededor del aeródromo para alinearlo para una aproximación a la pista. En este estado, el FCC genera datos del actuador para seguir una trayectoria definida por una parte del circuito del plan de misión. El FCC hará la transición a Scenario_State 516 si se recibe un Ente_Scenario_Command (por ejemplo, del GVC) durante el Circuit_State y el trayecto de entrada al punto de ruta de entrada proporcionado no viola las extensiones de vuelo. El FCC hará la transición a Inbound_State 520 si se recibe un Enter_Inbound_Command (por ejemplo, del GVC) durante el Circuit_State.
El FCC pasa del estado del Circuit_State 522 al Approach_State 524 cuando el vehículo alcanza un punto de ruta del circuito de la trayectoria de la parte del circuito que se designó como el Punto de Ruta de Salida del Circuito. Este punto de ruta está alineado con la pista para proporcionar una transición sin maniobras hacia la aproximación. La transición de Circuit_State a Approach_State se inhabilita al recibir un Inhibit_Approach_Command (por ejemplo, del GVC). En este caso, el FCC seguirá dirigiendo el vehículo a lo largo de los puntos de ruta del circuito. Cuando el FCC alcanza el último punto de ruta del circuito en el plan de la misión, regresará a la trayectoria del circuito moviéndose a un punto de ruta designado como un punto de ruta de Repetición de Circuito. Luego se borra el comando Inhibit_Approach para permitir una transición al Approach_State.
Si se entra al Circuit_State desde Approach_State 524 o Landing_State 526, el FCC utilizará los puntos de ruta del circuito de cancelación del plan de la misión (que generalmente comenzarán desde el extremo más alejado de la pista) en lugar de los puntos de ruta del circuito normal que comenzarán cerca del punto de ruta de entrada final. En el Approach_State 524, el FCC genera requerimientos (o comandos) que incluyen datos del actuador para aplicar 0,3 del freno de aire, y seguir una trayectoria definida por una parte de aproximación del plan de misión. El Approach_State es utilizado por el FCC para guiar al vehículo por un trayecto de aproximación y establecer las condiciones para el aterrizaje (incluidos los valores de los parámetros de posición y velocidad requeridos).
El FCC pasa de Approach_State a Circuit_State si:
(a) se recibe un Abort_Landing_Command (por ejemplo, del GVC); o
(b) el FCC detecta que el vehículo se ha desviado más de 11 m horizontal o verticalmente del trayecto de aproximación requerido.
El FCC pasa del Approach_State 524 al Landing_State 526 una vez que el vehículo ha pasado un punto de ruta umbral de aterrizaje del trayecto de aproximación.
En Landing_State 526, el FCC genera requerimientos cuando una bandera Flare_Commence es falsa para:
(a) seguir una trayectoria definida por una parte de aterrizaje del plan de misión;
(b) limitar el ángulo de inclinación lateral del vehículo en función de la altura del vehículo sobre el nivel del suelo (HAGL);
(c) aplicar el freno neumático a un nivel efectivo, por ejemplo, un freno neumático de 0,3.
El FCC utiliza Landing_State 526 para realizar las maniobras finales necesarias para lograr un aterrizaje de tres puntos. Esto incluye la guía del vehículo hacia la parte final del trayecto de aterrizaje y el enderezamiento y la retención del vehículo para lograr un aterrizaje de tres puntos con una tasa de descenso aceptable y un rebote mínimo.
El FCC pasa de Landing_State 526 a Circuit_State 522 si:
(a) se recibe un Abort_Landing_Command (por ejemplo, del GVC); o
(b) el FCC detecta que el vehículo se ha desviado más de 11 m horizontal o verticalmente del trayecto de aproximación requerido y el vehículo no ha iniciado una maniobra de enderezamiento y espera.
El FCC pasa del Landing_State 526 al Rollout_State 528 cuando el FCC determina: (i) el vehículo ha mantenido el peso sobre las ruedas durante 2 segundos con base en los datos del sensor WOW 250; y (ii) ha reducido su velocidad aerodinámica por debajo de la velocidad de pérdida.
En el Rollout_State 528, el FCC genera requerimientos que incluyen datos del actuador para detener el vehículo y seguir un trayecto de lanzamiento del plan de misión. El FCC utiliza Rollout_State para desacelerar el vehículo desde las velocidades de aterrizaje/despegue hasta detenerse, mientras conduce el vehículo a lo largo de la línea central de la pista (según lo definido por los puntos de ruta de aterrizaje/despegue en el plan de la misión).
El FCC pasa del Rollout _State 528 al Taxi _State 510 si la velocidad del vehículo se ha reducido por debajo de 2,0 m/s, el FCC no recibe comandos de control manual y se ha generado un Taxi_Command (que puede provenir del GVC).
El FCC pasa del Rollout_State 528 al Engine_Shutdown_State 530 si la velocidad del vehículo se ha reducido por debajo de 2,0 m/s y se genera un Engine_Shutdown_Command (por ejemplo, desde el GVC).
En el Engine_Shutdown_State 530, el FCC genera datos del actuador para:
(a) establecer todos los frenos de las ruedas a completamente activados;
(b) requerir cero tasas de balanceo, cabeceo, deslizamiento lateral y velocidad del aire del motor;
(c) desactivar el acelerador automático;
(d) requerir cero frenado neumático;
(e) establecer el requerimiento de aceleración del motor a inactivo;
El FCC utiliza Engine_Shutdown_State 530 para colocar el vehículo en una condición conocida en la que se puede apagar el motor, lo que requiere aceleración inactiva y frenado completo.
El FCC pasa de Engine_Shutdown_State 530 a Shutdown_State 532 al recibir o generar un Shutdown_Command (por ejemplo, desde el GVC). En el Shutdown_State 532, el FCC se sitúa en una condición en la que puede apagarse. La acción final antes de que el FCC marque el sistema como apagado es liberar los frenos de las ruedas del vehículo para que los operadores en tierra puedan moverlo a un hangar.
Aunque los CSC se describen como componentes de software integrados, estos también pueden implementarse mediante circuitos de hardware, tales como ASICS y FPGA. La invención también se puede aplicar a vehículos terrestres así como a UAV.

Claims (18)

REIVINDICACIONES
1. Un ordenador de control (100) para un vehículo no tripulado, que incluye:
una interfaz de sensor (250) para recibir datos de sensor de los sensores del vehículo, dichos datos de sensor que incluyen valores de datos asociados con el movimiento del vehículo;
una interfaz de control del actuador (252) para enviar datos del actuador para controlar los actuadores del vehículo, dichos actuadores que controlan partes del vehículo asociadas con el control del movimiento del vehículo; y
caracterizado porque el ordenador de control (100) incluye un componente de gestión del sistema (204) para ejecutar una máquina de estados que tiene estados correspondientes a una o más fases de dicho movimiento y para determinar una transición entre un estado actual de dichos estados y otro de dichos estados con base en al menos una condición asociada con dicha transición, dicha al menos una condición se determina con base en al menos uno de dichos datos del sensor, dichos datos del actuador y el estado de dicho ordenador en donde dicha al menos una condición asociada con dicha transición representa la finalización de una fase de movimiento de dicho estado actual.
2. Un ordenador de control de acuerdo con la reivindicación 1, en donde dicha al menos una condición representa la violación de un límite de movimiento de dicho vehículo asociado con dicho estado actual.
3. Un ordenador de control de acuerdo con la reivindicación 1, en donde una fase de movimiento de dicho vehículo corresponde a una pluralidad de dichos estados.
4. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen un estado de inicio en donde dichos datos del actuador requieren que dicho vehículo esté estacionario y dicho componente de gestión del sistema determina la inicialización y el funcionamiento exitosos de dicho ordenador.
5. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen un estado de alineación de navegación en donde se prueban dichos sensores asociados con la navegación, y se obtienen datos iniciales del sensor de navegación que incluyen datos de posición y velocidad.
6. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen un estado de arranque del motor, en donde se acepta y valida un plan de movimiento y se arranca con éxito un motor de dicho vehículo.
7. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen un estado de posición, en donde dichos datos del actuador se generan con base en dichos datos del sensor para mover dicho vehículo a una posición de lanzamiento, dicha al menos una condición es para la transición a un estado de lanzamiento.
8. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen un estado de bosquejo en donde el ordenador genera datos del actuador para mover el vehículo a través de puntos de ruta de bosquejo de un plan de movimiento.
9. Un ordenador de control como se reivindicó en la reivindicación 8, en donde el ordenador incluye componentes de gestión de puntos de ruta, navegación y guía para generar datos del actuador con base en los datos del sensor para completar los puntos de ruta.
10. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde los estados incluyen un estado de entrada, y dicha al menos una condición para una transición al estado de entrada incluye una condición de error asociada con el vehículo.
11. Un ordenador de control como se reivindicó en la reivindicación 10, en donde la condición de error incluye la pérdida de comunicaciones con un controlador remoto.
12. Un ordenador de control como se reivindicó en la reivindicación 10 u 11, en donde, en el estado de entrada, el ordenador genera datos del actuador para que el vehículo siga una trayectoria de entrada de un plan de movimiento para volver a una ubicación base.
13. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde los estados incluyen al menos un estado en el que el ordenador genera datos del actuador para que el vehículo siga un trayecto de espera.
14. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen estados de circuito, aproximación y aterrizaje correspondientes a una fase de movimiento de aterrizaje del vehículo.
15. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen un estado de despegue y ascenso correspondiente a una fase de movimiento de despegue del vehículo.
16. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen estados de bosquejo y de vuelo sin rumbo definido que corresponden a una fase de movimiento en crucero del vehículo.
17. Un ordenador de control de acuerdo con cualquiera de las reivindicaciones anteriores, en donde dichos estados incluyen estados de apagado del motor y apagado del ordenador de control que corresponden a una fase de apagado de un vehículo.
18. Un método realizado por un ordenador de control (100) para un vehículo no tripulado, que incluye:
recibir datos de sensor de los sensores del vehículo, dichos datos de sensor que incluyen valores de datos asociados con el movimiento del vehículo;
enviar datos del actuador para controlar los actuadores del vehículo, dichos actuadores que controlan partes del vehículo asociadas con el control del movimiento del vehículo; y
caracterizado porque el método incluye ejecutar una máquina de estado que tiene estados correspondientes a una o más fases de dicho movimiento y para determinar una transición entre un estado actual de dichos estados y otro de dichos estados con base en al menos una condición asociada con dicha transición, dicha en al menos una condición se determina con base en al menos uno de dichos datos del sensor, dichos datos del actuador y el estado de dicho ordenador, y dicha al menos una condición asociada con dicha transición representa la finalización de una fase de movimiento de dicho estado actual.
ES12752630T 2011-02-28 2012-02-14 Ordenador de control para un vehículo no tripulado Active ES2913173T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2011900735A AU2011900735A0 (en) 2011-02-28 Control computer for an umanned vehicle
PCT/IB2012/000264 WO2012117280A1 (en) 2011-02-28 2012-02-14 Control computer for an unmanned vehicle

Publications (1)

Publication Number Publication Date
ES2913173T3 true ES2913173T3 (es) 2022-05-31

Family

ID=46757394

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12752630T Active ES2913173T3 (es) 2011-02-28 2012-02-14 Ordenador de control para un vehículo no tripulado

Country Status (8)

Country Link
US (1) US9199725B2 (es)
EP (1) EP2681635B8 (es)
KR (1) KR20140052978A (es)
AU (1) AU2012223032B2 (es)
CA (1) CA2831216C (es)
DK (1) DK2681635T3 (es)
ES (1) ES2913173T3 (es)
WO (1) WO2012117280A1 (es)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10331136B2 (en) * 2006-02-27 2019-06-25 Perrone Robotics, Inc. General purpose robotics operating system with unmanned and autonomous vehicle extensions
US10240930B2 (en) 2013-12-10 2019-03-26 SZ DJI Technology Co., Ltd. Sensor fusion
US20150379408A1 (en) * 2014-06-30 2015-12-31 Microsoft Corporation Using Sensor Information for Inferring and Forecasting Large-Scale Phenomena
ES2558732B2 (es) * 2014-08-05 2016-11-14 Universidad De Alicante Sistema y método para la planificación de vuelo autónomo
WO2016033795A1 (en) 2014-09-05 2016-03-10 SZ DJI Technology Co., Ltd. Velocity control for an unmanned aerial vehicle
WO2016033796A1 (en) 2014-09-05 2016-03-10 SZ DJI Technology Co., Ltd. Context-based flight mode selection
CN109388150B (zh) 2014-09-05 2022-04-29 深圳市大疆创新科技有限公司 多传感器环境地图构建
CN104781781B (zh) * 2014-11-14 2018-06-05 深圳市大疆创新科技有限公司 一种移动物体的控制方法、装置及移动设备
US10967960B2 (en) 2015-04-06 2021-04-06 Archon Technologies S.R.L. Ground movement system plugin for VTOL UAVs
US10372142B2 (en) 2015-06-23 2019-08-06 Archon Technologies S.R.L. System for autonomous operation of multiple hybrid unmanned aerial vehicles supported by recharging stations to perform services
WO2017035590A1 (en) * 2015-09-03 2017-03-09 Commonwealth Scientific And Industrial Research Organisation Unmanned aerial vehicle control techniques
US9938001B1 (en) * 2015-09-28 2018-04-10 Amazon Technologies, Inc. Unmanned aerial vehicle (UAV) deployment of passive control stabilizers
WO2017079341A2 (en) 2015-11-04 2017-05-11 Zoox, Inc. Automated extraction of semantic information to enhance incremental mapping modifications for robotic vehicles
US11283877B2 (en) 2015-11-04 2022-03-22 Zoox, Inc. Software application and logic to modify configuration of an autonomous vehicle
US9606539B1 (en) 2015-11-04 2017-03-28 Zoox, Inc. Autonomous vehicle fleet service and system
US9632502B1 (en) * 2015-11-04 2017-04-25 Zoox, Inc. Machine-learning systems and techniques to optimize teleoperation and/or planner decisions
US10401852B2 (en) 2015-11-04 2019-09-03 Zoox, Inc. Teleoperation system and method for trajectory modification of autonomous vehicles
US9630619B1 (en) 2015-11-04 2017-04-25 Zoox, Inc. Robotic vehicle active safety systems and methods
CN106202606A (zh) * 2016-06-22 2016-12-07 百度在线网络技术(北京)有限公司 一种模拟智能体的特征信息获取方法和装置
US10836639B1 (en) 2016-10-26 2020-11-17 Air Stations Llc/Elevated Analytics Llc Joint Venture Air quality measurement system
CN106527479B (zh) * 2016-11-29 2017-12-12 广州极飞科技有限公司 一种无人机的控制方法及装置
US10556675B2 (en) 2017-01-17 2020-02-11 Goodrich Corporation System and method for autobraking with course trajectory adjustment
US10866226B1 (en) 2017-02-07 2020-12-15 Air Stations Llc/Elevated Analytics Llc Joint Venture Multi-point ground emission source sensor system
US10372143B2 (en) 2017-03-20 2019-08-06 Apium Inc. Automated air traffic control of unmanned air vehicles
US10928371B1 (en) 2017-03-31 2021-02-23 Air Stations Llc/Elevated Analytics Llc Joint Venture Hand-held sensor and monitor system
CN107272657B (zh) * 2017-07-21 2020-03-10 北京图森未来科技有限公司 实现车辆自动检修的方法及系统、相关设备
EP3434584B1 (en) * 2017-07-28 2021-06-02 Ge Avio S.r.l. System and method for determining minimum pitch and minimum gas generator idle condition
FR3069665B1 (fr) * 2017-07-31 2021-01-08 Thales Sa Dispositif de controle pour vehicule sans pilote humain embarque, procede de controle de pilotage d'un vehicule sans pilote humain embarque, vehicule sans pilote humain embarque comportant un tel...
US11548626B2 (en) * 2019-07-11 2023-01-10 The Boeing Company Tuned mass damper for aircraft
US11958183B2 (en) 2019-09-19 2024-04-16 The Research Foundation For The State University Of New York Negotiation-based human-robot collaboration via augmented reality
US20220189316A1 (en) * 2020-12-10 2022-06-16 Xwing, Inc. Unmanned aircraft control using ground control station
CN114115287B (zh) * 2021-12-06 2023-09-22 西安航空学院 一种无人车-无人机空地协同巡逻和引导系统
CN114415728B (zh) * 2022-01-21 2023-11-03 广东汇天航空航天科技有限公司 飞行汽车的控制方法、装置、交通工具及存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5716032A (en) * 1996-04-22 1998-02-10 United States Of America As Represented By The Secretary Of The Army Unmanned aerial vehicle automatic landing system
AU2004294651A1 (en) 2003-10-21 2005-06-16 Proxy Aviation Systems, Inc. Methods and apparatus for unmanned vehicle control
US7289906B2 (en) * 2004-04-05 2007-10-30 Oregon Health & Science University Navigation system applications of sigma-point Kalman filters for nonlinear estimation and sensor fusion
US7302316B2 (en) * 2004-09-14 2007-11-27 Brigham Young University Programmable autopilot system for autonomous flight of unmanned aerial vehicles
US7805947B2 (en) * 2005-05-19 2010-10-05 Djamal Moulebhar Aircraft with disengageable engine and auxiliary power unit components
US8718838B2 (en) * 2007-12-14 2014-05-06 The Boeing Company System and methods for autonomous tracking and surveillance
US9026272B2 (en) 2007-12-14 2015-05-05 The Boeing Company Methods for autonomous tracking and surveillance
US9422922B2 (en) * 2009-08-28 2016-08-23 Robert Sant'Anselmo Systems, methods, and devices including modular, fixed and transportable structures incorporating solar and wind generation technologies for production of electricity

Also Published As

Publication number Publication date
AU2012223032B2 (en) 2015-10-29
EP2681635A4 (en) 2017-03-08
US9199725B2 (en) 2015-12-01
DK2681635T3 (da) 2022-05-09
EP2681635B8 (en) 2022-07-20
CA2831216A1 (en) 2012-09-07
EP2681635A1 (en) 2014-01-08
US20130338856A1 (en) 2013-12-19
AU2012223032A1 (en) 2013-10-03
CA2831216C (en) 2018-07-24
EP2681635B1 (en) 2022-04-06
WO2012117280A1 (en) 2012-09-07
KR20140052978A (ko) 2014-05-07

Similar Documents

Publication Publication Date Title
ES2913173T3 (es) Ordenador de control para un vehículo no tripulado
US10403161B1 (en) Interface for accessing airspace data
US11900823B2 (en) Systems and methods for computing flight controls for vehicle landing
RU2568510C1 (ru) Безопасная вынужденная посадка беспилотного летательного аппарата
ES2908842T3 (es) Método para el control autónomo de un vehículo aéreo y sistema correspondiente
ES2771456T3 (es) Sistema de seguimiento para aeronaves no tripuladas
US11161611B2 (en) Methods and systems for aircraft collision avoidance
US11619953B2 (en) Three dimensional aircraft autonomous navigation under constraints
CN111650958B (zh) 一种固定翼无人机起飞段切入航路点的在线路径规划方法
US8897931B2 (en) Flight interpreter for captive carry unmanned aircraft systems demonstration
CN107108022A (zh) 用于控制和限制无人机系统(uas)操作的监管安全系统
EP3866138A1 (en) Systems and methods for automated cross-vehicle navigation using sensor data fusion
JP2009515771A (ja) 自動上空旋回飛行のための制御システム
US10502584B1 (en) Mission monitor and controller for autonomous unmanned vehicles
WO2017021955A1 (en) Constraints driven autonomous aircraft navigation
EP3792896A1 (en) Automatic descent method for an aircraft from supersonic regime and associated system
Mejias et al. Controlled emergency landing of an unpowered unmanned aerial system
Keshmiri et al. Flight test validation of collision and obstacle avoidance in fixed-wing UASs with high speeds using morphing potential field
JP5166349B2 (ja) 固定翼機、固定翼機システムおよび固定翼機の着陸方法
Jantawong et al. Automatic landing control based on GPS for fixed-wing aircraft
US20230206774A1 (en) Method and system for assisting with the approach of an aircraft with a view to landing
MX2008006166A (es) Sistema de control para vuelo automatico en circulo