Components

  • Everything in the Pyxida Firmware is Object Oriented
  • Are the building blocks of the Pyxida firmware
  • Take some sort of input, do some processing and return an output
  • Arranged in a hierarchy, think of a classes instantiating other classes

HOOTL Discussion

  • We have some basic testing code in Google something
    • Reads some simulation files and sends them into hardcoded sensor objects
    • Doesn’t run the loop firmware, but tests the components by themselves
      • It’s basically unit testing
    • Doesn’t simulate interaction of components or a sense of time passing

  • HOOTL should be adaptable for camera firmware and for STM32 hardware

  • But we want a ground up rewrite for HOOTL
    • Make the hardware layer abstractable (at least somewhat)
    • Should be simulating the entire operation of the pyxida firmware rather than individual components
    • The code shouldn’t care if it’s running on a Teensy or in the simulation

  • What we need to do in the near future
    • Make a HOOTL test file
      • Should create simulated hardware
        • GPS
        • Accelerometer
        • Barometer
        • IMU
        • Flash chip
        • Camera controller
        • Radio
          • This might mean communication with ground station
        • Pyrotechnics (I2C expander)
        • GPIO read/writes for the MCU (this has already been wrapped up)
        • Initialize a log file
      • Reads from simulation files that tells the simulated hardware how to respond to various function calls (e.g. simulated_adxl.txt)
        • For example, when firmware calls getX() from the firmware, HOOTL will respond with a value from some text file
        • This could be made more advanced/comprehensive with OpenRocket Integration
      • Runs Setup
      • Runs Loop
        • Goes through every timestep
        • Log file generation
          • Whenever Serial.print calls are made, store that into a text file
          • All the radio packets that will be sent
      • For unit testing
        • Check if the state machine values are what we expected at certain times
          • E.g. does it enter the BOOST state at the correct time of
        • Is the Kalman filter outputting correct values?
        • Is the state estimator producing reasonable estimates?
        • Are the comm packets correct?
    • Build it with CMake
    • Be able to run it locally
      • Should be able to run one loop of the firmware
  • No labels