Difference between revisions of "User:Callahanp"

From FlightGear wiki
Jump to navigation Jump to search
Line 95: Line 95:
====Modules on the Path to Holding Short====
'''Modules on the Path to Holding Short'''
the gdb run command gets things going in gdbgui. Just type "r"
the gdb run command gets things going in gdbgui. Just type "r"

Revision as of 17:14, 13 February 2018

What I'm doing:

I am a flight simulation hobbyist currently working on building instruments, gauges, radios and controls for a C172. 

I'll be working on the interface between Flightgear and low level hardware in a panel or cockpit. It is my understanding that others, including core Flightgear developers are also working on this and my efforts will follow, derive from, depend on and I hope contribute in some small way to their work.

Recently I began the effort to fully understand the skills needed to contribute to the Flightgear project's codebase. I know c++ from a course in the early 90's. I'm looking at Kdevelop and QTquick as development tools.

Flightgear Codebase

My area of interest is in Flightgear's code includes:

  • telnet
  • phi
  • reset & re-initialize
  • any method to set or get a property
  • the property tree itself
  • configuration files
  • command line parameters

I'm beginning to look through various parts of the Flightgear code-base to understand how the parts fit together and how supporting libraries are used in the project. I'd like to learn how aircraft data and graphics are integrated into the working program, and how, why and where Nasal scripting is used. To this end, I have

* Built a full debug version of the next branch
* Installed 
** gdbgui
** atom for basic code exploration.

Later I'll try QtCreator

Here's my directory structure for building

  • $HOME
    • A separate disk to make it easy to reinstall linux. $HOME is the same as /home/$USER
  • $HOME/fg
    • Scripts I need to build and flightgear such as download_and_compile.sh, and /run/debug script
    • This is actually a symlink to a folder on a separate disk from /home.
    • I do this so I can build the software I want without continually expanding my home disk's size.
    • The fg directory contains a folder for each different build of Flightgear.
      • next for running next
      • nextrti for running next with OpenRTI
      • nextd for debugging next
      • stable
      • stabled
    • Each of these directories contains clones for flightgear, simgear and other projects like OSG and OpenRTI as needed.

Rather than use excessive bandwidth, when I need a fresh copy, I just run download_and_compile.sh in a folder that already has a copy of the sources. Then I copy the folder over to the one I want to refresh and remove the build folder within the new one. Then run the script again to produce the executable version I want. As currently structured, download_and_compile.sh requires a separate set of sources for each different version built.

Here's the atom/run/debug script I use for debugging cd $HOME/fg/

# ~/fg/debug 
$cmd = "$HOME/fg/nextd/install/flightgear/bin/fgfs \
  --fg-root=$HOME/fg/nextd/install/flightgear/bin/../fgdata/ \
  --log-level=2 \
  --fg-scenery=$HOME/fg/nextd/install/flightgear/bin/../fgdata/Scenery \
  --fg-aircraft=$HOME/fg/nextd/install/flightgear/bin/../fgdata/Aircraft \
  --fg-aircraft=$HOME/.fgfs/Aircraft/org.flightgear.fgaddon/Aircraft \
  --httpd=5401 --telnet=5400 --airport=KSFO"
 $gdbgui "$cmd"

When the source window appears, press the "r" key to start debugging.

I start by stepping through bootstrap and other modules until flightgear is up and running. I'm making some notes. There are three sections:

  • Path will trace the path through modules that provide significant functionality to the Simulator until the aircraft is shown holding short or parked somewhere. only the module's source path and a brief explanation or list of why it's on the "path".
  • Modules lists all the classes and methods or functions executed on the "path" as well as those that are not executed in the path.
  • Utility Calls will contain notes on various library calls, noting what the call looks like, where the library comes from, what the call does and where else it might be used. These will be functions with a purpose that is not limited to flight simulation.

The Path to "Holding Short"

Module Description Steps
src/Main/bootstrap Bootstrap provides the top level of the stack for executing either fgviewerMain or fgMainInit.
  • Enable Floating Point features with InitFPE
  • Set locale settings specific to using C or C++
  • Uninstall if requested
  • Initialize logging
  • Initialize some static objects in OSG to prevent crashes on exit
  • set the std:: terminate function
  • set the atexit function
  • pass control to the viewer with fgViewerMain or initialize using fgMainInit
  • catch throwables and other fatal error conditions, providing appropriate error messages
src/Main/Main fgMainInit
  • set logging level and enable logging
  • setup globals as an instance of FGGlobals.
Example Example Example

Modules on the Path to Holding Short the gdb run command gets things going in gdbgui. Just type "r"

I'm going to record a list of functions called, in the order they are called in with descriptions where appropriate. to get information about where these functions are located, I'll use the atom's project search or the step into feature of gdbgui. If the call is along the main line of execution, it will be in Bold Face. Paths start with directories under flightgear/src, except for /simgear which is under /simgear. Yes there is a simgear/simgear in the path. There's proably a reason why its not simgear/src

Full Text of Call Called Function Location or Include File Notes
command line in bootstrap.cxx
main(argc, argv)
bootstrap.cxx contains the main function. main.cxx does not.
detectSIMD() bootstrap.cxx returns true if the cpu supports sse2.
gethostname(_hostname, 256) unistd.h glibc returns the hostname of your computer
signal(SIGPIPE, SIG_IGN) signal.h directs SIGPIPE to the SIG_IGN signal handler - Portability: use sigaction() instead
signal(SIGSEGV, segfault_handler) signal.h Flightgear formats the message with a backtrace and exits with std:abort()
segfault_handler (int signo) bootstrap.cxx
initFPE(flightgear::Options::checkForArg(argc, argv, "enable-fpe")) main/options.cxx
checks the command line arguments for the enable-fpe option. Calls InitFPE with the result.
see bootstrap.cxx for more details
signal(SIGFPE, handleFPE) signal.h
We handle Floating Point Exceptions
setlocale(LC_ALL, "")
setlocale(LC_NUMERIC, "C")
setlocale(LC_COLLATE, "C")
return fgUninstall() fg_init.cxx Command line options are checked to determine if uninstall should be called.
sglog() /simgear/debug/logstream.cxx This initializes the log. see logstream.cxx for details
std::set_terminate(fg_terminate); <exception>
sets the standard template library terminate routine
atexit(fgExitCleanup) stdlib.h
registers the given function to be called at normal process termination, either via exit(3) or via return from the program's main(). Functions so registered are called in the reverse order of their registration; no arguments are passed
fgviewerMain(argc, argv) flightgear/Viewer/fgviewer.cxx see viewer topics for details. This is called in bootstrap.cxx if the command line arguments include --viewer
fgMainInit(argc, argv) Main/main.cxx Starts to initialize flightgear. This is called in bootstrap.cxx if command line arguments do not contain --viewer
catch block various termination for most or all errors. Read the end of bootstrap.cxx for more information
flightgear::shutdownQtApp() bootstrap
Done separately from atexit. see bootstrap.cxx for more information
CrashRpt.h #if defined(HAVE_CRASHRPT). This only happens on windows.
Full Text of Call Called Function Location or Include File Notes
from bootstrap.cxx
fgMainInit( int argc, char **argv )
Main/main.cxx all the arguments from the command line are still there
sglog().setLogLevels( SG_ALL, SG_INFO )
/simgear/debug/logstream.cxx Pretty obvious what this does. What does sglog() actually return?
new FGGlobals; Main/FGGlobals.cxx FGGlobals is a bucket for subsystem pointers and properties representing the sim's state. It's constructor populates the values, including the locale, the root node of the property tree, the subsystem, event, command and resource managers. It also adds resource providers for Aircraft, he Aircraft Directory and Add-ons. Question: What is it that makes globals = new FGGlobals a global object. Here it's a local variable isn't it? Wouldn't it go out of scope in things fgMainInit calls?
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.
Full Text of Call Called Function Location or Include File Notes
new FGRenderer Main/globals.cxx
Why is the definition in globals.cxx and in renderer.cxx
new SGSubsystemMgr Main/globals.cxx
What makes a component a candidate for inclusion under the subsystem manager?
new SGEventMgr Main/globals.cxx
SGCommandMgr::instance() Main/fg_commands.cxx

see also:
Scripting/NasalSys.cxx for NasalCommand
SGPropertyNode* root = new SGPropertyNode
props = SGPropertyNode_ptr(root);
all of simgear/props Widely Used How much of the property Node system does one need to understand?
locale = new FGLocale(props);
auto resMgr = simgear::ResourceManager::instance() simgear/misc/ResourceManager.cxx Review: auto and what does the resource manager do?
new AircraftResourceProvider() Local Function
new CurrentAircraftDirProvider() Local Function
new flightgear::addons::ResourceProvider()
init_properties() local function adds property tree nodes for position/, current-view/ and orientation/

sim_time_sec( 0.0 )
fg_root( "" )
fg_home( "" )
time_params( NULL )
channel_options_list( NULL )
initial_waypoints( NULL )
channellist( NULL )

FGGlobals class initializations things to be set later

WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.
Full Text of Call Called Function Location or Include File Notes
fgInitConfig locally defined
  • sets up FG_HOME in the property tree, making sure it exists
  • sets developer-mode when appropriate
  • Read global defaults into globals->get_props() from $FG_ROOT/defaults

Progress on Cockpit Building

As of Feb 1, 2018:

  • I've done only a few prototype circuits
  • have been working to develop skills I'll need to produce a realistic cockpit.
  • Developing skills in Fusion 360 to support 3d Printing and 3d machine tools.
  • Working on tests for a cluster based on Raspberry Pi Zeros
  • Beginning to use a 3d Router
  • Milling into thin prisms and hand polishing disks of plexiglass for illuminating dials in Sim Instruments

As part of my Cockpit Building efforts, I'm also working on


Maybe our projects overlap and maybe I can be of help you in some small way. I love bouncing ideas back and forth in personal or public e-mails. Feel free to contact me about your non-commercial simulation projects.
Email Callahanp through the wiki

I show up occasionally on #flightgear on irc.flightgear.org and am a member of several public forums related to cockpit building.

Callahanp (talk) 09:45, 11 November 2017 (EST)

My Skills
  • Programming in whatever language is available
  • Databases
  • Making the following list of chips do what they do:
  • MCP23XXX Multiplexer
  • MAX7219 Serially Interfaced, 8-Digit LED Display Driver
  • Designing a few types of circuits that work on a breadboard (see electronics below)
My Developing Skills -- Beginner
  • Grokking Flightgear's code base.
  • Very basic machining on a lathe or mill - no significant experience
  • Electronics - Basics - DC, High & Low speed digital circuits, motor control, emi suppression and mitigation
  • Soldering - Learn to deal with small components
  • Designing circuits that make it from breadboard to cockpit.
  • Getting a cokpit project off the ground
  • C++ - Updating coding skills from an early version of C++
  • Avoiding Writing Howtos
My Developing Skills -- Making Good Progress
  • Fusion 360 3dCad
  • 3d Router

The Howtos -- Oh yeah... those...

I'm working on these along side building my cockpit. Some of the early attempts were not that useful. My current approach is to build and document actual hardware. I hope this will be more helpful.

Current Projects:

See below for the my personal rules about these howtos going forward. I had to write these because it was becoming a morass and time waster.

The following is yet another work in progress

Writing Advice to Callahanp from Callahanp  or How to write a Howto.

Rule 1. Brevity.

Rule 2. Real Hardware. If I haven't done it yet I'll talk about it on my personal wiki page. That's where stuff like that belongs.

Rule 3. Project Planning, Building Teams, and anything else about developing a hobby project belong elsewhere. If you want to write about these things, go ahead, but don't do it in a Howto on building something specific like a cockpit. If you haven't done the project yet you'll get it wrong. Plus, you'll sound like a...

Rule 4. Grand visions, Vaporware, Abstract thinking, Advice and other nonsense don't belong anywhere.

Rule 5. Get rid of your darlings. Those witty turns of phrase, that elegant prose, the puns, jokes and asides. Fun to write maybe but not so fun to read. They're distractions. These are things a skillful writer can weave into an uninterrupted smooth train of thought but you're not that good a writer. Don't even try,

'nuff said.