-
Notifications
You must be signed in to change notification settings - Fork 0
stardos directory structure
STARDOS files are located in /opt/stardos.
The directory looks like this:
/opt/stardos
├── bags/
├── computer.json
├── configs/
├── data/
├── datasets/
├── files/ -> workspace/src/stardos_utilities/files
├── scripts/ -> workspace/src/stardos_utilities/scripts
├── services/ -> workspace/src/stardos_utilities/services
├── settings.json
├── tmp/
└── workspace/
I will order these by percieved importance.
This file contains a ROS2 workspace. On an aircraft, it will contain cloned versions of every STARDOS node that will run on your system. On the ground station, you technically only need the control node and the datalink node, as the ground station does not run other kinds of nodes, but you may want to clone everything that will run on the aircraft as well so that you can, for instance, have access to their config files.
This is a RAMFS, a filesystem that only exists in memory. It stores in-progress versions of files produced by pipeline nodes. Camera nodes write to this filesystem; pipeline nodes read from and write to this filesystem. The writer node is currently the only node that runs in a processing pipeline that does not write to this filesystem.
The internal structure of this directory follows the STARDOS namespace structure (system/computer/capture_group/pipeline/node). Each of the node directories contains all the output of the node it's named for, usually named in correspondence to the ID of the capture request received by the producer node in the pipeline. All nodes thereafter will be told when they need to process data and where the information is located; in other words, nodes do not need to keep track of where input images are stored. When a node receives a SensorData message, it should copy the data each filename contained therein, do its processing, and write the processed data to its own output directory with the same base filename as it had when it was received. libstardos and pylibstardos back up the image if it fails to process.
This directory stores final data output from each pipeline node. Its structure is similar to that of the tmp directory, except that there are not directories for each node. This is because each pipeline will only have one output, so having every data directory end with an extra writer is pointless.
Specifically, this directory is associated with the currently running mission. Strictly speaking, data is just linked to a different directory that is associated with the specific run, located in...
This directory stores a bunch of data directories, one for each instance of a mission being run. They are indexed first by the name of the mission, then by the date and time the mission began. If the tmp directory for a run was not cleared, then the directory for the run also stores a backup of that.
For each mission, stardos_control creates a bag of all the ROS information produced by the mission and stores them here.
Contains configuration files for components that rely on such files. Most configuration of stardos nodes is done by passing JSON through stdin, but some software is not so easily manipulable and requires information from some external file.
Generally symlinked to workspace/src/stardos_utilities/files instead of created explicitly -- run the install.sh script from stardos_utilities to do this step for you.
Contains various scripts that set up the environment to run a specific stardos program. This is how the control node and the datalink node are started on system boot.
Generally symlinked to workspace/src/stardos_utilities/files instead of created explicitly -- run the install.sh script from stardos_utilities to do this step for you.
Contains systemd services, which run when the system boots. This is symlinked from stardos_utilities as well, but this actually isn't its final location. Running the install.s script from stardos_utilities will create this symlink but will also save the service files to /etc/systemd/service, where it must be for systemd to recognize it.