If you have done Ardupilot or Arduino source code development, the first thing you do when you clone source code from Github is probably looking for the main function. This is exactly what I did. I spent about 2 weeks looking for a main function, hoping to stumble across something that initializes everything, execute commands in a loop. But nothing in the source code looks even close to this. PX4 has a much more powerful architecture, it doesn’t rely on a single main function. And here is how it works.
Note: Since this is a first look at PX4 architecture, everything will be very high level. For lower level architecture, please wait…
A quick summary:
- The example code
- A very high level overview
- NSH initializing script
1. The example code
The “writing an application” tutorial on the official PX4 development guide is actually very useful, and it is definitely the first thing anybody should do. Follow the instructions on this page: Writing an Application
I will make extensive references to this example application in this and future logs.
2. A very high level overview
The best explanation is, PX4 works just like a Linux operating system. The system initializes according to the rules in a NSH script. The script will start all essential applications at boot, which I will talk about in section 4. Once the system is initialized, you can run many different small applications that are each dedicated for a small task. All of these applications are included in the “Firmware/src/modules” directory.
For a multicopter, some significant applications are “mc_att_control” (multicopter attitude control), “mc_pos_control” (multicopter position control), “attitude_estimator_q” (q stands for quaternion based). If you have a quick scan at the source code of each application, you will see they all use these functions somewhere in the code:
This is the definitive feature that makes PX4 different to Ardupilot. The “orb” is actually “uORB”, which itself deserves a new section, in section 3. “uORB” will handle all the communications between applications, the communication messages are called “topics“, each topic usually contains relevant data in a structure. Applications can subscribe a topic from uORB, copy data within the topic, and use these data. The application can also modify these data and advertise to a topic, the data can then be published for other applications to subscribe and copy.
uORB stands for “micro Object Request Broker”. uORB handles messaging API used for inter-thread/inter-process communication. In simple words, if an application wants to communicate with another application, it has to go through uORB.