Re: [Jsbsim-devel] Slaved FDM

[Curtis O. <cur...@gm...>]

On Fri, Jan 1, 2010 at 4:21 PM, David Culp wrote:

> Happy New Year!
>
> I was visiting the openAE website and the image of Virgin Galactic's
> launcher/spaceship duo reminded me of earlier dicussions here concerning
> running JSBSim in a slaved mode.  To be clear, by "slaved mode" I mean
> running the FDM for the carried object, in this case the spaceship, in a
> mode which looks to an outside application for position and orientation.  In
> this case the slaved object would run the EOM backwards to keep the velocity
> and acceleration values populated with meaningful values, so that at the
> time of release (when the object is un-slaved) the EOM can then be run
> normally with proper initial values all along the EOM chain.
>
> Would this be a good time to renew discussion?
>
> Note:
> In this scenario I see the launcher as an AI object only, not as a
> JSBSim-powered object.
>
>
Hi Dave and Jon,

I have another potential usage case that might benefit from something
similar.   Let me state up front this isn't fully thought out!

I do quite a bit of UAV work these days.  Typically we use inertial sensors
(gyros and accelerometers) in combination with gps to estimate the current
location and attitude of the vehicle.  Gps arrives at a slower rate than the
inertial data.  Given an initial state (location, velocity, attitude) we can
estimate our new location, velocity vector and attitude moving forward in
time based on the inertial data alone, and sometime in the future (i.e. once
a second) we receive a gps reading and that combined with a few tricks
allows us to correct our location, velocity, and attitude estimate.

What we think might be interesting to investigate is to build up a flight
dynamics model of our vehicle and use that in real time (with knowledge of
the control surface locations) to provide another way to estimate our
location, velocity, and attitude as time progresses.  The results of
crunching the equations of motion could be used to help constrain potential
errors, the results could be rolled into the kalman filter along with
everything else, we could compute an attitude estimate at a higher rate than
the sampling rate of our inertial sensors.

I think in basic theory, what I would like to do is similar to what Dave is
proposing ... the idea of running the equations of motion and keeping the
pipeline full of good data, but slaving the position, velocity vector and
attitude to some external reference and being able to update/reset these
basic location/attitude state values without blowing everything up
internally.

I know Dave is talking about executing the inverse of the EOM, but I'm not
able to turn my head inside out on a holiday. :-)

Curt.
-- 
Curtis Olson: http://baron.flightgear.org/~curt/