fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/AIModel/AIManager.hxx

151 lines
4.3 KiB
C++
Raw Normal View History

David Culp: I added an AIStatic object to my OV-10 sim for use in putting city signs, vehicles, or anything else that will be static, but that I don't want to put in the scenery files. It's inexpensive. Before, I was making such things from AIShip. I also added the ability to set flight plans to repeat, so that when an airplane reaches the end it just starts over at the beginning. This is useful for my OV-10 sim. I have C-141 and KC-135 traffic flying approaches to Ramstein, and I only have to define two AI objects to do this. Also, I found an inefficiency in AIBase, where every AI object was calculating Mach number at every dt. Now only AIBallistic objects do this.
2005-06-04 09:38:52 +00:00
// AIManager.hxx - David Culp - based on:
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
// AIMgr.hxx - definition of FGAIMgr
// - a global management class for FlightGear generated AI traffic
//
// Written by David Luff, started March 2002.
//
// Copyright (C) 2002 David C Luff - david.luff@nottingham.ac.uk
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#ifndef _FG_AIMANAGER_HXX
#define _FG_AIMANAGER_HXX
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
#include <list>
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
#include <simgear/structure/subsystem_mgr.hxx>
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
#include <Main/fg_props.hxx>
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
#include <AIModel/AIBase.hxx>
#include <AIModel/AIScenario.hxx>
#include <AIModel/AIFlightPlan.hxx>
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
2004-11-29 09:41:43 +00:00
#include <Traffic/SchedFlight.hxx>
#include <Traffic/Schedule.hxx>
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
SG_USING_STD(list);
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
2004-11-29 09:41:43 +00:00
SG_USING_STD(vector);
class FGModelID
{
private:
ssgBranch * model;
string path;
public:
FGModelID(const string& pth, ssgBranch * mdl) { path =pth; model=mdl;};
ssgBranch *getModelId() { return model;};
const string & getPath() { return path;};
};
typedef vector<FGModelID> ModelVec;
typedef vector<FGModelID>::iterator ModelVecIterator;
David Culp: I added some things to the AI stuff to improve the AIThermal processing. Before, all the thermals were processed in order, and the last one overwrote the prior one. Now, only the data from the nearest thermal is kept. This way a tile can be populated with many thermals, and (as long as they have the same diameter) the one nearest the airplane correctly takes effect. This will make us ready for the next step, "auto-thermaling", where FlightGear's tile manager can cover a tile with thermals, and set the thermal strength based on land-use type. I moved the enumerated object_type to the base class. When an AI object is created it now sets the _otype variable in the base class. This lets the AI manager find out what kind of AI object it is dealing with, using the base pointer. I also added a function isa() to the base class, so the manager can process objects differently based on their type. The AI manager now sends AIThermal processing to a different function, where only the data from the nearest thermal is kept. After the manager processes all the AI objects, then the results from the nearest thermal are applied to wind-from-down.
2004-03-07 12:08:46 +00:00
class FGAIThermal;
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
class FGAIManager : public SGSubsystem
{
private:
// A list of pointers to AI objects
typedef list <FGAIBase*> ai_list_type;
typedef ai_list_type::iterator ai_list_iterator;
typedef ai_list_type::const_iterator ai_list_const_iterator;
// Everything put in this list should be created dynamically
// on the heap and ***DELETED WHEN REMOVED!!!!!***
ai_list_type ai_list;
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
2004-11-29 09:41:43 +00:00
ModelVec loadedModels;
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
public:
FGAIManager();
~FGAIManager();
void init();
Mathias Frhlich: I have traced that reset on carrier problem down to several problems. One of them is the fact that on reset the carrier is updated while the aircraft is not. That made the aircraft drop down an elevator sometimes. Depending on the passed realtime while loading some parts of the scenery.
2005-07-13 12:25:16 +00:00
void reinit();
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
void bind();
void unbind();
void update(double dt);
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
void* createBallistic( FGAIModelEntity *entity );
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
2004-11-29 09:41:43 +00:00
void* createAircraft( FGAIModelEntity *entity, FGAISchedule *ref=0 );
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
void* createThermal( FGAIModelEntity *entity );
void* createStorm( FGAIModelEntity *entity );
void* createShip( FGAIModelEntity *entity );
David Culp: Here's code to support a new AICarrier class, which I think will be sufficiently different from a basic AIShip that it should have its own class.
2004-10-28 08:33:55 +00:00
void* createCarrier( FGAIModelEntity *entity );
David Culp: I added an AIStatic object to my OV-10 sim for use in putting city signs, vehicles, or anything else that will be static, but that I don't want to put in the scenery files. It's inexpensive. Before, I was making such things from AIShip. I also added the ability to set flight plans to repeat, so that when an airplane reaches the end it just starts over at the beginning. This is useful for my OV-10 sim. I have C-141 and KC-135 traffic flying approaches to Ramstein, and I only have to define two AI objects to do this. Also, I found an inefficiency in AIBase, where every AI object was calculating Mach number at every dt. Now only AIBallistic objects do this.
2005-06-04 09:38:52 +00:00
void* createStatic( FGAIModelEntity *entity );
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
void destroyObject( void* ID );
David Culp: Here's a new batch of AI code which includes a working radar instrument. I put the radar calculations into the existing AIAircraft class. It was easier that way, and it can always be migrated out later if we have to. Every tenth sim cycle the AIManager makes a copy of the current user state information. When the AIAircraft updates it uses this information to calculate the radar numbers. It calculates: 1) bearing from user to target 2) range to target in nautical miles 3) "horizontal offset" to target. This is the angle from the nose to the target, in degrees, from -180 to 180. This will be useful later for a HUD. 4) elevation, in degrees (vertical angle from user's position to target position) 5) vertical offset, in degrees (this is elevation corrected for user's pitch) 6) rdot (range rate in knots, note: not working yet, so I commented it out) and three items used by the radar instrument to place the "blip" 7) y_shift, in nautical miles 8) x_shift, in nautical miles 9) rotation, in degrees The radar instrument uses the above three items, and applies a scale factor to the x-shift and y-shift in order to match the instrument's scale. Changing the display scale can be done entirely in the XML code for the instrument. Right now it's set up only to display a 40 mile scale. The radar is an AWACS view, which is not very realistic, but it is useful and demonstrates the technology. With just a little more work I can get a HUD marker. All I need to do there is make a bank angle adjustment to the current values.
2004-02-27 10:20:17 +00:00
inline double get_user_latitude() { return user_latitude; }
inline double get_user_longitude() { return user_longitude; }
inline double get_user_altitude() { return user_altitude; }
inline double get_user_heading() { return user_heading; }
inline double get_user_pitch() { return user_pitch; }
inline double get_user_yaw() { return user_yaw; }
inline double get_user_speed() {return user_speed; }
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
Vivian Meazza: The value of rho (air density) varies with height. (Including the upper stratosphere, ust in case someone wants to model ICBMs.) The standard atmosphere is used (based on a sea-level temperature of 15 deg C.). Erik Hofman: I moved this code over the AIBase::update() so all AIModels can make use of rho, temperature, pressure, etc.
2004-09-22 19:11:36 +00:00
inline int getNum( FGAIBase::object_type ot ) {
MSVC fixes.
2004-09-23 07:48:25 +00:00
return (0 < ot && ot < FGAIBase::MAX_OBJECTS) ? numObjects[ot] : numObjects[0];
Vivian Meazza: The value of rho (air density) varies with height. (Including the upper stratosphere, ust in case someone wants to model ICBMs.) The standard atmosphere is used (based on a sea-level temperature of 15 deg C.). Erik Hofman: I moved this code over the AIBase::update() so all AIModels can make use of rho, temperature, pressure, etc.
2004-09-22 19:11:36 +00:00
}
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
Mathias Frhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
void processScenario( const string &filename );
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
2004-11-29 09:41:43 +00:00
ssgBranch * getModel(const string& path);
void setModel(const string& path, ssgBranch *model);
Mathias Frhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
static bool getStartPosition(const string& id, const string& pid,
Point3D& geodPos, double& hdng, sgdVec3 uvw);
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
private:
bool initDone;
Add AI models enableing/disableing command line option and support code.
2004-05-19 13:55:49 +00:00
bool enabled;
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
int numObjects[FGAIBase::MAX_OBJECTS];
David Culp: Here's a new batch of AI code which includes a working radar instrument. I put the radar calculations into the existing AIAircraft class. It was easier that way, and it can always be migrated out later if we have to. Every tenth sim cycle the AIManager makes a copy of the current user state information. When the AIAircraft updates it uses this information to calculate the radar numbers. It calculates: 1) bearing from user to target 2) range to target in nautical miles 3) "horizontal offset" to target. This is the angle from the nose to the target, in degrees, from -180 to 180. This will be useful later for a HUD. 4) elevation, in degrees (vertical angle from user's position to target position) 5) vertical offset, in degrees (this is elevation corrected for user's pitch) 6) rdot (range rate in knots, note: not working yet, so I commented it out) and three items used by the radar instrument to place the "blip" 7) y_shift, in nautical miles 8) x_shift, in nautical miles 9) rotation, in degrees The radar instrument uses the above three items, and applies a scale factor to the x-shift and y-shift in order to match the instrument's scale. Changing the display scale can be done entirely in the XML code for the instrument. Right now it's set up only to display a 40 mile scale. The radar is an AWACS view, which is not very realistic, but it is useful and demonstrates the technology. With just a little more work I can get a HUD marker. All I need to do there is make a bank angle adjustment to the current values.
2004-02-27 10:20:17 +00:00
SGPropertyNode* root;
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
SGPropertyNode* wind_from_down_node;
David Culp: I'm looking through the AI code, trying to find the bug that's killing the thermals. The following things don't look right: 1) AIManager::101 , the Traffic Manager pointer is searched for by name at every dt. I'll leave this for you to look at. 2) AIManager::295 , the thermal height is not being set. We need to restore the line: ai_thermal->setHeight(entity->height_msl); This fixes the thermal problem. 3) AIManager::328 , I changed the fetching of the user state to occur every sim cycle, and changed the fetching function from by-name lookup to a lookup by node pointer. It should be faster now, and more accurate too. This helps the air-refueling.
2005-04-19 12:52:26 +00:00
SGPropertyNode* user_latitude_node;
SGPropertyNode* user_longitude_node;
SGPropertyNode* user_altitude_node;
SGPropertyNode* user_heading_node;
SGPropertyNode* user_pitch_node;
SGPropertyNode* user_yaw_node;
SGPropertyNode* user_speed_node;
David Culp: First, preferences.xml will define the scenario filename. For now, the other way of defining ai objects still works, so the sailboat stays in preferences.xml. Later, I'll move the sailboat into the demo scenario. If no scenario filename is given, then no scenario will be processed. I changed the demo scenario to create two 737's, one takes off on runway 01L, and the other takes off on runway 01R. This will make a good demo for the ai system. One problem, if you takeoff on 28L/R right away, you might run into the taking-off 737's, or be scared.
2004-05-17 08:45:33 +00:00
string scenario_filename;
David Culp: Here's a new batch of AI code which includes a working radar instrument. I put the radar calculations into the existing AIAircraft class. It was easier that way, and it can always be migrated out later if we have to. Every tenth sim cycle the AIManager makes a copy of the current user state information. When the AIAircraft updates it uses this information to calculate the radar numbers. It calculates: 1) bearing from user to target 2) range to target in nautical miles 3) "horizontal offset" to target. This is the angle from the nose to the target, in degrees, from -180 to 180. This will be useful later for a HUD. 4) elevation, in degrees (vertical angle from user's position to target position) 5) vertical offset, in degrees (this is elevation corrected for user's pitch) 6) rdot (range rate in knots, note: not working yet, so I commented it out) and three items used by the radar instrument to place the "blip" 7) y_shift, in nautical miles 8) x_shift, in nautical miles 9) rotation, in degrees The radar instrument uses the above three items, and applies a scale factor to the x-shift and y-shift in order to match the instrument's scale. Changing the display scale can be done entirely in the XML code for the instrument. Right now it's set up only to display a 40 mile scale. The radar is an AWACS view, which is not very realistic, but it is useful and demonstrates the technology. With just a little more work I can get a HUD marker. All I need to do there is make a bank angle adjustment to the current values.
2004-02-27 10:20:17 +00:00
double user_latitude;
double user_longitude;
double user_altitude;
double user_heading;
double user_pitch;
double user_yaw;
double user_speed;
David Culp: I added some things to the AI stuff to improve the AIThermal processing. Before, all the thermals were processed in order, and the last one overwrote the prior one. Now, only the data from the nearest thermal is kept. This way a tile can be populated with many thermals, and (as long as they have the same diameter) the one nearest the airplane correctly takes effect. This will make us ready for the next step, "auto-thermaling", where FlightGear's tile manager can cover a tile with thermals, and set the thermal strength based on land-use type. I moved the enumerated object_type to the base class. When an AI object is created it now sets the _otype variable in the base class. This lets the AI manager find out what kind of AI object it is dealing with, using the base pointer. I also added a function isa() to the base class, so the manager can process objects differently based on their type. The AI manager now sends AIThermal processing to a different function, where only the data from the nearest thermal is kept. After the manager processes all the AI objects, then the results from the nearest thermal are applied to wind-from-down.
2004-03-07 12:08:46 +00:00
double _dt;
David Culp: Here's a new batch of AI code which includes a working radar instrument. I put the radar calculations into the existing AIAircraft class. It was easier that way, and it can always be migrated out later if we have to. Every tenth sim cycle the AIManager makes a copy of the current user state information. When the AIAircraft updates it uses this information to calculate the radar numbers. It calculates: 1) bearing from user to target 2) range to target in nautical miles 3) "horizontal offset" to target. This is the angle from the nose to the target, in degrees, from -180 to 180. This will be useful later for a HUD. 4) elevation, in degrees (vertical angle from user's position to target position) 5) vertical offset, in degrees (this is elevation corrected for user's pitch) 6) rdot (range rate in knots, note: not working yet, so I commented it out) and three items used by the radar instrument to place the "blip" 7) y_shift, in nautical miles 8) x_shift, in nautical miles 9) rotation, in degrees The radar instrument uses the above three items, and applies a scale factor to the x-shift and y-shift in order to match the instrument's scale. Changing the display scale can be done entirely in the XML code for the instrument. Right now it's set up only to display a 40 mile scale. The radar is an AWACS view, which is not very realistic, but it is useful and demonstrates the technology. With just a little more work I can get a HUD marker. All I need to do there is make a bank angle adjustment to the current values.
2004-02-27 10:20:17 +00:00
int dt_count;
void fetchUserState( void );
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
David Culp: I added some things to the AI stuff to improve the AIThermal processing. Before, all the thermals were processed in order, and the last one overwrote the prior one. Now, only the data from the nearest thermal is kept. This way a tile can be populated with many thermals, and (as long as they have the same diameter) the one nearest the airplane correctly takes effect. This will make us ready for the next step, "auto-thermaling", where FlightGear's tile manager can cover a tile with thermals, and set the thermal strength based on land-use type. I moved the enumerated object_type to the base class. When an AI object is created it now sets the _otype variable in the base class. This lets the AI manager find out what kind of AI object it is dealing with, using the base pointer. I also added a function isa() to the base class, so the manager can process objects differently based on their type. The AI manager now sends AIThermal processing to a different function, where only the data from the nearest thermal is kept. After the manager processes all the AI objects, then the results from the nearest thermal are applied to wind-from-down.
2004-03-07 12:08:46 +00:00
// used by thermals
double range_nearest;
double strength;
void processThermal( FGAIThermal* thermal );
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
};
#endif // _FG_AIMANAGER_HXX
Copy permalink