Skip to content

unit tests #1

@aeolyus

Description

@aeolyus

Architecture

Structure

  • Subsystem
  • Command
  • Controller (the helper class for the purposes of this doc)

Example

  • SwerveSubsystem
    • has access to motor controllers and input
    • does NOT use complicated logic to figure out how to move motor controllers or take input
    • all this does is provide an interface in front of a "group" of motor controllers and inputs
  • SwerveController
    • contains state about inputs and possibly previous inputs
    • contains logic concerning output based on inputs and previous inputs
  • SwerveCommand
    • this gets passed a SwerveSubsystem and a SwerveController
    • the data flow goes like this:
      SwerveCommand:loop{
        check SwerveSubsystem:input
        feed input from SwerveSubsystem to SwerveController
        SwerveController reports back how to move based on inputs
        feed output into SwerveSubsystem on how to move motor controllers
      }
      
Step Subsystem Command Controller
0 Initialized with motor controllers and input Initialized with Subsystem and Controller Initialized with whatever is needed for the function to work (it could be constants, whatever)
1 Command asks Subsystem for input
2 Subsystem gets input and returns it
3 Command takes input and gives it to the Controller
4 Controller takes input and does some calculations and returns it
5 Comamnd takes output of Controller and passes it to Subsystem
6 Subsystem takes those values and sets motor controllers correspondingly
7 Repeat from step 1

Thanks to @xorkevin for this wonderful explanation

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions