Creating a computer to fly at Mach 2.5 and above.

So, the aircraft’s rough shapes are ready. And I have also realized the severely high level of dual purpose use that this aircraft can offer. Until I can create an aircraft shape that can be insulated from being adapted for defense purposes, I intend to keep most of that work a secret.

What is all the fuss about then?

Last year, I grew an interest in HyperVector and High Dimensional Computing, especially used in neuromorphic computing. After thinking about it, I decided to make an implementation of it for my own use, in a Home AI system called WONG-I. The system named after Dr. Strange’s assistant and the librarian of Kamar Taj, was supposed to be just like him, extremely knowledgeable, reliable and be able to adapt and assist no matter what. After relying on friends and family who shared similar interests as me, I decided to make it on my own as I was way more determined to make it as well as way more passionate about the technology and its uses in my home. Then came with it a Phased Array Radar, a thermal management system for a completely new discrete computing standard and other things including a sensor suite and optimized operating systems and other ancillary sensor suites, systems and support structures that were needed.

Okay sure, but how is a passion-project relevant to this Aircraft?

Well, the co-relation is multifold. But it is mainly related to the fact that I have been working on mainframe and ancillary computers for quite a while and had to make one for this aircraft. At Mach 2.5, the plane has to make a large number of decisions itself. I as the pilot will not have the reflexes, strength and mental processing capacity to fly the aircraft without dying, it is impossible and also delusional. Either way, what is important to know is that the aircraft needs to be immaculate about its processing and the timeframe needed to execute commands and most importantly troubleshoot its way through issues at Mach 2.5

So, here’s the deal.

I am going to need to make ancillary systems that communicate over a CAN or LAN, I will need to have future-proof computing standards that can be expanded as the testing features and functions of the aircraft increase and way to make it largely autonomous without creating large issues when controlling the aircraft with a remote or command module.

Firstly, I thought of the PCIe standard to create drop-in modules that housed a combination of discrete semiconductors; anything from I/O and signal processing to data processing and flight management. But, it turned out to be quite restrictive to implement. So, I decided to use SRIO, a comparatively much more open standard that allows me much higher data transfer rates although there are definitely more challenges to it than just finding the right one.

Next, I had to follow-up with a RTOS. Unlike Windows or macOS, operating systems on aircrafts need to be much more accurate about timing, resource management and constraints as well execution timeframes and other things. In layman’s terms, a RTOS is like a warden and servant all in one, where as other operating systems are much more like hotel room service; they focus on opulence and elegance at the cost of time, money, survival and other things.

I am deciding to use Zephyr RTOS and then as the system keeps getting complex, add-in more “cards” and compute modules that run a custom OS I built for the aircraft with the sole purpose of multi-mach flight.

Now that I have committed worse crimes than murder, the decision to work in C and C++, I must take your leave, ‘O’ Reader! And commit myself to the dark shadows of hell called C and C++ documentation.

Ciao!


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *