Creating guided missiles
| This article is a stub. You can help the wiki by expanding it. |
Status
You can check $FGDATA/Aircraft/f-14b/Nasal/fox2.nas (in Git) which models a tiny part of a complex weapons system.
- It checks for available weapons with respect of the pylon position.
- checks for missile readiness (all switchs on right position and time to temperature of the IR seeker).
- activates one missile search function.
- search for a possible target.
- locks on the target and check if any lock out condition. Calculate HUD symbology (diamond displayed over the target position in the HUD)
- checks for fire order
- calculates exact position/orientation/velocity when fire order so we can spawn a new AI object in the proper place.
- releases the missile and guides it with a crude FDM
- if available activates a new searching missile and drives both fired and searching objects (we can guide several fired missile (flying and tracking) and have an additional one in searching state (on its pylon and searching or tracking). Each object can have its own target.
- checks for (near) impact or lock out condition
- if impact, creates the properties used by bombable.nas so the target is actually damaged, and some other properties for the explosion graphical animation. Also it displays the distance from the target on the player screen when the missile explode.
There is a menu item in "Tomcat Controls" with a switch which allows those informations to be displayed as messages over MP.
Prototyping
Xiii worked on the f-14b. ATM every thing is in place to simulate an AIM-9 operation from armament panel and switches to the time the missile locks and try keeping its lock on the first target seen by its seeker, and it is already fun. That was the first step. The next one was spanning an AI or a submodel with its own guidance system.
Well, the AI are created, under the right pylons and the missile now flies as could fly a submodel, excepted that it is powered by a 30 sec. 230 lbs thrust rocket engine (i didn't found data about drag and thrust, so they are mostly guessed). Drag, gravity and pitch are done. Yaw isn't modeled yet. It reaches 2.5 M in 2 sec if launched at 0.8 M. I never seen it faster than 2.65 M. My problem now is to reuse the code I made first for the seeker of the sidewinder before launch without duplicating it in another place. This is just code cleaning and reorganization, but it can be long. All of this is in the usual un-readable-un-maintainable xiii's nasal code TM.
An other problem is I didn't find a way to stop the smoke trail (particles) after the 30 sec boost duration. Perhaps this could be done with several AIM-9 models xml files, though I don't like this idea.
For the physics I used mostly equations found in AIBallistic.cxx andAIBase.cxx. This is a good place to start.
There is still a lot to do, but at that point we already have the thruster advantage over regular submodels.
The first proto is running on the f-14b, then I'll try to make it more packaged before adding it to A-10 and may be the f16. Well the missiles exists now, there is still a bit of work before test releases, but I already can play with them
These AIM-9 are integrated in the tomcat system, a bit like I did at first for the A-10 but with a bit more complexity in the weapon system. The A-10 AIM-9 were raw submodels with a fixed speed and a ballistic trajectory. That's all.
Unlike the A-10 ones, the new AIM-9 are AI models, they pull information from an external script that a target (MP or AI tanker ATM) is lockable. They perform further test like range and datum line deviation then they lock on the target. They may lose also the lock, this is modeled with a simple but realistic seeker/gimbals simulation. Then you fire them, they have a crude FDM with drag, thrust, and gravity effect. The seeker logic/mechanics determines a proportionnal navigation trajectory (as the real one). Tests are done so the missile explode if it reaches at least 50 meters or less from the moving target. If it miss, the seeker is reset and the missile flies free. The thrust give just the acceleration needed to reach 2.5M in 2 sec approx. With a ratio thrust/weight of 1.2, it depends on altitude, attitude and A/C initial velocity. The thrust duration is 30 sec, after that the missile glides.
Ah, they have a poor precision, when fired in good conditions, that is a low target/datum line deviation and a 2 to 5 NM range, they "hit" at not less than a few tenth meters. I have seen a few time a 10 or a 5 meters score. This is not the expected sidewinder exploding in the exhaust pipe (do sidewinders always hit directly ??). I still have to test on evading targets and look for improvements clues in the docs I have.
Smoke and explosion visual effects are now done and I'm happy with them. Current short TDL: 1) write some doc as it is not so simple to use (lot of switches in the F-14b) 2) put an archive somewhere so you can see and test. 3) learn how to commit in GIT.
Sounds: well, new sounds make FG crash randomly on my box so I'm not inclined to add too much of them, at least for the time being.
Longer TDL (fall 2010): 1) the search part of the program relies on the f-14b radar code, it should be completely independent (currently there is some restriction with the type of available targets, this is part of the radar stuff). 2) ground interaction could be fun, specialy for clumsy pilots. 3) messages over MP, possibly interaction with bombable36q. 4) add more realism like clouds or target aspect interaction.
Guidance
About guidance, the steering of a missile is not the most complex thing, at least from a simulation point of view. Now, it is nearly impossible to match exactly a direct hit with the framerates we have, so there is a need of some tricks here and there to give the missile a chance (some kind of funny "post prediction"). The complex thing is rather locking one from several target, assign it to a missile, fire, steer, and while doing this, repeat the operation with a possible other target and another missile. Be able to cancel the operation in case of a lock loss is part of the game. For this part you will have to handle a lot of logic. Now doing a crude FDM, checking how to spawn a new AI missile and apply the FDM is not woodoo science, the hard work is already done and may not need all the radar stuff and weapon system. Same for making it work with bombable.
Trajectory & Proximity Detection
About the trajectory and proximity detection: There is plenty of room to improve the trajectory algorithm. But this would drive us toward a 100% collision chance and this would oblige us to add adverse conditions to downside the success rate and keep a reasonable scoring. Users experience may also be unchanged after adding lot of computations. Anyway,I agree with you about the poor more or less 75% score on the level flying tanker. I'll try to think about how to test your idea, but if you can stand my code, you are welcome to play with the algos!
In the case of the sidewinder, the real thing use a proportional navigation http://en.wikipedia.org/wiki/Proportional_navigation algorythm and the thing you have now in FG does the same. Do you know what trajectory algos use the the Sparrow or the Phoenix ? I don't know yet. There are also differences in the way they get the target, active semi-active and such. Also propulsion, acceleration, speed, boost duration, turn rate may change.
So be patient, in a year or two, we may begin to speak about the sparrow
Creating scripted AI missiles
Basically, xiii has illustrated that this is perfectly possible, and there are plans in place to generalize the existing code to turn it into a reusable Nasal module for the $FG_ROOT/Nasal directory eventually, so that all users can easily create new AI objects that can be controlled from Nasal, just by subclassing an existing Nasal class.
This will all depend on solid background knowledge of Nasal, and the AI system (its properties) however - so the best thing you can do right now, is reading more about Nasal to see how it works. Even if the approach had already been fully documented, and if the module would be available right now - you would still need to know Nasal.
If you know Nasal, and once you actually understand a script written by someone else, you can see for yourself. Really, xiii's code is not only pretty well structured and even uses OOP to separate code and data into distinct modules, but is also well commented.
In my opinion, xiii's script would be an excellent place to start generalizing the whole concept of Nasal controlled AI objects, starting to rewrite anything from scratch without looking at xiii's code would be a big mistake from my point of view.
While the "tanker.nas" script used to be the de facto example for illustrating how to script AI objects, xiii's code has in my opinion become the standard for showing how to combine scripted AI objects with custom, scripted FDMs to create autonomous objects.
Basically, if you need help understanding xiii's current code, it is pretty unlikely that you'll be able to come up with a generic module, like the one you described.
Really, doing from scratch what xiii has done with the AI guided missiles script, will require a solid understanding of both, Nasal and the AI systems, as well as a good background in physics, maths and FlightGear in general. All of this will get blatantly obvious to you, once you actually look at and understand the code in question!
For example, are you familiar with 3D maths, vector/matrix operations? This is just one thing that xiii makes use of!
In this sense, it would really be a bad project for trying to learn Nasal in my opinion, especially if you lack the background in programming, maths or physics. Such advanced addons, are no longer just about learning ONE new thing, but mostly about APPLYING knowledge of a number of different fields.
I am REALLY convinced that trying to learn Nasal with such a big project would probably be a pretty frustrating experience for most people, who lack the corresponding professional background.
So, I don't know about your professional background, but if it is not in any way related to software development, physics or maths, I am pretty sure that trying to contribute the way you hope, will provide for a rather steep entry barrier - especially without a solid understanding of the corresponding FlightGear systems involved.
Really, believe me: Learning Nasal is one thing(a couple of weeks will do for basic things, especially if you are already familiar with JavaScript) , getting to know the AI system another (another 2-3 weeks) - creating scripted FDMs yet another (fancy maths), but applying ALL these principles to create a completely new hybdrid solution, is a huge non trivial undertaking which is not well suited for providing a good "learning experience" with direct gratification.
Don't try to run before you can walk...
Known Issues
A cruise missile is more than a simple AA passive guidance missile, it's rather a one way UAV, in other terms a jet aircraft without landing gear, so it worth something better than the very crude fox2 nasal FDM. Fox2.nas is good at managing several submodels, engaging one or more AI/MP target, managing weapons on different pylons and it only uses a proportional pursuit guidance algorythm which simply change the velocity vector inside a given flight envelope (basicly a G limiter). There is no phisical effect but thrust, gravity and drag. I would say that's less than a FDM :-/
AFAIK, please correct me if I'm wrong, there isn't the possiblity to run 2 real FDMs at the same time in FG but to use 2 instances of FG. Now it's perfectly possible to run a very basic FDM with nasal scripting.
A generic AI module
Code reuse is actually a very good idea, especially because there are now three different scripts doing basically the same thing: controlling AI objects and because there were meanwhile so many people also asking how to control AI objects using Nasal, and I haven't yet had the time to write a howto, so a reusable Nasal module might be a good idea.
So I am wondering, if we should take a look at the three addons (tanker.nas, fox2.nas, flug's bombable) and come up with a new generic Nasal module for controlling AI objects? Normally, this would be a task for the Nasal library maintainers. But just looking at the three scripts, it should be possible to come up with an API. This would make it easier for other people to reuse your code and create similar addons.
So it is probably a good idea to base such an "ai.nas" module on your code, i.e. simply take a look at your code, generalize and abstract it and put it into a new Nasal module. Once your own scripts can use that module, we can still look at the other two addons (bombable and local-weather) to see how the ai module needs to be modified to be fully usable by the other scripts.
That in itself should help reduce duplicate code and improve code reuse among Nasal scripts.
Or maybe even help improve such an ai.nas module. Once we have a working ai.nas module, we could start work on porting all existing addons to start using this module then.
I am really convinced that this is the right thing to do, because it is generally better to look at any large portions of code and see how it can be refactored into distinct reusable components. This is something that has been done rather well with the Nasal standard library in $FG_ROOT/Nasal.
Starting this effort right now would help us combine all related projects and unifying the code.
And I think it is a good idea to do this directly, without bothering the core developers at the moment. The Nasal library maintainers can still check everything and improve the final outcome once we are satisfied ourselves.
Until then it should be completely possible to sort of have a "peer review" where we review our Nasal scripts and help improve them. Having a group of volunteers who can read and write Nasal to help review/create new modules would be a good thing, because it would mean less work for the core developers. Especially given the size of the three addon scripts, each of which is more than 100 kb in size if I remember correctly.
With such a workflow, the library maintainers would only get to see reviewed and fixed code.
Future Plans
I wonder if building a controler loop wouldn't worth the pain, as for now, functions call themselves in an awful gordian knot... Now if the freeze happens without the weapons system running, even if it is much less often, then will have to search somewhere else.
Well in any case a controler loop might help the reuse of the code, frankly ATM it looks like crap.
I also noticed that the freeze occurs mostly after a cockpit sound play.
Bombable Support
Also, there is another related effort - by the forum user "xii": xiii created an implementation of a "seeking missile" for the f14b aircraft, IIRC the file is called "fox2.nas". While these two systems are not yet integrated as far as I know, it should be fairly straight forward to do - you would then have a "dog fighting" system with f14 aircraft that can actually shoot seeking missiles.
Integrating these two systems (Nasal scripts in fact!) would probably be an excellent exercise to get to know FlightGear's internal architecture, its built-in extension language (Nasal) and related systems such as the AI traffic system etc.