Menu
▾
▴
jsbsim-devel
|
From: David C. <dav...@co...> - 2010-01-01 22:21:53
|
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. Dave |
|
From: Curtis O. <cur...@gm...> - 2010-01-01 22:40:55
|
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/ |
|
From: Jon S. B. <jon...@co...> - 2010-01-02 06:06:40
|
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/ Curt, It sounds like what you want is the ability to set (or reset) the state vector for a simulated vehicle model at will. At that time you could fly out the model for as long as desired. There are a few functions calls in JSBSim that could be helpful, but I don't think they have been applied exactly to what you want to do, yet. FGFDMExec::RunIC() // Requires the FGFDMExec::IC structure to be populated. FGState::Initialize(FGInitialCondition *FGIC) FGPropagate::Initialize(FGInitialCondition *FGIC) Jon |
|
From: Jon S. B. <jon...@co...> - 2010-01-02 05:54:58
|
> 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. It has long been my hope to develop the "child" modeling capability that currently has "stubs" set up in JSBSim. The idea is that a <child> element within a "master" aircraft config file would cause the instantiation and loading of an FGFDMExec instance that is controlled by the master FGFDMExec instance. The child vehicle would update its state vector (location, orientation, velocity, attitude rates) based on the master (parent) vehicle. The child vehicle would be placed at a known location that relates the Vehicle Reference Point (VRP) of the parent and child vehicles. But, there are a lot of details that would need to be worked out for this to work. I think Dave is proposing something different than the multi-body sim capability that I am describing. For all cases, though, there does need to be a way to set the state vector for a given vehicle. That would have to include setting past values, as well. Then there's the question of how you detach a child vehicle. And lots of other questions. Jon |
|
From: Leonardo F. G. <fab...@gm...> - 2010-01-03 03:56:50
|
On Sat, Jan 2, 2010 at 12:54 AM, Jon S. Berndt <jon...@co...>wrote: > > For all cases, though, there does need to be a way to set the state vector > for a given vehicle. That would have to include setting past values, as > well. Then there's the question of how you detach a child vehicle. And lots > of other questions. > > Jon > > Well, I don't want to change the topic, but... One question that will surely arise if this parent-child modelling is made possible, is how to model the aerodynamic effects of the parent ship on the child during the first seconds after release. For this the downwash and sidewash from the parent ship would need to be known at different locations around it, data which is not easy to know. This issue has been discussed before referring to in-flight refuelling modelling; I just can't recall what was the conclusion, or final words... Fabian |
|
From: Jon S. B. <jon...@co...> - 2010-01-03 05:22:54
|
Yes, I've thought about this. There are several ways that one could do this. Each body could have its own aerodynamic model. Alternatively, the master vehicle could model the combined aerodynamic characteristics. Also, for each flight "mode" - that is for each vehicle configuration - there could be a flag set that would cause the aerodynamics subsystem for each body to calculate the aerodynamics specifically for that mode. Proximity effects could be modeled similarly, if the simulation executive tracks the relative distance between the vehicle parts. Jon From: Leonardo Fabian Grodek [mailto:fab...@gm...] Sent: Saturday, January 02, 2010 9:57 PM To: Development issues Subject: Re: [Jsbsim-devel] Slaved FDM On Sat, Jan 2, 2010 at 12:54 AM, Jon S. Berndt <jon...@co...> wrote: For all cases, though, there does need to be a way to set the state vector for a given vehicle. That would have to include setting past values, as well. Then there's the question of how you detach a child vehicle. And lots of other questions. Jon Well, I don't want to change the topic, but... One question that will surely arise if this parent-child modelling is made possible, is how to model the aerodynamic effects of the parent ship on the child during the first seconds after release. For this the downwash and sidewash from the parent ship would need to be known at different locations around it, data which is not easy to know. This issue has been discussed before referring to in-flight refuelling modelling; I just can't recall what was the conclusion, or final words... Fabian |
Thanks for helping keep SourceForge clean.
X