88d623bedb
* Add vitepress tree * Update existing workflows so they dont trigger on changes in the docs path * Add nojekyll, package.json, LICENCE etc * Add crowdin docs upload/download scripts * Add docs flaw checker workflows * Used docs prefix for docs workflows * Crowdin obvious fixes * ci: docs move to self hosted runner runs on a beefy server for faster builds Signed-off-by: Ramon Roche <mrpollo@gmail.com> * ci: don't run build action for docs or ci changes Signed-off-by: Ramon Roche <mrpollo@gmail.com> * ci: update runners Signed-off-by: Ramon Roche <mrpollo@gmail.com> * Add docs/en * Add docs assets and scripts * Fix up editlinks to point to PX4 sources * Download just the translations that are supported * Add translation sources for zh, uk, ko * Update latest tranlsation and uorb graphs * update vitepress to latest --------- Signed-off-by: Ramon Roche <mrpollo@gmail.com> Co-authored-by: Ramon Roche <mrpollo@gmail.com>
3.9 KiB
PX4 System Architecture
The sections below provide high-level overview of the PX4 hardware and software stack for two "typical" PX4 systems; one that has just a flight controller, and another that has a flight controller and a companion computer (also known as a "mission computer").
::: info The PX4 Architectural Overview provides information about the flight stack and middleware. Offboard APIs are covered in ROS and MAVSDK. :::
Flight Controller (only)
The diagram below provides a high level overview of a typical "simple" PX4 system based around a flight controller.
The hardware consists of
- Flight controller (running the PX4 flight stack). This often includes internal IMUs, compass and barometer.
- Motor ESCs connected to PWM outputs, DroneCAN (DroneCAN allows two-way communication, not single direction as shown) or some other bus.
- Sensors (GPS, compass, distance sensors, barometers, optical flow, barometers, ADSB transponders, etc.) connected via I2C, SPI, CAN, UART etc.
- Camera or other payload. Cameras can be connected to PWM outputs or via MAVLink.
- Telemetry radios for connecting to a ground station computer/software.
- RC Control System for manual control
The left hand side of the diagram shows the software stack, which is horizontally aligned (approximately) with the hardware parts of the diagram.
- The ground station computer typically runs QGroundControl (or some other ground station software). It may also run robotics software like MAVSDK or ROS.
- The PX4 flight stack running on the flight controller includes drivers, comms modules, controllers, estimators and other middleware and system modules.
FC and Companion Computer
The diagram below shows a PX4 system that includes both a flight controller and a companion computer (here referred to as a "mission computer").
The flight controller runs the normal PX4 flight stack, while a companion computer provides advanced features that utilise computer vision. The two systems are connected using a fast serial or IP link, and typically communicate using the MAVLink protocol. Communications with the ground stations and the cloud are usually routed via the companion computer (e.g. using the MAVLink Router (from Intel)).
PX4 systems typically run a Linux OS on the companion computer. Linux is a much better platform for "general" software development than NuttX; there are many more Linux developers and a lot of useful software has already been written (e.g. for computer vision, communications, cloud integrations, hardware drivers). Companion computers sometimes run Android for the same reason.
::: info The diagram shows a cloud or ground station connection via LTE, an approach that has been used a number of PX4-based systems. PX4 does not deliver software specifically for LTE and/or cloud integration (this requires custom development). :::