Skip to content

Latest commit

 

History

History

CiC

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 

CiC - Command and Control for toy space missions

As an Arduino project grows, the complexity of the software can become overwealming. CiC provides an architecture for building complex projects with reusable components.

Complex projects also demand features for observability. The memory contrained environment for Arduinos, for example on the common UNO board, mean off-the-shelf solutions may not fit.

Architecture

CiC is built in C and is designed around an event bus to enable loosly coupled components.

Typically the core system loop is handled in the standard Arduino loop() function. Events are generated by responding to real-world activity (including a radio) and routed through the event bus to listening components.

Who should use this system?

Primarily the author. It's experimental and certainly not flight worthy. Consider this more of an educational project.

Components

  • evt event is the event subsystem.
  • com communications interfaces with a hardware interface and decodes multiple types of messages for consumption by other components.
  • to telemetry provides an interface for recording parameters and their values, packaging up a packet to send to mission control.
  • ci command ingestion processes commands and maps them to mission specific functions.
  • tmr timer provides for triggering events on a timed schedule
  • tbl table provides persistent storage of runtime adjustable configuration variables.

Usage

Testing

Simple tests are available using the provided Makefile

$ make test

These run under gcc and are helpful for local development.

Influences

Inspiration for this project came from looking at two competing NASA projects:

Both are used in real world space missions.

cFS is the older more mature system. It's written in C and is architected around an event bus.

fPrime is a newer system famously used on Ingenuity. It's written in C++ and is architected around "ports" and configurable build system to connect components together.

Principles

  • Loose coupling by using the event bus is good, but don't go overboard. It's not worth adding unnecessary indirection.
  • Make it observable.
  • Prefer consistent memory usage. (pre-allocation is good)
  • Avoid globals within components. Rely on the Mission to define them.

TODO

  • A TBL component would be helpful for storing stateful data that preserves reboots. For example, error flags shouldn't be reset.
  • Tools for tracking memory consumption during a live mission.