Board index FlightGear Support Compiling

Debug autopilot code using gdb in flightgear simulation

Building FlightGear from source, and in the need for help?

Debug autopilot code using gdb in flightgear simulation

Postby developb » Thu Mar 05, 2020 3:50 pm

Hi,

I have build flightgear from source and could fly v22 ausprey model.
To debug, I have added -g option in the file src/Main/CMakefiles/fgfs.dir/flags.make at C_FLAGS and CXX_FLAGS.

I could set breakpoint at main() but the breakpoint at PIDController::update() or Autopilot::Autopilot() did not work.
I am still looking at it, if I need to enable follow-child mode option in gdb session...and would update the result, but suggestions are welcome.
I am new to cmake framework and seems I enabled -g option in an intermediate file probably... kindly correct.

Thanks in advance.
developb
 
Posts: 2
Joined: Thu Mar 05, 2020 3:41 pm

Re: Debug autopilot code using gdb in flightgear simulation

Postby wkitty42 » Thu Mar 05, 2020 5:06 pm

you don't need to edit any files to build a debug flavor, AFAIK... there is just a parameter that's passed and the build system takes care of the rest...

eg: /path/to/cmake -DCMAKE_BUILD_TYPE=Debug blah blah blah

valid values for FlightGear and SimGear are Debug, RelWithDebInfo, and Release... RelWithDebInfo is the default for FG releases...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 6488
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Debug autopilot code using gdb in flightgear simulation

Postby Hooray » Thu Mar 05, 2020 9:03 pm

What exactly is it you're trying to do? I mean, what is the reason for even trying to use gdb here? There are so many layers of indirection involved here, that there are more straightforward ways by modifying the code rather than using something like gdb which has no notion of properties, listeners, tied properties, nasal code etc

Finally, I believe the whole AP system is set up as a singleton, or rather used to be - meanwhile there is also the property rule mechanism.

But it would be better to tell us what exactly you'd like to do, and why.

Using gdb to debug an autopilot in flightgear seems rather low level, almost akin to writing assembly code to develop a new autopilot in fgfs
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11835
Joined: Tue Mar 25, 2008 8:40 am

Re: Debug autopilot code using gdb in flightgear simulation

Postby developb » Fri Mar 06, 2020 9:01 am

@wkitty42 Tried cmake with debug option; did not work. ( -DCMAKE_BUILD_TYPE=Debug)

@hooray
I want to understand code flow. As simple as that.
I understand the framework should be using xml file based data to generate tuning variables etc needed for the autopilot code.
I want to start here.

I am trying to get hands on over autopilot code/framework in flight gear, simultaneously understand software design, intermediate values during code flow using pid controller, the guidance loop and autopilot loop how they are designed etc. Rather than code walkthrough, I feel like spending some time debugging.

Can you help me with the smartest way out...
developb
 
Posts: 2
Joined: Thu Mar 05, 2020 3:41 pm

Re: Debug autopilot code using gdb in flightgear simulation

Postby wkitty42 » Fri Mar 06, 2020 3:22 pm

developb wrote in Fri Mar 06, 2020 9:01 am:@wkitty42 Tried cmake with debug option; did not work. ( -DCMAKE_BUILD_TYPE=Debug)

more details are needed to be able to progress...

FWIW: i use the *nix download_and_compile.sh script and the above define is all we use... nothing else is needed...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 6488
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Debug autopilot code using gdb in flightgear simulation

Postby Hooray » Wed Mar 11, 2020 3:48 pm

developb wrote in Fri Mar 06, 2020 9:01 am:@wkitty42 Tried cmake with debug option; did not work. ( -DCMAKE_BUILD_TYPE=Debug)

@hooray
I want to understand code flow. As simple as that.
I understand the framework should be using xml file based data to generate tuning variables etc needed for the autopilot code.
I want to start here.

I am trying to get hands on over autopilot code/framework in flight gear, simultaneously understand software design, intermediate values during code flow using pid controller, the guidance loop and autopilot loop how they are designed etc. Rather than code walkthrough, I feel like spending some time debugging.

Can you help me with the smartest way out...


The FlightGear autopilot system is a different beast, you basically need to understand some important concepts first, before it makes sense to use a debugger or breakpoints


http://wiki.flightgear.org/Property_tree
http://wiki.flightgear.org/PropertyList_XML_File
http://wiki.flightgear.org/Autopilot
http://wiki.flightgear.org/Autopilot_Co ... _Reference
http://wiki.flightgear.org/Autopilot_Tuning_Resources

Only once you understand how these things hang together (XML files loaded into a property tree data structure, which is in turn traversed to procedurally create a number of C++ data structures, which are in turn also property driven, will it make sense to look at the lower level implementation details)

Personally, I would use logging at the XML level - or look at the internals using FlightGear's 2D drawing support:

http://wiki.flightgear.org/Oscilloscope_addon
Image

http://wiki.flightgear.org/Canvas_Snippets
http://wiki.flightgear.org/FGPlot


The "oscilloscope" addon could be easily extended to specifically support common autopilot elements and then track/display those as you wish.
This is implemented in a Javascript-like language that runs inside FlightGear, called "Nasal" - see the wiki for details.

With all that being said, I would probably start using FlightGear's built-in logging support (--log-level), and then set up "debug" for the AP in question, while disabling everything else (minimal startup profile, as per the wiki)

You will find all relevant files here: https://sourceforge.net/p/flightgear/fl ... Autopilot/

The common baseclass is this one: https://sourceforge.net/p/flightgear/fl ... ponent.cxx

(Note "debug" support there, which you could activate and/or extend as needed)

This would also be the right place to track code flow/callgraphs

For input value handling, refer to: https://sourceforge.net/p/flightgear/fl ... tvalue.cxx

The whole AP system is set up here: https://sourceforge.net/p/flightgear/fl ... opilot.cxx

For the initialization of the system, refer to $FG_ROOT/Main/fg_init.cxx, you will see two instances being set up there - one for FDM-rate coupled systems, and one called "property-rules" for framerate-coupled systems: https://sourceforge.net/p/flightgear/fl ... t.cxx#l911
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11835
Joined: Tue Mar 25, 2008 8:40 am


Return to Compiling

Who is online

Users browsing this forum: No registered users and 1 guest