I am a flight simulation hobbyist currently working on building instruments, gauges, radios and controls for a C172.
- 1 What I'm doing:
- 1.1 Flightgear and Simgear Code
- 1.2 IDEs
- 1.3 Figuring out how to contribute to FlightGear
- 1.4 Progress on Cockpit Building
- 1.5 Contact
- 1.6 My Skills
- 1.7 My Projects
- 1.8 UFO? You decide...
- 1.9 The Howtos
What I'm doing:
Recently I began the effort to fully understand the skills needed to contribute to the Flightgear project's codebase. 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.
These are nearly ready for publicatiion
[[User:Callahanp/Flightgear_and_Simgear_Code/Tools_for_a_Flightgear_Developer|Tools for a Flightgear Developer] (see also Tools of the Trade)
From Command Line to Holding Short
From Command Line to Holding Short. A look at what gets called when you start Flightgear from the command line until you are on the runway.
Flightgear and Simgear Directory Descriptions and File Counts
Flighgear/Simgear Code Exploration Project
Why I'm reading code
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. While I could just focus on the property tree and network interfaces, I still want a basic understanding of all areas of flightgear.
Working on Configurations for Eclipse and QTCreator IDEs
Figuring out how to contribute to FlightGear
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
- User:Callahanp/Two Way Communication between a Raspberry Pi and Arduinos
- Connecting to a Raspberry Pi Zero via USB Ethernet Including the use of SSH and connection of the zero to the internet
- Creating a cluster with Raspberry Pi Zeros
- Snippets of text that may or may not be used somewhere
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)
- Programming in whatever language is available
- 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
- Tormach 1100 CNC Mill
UFO? You decide...
Flightgear of the Future.
There's been recent discussion of what it would take to write Flightgear from scratch today.
I think a better question is how to go about undertaking any major restructuring of Flightgear's codebase to take advantage of modern tools and techniques. And I think we already have an answer to that.
In fact, there's an excellent example happening right now in the Spring of 2018. It's Edward's work on unit testing and the restructuring of the subsystem manager. If you're interested in how big changes come about I'd suggest reading everything related to this effort rather closely and following the ongoing discussion over the need to refactor the way flightgear subsystem dependencies are handled. Look not just for the technical details, but for the way Edward limited the scope of his current activity and for the quality of the interactions between the interested parties. I think its a model for anything major anyone wants to undertake in Flightgear. In fact this kind of interaction is nothing new in the flightgear project. Other examples abound. Everything from the adoption of OSG to QT has gone through a similar process.
Those of us who want to be involved in big changes need to know this process well. So read the mailing list entries in detail and notice the choices people are making and the reasons why. The last thing anyone wants is divisive discussion over direction or choices already made. Especially where the root of the discussion is a misunderstanding or refusal to recognize how the project actually works over a period of time.
So now here's my take on what would be a big Flightgear code change - Multicore Processing and Clusters. The changes in play today lay the groundwork for this.
* If you were to write FlightGear today... * Designs for the subsystem manager factory * Code formatting for the whole FlighGear codebase * Questions about the TestSuite * CppUnit branches for merging
-- 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.
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 & Software. 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,