Giter Site home page Giter Site logo

joshua-jerred / giraffe Goto Github PK

View Code? Open in Web Editor NEW
0.0 1.0 0.0 57.37 MB

A Unified High Altitude Flight Observation and Control System. With homogeneous software and hardware, both on the ground and in the air.

Home Page: https://giraffe.joshuajer.red/

License: Other

CMake 1.62% C++ 60.75% HTML 0.34% JavaScript 22.15% Python 3.94% Shell 1.12% CSS 7.85% Dockerfile 0.04% C 2.19%
aprs amateur-radio psk31 raspberry-pi sstv weather-balloon

giraffe's Introduction

Giraffe Unit Tests

Giraffe

A Unified Flight Command and Control System


Learn More About it

Read about why I'm doing this: https://joshuajer.red/Giraffe-Introduction/

Detailed software documentation (Doxygen): http://giraffe.joshuajer.red/

Check out the Giraffe GitHub Project to see what I'm currently working on.


Photos

Giraffe Network Diagram The Giraffe Network - A diagram of Giraffe's components and how they interact with each other.

The flight computer prototype 2 PCB on top of a Pi 4. It's accompanied by the SA868 testing PCB with a dummy load antenna and it's supporting PCM2902 sound card testing PCB. Connected with debugging spaghetti.

The Data Monitor Page from GWC The Configuration Page from GWC This is the web client, used to configure the flight computer on the ground and to monitor/control it in the air.


Table of Contents


About

Giraffe is a "flight command and control system" first developed for high altitude balloon flights.

The purpose of this project is mainly to have a 'learning lab' where I can experiment with all of the things that I'm interested in. This includes C++, Linux Embedded Development, Circuit Design, RF/Amateur Radio, Node.js, CI, interfacing hardware with the web, meta-programming, and more.

The system includes the following key components:

  • GFS Giraffe Flight System
    • The hardware and software that actually flies
  • GGS Giraffe Ground Station
    • Software that helps interface with the flight system both on the ground and in the air.
  • GDL Giraffe Data Link
    • The hardware and software used on both GFS and GGS to connect them together via long distance radio links.
  • GWC Giraffe Web Client
    • A web client to easily configure, control, and monitor all Giraffe components in one place.

Current High Level Functionality

  • Detailed configuration via the web interface of all system components.
  • Telemetry support for APRS, SSTV, and Data Packets.
  • Aggressive error handling for all software components. Everything is designed to be able to fail gracefully and recover when possible.
  • Detailed and configurable logging of data and telemetry.
  • Drivers/Firmware for the Raspberry Pi BCM interface along with many different sensors, radios, and other hardware.

Planned High Level Functionality Prior to the First Flight

  • Two way communication via GDL

Development Details

The flight software is written in C++, the web interface and ground stations are written in Node.js, and some Python is sprinkled in.

There are common components, including a large collection of configuration and data point metadata files that are used to generate code for both the flight system and the ground station. For example, to add a configuration option for the flight computer, you just need to add the information to the metadata file, run the generator, rebuild, and redeploy. It will then be inside of the flight software, configurable via the web interface, and safely implemented to restrained values to prevent misconfiguration. This works for integers, floats, strings, and enums.

Being a 'learning lab' project, nearly everything is built from the ground up including my own implementations of:

  • Linux I2C and Serial wrappers
  • BCM Interface for direct GPIO control on the Raspberry Pi
  • Device Drivers
    • BMP180 (I2C Environmental Sensor)
    • BME280 (I2C Environmental Sensor)
    • SAM-M8Q (I2C GPS using the UBX protocol)
    • SA868 (2w VHF Radio Module)
    • MCP3021 (I2C ADC)
  • Modulation (Using my WAV file generation and Modulation library)
    • PSK - For data packets
    • AFSK, AX.25, APRS (Position and Telemetry) - For tracking via aprs.fi
    • SSTV (Robot36) - For image transmission
  • A web interface for flight computer debugging, configuration, and control
  • Custom hardware for the flight computer
  • Simple configuration file for the flight computer

Libraries that I've written for this project:

Where I used existing 3rd party libraries:

  • JSON parsing for the web server module and configuration reading (nlohmann/json)
  • Image Manipulation for PNG/JPEG support in my SSTV Image Tools Library (Magick++)
  • Google Test for unit testing

Everything is designed to be modular and extensible so that it can be used for all types of HAB flights or even some other future implementations where command and control is needed. The software is made to work on any ARM based single board computer that runs Linux, like the Raspberry Pi but it is targeted towards the Pi Zero 2 and Pi 4.

The framework utilizes open communication protocols/modulation modes like APRS, AFSK, PSK31, and SSTV to allow for easy integration into existing software. Two way communication, which is currently in development, allows you to send commands to the flight computer from the ground station. There is a lot more included that isn't mentioned here, so please see the rest of the documentation.

Too see my more older, simplified, python implementation of this project check out the the AOS repo.


Hardware

I'm currently working on hardware prototypes.

The flight computer is (will be) made up of two boards; it is targeted towards the Raspberry Pi Zero 2 and maintains the same footprint. The Raspberry Pi will be sandwiched between the two boards, with the top board being the "hat" and the bottom board being the "shoe".

Hat

The hat contains the majority of the circuitry. It is a four layer PCB containing the following:

  • Power Management
    • Connects to the battery (21700 Cells) via a terminal block
    • Includes a 5v linear regulator and support circuitry, this powers the Pi and the other PCB
    • Voltage Divider for battery voltage measurement
  • Sensors
    • BME280 (Temperature, Pressure, Humidity)
    • MCP3021 (Battery Voltage)
    • CAT24C32 (EEPROM, GPIO Configuration at boot)
    • BMI088 (6 Axis IMU)
  • 2x 1-Wire Headers for DS18B20 Temperature Sensors
  • 1x I2C Header for general expansion

image image

You'll notice a lot of open space on the top of the PCB, this is to isolate the SAM-M8Q and to provide it a large ground plane. Although the ground plane size is out of spec I have had no issues with acquiring and maintaining a GPS lock.

Known Issues

There are a few known issues with prototype 2:

  • Power Management! I'm currently working on replacing the linear regulator with a boost converter.
  • The BME280 is too close to the power supply. This results in much higher temperature readings and inaccurate pressure/humidity readings as they're temperature compensated.

Other than that, this prototype is working great!

Shoe

The shoe contains the telemetry circuitry. It is a four layer PCB containing the following:

  • SA868 (2w VHF Radio)
    • Isolation circuitry to prevent interference with the Pi
    • Serial Logic Level Converter (3.3v to 5v)
  • Low Pass Filter and SMA Connector
  • Integrated PCM2902 Audio Codes
    • USB interface with the Pi
    • 2x input channels, 2x output channels, only one of each is currently used.
  • An attempt to impedance match the RF traces from the SA868 to the SMA connector and provide shielding.

The radio will be on the very bottom of the hardware stack, hopefully isolating it from the rest of the hardware.

Front image

Back image

Known Issues

  • Power control circuitry is not functional. Although 5v power is fully cut off with the GPIO controlled optical relay, the SA868 still draw power from the serial logic level converter. This results is the SA868 being unreliable after restarts and frequency changes. More isolation needs to be added.

Shoe Testing PCBs

I'm just waiting to finish debugging the SA868 and PCM2902 testing PCBs before ordering this one.

Left: SA868 Testing PCB with a dummy load antenna.

Right: PCM2902 Testing PCB with USB interface.

Unfortunately, I don't have the equipment to test it properly, but the SA868 PCB includes a low pass filter to take care of the messy RF output that these modules are known to have.


Building and Installing the Flight Software

Installing Prerequisites

Building the Flight Software

# Clone the repo with it's submodules (MWAV, WAVGen, and SSTV Image Tools)
git clone --recurse-submodules https://github.com/joshua-jerred/Giraffe.git

# If using the --recurse-submodules flag didn't work for any reason, you can use:
# git submodule update --init --recursive --remote
# and then pull the latest change.

# Move into the repo and create a build directory
cd Giraffe && mkdir build && cd build

# Configure the build
cmake .. # You can add -DSSTV_ENABLED=OFF to disable SSTV (Requires Magick++)

# Build the flight system
make giraffe_flight_system

# Install is currently disabled until some details are finalized
# Install the flight system (Optional)
# sudo make install

Flight Software Configuration/Web Client

Configuration is no longer done through the config file, but instead through the web interface! This is where the ground station and flight system are configured.

Multiple clients can be connected to the web interface at once to allow for a team to monitor the flight together.

The Configuration Page from GWC


Development is no longer done by release, but instead features will be added as they are completed.

giraffe's People

Contributors

joshua-jerred avatar

Watchers

 avatar

giraffe's Issues

Error Logging

Each time an error is received by the data module it should log it to a file (if enabled). Add a toggle to the configuration file to turn error logging on and off.

Fix the shutdown process

The shutdown is currently an absolutely unsafe disaster as there are many threads that are killed during the shutdown. CTRL+C is handled but it currently doesn't do anything.

The shutdown function should request that all sensors stop and shut down before turning off.
May need to implement some form of an interrupt within the modules/extensions that use threading.


Edit:
Segfault on exit currently as the extensions are trying to access the data stream when it does not exist.

utility-I2C

Implement a basic I2C library that will handle the low-level I2C connection.

Implement - Location Data

The Data Module needs to parse GPS packets as they arrive to maintain the following in the data stream:

  • Last Good GPS Fix
  • Current GPS Data
    • Includes 'GPS Status' which is a boolean value that is set to true if the GPS packets are arriving
    • An expiration time (currently undefined) will state when the data is no longer considered good

Finalize Extension List

Environmental

  • Pressure Sensor (BME280)
  • Temperature Sensor(s) (DS18B20, BME280)
  • Humidity Sensor (BME280)
  • Light Sensor(s) UVA, UVB, UVC, or wide spectrum UV sensor. Visible spectrum sensor for RGB.
    - TSL25911FN
    - LTR390

Location/Physical Sensors

  • GPS Sensor (SAM-M8Q)
  • Accelerometer / Gyro (BMI055)

System Sensors

  • Voltage/Battery Fuel Gauge sensor (MAX17048G)
  • On PCB Thermocouple - Not needed. Between the BME280 on the board and CPU temp, this isn't that important.

Radio

  • VHF Radio Module (DRA818)
  • Audio Input/Output for radio (TI PCM2902C)

System Info Extension

  • CPU Load Average/Temperature
  • RAM Usage
  • Disk Usage/Available Space/Used Space
  • Log File Size (This will go in the data module)

Minimal implementation of 'telemetry module'

Implement all functions needed by the FlightRunner for sending data. This does not need to include two-way communication in any form.

For now, do not modulate anything, just output the transmission request to a log file in the executable root. This should include data packet and APRS simulation.

Prepare for Merge of the 0.3 iteration development branch with main

  • Fix all file Doxygen headers
  • Prepare hardware for unit tests
  • Finish refactor #54
  • Change all version numbers
  • Run a 'comprehensive' test on the GFS in the Pi Environment
  • Pass all unit tests
  • Generate and Publish Doxygen docs
  • Update Readme
    • Publish Schematic for GFC Prototype 2
    • Updated image of the web server

utility-one-wire

Implement a basic 1Wire library that will handle the low-level 1Wire connection.

BME280 Driver

The BMP180 is no longer made and there are better options.

Look into:
BMP390
BME280 - Contains RH and Temperature in a similar package size

Implement - Data Packet Modulation Mode in config

In the configuration file/configuration module implement 'Data Packet Module Mode' which will have the following options

  • PSK
  • AFSK

For the two modules modes it will use the configuration data that is already implemented.

Implement Web Server

Implement the webserver in python with the general flow of:

GFS > Socket > Python > HTTP > Browser

Implement Error Frame

Implement an error frame similar to the data frame. Utilize the expiry time to clear errors.
This needs to be done with either a vector, map, or queue.

If the expiration time is '0' the error does not expire.

'DataModule::checkForStaleErrors()' segfault

Segfault in the data module when checking for stale errors.

  for (auto& [source_and_unit, packet] : errorframe_) {
    if (packet.expiration_time == 0) {  // 0 means it never expires
      continue;
    }
    if ((int)packet.expiration_time < (int)now) {
      errorframe_.erase(source_and_unit);
    }
  }

Valgrind output:

==209221== Thread 2:
==209221== Invalid read of size 8
==209221==    at 0x178962: std::__detail::_Hash_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, ErrorStreamPacket>, true>::_M_next() const (hashtable_policy.h:283)
==209221==    by 0x177B8E: std::__detail::_Node_iterator_base<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, ErrorStreamPacket>, true>::_M_incr() (hashtable_policy.h:300)
==209221==    by 0x176F77: std::__detail::_Node_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, ErrorStreamPacket>, false, true>::operator++() (hashtable_policy.h:352)
==209221==    by 0x175BAA: DataModule::checkForStaleErrors() (module-data.cpp:204)
==209221==    by 0x175C6D: DataModule::runner() (module-data.cpp:231)
==209221==    by 0x17C7FB: void std::__invoke_impl<void, void (DataModule::*)(), DataModule*>(std::__invoke_memfun_deref, void (DataModule::*&&)(), DataModule*&&) (invoke.h:74)
==209221==    by 0x17C74E: std::__invoke_result<void (DataModule::*)(), DataModule*>::type std::__invoke<void (DataModule::*)(), DataModule*>(void (DataModule::*&&)(), DataModule*&&) (invoke.h:96)
==209221==    by 0x17C6AE: void std::thread::_Invoker<std::tuple<void (DataModule::*)(), DataModule*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (std_thread.h:253)
==209221==    by 0x17C663: std::thread::_Invoker<std::tuple<void (DataModule::*)(), DataModule*> >::operator()() (std_thread.h:260)
==209221==    by 0x17C643: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (DataModule::*)(), DataModule*> > >::_M_run() (std_thread.h:211)
==209221==    by 0x49582B2: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==209221==    by 0x4C43B42: start_thread (pthread_create.c:442)
==209221==  Address 0x4e38130 is 0 bytes inside a block of size 152 free'd
==209221==    at 0x484BB6F: operator delete(void*, unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)

Move wav files to ram disk - manage packets

Packets do not need to be kept in audio form. If a request comes in to repeat a packet regenerate audio from textual data.

The wav files should be deleted right after transmission, it's cheap to regenerate.

Large refactor to clean up code base

  • Put modules in a single header a1472dc
  • Put extensions in a single header f93f8cd
  • Interfaces should all be in one header 91b2df0
  • Change 'modulation utilities' to MWAV Repo for easy updates 6bb431d

Use namespaces where possible

  • Extension namespace 3f704a4
  • Utility namespace Not really needed yet, removed 'utility' from file names
  • Module namespace a1472dc

Update - Data Log

The data module file data log file functionality needs to be updated:

{
"time-stamp":"date-time",
"data": [ 
          "source1": [{"unit": "value"}, {"unit": "value"}, {"unit": "value"}],
          "source2": [{"unit": "value"}, {"unit": "value"}, {"unit": "value"}]
     ]
}
  • File rotation once file size of 'x' is hit
  • Log Data List in Config
    • Update config json/config module to be like the following:
[
"source1": ["unit", "unit", "unit"],
"source2": ["unit"]
]

Extension Status to Data Stream

The following functionality needs to be added:

  • Extensions should send their status to the Data Stream upon updating their status
    • This should be part of the parent extension class
  • The data stream should keep this in an unordered map
  • The ability to get a copy of the map from the data stream
  • A simple display on the web server of the status of each extension

Implement - No GPS Configuration Warning

This will originate from the Configuration Module.

If a GPS is not configured properly, or if it does not exist, the configuration module should report this.

Extension shutdown

Extension shutdown is currently really messy and often results in seg faults. This needs to be fixed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.