Quote:
Originally Posted by mikets
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:
Code:
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.
|
I did do quite a bit of coding tonight using these techniques and I am seeing case 2 logic being executed when case1 is the state iterative autonomous. If the encoder values I am checking for are true in both case1 and case2 then the sequence becomes unstable. The only way I can think to protect case1 logic from case2 is to use Booleans
Case1:
If (encoder < 400 && case1-Boolean == true && case2-Boolean == false)
Then do some work
State++
Break;
Case2:
If (encoder < 400 && case1-Boolean == false && case2-Boolean == true)
Do some other work.
Is there a way in eclipse to step throu the code while it is executing on the rio?