Hypothetical question on Avionics in BMS
-
@MartinGecko and @sasah320 … I am (or was) a C++ expert and wish I wasn’t. So if someday scientists figure out how to achieve a vulkan mind-meld … hit me up. lol
I consider those early years (~a decade) of my career to be a gigantic waste… the productivity of modern languages (C# or Java … or Python etc) is about 20x greater… and performance only a few % slower… I sincerely recommend to start with one of those, for anyone intent on learning software development.
The goal is to help the Devs… If C++ is what they need, C++ it is. But I am afraid we have to wait to Warp Drive to be available so I can go to Vulcan and hire somebody there to mind-meld us… maybe it takes a little long… :eyebrows:
-
the productivity of modern languages (C# or Java … or Python etc) is about 20x greater… and performance only a few % slower… I sincerely recommend to start with one of those, for anyone intent on learning software development.
I should probably amend that to mention Rust? Gaining a lot of popularity in the past year… and it’s actually much more C/C++ like than C#/Java/Python. (No garbage collection … ownership of memory-allocation is explicitly modelled in the language.)
I haven’t done anything with it, so can’t personally recommend it, but … well I’m actually a little bitter, it looks pretty close to the language of my dreams, back when I was doing a lot of C/C++ work.
And, I haven’t heard anybody else say this, but it might be a good on-ramp, for backing into C++. Easier to learn, modern docs and samples (as opposed to 30 years of cruft and crap and diverging standards) and certainly internalizing core Rust concepts (like RAII, immutability, and ownership of memory-allocation) will help you write better, cleaner, safer C++ code if eventually you do go that path.
https://doc.rust-lang.org/rust-by-example/hello.html
Ok I’m WAYYY OT now, sorry.
-
I should probably amend that to mention Rust? Gaining a lot of popularity in the past year… and it’s actually much more C/C++ like than C#/Java/Python. (No garbage collection … ownership of memory-allocation is explicitly modelled in the language.)
I haven’t done anything with it, so can’t personally recommend it, but … well I’m actually a little bitter, it’s pretty close to the language of my dreams, back when I was doing a lot of C/C++ work.
And, I haven’t heard anybody else say this, but it might be a good on-ramp, backing into C++. Easier to learn, modern docs and samples (as opposed to 30 years of cruft and crap and diverging standards) and certainly internalizing core Rust concepts (like RAII, immutability, and ownership of memory-allocation) will help you write better, cleaner, safer C++ code if eventually you do go that path.
https://doc.rust-lang.org/rust-by-example/hello.html
Ok I’m WAYYY OT now, sorry.One word, Assembly…
-
As the saying goes: “C allows you to shoot yourself in the foot easily while C++ allows you to take your entire leg off.”
I did a lot of C back in the Amiga days (Manx Aztec C and Lattice C later on), my physics thesis involved C++ in the mid nineties because no money or pain in the world would force me to program in FORTRAN, but that’s about it. I’ve never really grasped the core concepts of C++ (if there are any core concepts shared between the various “standards” and dialects), and today I really prefer python & friends for the stuff I’m doing, it’s fast enough for my purposes. Rust is being discussed for entering the Linux kernel landscape, that should be interesting so the language sure is worth a 2nd look I’d wager.
All the best,
Uwe
-
One word, Assembly…
Anyone can write assembly.
Its easy to write C#, and its not hard to write decent C# that the compiler will fix. Writing good assembly is an art form that I doubt I’ll ever acquire.
-
One word, Assembly…
lol, I started to write, that C/C++ evolved in a time when the only other alternative was assembly – for 8- or 16-bit CPUs with a tiny handful of registers – so it seemed wonderful at the time, but now it’s so painful…
Not trying to sound so negative about it – I guess my point is we should all respect and appreciate the deep dedication of everyone on BMS team who is still fearlessly wrestling with this 20+ year-old C++ codebase!
-
There are three different FMs in BMS
OFM (legacy)
NFBW
AFMThey are all configurable to a certain extend from the data files.
Let’s be clear about that. From my point of view there is absolutely no need to externalise more the FMs.
In 12 years of AFM existence , noeone has created another one
I created f18 , mirage 2000, harrier and su33 that are still very rough v’but noeone took the stick to improve them
Point is: BMS already allows huge possibilities to create FMs from the data files , VERY detailed
FMs (just open an AFM file to understand), but this is a very complex task and so far noeone took it (for AFM)My advice : better focus on avionics , this is what is lacking .
-
(just open an AFM file to understand)
I had never really looked at one, before this thread. There’s a lot more detail in there than I expected, but I don’t know how to parse or interpret some of the more opaque tables of numbers…
How do the declarative FMs account for such widely different plane geometries and configurations (eg. a delta-wing w/ canards) vs the F-16?
I do see some obvious geometry params in the dat files (eg. for landing gear … and CG for fuel tanks and stores) but not much about size and location of control surfaces, flaps or speedbrake etc. But I certainly don’t know what all the various tables represent.
Or are all the various aero effects distilled down to just pitch-rate / roll-rate / drag-factor, et al, based on mach/altitude and control inputs…?
(Not trying to nitpick or be rhetorical, just genuinely curious. I really would have expected there would need to be some a/c-specific code behind each AFM file to compute aero effects on control surfaces / flaps / brake etc.)
But I agree, if it can all be done declaratively it’s better to have one or two codepaths to maintain and debug, than a few hundred.
Edit:
Thinking further about the physics calculations, we probably can’t ever truly know things like moment-of-inertia around the center axes, better than a rough approximation, for something as large and complex as a fighter plane (with rapidly spinning jet turbines!) so it probably doesn’t make much sense to try to model precise forces/torques of aero control surfaces… -
I had never really looked at one, before this thread. There’s a lot more detail in there than I expected, but I don’t know how to parse or interpret some of the more opaque tables of numbers…
How do the declarative FMs account for such widely different plane geometries and configurations (eg. a delta-wing w/ canards) vs the F-16?
I do see some obvious geometry params in the dat files (eg. for landing gear … and CG for fuel tanks and stores) but not much about size and location of control surfaces, flaps or speedbrake etc. But I certainly don’t know what all the various tables represent.
Or are all the various aero effects distilled down to just pitch-rate / roll-rate / drag-factor, et al, based on mach/altitude and control inputs…?
(Not trying to nitpick or be rhetorical, just genuinely curious. I really would have expected there would need to be some a/c-specific code behind each AFM file to compute aero effects on control surfaces / flaps / brake etc.)
But I agree, if it can all be done declaratively it’s better to have one or two codepaths to maintain and debug, than a few hundred.
Edit:
Thinking further about the physics calculations, we probably can’t ever truly know things like moment-of-inertia around the center axes, better than a rough approximation, for something as large and complex as a fighter plane (with rapidly spinning jet turbines!) so it probably doesn’t make much sense to try to model precise forces/torques of aero control surfaces…Ok you really need to read all the FM articles available in the Article section here on the website
You will understand that AFM is not based on a local model but on a NASA model from TP1538 which is the best model available for the F16.
Another FM model coexists in BMS, this is the local modeling that you can find if you open the A10 AFM file
Again BMS has already everything ready to make any flight model you want.
The only thing that could be better externalized is the FLCS. For now the FLCS can be tweaked from the AFM files
However to have a total different fLcs than the f16 you can’t do it outside the code
Right now the F18 or SU33 have a dedicated flcs but part of it is « hardcoded »
In short : externalizing aero module or mechanical module is done already.
Externalizing FLCS could be better
Please read all the FM articles
And again : priority is avionics , FM code is already ready
-
Ok you really need to read all the FM articles available in the Article section here on the website
Indeed thanks! I did not ever see those. Haven’t read through them all yet but I really like the way you captured all your thinking and design choices and considerations along the way … complete with clear, simple diagrams and illustrations … it is surprisingly easy reading for such a difficult topic. So, well done, sir.
-
are all the various aero effects distilled down to just pitch-rate / roll-rate / drag-factor, et al, based on mach/altitude and control inputs…?
(Not trying to nitpick or be rhetorical, just genuinely curious. I really would have expected there would need to be some a/c-specific code behind each AFM file to compute aero effects on control surfaces / flaps / brake etc.)
Depends how you approach the problem. More than one way to skin a cat! I seem to recall at least one other sim has a go at solving that kind of problem in real time, to a decent approximation - might have been xplane?
Thinking further about the physics calculations, we probably can’t ever truly know things like moment-of-inertia around the center axes, better than a rough approximation, for something as large and complex as a fighter plane (with rapidly spinning jet turbines!) so it probably doesn’t make much sense to try to model precise forces/torques of aero control surfaces…
What you can do instead is look at its observed performance and work backwards from that to find its torques and forces collectively. We already know the aircraft performance, from flight test data, so we don’t have to try make predictions we can’t test.
-
Depends how you approach the problem. More than one way to skin a cat! I seem to recall at least one other sim has a go at solving that kind of problem in real time, to a decent approximation - might have been xplane?
What you can do instead is look at its observed performance and work backwards from that to find its torques and forces collectively. We already know the aircraft performance, from flight test data, so we don’t have to try make predictions we can’t test.
For the f16 the inertia matrix is not approximated
-
You can do inertia modeling through simple geometry and weight/CG distributions, but the problem with a fighter is that there are so many different combinations/configurations that it can turn into a serious chore. I’ve flown Trainers that account for body inertia changes and it does make a serious difference that you can “feel” in the reactions of the airplane. That, and the effects of aerodynamic damping due to roll rate and such…but accounting for inertia - particularly as stores are released - really does stand out if you know what you are looking at.
…avionics is easier.
-
There are three different FMs in BMS
OFM (legacy)
NFBW
AFMThey are all configurable to a certain extend from the data files.
Let’s be clear about that. From my point of view there is absolutely no need to externalise more the FMs.
In 12 years of AFM existence , noeone has created another one
I created f18 , mirage 2000, harrier and su33 that are still very rough v’but noeone took the stick to improve them
Point is: BMS already allows huge possibilities to create FMs from the data files , VERY detailed
FMs (just open an AFM file to understand), but this is a very complex task and so far noeone took it (for AFM)My advice : better focus on avionics , this is what is lacking .
Hi, Mav,
I had never figured out (exactly) who had set up the Bug. Now that I know, I just wanted to thank you personally for the work you did on it, way back when. As I’ve written many times, you’ve given us a great foundation to work with.
And, personally, I agree with you. Avionics should be the focus on the Bug, and do what we can.
All, it’s a matter of prioritizing and time management. Assuming it can even be done, I feel there’s enough interest in the Hornet in BMS to make it worthwhile. I would certainly be on board with the Project. But, I just don’t see us having the time, manpower, or resources to do it for every jet in BMS, though I’d love to be proved wrong on that.
The Mafia is working on several theaters and with a lot of different jets. So, the first priority is to get working cockpits in them . A very good example of that is the new Viet Nam.
Let me just say…If anyone out there has a passion for flight modeling and wants to join the Mafia, they would be most welcome. -
Hi, Mav,
I had never figured out (exactly) who had set up the Bug. Now that I know, I just wanted to thank you personally for the work you did on it, way back when. As I’ve written many times, you’ve given us a great foundation to work with.
And, personally, I agree with you. Avionics should be the focus on the Bug, and do what we can.
All, it’s a matter of prioritizing and time management. Assuming it can even be done, I feel there’s enough interest in the Hornet in BMS to make it worthwhile. I would certainly be on board with the Project. But, I just don’t see us having the time, manpower, or resources to do it for every jet in BMS, though I’d love to be proved wrong on that.
The Mafia is working on several theaters and with a lot of different jets. So, the first priority is to get working cockpits in them . A very good example of that is the new Viet Nam.
Let me just say…If anyone out there has a passion for flight modeling and wants to join the Mafia, they would be most welcome.I think you can thank Mav for the whole of Nav Ops. Had a lot of fun with it when it was out first.
-
For the f16 the inertia matrix is not approximated
Perhaps I’ve done a poor job explaining what I meant, or perhaps I don’t understand the subject as well as I thought I did: I’ve tried to say that we could approximately determine the aircraft performance from knowing its shape and the movement of its control surfaces, but that this is not how its done in BMS; rather, that in BMS you have worked from knowing the actual performance, and calculating from that the aircraft behaviour.
Of course, you don’t need me to explain to you how it works in BMS! I was trying to explain to airtex how it works, but your knowledge here would obviously be more detailed than mine, and I’d welcome more detail, or corrections, on how it works.
You can do inertia modeling through simple geometry and weight/CG distributions, but the problem with a fighter is that there are so many different combinations/configurations that it can turn into a serious chore. I’ve flown Trainers that account for body inertia changes and it does make a serious difference that you can “feel” in the reactions of the airplane. That, and the effects of aerodynamic damping due to roll rate and such…but accounting for inertia - particularly as stores are released - really does stand out if you know what you are looking at.
…avionics is easier.
In this regard, BMS is the only sim I’ve ever thought had decent handling, and it has literally been the benchmark for me, against which all other flight sims are compared.
-
could approximately determine the aircraft performance from knowing its shape and the movement of its control surfaces, but that this is not how its done in BMS; rather, that in BMS you have worked from knowing the actual performance, and calculating from that the aircraft behaviour.
That is the top-line summary I took away from reading
https://www.benchmarksims.org/forum/content.php?135-Flight-Model-(FM)-Developer-s-Notes-Part-3(But there’s some implementation of the former approach too, in non-fly-by-wire a/c like the A-10.)
For the context of this thread … it can be noted, that there are some elements of the flight-model, such as FLCS behaviors/limits/overrides, and subtle things like ARI, and the blended pitch/aoa-control when in landing-gains, which may fall under the definition of “avionics” that one might want to model differently in non-F16 planes.
-
Hi all!
Pretty new in BMS lands here, enjoying taming the F16 and sincerely impressed on the devs work on it.
I write this post in order to share some humble thoughts and ideas about the possible implementation of the avionics of other planes than the F16. I know it’s a recurrent topic here with many older posts demanding it, but that is not my intention: I’m pretty happy with all the content we have for free.
I think that would be very interesting to have other avionics in BMS implementes in a so modular way that make possible for not only the BMS team to introduce new and complete hi fidelity planes, but also from small teams from the community (somewhat like third party planes in DCS but a la BMS).
The idea is to modularize avionics code (as far as I know is the “last but not least” thing missing to make that possible, correct me if I’m wrong) in a way that it’s possible to build an API that, in one hand, implements methods to allow the “plane” to recover info on demand and commit actions on the “core” (if needed) and, in the other hand, registering of callbacks for environment state awareness.I’ve mentioned “other avionics” but maybe is interesting to move it to the full scale “other planes”, as making them fully modular and depending the less possible from obscured systems on the “core” would be the best scenario. Not sure about that, because obviously I don’t have any knowledge about the BMS code, so I’m making maybe some far fetched guesses.
The new plane/avionics would then be send to BMS team for quality approval (or the proccess they want) and, then, included in the source code and compiled along the rest of the system. If the API is implemented in a way that allows it, maybe the third party plane could be implemented in other languages like Rust, in order to make it less C++ typical error prone and making the development easier, faster and clearer for third parties. That could be done with an abstract API, implemented by specific ones using C++ interoperability libs, one for each “approved” development language.
Anyway, I write that post not as a wish list. Although I don’t have experience with C++ outside some personal small projects, I’m a seasoned software developer and I’ve been looking around FreeFalcon code in order to see if that task is possible with that code without dying in the process and put my hands on it to try to make a draft of my ideas there.
I would like to know your opinions about these ideas and/or if FF is a good ground base to build some kind of POC (I know the code has changed a LOT in BMS in comparison with what is left of FF).
(Sorry if that isn’t the category for that post)
-
It’s not impossible but the first thing that needs doing is actually rewriting the code in a way that makes the avionics modular. Iiirc the dev who mentioned this in the past, is currently busy with other stuff. Probably same goes for a potential SDK for such modules.
-
@moidesko I am of a similar mind … there was a great thread on this, about a year ago. Will see if I can find it.
The biggest challenge, as I recall, is not so much modelling a plug-in architecture for the components of the plane itself… but defining its interface boundary with the entire rest of the world. (Thinking about “avionics” like AESA radars, and new sensors like IRST.)
The prior discussion left me with a sense of just how horribly intertwined the campaign / world-model code is (which is part of why we’re still stuck with the 2D interface from 1998). Refactoring all of that, and defining a stronger interface boundary around all the entities in-theater, would probably be a necessary prereq step.