____ __ __ ____ __ ___ _ _
/ __ \___ ____/ /___ _/ / / __ \/ /___ _____ ___ / |_ __(_)___ ____ (_)_________
/ /_/ / _ \/ __ / __ `/ / / /_/ / / __ `/ __ \/ _ \ / /| | | / / / __ \/ __ \/ / ___/ ___/
/ ____/ __/ /_/ / /_/ / / / ____/ / /_/ / / / / __/ / ___ | |/ / / /_/ / / / / / /__(__ )
/_/ \___/\__,_/\__,_/_/ /_/ /_/\__,_/_/ /_/\___/ /_/ |_|___/_/\____/_/ /_/_/\___/____/
This is the design and firmware for a pedal-plane special-effects controller based on the Teensy 3.2 microcontroller. Pedal planes are small pedal-powered airplanes for children aged about 3-7. Some sources of pedal plane kits and plans are PuddleJumpSquadron, Experimental Aircraft Association, and Aviation Products, Inc..
See examples/p-51/ for a working example.
- Complex engine sound (starter, startup, idle, various RPMs)
- The engine can 'auto-start' when the plane begins to move
- Machine gun sound
- occasionally plays 'hit' and 'plane crash' sounds
- Bomb-drop sound
- Navigation lights
- Gyro spool-up sound on master power up
- Bluetooth interface
- Random radio 'chatter' e.g.: Two 109's 12:00 high
- Android app
- Landing lights (TODO)
- 'Zoom' flyby sound
- 'Zoom' plays when pilot turns plane hard (needs tweaking)
- Configuration stored to EEPROM
- overall gain
- gain for various sounds
- machine gun accuracy
The system is built around a Teensy 3.2 microcontroller. The code should run fine or with minimal changes on other large Arduino-like controllers. A google docs spreadsheet contains the roadmap, bill of materials, and pin connections.
Version 1.87 from https://www.arduino.cc/en/Main/Software
Version 1.44 from https://www.pjrc.com/teensy/td_download.html
This project leverages a few Arduino libraries. Please follow the instructions below to install them.
- cd to your Arduino libs directory. (The default is ~/Arduino/libraries on Linux or ~/Documents/Arduino/libraries on Windows)
- clone https://github.com/kdahlhaus/Pedal-Plane-Avionics/
- clone https://github.com/kdahlhaus/EventSystem
- clone https://github.com/kdahlhaus/Arduino-SerialCommand (note that this is not the one in the Arduino lib manager)
- clone https://github.com/thomasfredericks/Bounce2.git
- clone https://github.com/adafruit/Adafruit_Sensor.git
- clone https://github.com/adafruit/Adafruit_LIS3DH
- clone https://github.com/janelia-arduino/Functor.git
- clone https://github.com/jgillick/arduino-LEDFader.git LEDFader (note that library must be in dir LEDFader due to the name of the include files it contains)
- Use the library manager to add:
- n ArduinoLog (or https://github.com/thijse/Arduino-Log/)
You can optionally clone the git repositories somewhere else and make a symbolic link to the library under the IDE's libraries directory. For example: Windows: mklink /D C:\Users\kevin\Documents\Arduino\libraries\Arduino-SerialCommand C:\Users\kevin\prog\arduino\libs\Arduino-SerialCommand Linux: ln -s ~/prog/arduino/libs/Arduino-SerialCommand/ ~/apps/arduino-1.8.6/libraries/
(If you use UECIDE, replace the Arduino directory above with "UECIDE")
The SD is the limiting factor on the number of sounds that can be played at once. Use a high-quality SD card, such as the SanDisk Ultra Micro SD. The maximum size card supported by the system is 32 GB.
The card must be formatted using a FAT32 file system.
Sounds are 16-bit PCM WAV files at 44100 kHz sample rate.
All sounds are located in the root directory of the SD card or in a directory off of the root. These are the required names:
-
bombdrop.wav
-
startup.wav # played once on avionics start (the gyro spool-up)
-
crash.wav # plane crash sound
-
machguns.wav
Motor sounds:
- starters.wav # motor starter sound start
- starterl.wav # motor starter sound loop
- starting.wav # motor starting
- idle.wav # motor idling
- rpm1.wav
- rpm2.wav
- rpm3.wav
- stop.wav # engine stopping
Radio chatter sounds can have any name and are located in:
- /radio/
Zoom sounds can have any name and are located in;
- /zoom/
This is the biggest challenge. I unfortunately do not have the license to distribute all of the sounds I use. I use the Audacity Sound Editor for editing the sounds. Note that with Audacity, you must "export" the sound as a wav file as the "Save" function saves the sound as an Audacity sound project. Most edits include cropping, amplification, fade-in, and fade-out. Some of the youtube videos have a B-17 drone sound effect. Applying a 151 Hz notch filter to the sound decreases that noise. Here are some links to sources of sounds:
- P-51 Sounds for the Flight Gear Simulator TODO: These could actually be distributed as sample sounds.
- Gee-Bee Sounds for the Flight Gear Simulator TODO: These could also be distrubuted as sample sounds.
- IL-2 1946 B-17 Mission This is good for radio chatter.
- P-51 Startup / Fly By
- [Radio turning] (https://www.audiomicro.com/tuning-old-tube-radio-electronics-appliances-tuning-old-tube-radio-free-sound-effects-45484)
- Radio on / off
Soundbible.com has many free sounds, many licensed so that they can be distrubuted if attriubtion if given to the author.
The main aspects of the code's architecture are:
- Event-Driven
- Object-Managed Setup
- Code Conventions
Components communicate through events. An event is a combination of an event number (defined in avionics_events.h) and an optional parameter. There can be an arbritary number of sources and responders for a given event. Most of the time, the sources for an event are a switch and the serial interfaces. The most common pattern of event usage within the program is that a given event is generated by a switch and the serial interfaces and handled by a single domain object. DROP_BOMB is a good example of an event that follows this pattern.
For example, the machine-gun switch sends a "MACHINEGUNS_START" event when it is pressed. The machine-guns listen for this event and begin shooting the machine guns when it is received. For now, shooting means playing the sound, but it could also mean synchronizing machine-gun flashes as well. MACHINEGUNS_STOP is sent when the button is released and the machine-guns stop.
This allows events to come from the USB terminal or bluetooth connection and cause the exact same effect as the physical switch.
The common pattern in Arduino sketches is to implement a function called 'setup' that contains hardware-related setup such as setting input / outuput pins. I wanted objects in the system to control and setup the hardware they use as appropriate. For example, a Switch object sets the pin it uses as an input. I have handled this by dynamically allocating these objects within the 'setup' function and having the constructors of the objects set the hardware configuration as appropriate. This means that these objects must be constructed within the context of the 'setup' call. This is not enforced by code but creating objects outside of setup may not work as desired. Memory fragmentation is not a concern because these objects live the entire lifetime of the program and are not deleted and recreated during execution.
This hides details (keeping the main sketch clean) and ensures correct configuration.
The downside is that high-level objects must be dynamically allocated within the setup() call.
- Hardware configuration in the constructor
- Objects should handle their own hardware configuration in the constructor.
- Objects are dynamically allocated within 'setup.'
- Update
- Objects that need to 'run' or be periodically updated implement a member function called 'update.' This is added to the 'loop' function in PedalPlaneAvionics.ino.
- Events
- Domain objects communicate or are triggered by events defined in 'avionics_events.h'
- Events should have a command defined in 'interpreter.cpp'
- Coding style
- I'll start off by apologizing for the mixture of camel-case and underscores separating the words. I've been out of the C/C++ world for some time and so went back and forth a bit when starting this project. My intention is to stay with camel-case and to slowly refactor any underscored variable or function names.
- A similar case exists for brackets.
- Pedal Plane Group on Facebook Lots of ideas on features and motivation to pursue this project. I've used ideas from Mike Badger and Alex Romero in particular. Thanks!
- Open Panzer is an open-source Teensy-based sound system for model tanks. I've used ideas from it (no code) in designing the Pedal Plane Avionics.
This project is licensed under the GNU GPL 3.0. My intent is for it to be freely used and modified. If you distribute modified code though you have to make your modifications available in source form.