Announcement

Collapse
No announcement yet.

State Machine Architecture

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • State Machine Architecture

    Observation 1: This is my 4th season doing FTC, and I have found that the season is a very short window to convey the complexities of Java programming and robot control architectures while simultaneously not being distracted by all the Java syntax cruft. Last year we built a reasonable state machine, but we quickly had a nasty mess of if/else statements spanning multiple classes. Managing telemetry was difficult and sharing the right state between the helper classes was an area where the coach (me) had to step in and lend a hand.

    Observation 2: Many simple programming frameworks are event-driven. New programmers come up to speed quickly on that model.

    Observation 3: Event-driven frameworks and state machines go together very nicely.

    So this year we are piloting an event-driven state machine framework. It requires only a few classes to support. It nicely removes a lot of the opMode boiler plate. Each state is a separate java class. So no `if` statements or `switch` statements to manage state transitions. Yes, that means more classes, but they should all be short and have a minimum of distracting syntax and boiler plate. The logic should shine through.

    Here is the README:
    https://github.com/CheetahRobotics/f...hine/README.md

    Any and all feedback/observations/pull requests welcome.

    Again, my goal is something that is easy for new programmers to work with. Something that shortens the learning curve. The code should have a minimum of boiler plate and syntactical noise and it must be easy to read and write the robot control logic.

  • #2
    Thanks Robert Woodley Understanding State Machines is something we've struggled with in the past (as much as Philbot has tried to help), and have pretty much given up on it, in large part because we don't have a programming mentor, and only one self-taught coder.

    We'll certainly check this out, as this season auton certainly seems to lend itself well to this structure.

    Best of luck this season and thanks again...
    Michael P Clark
    Founding Mentor, FTC 9958
    http://www.redfishrobotics.com
    "We're Hooked on FIRST"

    Comment


    • #3
      Our team invested in an object-oriented state machine after our first season, and it has made a big difference in getting the concepts across to the students. There's a little bit of a learning curve up front, but the team has found that mapping from a state machine diagram on the whiteboard into code in classes in the state machine is much more straightforward and clean compared to a giant switch statement. They've also found that adding "safety" to the steps such as timeouts and fallback execution to be much easier.

      The state machine based on objects also lets the team reuse portions of the state machine in tele-op for multi-step actions initiated by the drive team - they used that for a sequence for our shooter in Velocity Vortex. Later on one of our programmers noticed that because the state of the state machine itself was local to each instance of a state machine step, she was able to add a debugging mode to the state machine executor that lets the team move step-by-step, adjust parameters and reset to start all from the drivers' station.

      Comment


      • #4
        markdmatthews Yes, the ability to manually set states will be quite useful for debugging I think. And yes, whiteboarding a state machine beforehand makes the transition from design to implementation less painful and clearer for kids trying to master all this new stuff. I'd be interested in seeing any more details you'd care to share. I just did this on my own and am interested in other approaches.

        Comment


        • #5
          Originally posted by Robert Woodley View Post
          markdmatthews Yes, the ability to manually set states will be quite useful for debugging I think. And yes, whiteboarding a state machine beforehand makes the transition from design to implementation less painful and clearer for kids trying to master all this new stuff. I'd be interested in seeing any more details you'd care to share. I just did this on my own and am interested in other approaches.
          Hi Robert,

          The basics of it are pretty small, the team has them up on GitHub here - https://github.com/HF-Robotics/ftc_a.../corelib/state

          It leans a bit on some of our other core classes, debounced buttons, etc. to drive the debugger, but the core debugger logic is in StateMachine.java.

          - Mark

          Comment


          • #6
            Robert,

            I forgot that it would probably be more clear with an example, here's one from Relic Recovery that uses the REV Hub's IMU to turn to a known angle (using proportional control) with the robot's Mecanum drive base, as you can see it's pretty small, self-contained (imagine storing these variables in one class for each time you want the robot to turn), and we reuse it multiple times for autonomous runs:

            https://github.com/HF-Robotics/ftc_a...TurnState.java

            - Mark

            Comment


            • #7
              Not always in state machine diagram form - but these thoughts captured on the whiteboard do translate pretty quickly to the object-oriented state machine, especially as seasons pass we have more reusable states, like "move this distance", and "turn to this heading":

              Comment


              • #8
                Yes, that's basically the same idea, except it isn't event driven. Also, your 'state machine paused' state could actually be, well, another state. Thanks for the feedback.

                Comment

                Working...
                X