The Second Sprint Thread

Applications & Usage Yukon
1

The following is a direct copypasta of Nuno’s write-up. I wash my hands.

Tasklist

Backend

  1. System and session mockup:

    1. Choose a specific language/data format to specify and describe the overall system. This includes nodes, subjects, pub/subs, data stream and buses;
      1. Create an example test that loads the system description, defined on the chosen format, on the backend. This test should be run manually. Addition to CI is an extra;
    2. Choose a specific language/data format to specify and describe the overall session. For simplification matters, it should be equal to the one used on the system description. This includes, but not limited to: timed interactions between nodes including service calls and simulated timeouts, failure injection, very-high bus load simulation, programmatic reactions to data payloads, seeded random data generation;
      1. Create an example test that loads the session description, defined on the chosen format, on the backend. This test should be run manually. Addition to CI is an extra;

  2. Code and functionality cleanup:

    1. Make sure that the overall functionality that previously existed makes sense, and if yes, make sure it works;
    2. Removed unrequired/untested/not functional code after the previous point validation;
    3. Verify and add/remove dependencies from the current source code.

Frontend

  1. Code and functionality cleanup:

    1. Make sure that the overall functionality that previously existed makes sense, and if yes, make sure it works;
    2. Removed unrequired/untested/not functional code after the previous point validation;
    3. Verify and add/remove dependencies from the current source code.

  2. Main window mock user-interface:

    1. Add a top bar that includes a mock search bar (simple HMTL/CSS search box);
    2. Add a right-side top-to-bottom bar with a similar aspect to a console/log output view;
    3. Add a left-side top-to-bottom bar with top-level utility items that are used to update the data-flow UI.
      1. Add button to load system description - for now this only allows to load the mock system description file;
      2. Add button to load session description - for now this only allows to load the mock session description file;
      3. Add button to load to reload the elements in the data-flow UI;
      4. Add button to clear the data-flow UI;
    4. Add a centered window canvas representing the data-flow UI;

  3. Data-flow canvas area:

    1. Add a picture of a VTOL aircraft that serves as a background to UI;
    2. Add static node rectangle boxes to the following sensors/actuators. These should be placed over the background places where does components exist in the aircraft:
      1. One Airspeed sensor;
      2. One Flight Controller;
      3. Two servos;
      4. Four ESCs;
      5. One Battery Management System;
    3. Create the following (subject-related) logic connections between the following nodes, represented by a black arrow, from the publisher to the subscriber, when it’s a one-directional flow of data with respect to a specific subject, and a dual-sided blue arrow, when it’s a bi-directional flow of the same subject between two nodes:
      1. Airspeed sensor → Flight Controller, with the subject being Airspeed (Airspeed data type structure is WIP, no port ID);
      2. Battery Management System → Flight Controller, with the subject being BatteryStatus (no port ID);
      3. Flight Controller → Servos, with the subject being ServoCommand (ServoCommand data type structure is WIP, no port ID);
      4. Flight Controller → ESCs, with the subject being ESCCommand (ESCCommand data type structure is WIP, no port ID);
      5. Flight Controller ↔ all nodes, with subject being Heartbeat (port ID 32085);
    4. Make each rectangle draggable inside the data-flow canvas;
      1. This also means that the logic data-flow connections need to follow the node boxes, following the shortest path and not overlapping over the other node boxes;
    5. The following node information should be immediately visible in the box:
      1. Top: Node name and ID;
      2. Center: Node up-time;
      3. Bottom: Node health information and current operation mode.
    6. Add a button to each node box that when pressed, expands the box down with extra information. This might include, but not limited to: Node Software Image CRC, certificate of authenticity (COA).

Testing

  1. Testing with defined KPI’s:
    1. Establish KPIs (Key Performance Indicators) for Python/UDP/JavaScript data interchange. These KPIs shall be recorded as:
      1. Top-level numbers that can be asserted and are within range as part of the build.
      2. Graphs where additional information about available margins and other performance characteristics can be visualised.
    2. Implement tests that can be run manually in order to evaluate the KPI’s based on the mocked data being injected in the backend.
2

Resharing publicly

image
image1900×1061 841 KB