Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to understand the PX4/Pixhawk flight control software architecture, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

1. Brief introduction of PX4 software architecture.

PX4 is one of the most popular open source flight control boards. The software system of PX4 is actually a firmware, and its core OS is NuttX (http://www.nuttx.org/) real-time ARM system). The firmware also comes with a series of tool sets, system drivers / modules and peripheral software interface layers. all these software (including user-defined flight control software) are compiled into firmware along with the OS kernel, and then uploaded to the flight control board to realize the software configuration of the flight control board.

The software architecture of PX4 is mainly divided into four layers. Understanding its software architecture is the basis of developing user-defined flight control application software.

A) API layer: this is easy to understand.

B) Framework layer: contains default assemblies (nodes) for operating basic flight control

C) system library: contains all system libraries and basic traffic control functions

D) OS kernel: provides hardware drivers, network, UAVCAN, and fail-safe systems

The above is a relatively specific software architecture for PX4 system implementers. In fact, there is another high-level software architecture description for PX4 custom flight control application developers, which is relatively abstract, but simpler, that is, the entire PX4 software is divided into two layers as a whole:

A) PX4 flight stack: a collection of automatic control algorithms for autonomous UAV

B) PX4 Middleware: a collection of drivers, underlying communication and scheduling mechanisms for UAV controllers, sensors and other physical devices

The most interesting aspect of PX4 software architecture is the abstraction (polymorphism) of the architecture as a whole. That is, in order to maximize the reusability of the flight control algorithm code, it decouples the flight control logic with the specific underlying controller instructions. A set of high-level flight control algorithms (such as autopilot, GeoFence, etc.) can be applied to fixed-wing, helicopter, multi-rotor and other aircraft control situations without significant modification, which reflects the power of PX4 flight control: after the user program has been written, if you need to replace the UAV rack, you only need to simply modify the rack configuration parameters, and there is almost no need to modify the high-level user-defined flight control application.

It is important to understand the above original intention. Many people who come from automation and don't have much software experience tend to use the underlying control protocol to control the flight control board directly, but in fact, the PX4 architecture has provided a better choice at a higher level of abstraction, both code maintenance costs, development efficiency and hardware compatibility are significantly higher than the former. The main reason for many developers who support the former is that the efficiency of the high-level encapsulation mechanism is low, and the performance of the flight control board is not enough, which is easy to cause a large processing load on the flight control board, but in fact, from a personal point of view, it is easier to achieve higher processing performance by following the software architecture model of PX4, which is not easy to cause control congestion and improve the concurrent processing efficiency of the UAV side system.

2. PX4 control protocol and logic

Mavlink is one of the most common UAV flight control protocols. PX4 provides good native support for Mavlink protocol. The protocol can be used not only for the control of unmanned aerial vehicle (UAV) by ground station (GCS), but also for the information feedback of UAV to GCS. The flight control scene generally looks like this:

A) Manual flight control: GCS-> (MavLink)-> UAV

B) Information collection: GCS UAV

In other words, if you want to implement the ground station to control the flight, then your ground station uses the Mavlink protocol through the radio frequency channel (or wifi etc.) Just send control commands to the drone. If you want to enable the UAV to fly independently, then your own application (running on the UAV system) can use the Mavlink protocol to send local control commands to the UAV.

However, in order to achieve the flexibility of the flight control architecture and avoid relying on the underlying implementation details, PX4 does not encourage developers to directly use Mavlink in custom flight control programs, but encourages developers to use a messaging mechanism called uORB ((Micro Object Request Broker, micro-object request broker). In fact, uORB is conceptually equivalent to named pipes (named pipe) in posix, which is essentially an inter-process communication mechanism. Because PX4 actually uses NuttX real-time ARM system, uORB is actually equivalent to multiple processes (driver-level module) opening the same device file, and multiple processes (driver-level module) exchange and share data through this file node.

In the uORB mechanism, the messages exchanged are called topic, and a topic contains only one message type (that is, data structures). Each process (or driver module) can "subscribe" or "publish" multiple topic, a topic can have multiple publishers, and a subscriber can also subscribe to multiple topic. Because of the existence of the uORB mechanism, the above flight control scenario becomes:

A) Manual flight control: GCS-> (MavLink)-> (uORB topic)-> UAV

B) Information collection: GCS UAV

With the above background, you can write your own flight control logic. Just add a custom module to the PX4 source code, then use uORB to subscribe to relevant information (such as sensor messages, etc.), and publish relevant control information (such as flight mode control messages, etc.). Specific uORB API, uORB message definition can refer to PX4 documentation and source code, all control commands are in the msg of firmware code, no longer elaborate.

Finally, it is worth mentioning that in the PX4 system, it also provides a dedicated module named mavlink, and the source code is in firmware's src/modules/mavlink, which is quite similar to linux's console command toolset, which can be used as a command under the ntt console or as a system module to load and run in the background.

The features implemented include:

1) uORB message parsing, which actually translates uORB messages into specific Mavlink underlying instructions, or vice versa.

2) obtaining or sending Mavlink messages through serial/ radio frequency communication interface not only takes into account the development mode of user-written programs, but also applies to the script tool chain development mode similar to linux, which is very flexible to use.

After reading the above, do you have any further understanding of how to understand the PX4/Pixhawk flight control software architecture? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.