there was the situation where four directories contained jst two files,
of which three directories were aircraft related, and one directory contained
test code from Curt that might be better of in SimGear anyhow.
This is just a patch to move a bunch of files to new locations. In case of
local changes to any of them you can do the following:
move replay.[ch]xx from src/Replay to src/Aircraft
move control.[ch]xx from src/Control to src/Aircraft
move ssgEntityArray.[ch]xx from src/Objects to simgear/screen
In addition it has been decided only to use .[ch]xx files in all directories
unless it's contained within an FDM specific directory, in which case the
author is free to do whatever (s)he wants.
In this repspect the following files have been renamed in src/Multiplayer:
tiny_xdr.[ch]pp has become tiny_xdr.[ch]xx
multiplaymgr.[ch]pp has become multiplaymgr.[ch]xx
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
I found that all the current users of the companion
function, findByFreq() actually did assume radians despite the misleading
comment in the .hxx and .cxx saying it's degrees. I've fixed the
comment now, and no longer change the Navaids code. The new Navaids user
in NewWaypoint() is now passing radians to the findByIdent().
Note that along with fixing the comments in the navlist.hxx, I removed
an obsolete method findByLoc() declaration (there is no definition
anywhere).
I've prepared a patch as suggested by Hans-Georg Wunder and Jeff McBride.
In addition I've removed the ability to completely leave out the integral
action by setting Ti to zero. The velocity form of the PID algorithm _needs_
the integral action.
>> Hello List,
>>
>> I think there's a small bug in the moving-average filter in
>> xmlauto.cxx
>>
>> I noticed that the output from it was always out a bit and
>> checking with a calculator showed that it seemed to be dividing
>> by the number of samples + 1 instead of just the number of
>> samples.
>>
>> subtracting 1 from 'samples' in line 702 seems to fix the problem
>> and as 'samples' doesn't seem to be used elsewhere I think it's
>> safe. Possibly implies that the number of samples may be one
>> less than specified but I'm not familiar enough with c++ to spot
>> it.
Roy Ovesen:
You are right. I would suggest resizing input[] to (samples + 1) instead.
Change lines 654 and 661 to:
input.resize(samples + 1, 0.0);
That way we average over the number of samples as configured.
I just heard from John Wojnaroski that you and he are going to work on getting
a flightgear demo machine up for the linux expo thursday and Friday. John
indicated that he would very much like to get a CVS version with the new
traffic code up and running before the expo.
I've added some features to the PID controller:
Ability to set desired sampling interval in seconds. Use <Ts> under <config>
to set the desired sampling interval of the PID controller.
Example:
<config>
<Ts>0.1</Ts> <!-- desired sampling interval -->
<Kp>-0.05</Kp> <!-- proportional gain -->
<beta>1.0</beta> <!-- input value weighing factor -->
...
...
</config>
Ts defaults to 0.0, so if you don't set it it samples at the highest possible
frequency.
Add an offset to the input variables (input and reference).
Example:
<reference>
<prop>/controls/flight/elevator</prop>
<scale>-1.5</scale>
<offset>1.0</offset>
</reference>
Note that <scale> has higher precedence than <offset>, regardless of the order
that they appear in the config file.
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
I've added some digital filters to the autopilot. They are all low-pass
filters that filter away high frequency signals/noise. There are 4 different
filters:
1. Exponential - The algorithm is essentially the same as the one used in the
fgGetLowPass() function.
2. Double exponential - Two exponential filters in series. This filter has a
"steeper" frequency response curve. It filters "better" than the single
exponential.
3. Moving average - Averages a number of inputs.
4. Noise spike - limits the amount that the output value can change from one
sample to the next.
Filters 1 and 2 are characterised by it's filter-time in seconds. For filter 3
you have to set the number of input samples to average over. For filter 4 you
set the maximum allowed rate of change as [1/s]. Since the sampling interval
(dt) isn't constant we have to calculate the maximum allowed change for every
update.
Example of a double exponential filter with filter time 0.1 seconds, that is
1/0.1 = 10 Hz.
<filter>
<name>pressure-rate-filter</name>
<debug>true</debug>
<type>double-exponential</type>
<input>/autopilot/internal/pressure-rate</input>
<output>/autopilot/internal/filtered-pressure-rate</output>
<filter-time>0.1</filter-time>
</filter>
This would go in the autopilot configuration file.
I've also removed the filtering of the "pressure-rate" helper value, use the
new filters if you want to filter it! ;-)
This patch adds the ability to do a simple scaling of input without having to
add hardcoded helpers. Example:
<reference>
<prop>/autopilot/settings/vertical-speed-fpm</prop>
<scale>0.01667</scale>
</reference>
Add FGPredictor class to xmlauto. Add support for horizontal navigation based
on flight track as opposed to heading. Add crosstrack-error support to nav.
Simplify error adjust calculation for horizontal nav (better interception).
Fixed potential divide by zero that was producing nan issues in the xmlauto
code.
I've done some changes to xmlauto.cxx.
Only calculate the derivate filtering if derivate time Td is greater than
zero. This means that one can set Td=0.0 in the xml file to completely remove
the derivate action. (Setting Td to zero in the current version would lead to
a division by zero and crash.)
Setting the integrator time Ti to zero doesn't make sense, right! I've
modified so that setting Ti to zero results in the integral action being
completely removed.
seem to be fully deterministic in P-only mode. This old simple controller
does what I expect, so it's good for calulating stage #1's of multi-stage
controllers.
controls in the cockpit vs. which wheels they apply to. FlightGear now
sets /controls/gear/brake-left, /controls/gear/brake-right, and
/controls/gear/brake-parking. It should be up to the FDM to sort out
which wheels under which circumstances are affected by these controls
and ultimately what happens to the physical motion of the aircraft.
This has been on my local copy for a while (well tested :-))
It fixes a problem with the auto throttle jumping around needlessly. Adjustments are calculated based on the last calculated autothrottle setting rather than reading the throttle setting from the property tree.
These changes should preserve previous functionality (with the exception of a
couple bug fixes).
Bugs fixed:
- AP no longer resets the error accumulator when switching altitude modes or
just closing the autopilot GUI. It will not be necessary to collect the barf
bags after selecting a new altitude anymore. Makes things much smoother.
- climb_rate calculation in the altitude hold mode included a factor that made
sense for the c172. It is now scaled according to the configuration's target
climb rate.
Additions:
Autothrottle (supports speed control only) is more configurable and accurate.
VerticalSpeed mode added (automatically arms to altitude if flown toward
altitude setting).
Exposed various properties, added new lock properties.
clarity:
nav_radial => nav_target_radial (same as selected, except for a LOC)
nav_heading => nav_reciprocal_radial
nav_magvar => nav_twist (it's not always the same as magvar)
nav_heading_needle_deflection => nav_cdi_deflection
nav_gs_needle_deflection => nav_gs_deflection
Added nav_radial back in, but now it shows the current radial from the
VOR, as one would expect. This value also appears in the
/radios/nav[*]/radials/actual-deg property.
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.
I modified the files in src/Autopilot to add waypoint capabilities to the telnet port.
'set waypoint <WPT>' will set the next waypoint.
'get waypoint' returns one string which is the list of waypoints.
'set waypoint 0' will delete the next waypoint.
