23/05/2023, 18:16 Visão Geral da Arquitetura PX4 | Guia do usuário do PX4

Visão geral da arquitetura do PX4

O PX4 consiste em duas camadas principais: a pilha de voo é um sistema de estimativa e
controle de voo, e o middleware é uma camada de robótica geral que pode suportar
qualquer tipo de robô autônomo, fornecendo comunicações internas/externas e
integração de hardware.

Todas as fuselagens PX4 compartilham uma única base de código (isso inclui outros
sistemas robóticos como barcos, rovers, submarinos etc.). O design completo do sistema é
reativo , o que significa que:

Toda a funcionalidade é dividida em componentes trocáveis ​e reutilizáveis

A comunicação é feita por passagem assíncrona de mensagens
O sistema pode lidar com carga de trabalho variável

Arquitetura de software de alto nível

O diagrama abaixo fornece uma visão geral detalhada dos blocos de construção do PX4. A
parte superior do diagrama contém blocos de middleware, enquanto a seção inferior
mostra os componentes da pilha de voo.

https://docs.px4.io/main/en/concept/architecture.html 1/7
23/05/2023, 18:16 Visão Geral da Arquitetura PX4 | Guia do usuário do PX4

Storage
Database Parameters Logging

dataman param logger

Missions / Geofence EEPROM / SD Card / To SD Card or via
to SD Card / RAM FLASH MAVLink

External Drivers
Connectivity
Camera Control Gimbal / Mount
MAVLink
camera_trigger gimbal
mavlink

Message Bus GPS Airspeed, Telemetry,

via UART / UDP
Optical Flow,
uORB gps Distance Sensor, ...
FastRTPS
RC Input IMU Drivers
micrortps_bridge
rc_input / px4io /
CDR serialization via ...
UART / UDP PPM / SBUS / DSM  /
via SPI, UAVCAN, I2C
SUMD / ST24

Flight Control RC Handling

State Machine Autonomous Flight   RC rc_update ->

manual_control
commander navigator
Raw IMU data,
Mode Switching / Airspeed
Missions / RTL / ...
Arming / ...
Sensors Hub
Position
Setpoints
sensors
Position Controller Handle failover and
transform sensor data
mc_pos_control /
fw_pos_control_l1
IMU data,
Airspeed

Attitude
Position & Attitude
Setpoints Estimator
ekf2 / GPS,
Attitude & Rate attitude_estimator_q Optical
Controller Flow,
Distance
mc_att_control & Gyro data
mc_rate_control /
fw_att_control /
vtol_att_control

Thrust and Torque

Setpoints

Control Allocation

control_allocator

Mixing

Motor and Servo

Setpoints

Output Driver
pwm_out / px4io /
...

ESC / Servo control

PWM / UART / CAN / ...

https://docs.px4.io/main/en/concept/architecture.html 2/7
23/05/2023, 18:16 Visão Geral da Arquitetura PX4 | Guia do usuário do PX4

O código-fonte é dividido em módulos/programas independentes (mostrado no

monospace diagrama). Normalmente, um bloco de construção corresponde a exatamente
um módulo.

DICA

Em tempo de execução, você pode inspecionar quais módulos são executados com
o top comando no shell, e cada módulo pode ser iniciado/parado
individualmente via <module_name> start/stop . Embora top o comando seja
específico do shell NuttX, os outros comandos também podem ser usados ​no shell
SITL (pxh>). Para obter mais informações sobre cada um desses módulos, consulte
a Referência de Módulos e Comandos .

As setas mostram o fluxo de informações para as conexões mais importantes entre os

módulos. Na realidade, existem muito mais conexões do que as mostradas e alguns dados
(por exemplo, para parâmetros) são acessados ​pela maioria dos módulos.

Os módulos se comunicam entre si por meio de um barramento de mensagens de

publicação-assinatura denominado uORB . O uso do esquema de publicação-assinatura
significa que:

O sistema é reativo — é assíncrono e será atualizado instantaneamente quando novos

dados estiverem disponíveis
Todas as operações e comunicações são totalmente paralelizadas
Um componente do sistema pode consumir dados de qualquer lugar de maneira
thread-safe

Observação

Essa arquitetura permite que cada um desses blocos seja substituído de forma
rápida e fácil, mesmo em tempo de execução.

Pilha de voo
A pilha de voo é uma coleção de algoritmos de orientação, navegação e controle para
drones autônomos. Inclui controladores para fuselagens de asa fixa, multirotor e VTOL,
bem como estimadores de atitude e posição.

https://docs.px4.io/main/en/concept/architecture.html 3/7
23/05/2023, 18:16 Visão Geral da Arquitetura PX4 | Guia do usuário do PX4

O diagrama a seguir mostra uma visão geral dos blocos de construção da pilha de voo. Ele
contém o pipeline completo de sensores, entrada RC e controle de voo autônomo
(Navegador), até o motor ou servocontrole (Atuadores).

Position & Attitude

Sensors
Estimator

Attitude & Rate

Navigator Position Controller Mixer Actuator
Controller

RC

Um estimador recebe uma ou mais entradas de sensor, combina-as e calcula o estado do

veículo (por exemplo, a atitude dos dados do sensor IMU).

Um controlador é um componente que recebe um ponto de ajuste e uma medição ou

estado estimado (variável de processo) como entrada. Seu objetivo é ajustar o valor da
variável de processo de forma que coincida com o setpoint. A saída é uma correção para
eventualmente atingir esse ponto de ajuste. Por exemplo, o controlador de posição
assume pontos de ajuste de posição como entradas, a variável de processo é a posição
estimada atualmente e a saída é um ponto de ajuste de atitude e impulso que move o
veículo em direção à posição desejada.

Um misturador recebe comandos de força (como "virar à direita") e os traduz em

comandos individuais do motor, garantindo que alguns limites não sejam excedidos. Essa
translação é específica para um tipo de veículo e depende de vários fatores, como o
arranjo do motor em relação ao centro de gravidade ou a inércia rotacional do veículo.

Middleware
O middleware consiste principalmente em drivers de dispositivos para sensores
embutidos, comunicação com o mundo externo (computador complementar, GCS, etc.) e o
barramento de mensagens de publicação-assinatura uORB.

Além disso, o middleware inclui uma camada de simulação que permite que o código de
voo PX4 seja executado em um sistema operacional de desktop e controle um veículo
modelado por computador em um "mundo" simulado.

Taxas de atualização

https://docs.px4.io/main/en/concept/architecture.html 4/7
23/05/2023, 18:16 Visão Geral da Arquitetura PX4 | Guia do usuário do PX4

Como os módulos aguardam atualizações de mensagens, normalmente os drivers definem

a rapidez com que um módulo é atualizado. A maioria dos drivers IMU amostra os dados
em 1kHz, integra-os e publica com 250Hz. Outras partes do sistema, como o navigator ,
não precisam de uma taxa de atualização tão alta e, portanto, são consideravelmente mais
lentas.

As taxas de atualização de mensagens podem ser inspecionadas em tempo real no

sistema executando uorb top .

Ambiente de execução
O PX4 é executado em vários sistemas operacionais que fornecem uma API POSIX (como
Linux, macOS, NuttX ou QuRT). Também deve ter alguma forma de agendamento em
tempo real (por exemplo, FIFO).

A comunicação entre módulos (usando uORB ) é baseada em memória compartilhada.

Todo o middleware PX4 roda em um único espaço de endereço, ou seja, a memória é
compartilhada entre todos os módulos.

Observação

O sistema foi projetado de forma que, com o mínimo de esforço, seja possível
executar cada módulo em um espaço de endereço separado (as partes que
precisariam ser alteradas incluem uORB , e ). parameter
interface dataman perf

Existem 2 maneiras diferentes de executar um módulo:

Tarefas : O módulo é executado em sua própria tarefa com sua própria pilha e
prioridade de processo.

Tarefas da fila de trabalho : o módulo é executado em uma fila de trabalho

compartilhada, compartilhando a mesma pilha e prioridade de encadeamento da fila de
trabalho que outros módulos na fila.

Todas as tarefas devem se comportar de forma cooperativa, pois não podem

interromper umas às outras.
Várias tarefas da fila de trabalho podem ser executadas em uma fila e pode haver
várias filas.

https://docs.px4.io/main/en/concept/architecture.html 5/7
23/05/2023, 18:16 Visão Geral da Arquitetura PX4 | Guia do usuário do PX4

Uma tarefa da fila de trabalho é agendada especificando um horário fixo no futuro ou

por meio do retorno de chamada de atualização do tópico uORB.

A vantagem de executar módulos em uma fila de trabalho é que ela usa menos RAM e
potencialmente resulta em menos alternâncias de tarefas. As desvantagens são que as
tarefas da fila de trabalho não têm permissão para dormir ou sondar uma mensagem ou
bloquear IO (como a leitura de um arquivo). Tarefas de execução longa (realizando
computação pesada) também devem ser executadas em uma tarefa separada ou, pelo
menos, em uma fila de trabalho separada.

Observação

Tarefas em execução em uma fila de trabalho não aparecem em top (somente as

próprias filas de trabalho podem ser vistas - por exemplo, como wq:lp_default ).
Use work_queue status para exibir todos os itens ativos da fila de trabalho.

Tarefas em segundo plano

px4_task_spawn_cmd() é usado para iniciar novas tarefas (NuttX) ou threads (POSIX -
Linux/macOS) que são executados independentemente da tarefa de chamada (pai):

independent_task = px4_task_spawn_cmd(
"commander", // Process name
SCHED_DEFAULT, // Scheduling type (RR or FIFO)
SCHED_PRIORITY_DEFAULT + 40, // Scheduling priority
3600, // Stack size of the new task or thread
commander_thread_main, // Task (or thread) main function
(char * const *)&argv[0] // Void pointer to pass to the new task
// (here the commandline arguments).
);

Informações específicas do sistema operacional

NuttX

NuttX é o RTOS principal para executar o PX4 em uma placa de controle de voo. É de
código aberto (licença BSD), leve, eficiente e muito estável.

https://docs.px4.io/main/en/concept/architecture.html 6/7
23/05/2023, 18:16 Visão Geral da Arquitetura PX4 | Guia do usuário do PX4

Os módulos são executados como tarefas: eles têm suas próprias listas de descritores de
arquivo, mas compartilham um único espaço de endereço. Uma tarefa ainda pode iniciar
um ou mais encadeamentos que compartilham a lista de descritores de arquivo.

Cada tarefa/thread tem uma pilha de tamanho fixo e há uma tarefa periódica que verifica
se todas as pilhas têm espaço livre suficiente (com base na coloração da pilha).

Linux/macOS

No Linux ou macOS, o PX4 roda em um único processo, e os módulos rodam em suas

próprias threads (não há distinção entre tarefas e threads como no NuttX).

Edite esta página no GitHub

Última atualização: 23/03/2023, 06:24:09

https://docs.px4.io/main/en/concept/architecture.html 7/7