[mikets]

Originally Posted by Tparbotmail

These are all good suggestions and thank you. I am very interested in multi threading not quite sure how it works, but am pretty sure We are going to need it based on my understanding. I'd love to hear about it and see examples.

My question was more of a sanity check because I don't see a lot of Boolean and state discussion in Delphi or in code on git hub. I don't see the Boolean management technique that we used last year with our autonomous routine. So I am wondering if I have missed something obvious, like checking to see if the computer is plugged in, or the wpilib page in the Java section that demonstrates 10 ways to run iterative autonomous. On my team we call it "iterative choking" when the wheels start sputtering we know that that iterative is executing two different motor speeds simultaneously because our logic is flawed and lacks Boolean gatekeepers.

Is the problem really about managing state in autonomous? Maybe I am searching on the wrong terms. The example with the case statements is really good and make sense. We are actually trying to avoid timers this year and rely on sensors. I use timers in my example because timers are used a lot by everyone. Do you guys experience iterative choking too? Or did I completely miss the lecture on iterative autonomous?

Thanks

A lot of autonomous strategies are sequential, meaning you start an operation, you wait for it to complete before starting the next operation. That's what the switch/case state machine will do for you. You start an operation in one state, move to the next state to wait for it to complete before moving onto another state. However, it may be beneficial to start multiple operations simultaneously in the same state if these operations do not have dependencies on each other. For example, you may want to raise your elevator at the same time as driving the robot forward. There is no reason why you can't do that at the same time. But you don't need multi-threading to do this. You just have to check for multiple conditions before moving onto another state. For example, hypothetically, let's say you have some sort of elevator that will reach up to the high goal to score the boulder. You can do this sequentially, drive the robot forward to the castle wall then raise the elevator. But then it is wasting precious time. You can start driving forward as well as raising the elevator at the same time but you can't score the boulder until both operations are completed. You can still achieve this with a simple state machine:

switch (state)
{
    case 1:
        //
        // Keep driving forward and raising elevator until targets are reached.
        // When both targets are reached, move to the next state.
        //
        boolean reachedWall = sonarDistance <= stopDistance;
        boolean reachedHighGoal = elevatorHeight >= goalHeight;

        if (reachedWall)
            tankDrive(0.0, 0.0);
        else
            tankDrive(0.5, 0.5);
        
        if (reachedHighGoal)
            elevatorMotor.set(0.0);
        else
            elevatorMotor.set(0.5);

        if (reachedWall && reachedHighGoal)
            state++;

        break;

    case 2:
        scoreMechanism.extend();
        break;

    ...

In my opinion, multi-threading is not needed in most scenarios. It gives you more trouble than it's worth unless you understand issues with multi-threading programming (e.g. resource contention and thread synchronization). Of all the years doing robot programming, we developed a multi-tasking robot framework library that uses only a single thread. There is only one exception: vision targeting. And that's only because the NI vision processing code is a blocking call. Calling it will affect our robot's responsiveness. We took care of it in our library by spawning a separate thread doing vision processing. That's the only exception.