Command Incorrectly Reading "State" of Arm

Technical Java
1

(First, we have several kids who helped write this code. Excuse the naming scheme)

  • Subsystem called theCLAAAWWW
  • Object called “Arm”
  • Object called “Wrist”

theCLAAAWWW is the both the arm and wrist as one. It accesses the methods in the Wrist and Arm to run.

We get a “State” of the theCLAAAWWW by checking what angle the arm and wrist is in. Five states in total:

  • LOADING - Arm is straight up and down, wrist pointed backwards
  • TRANSPORT - Arm is straight up and down, wrist pointed forwards
  • LOW - Arm is outside bot, low to ground
  • MEDIUM - Arm is outside bot, medium above ground
  • HIGH - Arm is outside bot, high above ground

We never tell the robot what state it is in. It only checks itself through getState() which, again, is based on angles. The angles always print out correctly

We run a sequential command when buttons are pressed to go to different positions. We had to add quite a bit of logic to make sure the Wrist and Arm did not collide with the robot when it was going from one specific state to another. We wrote this logic in the sequential command.

The issue we are running into, is that when the sequential command checks what state it is in, it sometimes says LOADING when it runs the command. However, when we SmartDashboard getState(), it shows the correct “state”; it is switching so fast you cannot see it. In essence, it says its in LOADING for a split second when the command is run, and messes itself up. We use what “state” it is currently in and what its target state is to determine how it should move itself to get there.

Here is the sequential command.

Here is theCLAAAWWW and its getState() method

Here is Arm

Here is Wrist

Here is RobotContainer where we call the button presses.

One specific example: if the SmartDashboard says it is in LOW (via the getState() method) and we try to go to LOADING, it thinks it is already in LOADING (and print it out via PrintCommand()) when it runs even though the dashboard says LOW.

Hopefully someone can find where we made a mistake :smiley:

Bonus amazing picture of robot:
Capture

2

Because your state is determined from measured sensor values directly, and there is no caching of those values, you’re probably encountering problems with nondeterminism.

This is going to be very hard to fix except systematically; you need to make sure your state detection is robust and reads consistently throughout each iteration of the main robot loop.

1 Like
3

Will the same issue occur if we just check angle with the logic in the sequential command? Just drop the enum entirely

4

Unless you read it precisely once per iteration and cache the value, yes.

6

Is this the reason hash maps are use for states? To store the value more reliably?

7

You don’t need a hash map, just an enum and a way to update it canonically every iteration.

8

I wanted to make sure I’m going in the correct direction with this. I hope I understand what you mean.

  • Have enum with the states
  • Have a switch case for the states that stores the predetermined wrist and arm angles
  • Set starting state as, for example, LOADING (before match, make sure it is actually in LOADING)
  • Run commands to drive wrist and arm to those states and then change the state after doing that

So…is it as simple as not getting the states by angle, and just manually setting them every time we run a command to go to a new state?

1 Like
9

Yes.

2 Likes
10

This is why we love you. Man of few but powerful words :smiley:

2 Likes