diff --git a/.github/workflows/require-linear-issue.yml b/.github/workflows/require-linear-issue.yml new file mode 100644 index 0000000..b964e92 --- /dev/null +++ b/.github/workflows/require-linear-issue.yml @@ -0,0 +1,25 @@ +name: Require Linear Issue in Pull Request + +on: + workflow_dispatch: + pull_request: + branches: + - main + types: [opened, reopened] + +jobs: + require-linear-issue: + runs-on: ubuntu-latest + steps: + - name: Find the Linear Issue + id: find-issue + uses: ctriolo/action-find-linear-issue@v0.60 + with: + linear-api-key: ${{ secrets.LINEAR_API_KEY }} + + - name: Require Linear Issue + run: | + if [ -z "${{ steps.find-issue.outputs.linear-issue-identifier }}" ]; then + echo "Please add a Linear ID to the title of the Pull Request. Using the Linear branch name would have done this automatically." + exit 1 + fi \ No newline at end of file diff --git a/_typos.toml b/_typos.toml new file mode 100644 index 0000000..f5f00ea --- /dev/null +++ b/_typos.toml @@ -0,0 +1,2 @@ +[default.extend-words] +mosquitto = "mosquitto" \ No newline at end of file diff --git a/telemetry/packages/fake/README.md b/telemetry/packages/fake/README.md index b2298ca..f285482 100644 --- a/telemetry/packages/fake/README.md +++ b/telemetry/packages/fake/README.md @@ -29,7 +29,7 @@ To iteratively generate transient and physically reasonable series of data point simulation of the expected sensor readings during a live run. Data will be uploaded live to the GUI through the mqtt server, and assessed for error handling and other metrics. -I.e. all of the thermnistors have the exact same proerty values. In actuality, their readings will differ as they placed in different locations across the pod. However, the data structure does not hold this information and therefore they are equivalent, so only one generic 'thermistor' object will be studied. +I.e. all of the thermnistors have the exact same property values. In actuality, their readings will differ as they placed in different locations across the pod. However, the data structure does not hold this information and therefore they are equivalent, so only one generic 'thermistor' object will be studied. In contrast, the pressure gauges have descriptive names which allow one to infer their likely behaviour during operation (front/back-push refers to gauging pressure upon acceleration, which would see an absolute increase in gauge pressure on both ends of the pod due to the greater stagnation pressure and the nose of the pod and pressure wake field behind). Similarly, the pressure gauges of the reservoirs can be reasonably assumed to not vary significantly, but as temperature rises the pressure will increase slightly due to Amonton's Law. @@ -39,11 +39,11 @@ In contrast, the pressure gauges have descriptive names which allow one to infer The program will record and store all values calculated by each sensor's methods defined in `sensors.ts` over a user-specified timeframe, with each sensor set to a specific sampling time interval. `main.ts` filters and constructs an array of relevant and unique sensors from the Pod Ness sensor object structure. A new interface is created called `Sensor Data`. It extends `RangeMeasurement` - adding the properties of `currentValue` and `movingAvg`, and encapsulates the measurement object with the sensor's name as a `Record`, reflecting the object shape of the pod's sensor objects. -A Singleton class was created in its dedicated file, `data-manager.ts`. When the program is run, a single instance of this class is created. The instance holds the current set of data, and at each iteration is updated before the current data is pushed into data storage arrays for all sensors. Once created, this instance and its data property is accessible from both the main file, and the pod behavious class file, which holds all the methods written to generate each sensor's next value. +A Singleton class was created in its dedicated file, `data-manager.ts`. When the program is run, a single instance of this class is created. The instance holds the current set of data, and at each iteration is updated before the current data is pushed into data storage arrays for all sensors. Once created, this instance and its data property is accessible from both the main file, and the pod behaviours class file, which holds all the methods written to generate each sensor's next value. In the main file, the program's main function, `generateDataSeries`, runs a loop iterating through the time period defined. For each sensor type, it calls the relevant static method in the `Behaviour` class. Some sensors can be categorised, e.g. the navigation sensors. The values for displacement, velocity and acceleration are interdependet. As the pod's velocity is increased, its displacement and acceleration can be calculated, given the acceleration constraints provided by its critical limits nested object. -A logistic function was chosen as the appropriate function for pod velocity to follow. This allows us to minimse the time to reach maximum speed by adjusting the peak acceleration (dv/dt) to reach but not exceed 5m/s^2 at the velocity-time inflection point. +A logistic function was chosen as the appropriate function for pod velocity to follow. This allows us to minimise the time to reach maximum speed by adjusting the peak acceleration (dv/dt) to reach but not exceed 5m/s^2 at the velocity-time inflection point. Similar functions have been or are in the process of being created for the rest of the sensors. Complexity varies, and some require a lot more guesswork. @@ -106,7 +106,7 @@ Classes are instantiated once each in `main.ts`. The Sensor class is constructed The `_currentValue` variable is mutable, so that only a single instance per class is needed, updating its current value. -Not all sensors/measurements require their own class instance. For instance, in the navigation category only velocity (or the accelerometer reading) needs to be recorded in the class instance. From this value and given a reasonable function of time, the other navigation variables can be calculated accordingly at each time step using basic kinematics and calculus of limts. Additionally, many other measurements have a dependency on pod velocity, generally increasing in proportion to the speed. Temperature is another measurement which dictates certain others, like reservoir pressure for example. +Not all sensors/measurements require their own class instance. For instance, in the navigation category only velocity (or the accelerometer reading) needs to be recorded in the class instance. From this value and given a reasonable function of time, the other navigation variables can be calculated accordingly at each time step using basic kinematics and calculus of limits. Additionally, many other measurements have a dependency on pod velocity, generally increasing in proportion to the speed. Temperature is another measurement which dictates certain others, like reservoir pressure for example. Read more about sensors here. @@ -166,7 +166,7 @@ Runs the main loop with user-defined parameters, with the actual functionality a
  • Total runtime for the data generation loop
    • -
  • Instantiate sensor classses and finish loop functionality
    • +
  • Instantiate sensor classes and finish loop functionality