Refresh system architecture diagram

[mrpollo]

The current system architecture diagram, while still accurate, might not fully represent the actual capabilities of PX4, and it might be worth updating to present the newer additions and capabilities, including the custom flight modes, thanks to the uXRCE-DDS interface and the ROS 2 interface library.

Mostly, what I think should taken into account is that most modern drone topologies include a mission computer and a flight controller and that a pure "flight controller only" architecture is now the exception.

https://docs.px4.io/main/en/concept/px4_systems_architecture.html

[hamishwillee]

A bit of a whinge

My concern with this is that if we present the topology of FC (RTOS) + App layer compute (Mission computer) "first" then people are going to be very surprised about how "not turnkey" that option is when working with PX4.

That makes me uncomfortable, particularly as nothing else about PX4 supports this priority - we don't have much (if any) ROS-side code, we don't have a reference platform for this architecture, we don't test any code we do have full stack in the same way as we do PX4 on SITL and Pixhawk. The docs are very PX4 setup centric - probably because companion setup is not at all standardized, except PX4 side.

I guess we could move in this direction though. We do need to support this case better, and why not here.

Further down the page we have a section that broadly covers the architecture you are talking about: https://docs.px4.io/main/en/concept/px4_systems_architecture.html#fc-and-companion-computer

As a small start we might put that section first, updating the image to state how ROS connects them. We might refer to this as "Advanced Drone Architecture" or similar and explain that drones are moving towards this architecture and what PX4 does to support it - including info about ROS2 and the inbuilt modes for referencing the interface layer. Maybe also about things like MAVLink cameras, which are pass through into companions.

Then the stand alone PX4 would appear second.

Does this make sense?

• Other than custom flight modes, what do you think we have that supports this topology?
• Did you have any other thought on what you wanted?
• Were you expecting anyone in particular (other than me) to act on this?

[bkueng]

I agree with your points. I still think it makes sense to move into that direction, especially now that we have boards like the ARK Jetson.

I'm thinking something into this direction (not too different from what we have, but I think it better displays how things integrate):

[hamishwillee]

@bkueng That's great.

The only thing that I immediately questioned was the companion peripherals, which look "a bit" like they are connected to ROS2. Not sure that we need the image to show how they are connected, but shouldn't imply the wrong connection.

Do you have a source for that image? SVG/other?

I'll position it as you guys want. Let's get a solid story on turnkey mission computer setup so I'm not lying. A couple of useful real-work ROS2 modes with CI would go a long way towards that.

[hamishwillee]

@mrpollo @bkueng A question on terminology - this relates to both this PR and the flight modes.

We make a distinction between a companion computer running "some flight code" on a desktop OS (Ubuntu Linux), and a flight controller running PX4 flight stack on an RTOS (NuttX).
We're now moving towards integrated systems where both are present on the same base board. Something like Snapdragon Flight runs the RTOS runs on a DSP and the companion software runs on the main processor. They aren't separate, and the terms are particularly intuitive.

In addition, we currently have a clear name for code that runs on the FC - "PX4 flight stack". But what should we call the part of the code that runs on the companion IF it is part of the core offering. Arguably everything is part of the PX4 flight stack at that point!
More specifically, I have a mode written in PX4 and a mode written on ROS2 using the control library - if PX4 extends to the computer then how do I refer to the PX4 mode running on the RTOS part - "not a ROS2 mode"?

The only name we really need right now is something clear for "companion". But would appreciate your thoughts on whether this terminology provides a good path?

• Flight Controller (FC) - unchanged.

  • defined to always mean the RTOS running hardware even in future.
  • I'd love to call it "RTOS computer" but people know what an FC is now - too deeply embedded.

• General Computer (GC) -> replacing mission, offboard, onboard, companion.

  • offboard implies "on ground", companion implies "separate", "mission" implies "mission executing, and that's what PX4 does".
  • onboard is ok as it implies "on vehicle" but also implies that it is separate.
  • What we want here is something that implies: general computing not RTOS, can run higher level languages. But I'd like to avoid "controlling".

• Autopilot - the FC or FC + General - i.e. the brain as a whole.

• PX4 GC Flight Stack - PX4 code on General computer

• PX4 Full Flight Stack - PX4 code in RTOS and General Computer - When we need to disambiguate that we mean "FC + general compute"

• PX4 Flight Stack - Full stack or just RTOS stack, depending on context. What this means is that we don't change anything for now.

• PX4 FC Flight Stack - PX4 code on FC

  • when we need to clearly mean "on FC"
  • We could say PX4 RTOS Flight Stack instead, or something else?

So we might say "PX4 ROS 2 modes are part of the PX4 GC code", "The PX4 Full Stack includes flight modes running on both the FC and GC parts of the autopilot".

[bkueng]

Do you have a source for that image? SVG/other?

It's on draw.io, I gave you access. It's really only a draft, so feel free to edit as you see fit.
https://drive.google.com/file/d/1aNCXHWxcJH6b_4JinuReurxOVlogpFga/view?usp=sharing

We're now moving towards integrated systems where both are present on the same base board. Something like Snapdragon Flight runs the RTOS runs on a DSP and the companion software runs on the main processor. They aren't separate, and the terms are particularly intuitive.

Yes Snapdragon deviates a bit, but conceptually there's not too much of a difference, except that there's shared memory between the FC and companion, and some PX4 modules run on the Linux side. I.e. there's still separate processors.
Another example that deviates would be a Rasperry Pi with a Navio hat that runs PX4 on Linux.

Naming does get increasingly blurry, and your suggestion makes sense.

[hamishwillee]

Just FYI, done a minor iteration of this to match style of existing image (in progress). The main difference is that this pulls out MAVLink payloads and also lists them along with sensors and peripherals. Might revert it - did it so I can talk about MAVLink peripherals vs peripherals for which we provide a mavlink interface in the companion.

Also shows data path to cloud. Might remove that too - Just FMI how do we implement that? I assume that perhaps if you have an LTE/radio connection in Linux it just looks like an IP network - so you use different ports to talk to the Internet vs your QGC?

Mostly just posted this to let you know I'm still thinking about it.

[mrpollo]

@hamishwillee I agree with the direction you are going with this, I woudl keep the additions, moreover I will gladly polish the diagram for you if you give me access.

One think to point out, is this is the perfect opportunity to list out all the top level projects under Droneode. PX4, MAVLink, MAVSDK, QGC, and Pixhawk. With only Pixhawk missing here, but we can definetly list this.

[hamishwillee]

Hi @mrpollo, I've emailed you a link to edit on your gmail. All edits welcome. It is impossible to capture all possible setups here, which is why I might show a little less and explain more in text.

[mrpollo]

I agree with your approach @hamishwillee, I will take a shot at updating the diagram and share here for discussion. I also think its a great opportunity to expand in text what each section represents with proper links for more info.