target_track.nas

[redneck]

Not sure if this is the right place to put this or not. I've been playing with the file, trying to make it better, and I seem to have hit a wall. No matter what goal range I set, target speed, etc. I will almost always eventually overshoot. So, I did some testing and found that it works absolutely wonderfully at low altitudes. I match the target's speed once I'm about 3 nm away, and ever so slowly inch my way towards it as it turns and stuff, but never get within 1 nm of it. I know the original idea was to make the AP maintain formation, and I think that is still possible with my settings, since it will match the target's speed once it's within 3 nm of the target.
The problem sets in when I climb to altitudes above 10,000 ft. The target speed is ALWAYS too high, no matter where I am in relation to the target. Anyway, after a recent flight, I concluded that the speeds that the script is plugging into the AP must be in KTAS. This explains why it will work perfect at low altitudes, but leave me to play with the throttle manually at higher altitudes. So, I was wondering if there is anyway to get the script to recognize speed in KIAS, and use that instead?

You may be wondering, why would I want to take the fun out of maintaining formation with someone? Well, I like making videos, and I doubt a pilot would actually hold a camcorder and aim it at another plane, while trying to fly very close to it without crashing. Sure, s/he'd mount the thing somewhere in the cockpit, but that's about it, UNLESS a passenger takes the camera, and acts as cameraman. Basically, the idea is to give all planes with good APs functionality that is similar to the mibs. No, I wouldn't be satisfied just using the mibs, even if mine worked.

So yeah.... I will be very happy to receive any suggestions on how to modify this script, then I will apply them, test them to make sure it works as planned, and then release it right here! You'll just have to copy and paste the text and overwrite your copy of target_track.nas.

[Hooray]

Have you already taken a look at the Nasal script: http://gitorious.org/fg/fgdata/blobs/ma ... target.nas ?
Do you need any specific help understanding or modifying the script?

[redneck]

No, I don't know anything about GIT. The script has been updated since 1.9.1b? I'll see if I can figure it out.

I think I found the line that is the culprit. Now, ideally, I can just change the word "true" to "indicated", and have it work, but I have a feeling that's not going to work. I'll back up my file and try it anyway. Oh, and no it doesn't appear to have been updated since 1.9.1b.

As I expected, that made the script stop working.

[Hooray]

I am not sure if I am understanding you correctly, but if all you want to do is change a property, you can simply change its path in the source code.
For example, the velocity property is created using the following call:

Code: Select all

var speed_prop = sprintf("%s/velocities/true-airspeed-kt", target_root );

You have to watch out however, because some properties are "output" properties, because they are used to store results, while others are "input" properties that are used for doing calculations. There was recently a discussion about this. So you need to make sure that your changes make sense to FlightGear.

You can also use Nasal to convert from IAS to TAS or vice versa.

[redneck]

Yes, that line right there. I want to change that to indicated airspeed. I tried changing the word "true" to "indicated", and I tried omitting the word "true". Both attempts gave me the same result: a broken target tracking script.
I browsed through the internal properties, and thought I had found what I was looking for (that I needed to simply get rid of the "true"). I'm wondering how this part works exactly. I suppose FG can't just look at the ASI of an MP or AI aircraft, right? It has to calculate it's speed based on the amount of time it travels from one point to another point, and it does that about 20 times a second. Well, if that's the case, then maybe I need to insert a line that converts the true airspeed it gets into KIAS, and plug that value into the AP settings. I'm not sure how to go about doing that though.

[Hooray]

Okay, I think I understand now what your problem is: You have to keep in mind that the AI traffic system does not use the PID controller based autopilot code, so it does not provide the same modes like the standard autopilots.
You can see what properties are supported by having a look into the source code: http://gitorious.org/fg/flightgear/blob ... AIBase.cxx

This means basically, that you have to convert your desired speed to the unit used and expected by the AI traffic system.
Just making up a new property will not work because the hard coded AI autopilot does not provide for different AP speed modes (IAS, TAS, CAS, GS).

[redneck]

Okay, now you have completely lost me. Or, we have both lost each other. I'm trying to make this script better fulfill its purpose: plugging in the right values into the AP to allow the pilot to engage in formation, or follow from a distance (depending on range setting), by simply engaging the AP. I'm not trying to set up an AI traffic system. It seems I may just need to learn some actual programming skills before I can even wrap my mind around this. I was hoping to accomplish this by simply changing some variables, which isn't working quite as planned. Yeah, that source code stuff will take me a while to understand. Really, I know how to guess the stuff, and read carefully, and then know what modifying a variable is going to do, then backup the file and tinker with it gently. I know nothing about setting or writing properties.

[Thorsten]

Actually, the conversion of TAS to IAS isn't anything simple - you need the complete atmosphere model for that (it depends on temperature, pressure and altitude).

I don't think there is a simple function call available from Nasal which does that. So either someone makes it available from the C++ side, or you have to duplicate the environement model in Nasal.

[xiii]

I did a bit of nasal, inspired by Vivian's work on the sources to get air density and speed of sound from altitude. It is very simplistic and it use only simplified standard atmosphere as data, but it can be the starting point for an nasal environment API. It is just a matter to move it to the Nasal dir. I'll ask Vivian and Anders on IRC if they mind if I put that in the Nasal dir. Then I'll be happy if someone more confident with physics take care of it.

You can find this bit of Nasal in GIT: $FG_ROOT/Aircraft/f-14b/Nasal/environment.nas

[Thorsten]

Wouldn't it be more efficient and clean to ask someone to expose the existing environment model to Nasal? A simplified model for TAS to IAS won't help redneck, because his AP is still going to fly with the complicated version, so for any non-standard conditions it won't work properly, and while I know the atmospheric physics and in principle also know how to Nasal it, I really don't want to redo existing work...

[AndersG]

Wouldn't it be more efficient and clean to ask someone to expose the existing environment model to Nasal? A simplified model for TAS to IAS won't help redneck, because his AP is still going to fly with the complicated version, so for any non-standard conditions it won't work properly, and while I know the atmospheric physics and in principle also know how to Nasal it, I really don't want to redo existing work...

What about using appropriate inputs to drive the controller? I assume that the "real" goal is not (only) to fly at exactly the same speed as the "target" but also at a specific distance from it? Perhaps distance and closure rate can be used to control the speed sent to the AP? Then there is no need to know the target's speed in any specific measurement system.

Otherwise, I'd be surprised if the speed of the main aircraft isn't available in both KIAS and KTAS - so one could also control the AP KIAS hold speed to fly at some desired KTAS set speed.

Yes, both options require somebody to write a simple controller, but at least controllers, whether in Nasal or using the AP system, do not require a recompilation of FG.

Further, in general (but perhaps not with Thorsten's weather system) we do not know the atmospheric properties at the location of the AI aircraft so I don't think the data needed to compute an accurate IAS is available.

Cheers,

Anders

[redneck]

Yes, you are correct. Right now, it actually uses that concept to catch up to the aircraft, but when it's in range, attempts to match its speed by looking at just the aircraft's TAS, which is the wrong value to plug into the IAS for the AP. Let me find the part of the script that describes this function.

Code: Select all

target_speed = speed + range_error * 10.0;
        if ( target_speed < min_speed_kt ) {
            target_speed = min_speed_kt;
        }

The default used "range_error * 100", but that made the overshooting much more frequent, so I changed that. That fix, combined with changing the default range to 3 nm was enough to make it work nicely at low altitudes, even with the 787, enough that the AP could actually land safely by itself when following another landing jetliner.