RUN_TO_POSITION error locks robot in re-boot cycle until hard booted

[shishghate]

A couple of issues we have come across with RUN_TO_POSITION mode.

First off, if you don't set the target position for the first time it will throw the Exception Dialog. After that, picking any opmode and hitting play will lock it in an emergency stop reboot loop. The only way to escape is to hard boot the bot which is not possible during a match. Even a redeploy of code won't remove it from the loop.

Second, if you do set the target position in one opmode and then run another opmode that doesn't set the target position before setting the RUN_TO_POSITION mode, the second opmode will work fine and not throw the exception dialog. It appears something is is being cached and not properly cleared.

Here are the steps we have used to reproduce the problem using the attached file:

Update the motors in line 20 and or 21
Comment out lines 24 and 29.
Turn on hub
Deploy
Start OpMode
Exception thrown.
Hit Ok
Pick OpMode and try start.
Emergency stop thrown and in endless loop.

Here is the second case of once the target is set, it is remembered even after a code deploy

Update the motors in line 20 and or 21
Leave the setTargetPositions as is and make sure they are called
Turn on hub
Deploy
Start OpMode
Exit OpMode
Comment out lines 24 and 29
Redeploy
Start OpMode
It will not crash or throw the error.

TestLiftMotors.zip

[texasdiaz]

From your code sample it appears that there's some confusion about what RUN_TO_POSITION is meant to do.

You've appropriately identified that there's a very specific "command cycle" that commands must be carried out in - this properly sets up the firmware to take over the motion of the motor. This command sequence is:

1. Set the Target (encoder) Position
2. Set the mode to RUN_TO_POSITION
3. Set the power that the motor should use to run to that position

You should only do each of these ONCE per "command cycle". Sure, the code will sometimes not crash by setting them out of order, but that doesn't mean you should do it. Just like the encoder reset command mode (e.g. STOP_AND_RESET_ENCODER) commands issued to the firmware persist between OpModes (so, for example, you can reset a motor encoder in an autonomous OpMode and that encoder "offset" value will still persist in your driver-controlled OpMode when you run it - it only "resets" when the controller reboots or you command it again with another STOP_AND_RESET_ENCODER command). Therefore, it's completely possible to set the target position and run mode of a motor in one OpMode and then set the power in a totally different OpMode (not that I recommend it).

Also, the POWER in a setPower() command in RUN_TO_POSITION mode is not a signed value. This value is ALWAYS meant to be positive - you've set the position, the code knows which direction the motor needs to move in to reach that encoder position, you're just telling it how much power to use to get there. This does require that you've set the motor type properly in the robot config and that the polarity is managed correctly electrically.

While the firmware is commanding the motor to reach its target encoder destination, the isBusy() method will return TRUE. Once the encoder has reached position, the isBusy() will once again return FALSE.

Once RUN_TO_POSITION has completed, it will hold the position (as best it can). In order to program the motor to go to another encoder position, repeat the cycle with a new target position or put the motor in RUN_WITHOUT_ENCODER or RUN_WITH_ENCODER for "manual" mode.

-Danny

[shishghate]

Thanks for the quick response.

My bigger concern is the EMERGENCY_STOP.

Why does that happen?
Why isn't the standard exception dialog thrown?

We have had instances where we start an opMode with the proper sequence of commands and get this error. We then have to hardboot the hubs (power cycle). We then follow up with running the same opMode and we don't get the EMERGENCY_STOP.

This happened to me twice yesterday (hence the filing of the bug) and once during a tournament. I bring this up as I am wondering if it is somehow related to this issue:

https://ftc-community.firstinspires.org/t/stop-and-reset-encoder-sometimes-doesnt-stop-motor/922/7

Is there some timing issue where we need to wait between setting the target position and changing the mode during setup?

Either way, is there someplace where I can look at code to try and figure out how to not get into the EMERGENCY_STOP situation?

Thanks

[texasdiaz]

Understand that there's USER-CODE exceptions and then there's FIRMWARE exceptions. The former are nice java exceptions and just a simple "reload the code and try again" can usually solve the issue. However, the latter indicates a core system problem, and no OpMode that runs afterwards is guaranteed to have a firmware in a reasonable state and so the EMERGENCY STOP is issued.

No, there is no known timing issue where you need to wait between setting the target position and changing the mode during setup. What you must do at all times is write code that adheres to the command cycle format that I have specified, otherwise you risk putting the firmware into an illegal condition and/or risk the firmware doing something completely not what you want.

If you have additional questions, or need further clarifications on proper command structure for RUN_TO_POSITION, feel free to ask. But I'm afraid the firmware source code is proprietary and is not openly available.

-Danny

[j5155]

This exact issue caused my team to lose every single match at our state competition despite never happening during testing. Setting the target position while the motor is in the wrong state, or in a slightly wrong order, should definitely be something the SDK can check and stop early, instead of completely bricking the robot until the power is restarted.
The error should also have a stack trace if possible so that teams can find where the error is from.

We had this happen to us at state only during real matches and were unable to recreate it in any testing before or during the competition. I did not realize that it was caused by this until a few days after the competition had ended.

Code that caused the issue: https://github.com/jdhs-ftc/2023/blob/9af7a9f84a0ae1870aebeb2646865ab214078025/TeamCode/src/main/java/org/firstinspires/ftc/teamcode/auto/AbstractVisionOpMode.java lines 92 and 173