Skip to content

Architecture

Richard Arthurs edited this page Apr 8, 2018 · 7 revisions

Houston is built on Kivy, a python module for creating nice GUIs.

Kivy apps follow a similar structure to a webpage, with the .kv files defining the layout and style, and the .py files handling the back end control.

Houston is tab-based, with each tab's functionality put into a class such as UARTTab or SCHEDTab. Each tab's class is in its own python file.

Top

The top object is a box layout, and essentially spans the entire window. In the .kv file, you will see that the tabs are instantiated within the top class as well. Additionally, the top object spawns several tasks that do the following things:

  • Send/receive data from the UART
  • Parse our received data
  • Maybe something else

Sending Data

Data is placed in a queue called serial_TxQ to send to the satellite. It is sent out in the do_serial() function, which is run in a separate task from the main logic. Commands to send out are consumed from the queue almost instantly. This allows us to send out commands from multiple sources, such as the command entry box in the UART tab, or scheduled by Kivy to simulate a mission.

Commands

Commands are represented as dicts with the following fields:

  • the command to send
  • the epoch to send
  • relative flag (whether the epoch is absolute or relative to the time the schedule is uplinked).

Command Schedule

The command scheduling tab allows missions to be created and uplinked to the satellite.

Commands are sent to the satellite at the epoch entered at command creation. This is different from the satellite's own scheduling system. Upon receiving any command, the satellite will schedule the time for the command to run according to the data within the command itself. To use the satellite's scheduler and not Houston's, add the scheduling information to the command entry, not the epoch entry.

For example, we could immediately send two commands from Houston with satellite scheduling information in them. The satellite would execute the command according to the command's information, not necessarily exactly when it received the command from the ground. We could also schedule (in Houston), two commands to run immediately on the satellite, at a specific epoch. These commands would be sent at that epoch by Houston, and would run immediately, instead of being scheduled by the satellite itself.

This flexibility allows us to test the satellite's scheduler, and still allows us to execute sequences of immediate (or scheduled) commands with real delays between them, as we would between communication passes.

The Kivy clock module is used to schedule commands using the SatTest.uplink() method.

SatTest Class

This class manages the test. It contains several things:

  • Methods to convert between utc (time.time time) and satellite epoch time, used for scheduling
  • Several lists that keep track of acknowledged and new commands
  • A method to uplink commands that sends the command and allows us to keep track of its timeout

Command Stages

There are 4 command stages represented as lists of command dicts. command state flowchart

Clone this wiki locally