Lee has added two new filter types, "gain" and "reciprocal". These filters can
read their gain factor from a property. In the process we also added minimum
and maximum output clamps that are applicable to all filters.
I added the ability to configure adaptive controllers i.e. the controller gain
can be tied to a property, so that it can be changed at runtime. This
requires a change in the xml structure of the autopilot configuration file:
<Kp>
<prop>/autopilot/KAP140/settings/ROL/Kp</prop>
<value>0.10</value>
</Kp> <!-- proportional gain -->
The old method <Kp>0.10</Kp> still works so as to not break all existing
autopilots, but it will output a warning to use the new method.
Please find attatched a new version of xmlauto.cxx.
Remove the call to build() in reinit(). This prevents build() from being
called twice when Reload Autopilot is selected from the Debug menu.
I've also added the ability to define an enabled property for the filters.
It's used like the PID controllers. If there is no enabled tag then the
filter defaults to enabled so that nothing should get broken by this change.
This ability can be used to create a filter between the output of a PID
controller and the property that it controls (a control surface). By putting
a noise spike filter between the output of a controller and the control
surface that it controls, we can simulate the limited movement rate that is
inherent in autopilot servos.
autopilot with the servos off. In otherwords, the computer goes through the
motions of computing the desired behavior (pitch or roll) but doesn't actually
drive the outputs. This is potentially useful when implimenting a flight
director.
SGPropertyNode to guarded ones. This is also done for JSBSim/JSBSim.hxx,
for which JSB had given explicit permission a while ago. I postponed that
back then, but now is the time.
The ufo sets this to a very low value, "serious" aircraft (which don't want this
unrealistic automatism at all) set it to a very high value, and those that don't
care ... don't need to care.
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.
