This is probably not what you are looking for, but I've been working on some "simpler" (sorta?) firmware built on top of the ardupilot library/hal. I've only tested on a pixracer, but it should work on any ardupilot supported device. My firmware can do straight pass through to the servo outputs, it can do onboard mixing, it can do onboard gyro stabalization (prior to mixing, so works with vtails and elevons, etc.) It can output the pilot stick inputs via a simple serial protocol to a host (or companion) computer like the arduino. It is a work in progress, the code is currently going through some transition as I restructure some tihngs (in the telem branch), I've been developing and flying on this code since the mid-2000's. Happy to answer questions if anyone is interested. I'm sure if you ask on the ardupilot forum, ardupilot itself can also do all these things if you dig into the details.
Here's my flight controller firmware code:
https://github.com/RiceCreekUAS/rc-fmu-ap/tree/main
The communication protocol is kinda like a mavlink-lite (conceptually) without needing code for 100's of fancy packet types. You can define the packets you want to use with a simple json file, and then a script autogenerates a C++ header and also a python module so you can easily (and efficiently) pack/unpack messages. Coding communication by hand is not difficult, but it is tedious and brittle to changes, so this helps me a ton:
https://github.com/RiceCreekUAS/rc-messages
And one more important bit. The code is structured around sharing all the important data/state within the program using something called a property tree -- which is a 1-to-1 match with json, but provided via a convenient interface in C and python. There is even a way to write hybrid python/C++ apps that share data through a common property tree. I like developing around this design style, but for sure there are many other good ways to do things.
https://github.com/RiceCreekUAS/props2
And to make communication slightly easier, if you pick message field names that match the field names in the property tree (by agreeing with yourself to develop your code this way) then the messaging system can generate code to pack a message directly from the property tree, or unpack a message into the property tree. So the nice thing about that is you can receive and unpack a message in like 4 lines of code, and then data is there for the rest of your app to use.
The property tree is not thread safe (or ISR safe) so keep that in mind if you try it out in your code. I'm a big fan of a single main loop style of coding to keep thing as simple and understandable as I can.
On the subject of sbus vs. arduino. Sbus uses an inverted serial protocol (100,000 baud.) Arduino can support 100k baud, but you'll need a logical inverter on the signal line. You can get these for a couple $ -- at least before all the supply chain disruptions -- and it just plugs inline with RC style connectors. Otherwise if you pick a teensy instead of an arduino, these support inverted serial directly so you can plug your sbus right in.
Here is the arduino sbus library I was flying with for a few years (prior to porting all my stuff over top of ardupilot's library/hal layer and using their rcin library.)
https://github.com/RiceCreekUAS/rc-fmu-arduino/tree/master/src/sensors/sbus
Sorry for such a huge data dump all at once, I know it's a lot, but if any of this looks interesting, please feel free to ask questions. I'm happy to share whatever I know...
Random closing thought:
I ended up using the ardupilot library/hal like a fancy arduino development environment that already had support for all the interesting flight controllers and devices. It would be some extra work up front to get up to speed with their build system and api's, but you could do the same thing and not even need the external arduino board. There are always many many good ways to do things, so please carry on with what makes the most sense to you, just thinking out loud here ...
Good luck, these sorts of projects provide tremendous unbounded learning experiences, but be careful ... it's easy to get obsessed with it all!
Curt.