Mysterious robot run abort.

[mikets]

We were tuning our autonomous tonight and have encountered something I can't explain. May be one out of five or ten runs, autonomous would start, run several segments and then stopped as if somebody had pressed the "stop" button. There was no error/exception. It just simply stopped. The DS would show the "INIT" button again.
Has anybody seen this before?
We've seen this on both a ZTE and a Moto G3 phone. So it's not phone related. I wouldn't think it's related to our code because most of the time they ran fine. We were just fine tuning distance/angle numbers. When it stopped, it was on different segment of autonomous on different runs, so it was NOT stopping at the same spot of the code. Sometimes, it stopped really early, sometimes it stopped when autonomous was nearly completed. Sometimes in the middle. So it's random.

[FTC7253]

I know this sounds really basic, but while testing auton multiple times, our students have been bitten several times by not resetting the 30s timer. Other than that, I haven't seen many random stops that were not associated with USB disconnects or code issues.

[mlwilliams]

I've seen this happen even in Teleop while practicing so I don't think it's the 30 second timer. At least in teleop it would be legal to press init/play again but in autonomous you're dead.

[mikets]

I know this sounds really basic, but while testing auton multiple times, our students have been bitten several times by not resetting the 30s timer. Other than that, I haven't seen many random stops that were not associated with USB disconnects or code issues.

No, it's not the 30-second timer. In some runs, it stopped like 2 seconds after it started. So there is no way the timer has kicked in.

[mikets]

I've seen this happen even in Teleop while practicing so I don't think it's the 30 second timer. At least in teleop it would be legal to press init/play again but in autonomous you're dead.

Even if you are "allowed" to press init/play again. the robot is no longer at the "start up" position. The code will restart and not continue from where you were. No you are still hosed.

[Philbot]

No, it's not the 30-second timer. In some runs, it stopped like 2 seconds after it started. So there is no way the timer has kicked in.

Hi

You have to be careful here. I don't like this, but the timer does not get reset back to 30 sec automatically.
So if you pop into auto, and then change your mind, and hit stop, the timer has already started counting down.
Then if you simply hit init again, it will pick up from where it left off (perhaps with only a few seconds remaining).

You have to be very diligent to hit the timer disable/enable after a short auto run to ensure you have the full 30 sec.

Our drive team is fully aware of this, but they still forget some times. Typically when they are doing rapid testing of several auto modes.

Phil.

[mhaeberli]

mikets,

you mention fine-tuning distance / angle numbers.
what distance sensor are you using?
About ten days ago, we identified, reproduced, but have not fully isolated and documented the following behavior when running an MR Range Sensor - based autonomous:

-get a reference to the MR Range Sensor using the hardware map.
-do some stuff
-read the distance
-do some more stuff, including android.util.Log.d and some robot motion

Depending on whether the distance sensor was in some strange state or not, it would either work, or it would go straight from INIT, act as if it had auto-started, hit all of the non-conditional android.util.Log.d statements, and simply stop, showing the INIT button again.

In our case, the first range sensor read was after INIT, but before waitForStart().

It's almost as if the robot were disabled / stopping after the fault, but still running the code.

We had thought of "protecting" the range sensor read attempt with a try / catch, but have not yet done so.

Thanks,
Martin Haeberli
(de-)Mentor, FTC 7593, TigerBots

[4634 Programmer]

I've seen this happen even in Teleop while practicing so I don't think it's the 30 second timer. At least in teleop it would be legal to press init/play again but in autonomous you're dead.

Our TeleOp randomly stops after it has been running for several minutes as well...

[mikets]

mikets,

you mention fine-tuning distance / angle numbers.
what distance sensor are you using?
About ten days ago, we identified, reproduced, but have not fully isolated and documented the following behavior when running an MR Range Sensor - based autonomous:

-get a reference to the MR Range Sensor using the hardware map.
-do some stuff
-read the distance
-do some more stuff, including android.util.Log.d and some robot motion

Depending on whether the distance sensor was in some strange state or not, it would either work, or it would go straight from INIT, act as if it had auto-started, hit all of the non-conditional android.util.Log.d statements, and simply stop, showing the INIT button again.

In our case, the first range sensor read was after INIT, but before waitForStart().

It's almost as if the robot were disabled / stopping after the fault, but still running the code.

We had thought of "protecting" the range sensor read attempt with a try / catch, but have not yet done so.

Thanks,
Martin Haeberli
(de-)Mentor, FTC 7593, TigerBots

We used different distance sensors for different things. We use encoders for the drive train to track how far the robot has gone and we also used the range sensor to detect the distance to the wall. We don't have any issues with the range sensor. Well ... I take it back. When looking at our sensor log, we did see occasionally, the range sensor would give us bogus value of 255 cm. So I assume it has lost the echo. We have code to detect that and dismiss the bogus data. But other than that, the range sensor has been great.
What do you mean by "the range sensor go straight from INIT, ...". I don't understand what you are describing.

[mikets]

It's almost as if the robot were disabled / stopping after the fault, but still running the code.

We discovered the robot controller app never really "quits" even if you press the "3 dots" and select "Exit". You can only terminate it by bringing up all tasks and swiping it to the right. So even in fault/exception condition, the RC app is still running. This behavior bit us a few times because if your opmode has instantiated an object, it is not destroyed when the match is over or when quitting the app. If you start the opmode again, you may have multiple instances of the same object from a "previous run" hanging around. Normally, there is no problem with it until if the object you created in the previous opmode run is accessing something global. For example, our Menu class did display management using telemetry. If you are not careful, you could have two instances of menu trying to update the same line with telemetry causing flashing problem.

[FTC0417]

Mike, that's independent of the RC app physically exiting, isn't it? You'll have the same problem if you merely do a Restart Robot, won't you?

[mhaeberli]

mikets,

Normally, in an Auton LinearOpMode, we press "Init".

Then, when ready, we press "Start"

Then the OpMode code (after the waitForStart() call) runs, until time runs out, the OpMode is stopped, or it chooses to exit.

In the failure mode: "the range sensor go straight from INIT", as soon as one presses "INIT", the OpMode somehow blows by the waitForStart() call, runs through the rest of the code (at least the android.util.Log.d() statements), and exits.

What we found is that, when our code reads:

        rangeSensor = hardwareMap.get(ModernRoboticsI2cRangeSensor.class, "sensor_range");

        // likely Range Sensor failure here, should probably surround with try / catch and see what's happening.
        distance = rangeSensor.getDistance(DistanceUnit.CM);

the getDistance call fails sometimes, and causes the above-described weird failure.

if the code reads:

        rangeSensor = hardwareMap.get(ModernRoboticsI2cRangeSensor.class, "sensor_range");

        // likely Range Sensor failure here, should probably surround with try / catch and see what's happening.
        try {
        distance = rangeSensor.getDistance(DistanceUnit.CM);
        } catch (Exception ex) {
        }

(I was planning to try to print the Exception if / when it happens, but I haven't yet gotten that far.)

It turns out, one of the related side-effects we seem to observe is that the version number of the MR Range Sensor reports variously as v0.0, v1.2 (which seems to be the correct value), and v15.15.

Thanks,
Martin Haeberli
(de-)Mentor, FTC 7593, TigerBots

Thanks,
Martin Haeberli
(de-)Mentor, FTC 7593, TigerBots

[mikets]

I think PhilBot was right. We were running some more test runs yesterday and the autonomous finished before the 30-second timeout has expired so we just stopped the run with about 3 seconds left. On the next run, we pressed INIT and before we pressed RUN, we noticed the timer was still at 3 seconds. So if we had started the run, it would have just run for 3 seconds and quit. We never paid attention to that assuming the timer will "reset" before each run. But since PhilBot has mentioned this, I now pay more attention to the timer and saw this happening. So that's probably what had happened before. We just didn't pay attention.

[mikets]

Martin,
We don't have any problem with our range sensor. So I have no idea what caused your issue. If the range sensor access really caused an exception, unless it was an InterruptedException which is handled by the FTC SDK, the RC app should be terminated with exception info printed on both the RC and DS phones as well as on the debug console of Android Studio if you are connected to it. So I am not sure what you can do in your exception handler other than doing the exact same thing as if the exception was not caught.

[mikets]

Martin,
We don't have any problem with our range sensor. So I have no idea what caused your issue. If the range sensor access really caused an exception, unless it was an InterruptedException which is handled by the FTC SDK, the RC app should be terminated with exception info printed on both the RC and DS phones as well as on the debug console of Android Studio if you are connected to it. So I am not sure what you can do in your exception handler other than doing the exact same thing as if the exception was not caught.

May be you can catch the InterruptedException and throws some other exception just to make sure nobody was throwing an InterruptedException and "gracefully" terminate the RC app as if the "Stop" button has been pressed.