Skip to content

Training

Jump to bottom
Will Page edited this page May 8, 2025 · 1 revision

Stormbreakers Basic Training Stuff

The very basics

  • variables
  • classes
  • Functions
  • "structs" or data classes
  • Introduce enums (don't need to implement)
  • Explaining inherited classes as interfaces (because we deal with them).
  • "null" objects -> initialization (mostly avoided by minimizing indefinite declarations)

Special topics covered on an as-needed basis

  • Complex stuff involving inheritance or extending classes

    Aside from creating new commands or triggers (which mostly act as an interface), we don't do anything with this, and the few places we could it creates confusion because of hidden, unexpected behaviors.

  • Implementing/using Arrays/Lists

    Not especially common in simpler tasks, and java makes interacting messy. Handle as needed later.

  • Error handling

    Super gross in java, and we mostly need basics. Cover if necessary (mostly Lasercan), but prefer converting errors to Optionals and doing type checking instead of bubbling up (which lasercan also does).

Moving on to robot-coding

  • Teach the "command/robotcontainer/subsystem" model early

    If you do a ton of bot development before getting to "typical bot structure", code structure becomes a mess and it becomes harder to use any advanced features and reason through more complex tasks. It also gets the wrong habits engrained, which becomes an unlearning process later. It's OK to say "We'll get into the details of why this is" later, they'll figure things out.

  • Putting complex logic into a command

    This is a great way to prototype all sorts of bot ideas, and should help them when doing "upgrades" to older code.

  • Introduce a "trial project" for subsystems

    houses a single, simple system, and learn the basic java education. No need to get too deep beyond helping set up. Then, once they have it after a project or two, move into modelling "complex work" with commands. It's helpful when "prototyping" complex things using "commands" because you can cycle through different ways of prototyping it easily by swapping out commands being selected.

  • Subsystems
    • Robot nouns
    • Containers for a single actuator or "resource"
    • Safety through "locks" and requires
    • Organized place to keep associated code.
  • Commands
    • The robot "verbs", and actions systems can take
    • Can be basic and still be useful when decorated
    • Typical commands shouldn't end; Decorate or make shortcuts for ones that do

Stormbreaker Milestones

  • Motor Control

    • Spin a motor
    • Configure a motor with max current
    • Control on/off via joystick button
    • Control speed via joystick

  • Encoder Basics

    • Read an encoder
    • Configure encoder range/units through gearing
    • Enable/Disable Soft Limits
    • Write a homing sequence (state machine/periodic ok, command better)

  • Diffy

    • Create a Differential Drivetrain
    • Controller controlled
    • Two step autonomous drive using encoders

  • PID

    • Tune necessary PIDs using encoders
    • Set a velocity using a PID
    • Set a angular position using a PID
    • Set a elevator position using a PID

  • Commands

    • Create a command to move a system
    • Decorate command to stop based on sensor
    • Create a homing routine in command form
    • Create a default command that stops a system for you
    • Create a default command that does something other than stop the controlled system.
    • Pass a function pointer as a runnable
    • Pass a lambda to a command (just a function without a speial name)

  • Triggers

    • Command + Trigger subsystem interfaces over "method" ones.
    • Integrate with sensor section?
    • Kind of "hidden default" via joystick inputs (which are triggers)

  • Sensor Pro

    • Aim a tank drive using a gyro
    • Read a LaserCan, and use it to stop a command
    • start a control sequence based on sensor data (Trigger)

  • State Machine

    • Covering system "state" is very useful, especially in subsystems
    • ConditionalCommand + SelectCommand can be useful for attributing actions and states on simple systems
    • Need to find a sensible formal way to cover it; It's easy to make "custom" state machines for simple systems, but hard to scale up in complexity with consistent patterns.

  • Well Fed (FeedForwards)

    • recommended by prior stormbreakers, still in planning
    • Can be helpful on chassis control for auto driving

Clone this wiki locally