Originally created by: kanto... (code.google.com)@gmail.com
*What steps will reproduce the problem?*
1. Fly any aircraft with retractable gear (IAR80 chosen for test)
2. Try to land on the belly or fly very low over the ground with gear retracted
*What is the expected output? What do you see instead?*
Testing if a reasonable
belly landing could be modelled, I have found that the function
checking for altitude < -1 in Model.cpp does not take into account the
gear state (extended / retracted). What happens during testing is that
the airplane is unable to fly lower than *gear_length* - 1 over the
ground, because a crash detection is triggered even if the gear is
retracted. I have modified the code to take into account gear state
and got the correct expected behaviour (see patch attached).
*What version of the product are you using (when using GIT version, please
mention date or Hudson build number)?*
Latest GIT version.
*Please provide any additional information below or as attachment (Avoid
expiring external links, such as to imageshack/pastebin/...).*
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: kanto... (code.google.com)@gmail.com
Here are some snippets of my report to Andy Ross which did not conclude probably due to his lack of time:
As far as I can gather from the code, the position of the gear contact
points is not modified whether the gear is extended or not, in fact it
remains the same as defined via XML.
In Gear.cpp, at Gear::calcForce() + 7, no force is calculated unless
the gear is fully extended. The position is however taken into
consideration at Model::newState() in order to calculate the minimum
agl position overall. Since there is no check for gear extension and
the position of the contact points does not change when retracted, the
contact points will be underground (and won't generate a force) when
aircraft height is gear_length -1 :
if(_agl < -1) _crashed = true;
I have inserted the same check that exists in the function which
calculates the force, which skips the gear if it is not extended.
Perhaps the correct way would be to modify the gear contact point
position during extension and retraction, but I see that as quite
complicated since separate coordinates would have to be made available
in XML, and the position would have to be interpolated between start
and stop according to gear movement.
For collision purposes, the classic contact points automatically
generated from model coordinates still do their job even when gear is
retracted, the only thing that disappears is that crashed state when
the plane's gear is below ground (even when retracted).
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: bre... (code.google.com)@gmail.com
(No comment was entered for this change.)
Labels: YASIM FDM Type-FeatureRequest
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: bre... (code.google.com)@gmail.com
Kantoo, thanks for the patch! Probably a good idea if you posted the description to the devel list (add a link to this bug issue) since I'm not sure if YASim is actively maintained right now. I'm not aware of anyone checking YASim in the tracker here. Maybe some of our FDM experts on the devel list can comment on how belly landing should be modelled and/or test your patch.
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: aeitsch...@yahoo.de
Agree!
Currently belly-landing can be simulated by defining two different contact points.
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: kanto... (code.google.com)@gmail.com
Right now belly landing can be simulated indeed, except for aicraft whose gear positions are more than one meter below the lowest collision point (defined with XML fake gear objects). Thus, in my opinion this is a bug since in some aircraft like the IAR80 a collision is triggered even if the aircraft has not even touched the ground.
I will try to raise this issue on the mailing list.
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: aeitsch...@yahoo.de
has the patch already been committed?
Status: Accepted
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: bre... (code.google.com)@gmail.com
See merge request: https://www.gitorious.org/fg/flightgear/merge_requests/1554
Unfortunately, the patch disables crash detection completely when all gear are retracted (=> "newState" always leaves "min = 1e8" => min>-1 => no crash"), so aircraft indestructible.
I made a local test with a hard-coded gear length - and moving the gear contact point further up when gear is retracted. That keeps the crash detection - but still allows a belly landing. Note, YASim already moves the gear contact point further up depending on gear compression - so a similar calculation depending on gear extension is straight forward. But for a proper patch we'd need to make the gear length configurable (just as the compression length already is). Shouldn't be too much effort to extend YASim with another (optional) gear object parameter. Anyone interested in adding this to YASim?
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: kanto... (code.google.com)@gmail.com
Duly noted, and thanks for reply. I doubt there is need for another parameter, as normal contact points (which are stored as Gear type objects) already have _isContactPoint set, thus maybe needing only a little tweak (Airplane.cpp line 599).
I may be wrong due to the late hour, but I will definetly investigate this issue later.