fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/Instrumentation/gps.hxx

207 lines
6.1 KiB
C++
Raw Normal View History

Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
// gps.hxx - distance-measuring equipment.
// Written by David Megginson, started 2003.
//
// This file is in the Public Domain and comes with no warranty.
#ifndef __INSTRUMENTS_GPS_HXX
#define __INSTRUMENTS_GPS_HXX 1
This is step "1" of probably "many" in the process of separating out the scene management code and organizing it within simgear. My strategy is to identify the code I want to move, and break it's direct flightgear dependencies. Then it will be free to move over into the simgear package. - Moved some property specific code into simgear/props/ - Split out the condition code from fgfs/src/Main/fg_props and put it in it's own source file in simgear/props/ - Created a scene subdirectory for scenery, model, and material property related code. - Moved location.[ch]xx into simgear/scene/model/ - The location and condition code had dependencies on flightgear's global state (all the globals-> stuff, the flightgear property tree, etc.) SimGear code can't depend on it so that data has to be passed as parameters to the functions/methods/constructors. - This need to pass data as function parameters had a dramatic cascading effect throughout the FlightGear code.
2003-05-06 23:46:24 +00:00
#include <simgear/props/props.hxx>
Move FGEventMgr and FGSubsystemMgr over to SimGear, add SGEventMgr to FlightGear's globals structre and some small code cleanups
2003-09-24 17:20:55 +00:00
#include <simgear/structure/subsystem_mgr.hxx>
James Turner : Here's a patch which refactors the 'plain' GPS code into a slightly more manageable structure - i.e breaks the large update() method into various sub-functions. I've tested the patch with B1900d, and things seem to work as expected, but if anyone experiences GPS weirdness after this is committed, of course please report it. The motivation for this was helping me learn the code - I've planning some changes in this area, and splitting up the logic will hopefully make that task easier.
2008-12-09 08:10:33 +00:00
#include <simgear/math/SGMath.hxx>
// forward decls
class SGRoute;
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
James Turner : Here's a patch which refactors the 'plain' GPS code into a slightly more manageable structure - i.e breaks the large update() method into various sub-functions. I've tested the patch with B1900d, and things seem to work as expected, but if anyone experiences GPS weirdness after this is committed, of course please report it. The motivation for this was helping me learn the code - I've planning some changes in this area, and splitting up the logic will hopefully make that task easier.
2008-12-09 08:10:33 +00:00
class SGGeodProperty
{
public:
SGGeodProperty()
{
}
void init(SGPropertyNode* base, const char* lonStr, const char* latStr, const char* altStr = NULL);
void init(const char* lonStr, const char* latStr, const char* altStr = NULL);
void clear();
void operator=(const SGGeod& geod);
SGGeod get() const;
private:
SGPropertyNode_ptr _lon, _lat, _alt;
};
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
/**
* Model a GPS radio.
*
* Input properties:
*
* /position/longitude-deg
* /position/latitude-deg
* /position/altitude-ft
* /environment/magnetic-variation-deg
* /systems/electrical/outputs/gps
* /instrumentation/gps/serviceable
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
*
* /instrumentation/gps/wp-longitude-deg
* /instrumentation/gps/wp-latitude-deg
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
* /instrumentation/gps/wp-altitude-ft
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
* /instrumentation/gps/wp-ID
* /instrumentation/gps/wp-name
Roy Vegard Ovesen: I've added a tracking bug to the gps. This is of course very similar to a heading bug for a DG. I don't know if this is the common name, but I feel that for a gps the name tracking bug is more accurate than heading bug. A true bug error and a magnetic bug error is calculated and shifted into the -180 to 180 range so that they can be used by autopilots. I've also fixed a property name that crept in when I had to change back to indicated-***. Back then I accidentally changed the desired course name to "indicated-course". The property that is supposed to be the input for the desired course should naturally be named something like "desired-course", and definitely _not_ "indicated-course". If this name change breaks anything it should be fixed in the other end. I've also commented out a lot of #includes that I don't think is needed. I'm on Suse 9.0 now, and it builds fine here, but this might be a problem for different platforms I guess we have to cross our fingers.
2004-04-16 22:12:26 +00:00
* /instrumentation/gps/desired-course-deg
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
* /instrumentation/gps/get-nearest-airport
* /instrumentation/gps/waypoint-type
Roy Vegard Ovesen: I've added a tracking bug to the gps. This is of course very similar to a heading bug for a DG. I don't know if this is the common name, but I feel that for a gps the name tracking bug is more accurate than heading bug. A true bug error and a magnetic bug error is calculated and shifted into the -180 to 180 range so that they can be used by autopilots. I've also fixed a property name that crept in when I had to change back to indicated-***. Back then I accidentally changed the desired course name to "indicated-course". The property that is supposed to be the input for the desired course should naturally be named something like "desired-course", and definitely _not_ "indicated-course". If this name change breaks anything it should be fixed in the other end. I've also commented out a lot of #includes that I don't think is needed. I'm on Suse 9.0 now, and it builds fine here, but this might be a problem for different platforms I guess we have to cross our fingers.
2004-04-16 22:12:26 +00:00
* /instrumentation/gps/tracking-bug
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
*
* Output properties:
*
Return to original property names.
2004-03-23 02:44:24 +00:00
* /instrumentation/gps/indicated-longitude-deg
* /instrumentation/gps/indicated-latitude-deg
* /instrumentation/gps/indicated-altitude-ft
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
* /instrumentation/gps/indicated-vertical-speed-fpm
Return to original property names.
2004-03-23 02:44:24 +00:00
* /instrumentation/gps/indicated-track-true-deg
* /instrumentation/gps/indicated-track-magnetic-deg
* /instrumentation/gps/indicated-ground-speed-kt
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
*
Roy Vegard Ovesen: I've added a tracking bug to the gps. This is of course very similar to a heading bug for a DG. I don't know if this is the common name, but I feel that for a gps the name tracking bug is more accurate than heading bug. A true bug error and a magnetic bug error is calculated and shifted into the -180 to 180 range so that they can be used by autopilots. I've also fixed a property name that crept in when I had to change back to indicated-***. Back then I accidentally changed the desired course name to "indicated-course". The property that is supposed to be the input for the desired course should naturally be named something like "desired-course", and definitely _not_ "indicated-course". If this name change breaks anything it should be fixed in the other end. I've also commented out a lot of #includes that I don't think is needed. I'm on Suse 9.0 now, and it builds fine here, but this might be a problem for different platforms I guess we have to cross our fingers.
2004-04-16 22:12:26 +00:00
* /instrumentation/gps/wp-distance-nm
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
* /instrumentation/gps/wp-bearing-deg
Roy Vegard Ovesen: I've added a tracking bug to the gps. This is of course very similar to a heading bug for a DG. I don't know if this is the common name, but I feel that for a gps the name tracking bug is more accurate than heading bug. A true bug error and a magnetic bug error is calculated and shifted into the -180 to 180 range so that they can be used by autopilots. I've also fixed a property name that crept in when I had to change back to indicated-***. Back then I accidentally changed the desired course name to "indicated-course". The property that is supposed to be the input for the desired course should naturally be named something like "desired-course", and definitely _not_ "indicated-course". If this name change breaks anything it should be fixed in the other end. I've also commented out a lot of #includes that I don't think is needed. I'm on Suse 9.0 now, and it builds fine here, but this might be a problem for different platforms I guess we have to cross our fingers.
2004-04-16 22:12:26 +00:00
* /instrumentation/gps/wp-bearing-mag-deg
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
* /instrumentation/gps/TTW
* /instrumentation/gps/course-deviation-deg
* /instrumentation/gps/course-error-nm
* /instrumentation/gps/to-flag
* /instrumentation/gps/odometer
* /instrumentation/gps/trip-odometer
Roy Vegard Ovesen: I've added a tracking bug to the gps. This is of course very similar to a heading bug for a DG. I don't know if this is the common name, but I feel that for a gps the name tracking bug is more accurate than heading bug. A true bug error and a magnetic bug error is calculated and shifted into the -180 to 180 range so that they can be used by autopilots. I've also fixed a property name that crept in when I had to change back to indicated-***. Back then I accidentally changed the desired course name to "indicated-course". The property that is supposed to be the input for the desired course should naturally be named something like "desired-course", and definitely _not_ "indicated-course". If this name change breaks anything it should be fixed in the other end. I've also commented out a lot of #includes that I don't think is needed. I'm on Suse 9.0 now, and it builds fine here, but this might be a problem for different platforms I guess we have to cross our fingers.
2004-04-16 22:12:26 +00:00
* /instrumentation/gps/true-bug-error-deg
* /instrumentation/gps/magnetic-bug-error-deg
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
* /instrumentation/gps/true-bearing-error-deg
* /instrumentation/gps/magnetic-bearing-error-deg
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
*/
Move FGEventMgr and FGSubsystemMgr over to SimGear, add SGEventMgr to FlightGear's globals structre and some small code cleanups
2003-09-24 17:20:55 +00:00
class GPS : public SGSubsystem
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
{
public:
Roy Vegard Ovesen: Instrumentation and systems are now configureable from xml files. The two generic configurations generic-systems.xml and generic-instrumentation.xml configures the systems and instrumentation as it was hardcoded. You can override the generic configurations in a similar way as you override the autopilot configuration.
2004-10-16 12:37:39 +00:00
GPS (SGPropertyNode *node);
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
GPS ();
virtual ~GPS ();
virtual void init ();
virtual void update (double delta_time_sec);
private:
James Turner : Here's a patch which refactors the 'plain' GPS code into a slightly more manageable structure - i.e breaks the large update() method into various sub-functions. I've tested the patch with B1900d, and things seem to work as expected, but if anyone experiences GPS weirdness after this is committed, of course please report it. The motivation for this was helping me learn the code - I've planning some changes in this area, and splitting up the logic will hopefully make that task easier.
2008-12-09 08:10:33 +00:00
typedef struct {
double dt;
SGGeod pos;
SGGeod wp0_pos;
SGGeod wp1_pos;
bool waypoint_changed;
double speed_kt;
double track1_deg;
double track2_deg;
double magvar_deg;
double wp0_distance;
double wp0_course_deg;
double wp0_bearing_deg;
double wp1_distance;
double wp1_course_deg;
double wp1_bearing_deg;
} UpdateContext;
void search (double frequency, const SGGeod& pos);
/**
* reset all output properties to default / non-service values
*/
void clearOutput();
void updateWithValid(UpdateContext& ctx);
void updateNearestAirport(UpdateContext& ctx);
void updateWaypoint0(UpdateContext& ctx);
void updateWaypoint1(UpdateContext& ctx);
void updateLegCourse(UpdateContext& ctx);
void updateWaypoint0Course(UpdateContext& ctx);
void updateWaypoint1Course(UpdateContext& ctx);
void waypointChanged(UpdateContext& ctx);
void updateTTWNode(UpdateContext& ctx, double distance_m, SGPropertyNode_ptr node);
void updateTrackingBug(UpdateContext& ctx);
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
SGPropertyNode_ptr _magvar_node;
SGPropertyNode_ptr _serviceable_node;
SGPropertyNode_ptr _electrical_node;
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
SGPropertyNode_ptr _wp0_ID_node;
SGPropertyNode_ptr _wp0_name_node;
SGPropertyNode_ptr _wp0_course_node;
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
SGPropertyNode_ptr _get_nearest_airport_node;
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
SGPropertyNode_ptr _wp1_ID_node;
SGPropertyNode_ptr _wp1_name_node;
SGPropertyNode_ptr _wp1_course_node;
Roy Vegard Ovesen: I've added a tracking bug to the gps. This is of course very similar to a heading bug for a DG. I don't know if this is the common name, but I feel that for a gps the name tracking bug is more accurate than heading bug. A true bug error and a magnetic bug error is calculated and shifted into the -180 to 180 range so that they can be used by autopilots. I've also fixed a property name that crept in when I had to change back to indicated-***. Back then I accidentally changed the desired course name to "indicated-course". The property that is supposed to be the input for the desired course should naturally be named something like "desired-course", and definitely _not_ "indicated-course". If this name change breaks anything it should be fixed in the other end. I've also commented out a lot of #includes that I don't think is needed. I'm on Suse 9.0 now, and it builds fine here, but this might be a problem for different platforms I guess we have to cross our fingers.
2004-04-16 22:12:26 +00:00
SGPropertyNode_ptr _tracking_bug_node;
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
SGPropertyNode_ptr _raim_node;
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
SGPropertyNode_ptr _indicated_vertical_speed_node;
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
SGPropertyNode_ptr _true_track_node;
SGPropertyNode_ptr _magnetic_track_node;
SGPropertyNode_ptr _speed_node;
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
SGPropertyNode_ptr _wp0_distance_node;
SGPropertyNode_ptr _wp0_ttw_node;
SGPropertyNode_ptr _wp0_bearing_node;
SGPropertyNode_ptr _wp0_mag_bearing_node;
SGPropertyNode_ptr _wp0_course_deviation_node;
SGPropertyNode_ptr _wp0_course_error_nm_node;
SGPropertyNode_ptr _wp0_to_flag_node;
SGPropertyNode_ptr _wp1_distance_node;
SGPropertyNode_ptr _wp1_ttw_node;
SGPropertyNode_ptr _wp1_bearing_node;
SGPropertyNode_ptr _wp1_mag_bearing_node;
SGPropertyNode_ptr _wp1_course_deviation_node;
SGPropertyNode_ptr _wp1_course_error_nm_node;
SGPropertyNode_ptr _wp1_to_flag_node;
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
SGPropertyNode_ptr _odometer_node;
SGPropertyNode_ptr _trip_odometer_node;
Roy Vegard Ovesen: I've added a tracking bug to the gps. This is of course very similar to a heading bug for a DG. I don't know if this is the common name, but I feel that for a gps the name tracking bug is more accurate than heading bug. A true bug error and a magnetic bug error is calculated and shifted into the -180 to 180 range so that they can be used by autopilots. I've also fixed a property name that crept in when I had to change back to indicated-***. Back then I accidentally changed the desired course name to "indicated-course". The property that is supposed to be the input for the desired course should naturally be named something like "desired-course", and definitely _not_ "indicated-course". If this name change breaks anything it should be fixed in the other end. I've also commented out a lot of #includes that I don't think is needed. I'm on Suse 9.0 now, and it builds fine here, but this might be a problem for different platforms I guess we have to cross our fingers.
2004-04-16 22:12:26 +00:00
SGPropertyNode_ptr _true_bug_error_node;
SGPropertyNode_ptr _magnetic_bug_error_node;
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
SGPropertyNode_ptr _true_wp0_bearing_error_node;
SGPropertyNode_ptr _magnetic_wp0_bearing_error_node;
SGPropertyNode_ptr _true_wp1_bearing_error_node;
SGPropertyNode_ptr _magnetic_wp1_bearing_error_node;
SGPropertyNode_ptr _leg_distance_node;
SGPropertyNode_ptr _leg_course_node;
SGPropertyNode_ptr _leg_magnetic_course_node;
SGPropertyNode_ptr _alt_dist_ratio_node;
SGPropertyNode_ptr _leg_course_deviation_node;
SGPropertyNode_ptr _leg_course_error_nm_node;
SGPropertyNode_ptr _leg_to_flag_node;
SGPropertyNode_ptr _alt_deviation_node;
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
bool _last_valid;
James Turner : Here's a patch which refactors the 'plain' GPS code into a slightly more manageable structure - i.e breaks the large update() method into various sub-functions. I've tested the patch with B1900d, and things seem to work as expected, but if anyone experiences GPS weirdness after this is committed, of course please report it. The motivation for this was helping me learn the code - I've planning some changes in this area, and splitting up the logic will hopefully make that task easier.
2008-12-09 08:10:33 +00:00
SGGeod _last_pos;
Roy Vegard Ovesen: I've done som more work on the gps instrument. - You can now input airport-, nav- or fix-ID to select a waypoint. - You have to specify either "airport", "nav" or "fix" in the waypoint-type property (some fixes and navs have identical IDs). - Formatted the time to waypoint output. - Cleaned up and changed some propery names (wp-heading -> wp-bearing). - I've also added a name member to the FGNav class so that the gps instrument can get the name of the nav. - Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
double _last_speed_kts;
James Turner : Here's a patch which refactors the 'plain' GPS code into a slightly more manageable structure - i.e breaks the large update() method into various sub-functions. I've tested the patch with B1900d, and things seem to work as expected, but if anyone experiences GPS weirdness after this is committed, of course please report it. The motivation for this was helping me learn the code - I've planning some changes in this area, and splitting up the logic will hopefully make that task easier.
2008-12-09 08:10:33 +00:00
std::string _last_wp0_ID;
std::string _last_wp1_ID;
Roy Vegard Ovesen: I've added a vertical navigation capability to the GPS module. One can input two waypoints, wp[0] and wp[1], with altitude. If the altitudes differ, then the altitude deviation from a "straigth" line from wp[0] to wp[1] is calculated. The true course and course deviation from wp[0] to wp[1] is also calculated. All this can be found in the wp subdir where one also finds the wp[0] and wp[1] subdirs. All this has to be done through the property browser. Maybe I should make a gui window for the GPS!
2004-05-01 09:40:09 +00:00
double _alt_dist_ratio;
double _distance_m;
double _course_deg;
Roy Vegard Ovesen: - finish cleanup/optimization of instrumentation system (started by mfranz) - improve configuration of special properties by addressing them directly
2006-12-06 22:11:43 +00:00
double _bias_length;
double _bias_angle;
double _azimuth_error;
double _range_error;
double _elapsed_time;
James Turner : Here's a patch which refactors the 'plain' GPS code into a slightly more manageable structure - i.e breaks the large update() method into various sub-functions. I've tested the patch with B1900d, and things seem to work as expected, but if anyone experiences GPS weirdness after this is committed, of course please report it. The motivation for this was helping me learn the code - I've planning some changes in this area, and splitting up the logic will hopefully make that task easier.
2008-12-09 08:10:33 +00:00
std::string _name;
Roy Vegard Ovesen: - finish cleanup/optimization of instrumentation system (started by mfranz) - improve configuration of special properties by addressing them directly
2006-12-06 22:11:43 +00:00
int _num;
Roy Vegard Ovesen: Instrumentation and systems are now configureable from xml files. The two generic configurations generic-systems.xml and generic-instrumentation.xml configures the systems and instrumentation as it was hardcoded. You can override the generic configurations in a similar way as you override the autopilot configuration.
2004-10-16 12:37:39 +00:00
James Turner : Here's a patch which refactors the 'plain' GPS code into a slightly more manageable structure - i.e breaks the large update() method into various sub-functions. I've tested the patch with B1900d, and things seem to work as expected, but if anyone experiences GPS weirdness after this is committed, of course please report it. The motivation for this was helping me learn the code - I've planning some changes in this area, and splitting up the logic will hopefully make that task easier.
2008-12-09 08:10:33 +00:00
SGGeodProperty _position;
SGGeodProperty _wp0_position;
SGGeodProperty _wp1_position;
SGGeodProperty _indicated_pos;
Added simple GPS support (no waypoints yet).
2003-03-10 14:09:43 +00:00
};
#endif // __INSTRUMENTS_GPS_HXX
Copy permalink