We init our AutoOpMode with field coordinates and then keep track of the field position through the Auto period. When we transition to TeleOp I would like to use the last known position from the AutoOpMode.
I am thinking of using a static variable in the AutoOpMode and set it when on stop is requested. Then on TeleOp init, read those values in the TeleOpMode init from the AutoOpMode object.
Would this do the trick. It doesn’t look like the AutoOpMode object is destroyed, from my research on the topic. That would be a problem if it was!
Hi
We create a class that holds a variety of static values. Some are generated during Auto for Teleop, and others are just used by several subsystems.
We also use this class to determine if we need to do things like Home the Arm. Normally it’s done in Auto, so Teleop doesn’t need to do it, but if you are just testing, and not runing Auto, Teleop can tell that it hasn’t been done by checking the ARM_HAS_HOMED member.
1 Like
Just curious, but does this approach using static variables to save values across opmodes also assume the use of Android Studio? Or does it also work in OnBot Java?
Last season our programmers noticed that static variables in OnBot Java that were modified from within an OpMode would sometimes keep the changed values across program builds and not revert to a default unless a power cycle (or maybe a “restart robot”) was performed.
I speculated this is because of how OBJ compiles/loads its classes (and keeps the app running throughout), as opposed to Android Studio which rebuilds/restarts the entire app on every build, but I’m curious if that’s at all plausible/true and something for OBJ users to be aware of.
Phrased another way, in the example given above for ARM_HAS_HOMED… at what point does ARM_HAS_HOMED get reset back to “false”? Or is it just assumed to be homed once per power cycle?
Pm
I am using Android Studio, and I am afraid that all I can do is confirm that the values are reset every time.
Hmm… I’m not sure how it would work in OnBotJava. I should try to find out.
As for Android Studio… The thing to remember is that all the opmodes are compiled into the app when it’s built. So as far as the app is concerned, running an opmode is just executing a certain part of the app’s code. So unless the app is explicitly resetting things between opmode runs, you can’t assume things will always start out the same each time you run anopmode. That being said, there ARE a lot of things that the app resets between runs. For example, Motor directions get reset, so direction changes you may make in Auto, don’t just roll into Teleop. This used to happen and it was extremely confusing.
As for the ARM_HAS_HOMED example, it’s ONLY automatically set False when the Robot Controller app first starts up which happens at power-on. After that it’s up to the opmodes to manage the state.
To get a consistent behavior, we ignore the value when we run AUTO, and always home the arm, which sets ARM_HAS_HOMED to true as the last action in homeArm().
At the start of Teleop, we check the flag, and only home the arm if ARM_HAS_HOMED is false. So, at competition the arm is only homed at the start of Auto.
Finally, we explicitly clear ARM_HAS_HOMED to false when our Teleop LinearOpmode exits. This way, if we run teleop several times in a row while testing, the arm will assume it hasn’t been homed and so it homes itself each time.
It’s worth noting that the reason we don’t want to automatically home the arm at the start of Teleop at a competition is that you can’t be sure that the robot is in a safe state at the end of auto. It could have been hit by another robot, or just gone off course. So doing an automatic home might cause problems. We always provide a manual way to trigger homing the arm for these situations (like tapping the touch pad) so the driver can assess the situation and recover gracefully.
.
1 Like
