Hypothetical question on Avionics in BMS
-
So all we need to do is turn the Mig 17 into a Mig-15, the F-5A into an F-86, make them flyable and it’s 1952!
-
+1 to what Blu3wolf and I-Hawk are saying.
Part of the problem is defining how far do you want to take it (ie. what do we mean by “avionics”)… just different-looking MFD displays? Or actual new features and functionality specific to individual planes. (eg. thinking of the flaps and auto-throttle on the Hornet … vtol and thrust-vectoring on Harrier)
And not just new/different callbacks, for clickable cockpit switches, but consider different planes have different button/hat layouts on their sticks and throttles… do we want an ability to define and select different HOTAS bindings for different planes? Probably … considering the various hotas switches (TMS/DMS/CMS etc) are coupled so closely with the F-16 avionics.
Need to model different types of DED displays and ICP input controls… again just look at the Hornet for example of how different it can be, for a plane of same era and same country of origin.
And if we’ve gone that far, may as well go all-in … customizable flight-models, aerodynamics/weight and control surfaces.
The lowest priority, might be … different radio sets, and different IFF and IDM-style systems etc for very old (or very new or non-western block fighters…
Nothing is impossible but it’s a huge* swath of work just to get to the level of “different looking stuff on MFDs” in a way that could be programmed and plugged-in by third-parties without source access. (*I base this estimate solely on looking at the Hornet in BMS… which was clearly a labor of love by people with source-code access, and really only has a slightly-different looking HUD and badly mangled DED from the Viper… but, as always, I would love to be told I’m wrong.)
Airtex, I believe that what is meant by “avionics” is the the whole deal (ie: 1:1 with stock jet ) Just to clarify, the current BMS Hornet is not a carbon copy of the Viper. Flaps and autothrottle are already in the BMS Hornet, and it’s FM has been refined (in the F-18C, at least.
What you write about HOTAS, switchology, etc. , is frankly my biggest concern, especially if you’re consider doing this in all the jets in BMS. That, and the needed DOCs. -
Brother, Stevie,
If I may, I’d like to ask a question. Hopefully, this won’t set someone off, as I’ve made it clear I’m a BMS Guy. But…
We see DCS and others you mention routinely installing different avionics. What IS keeping us from doing it in BMS? Obviously it will be a big and technical project. So,is it a question of the time it would require? Is it (no offense to anyone) an “it’s a Viper Sim” thing? Is it a technical thing with our BMS coding? All of the above, or something else?I think there are really only two things stopping BMS in their tracks - 1) information available to build hifi avionics models from; and 2) the number of devs/personnel available to actually do the research and coding (which isn’t just a BMS problem).
There isn’t really a lot that could be done about either…for a lot of cases. But for the easier ones - like the Harrier, and some of the other older jets - one could see works in progress.
-
I think there are really only two things stopping BMS in their tracks - 1) information available to build hifi avionics models from;
FWIW, we can always copy-paste stuff from DCS
and 2) the number of devs/personnel available to actually do the research and coding (which isn’t just a BMS problem).
I’d estimate that more than the above, it’s about motivation. Let’s say that BMS currently has ~6 fully active coders, and out of those 6 I’d say that 1 or 2 can choose to focus on avionics, possibly of other platforms as well, but it’s solely their choice to decide what they’d like to focus on. At the core BMS don’t have and never had a “plan” - it’s mostly about people deciding what to chase and just run for that (ad it makes sense because after all this is a free time based development, so while I can expect people to work and deliver something, I can’t really tell them what that something should be). It’s mainly in API changes where we have some kind of “plan” due to the nature of possible dependency between 2 WIP items.
And just to say it again clear and loud: Avionics coding is “fun”, at least in my eyes - I mean the APIs are mostly exist and you just need to start building the systems. I liked it when I did it for the F-16, it was an interesting journey and I’m almost sure that as long as I’m around at some point I’ll return to do that, possibly in parallel to other developments that I plan later.
There isn’t really a lot that could be done about either…for a lot of cases. But for the easier ones - like the Harrier, and some of the other older jets - one could see works in progress.
If there are people that want to help and have the ability to code in C++ and they can prove us they can deliver quality stuff, then I’m here to hear them. I think that ~2 Devs that has the ability can initiate something very interesting in the avionics field and especially of other aircrafts. Developing an API that will be a door for other aircrafts systems isn’t so easy but also not that hard.
Cheers!
-
Well now I have a reason to learn C++
-
… It’s mainly in API changes where we have some kind of “plan” due to the nature of possible dependency between 2 WIP items.
…
If there are people that want to help and have the ability to code in C++ and they can prove us they can deliver quality stuff, then I’m here to hear them. I think that ~2 Devs that has the ability can initiate something very interesting in the avionics field and especially of other aircrafts. Developing an API that will be a door for other aircrafts systems isn’t so easy but also not that hard.Cheers!
I certainly see the avionics development would brake a lot of classes before it is running again. In the old SP source (unless you guys changed), avionics were distributed over several places of the solution, Aircraft, Cockpit, Displays, Faults, FCC, ICP, IRST, Radar and RWR and classes therein would necessarily need to be refactored. If you are interested on really touching that, a PM was sent.
-
Don’t assume DCS is the “gold standard”…or any sim, for that matter. As I survey different sims I find that they ALL have both strong points and weak points and that in general if you want to get something “real” you need to know what you are looking at and mix and mate vice “copy and paste”. This is why having the information available to do a hifi model is of paramount importance. You’ll find that when you know what the real story is you’ll probably end up making changes/augments.
Not to mention that modern aircraft change substantially over time…and that’s even harder to follow.
-
Damn… How I’d wish to be a c++ expert now… :frusty:
-
Damn… How I’d wish to be a c++ expert now… :frusty:
@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.
-
@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.