Mysterious robot run abort.

[robgcarlisle]

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.

Seen it. we also have the worst problem of it stopping and being hung in the stop routine... see my other post. This could be related to other posts about bad motor controllers...

[mhaeberli]

all,
Mischief managed - per Modern Robotics - the Core Device utility reports results back in decimal, not in hex - so decimal 18 parses to hex 0x12 which becomes v1.2.
Thanks,
Martin

[5294-jjkd]

Version number as two nybbles perhaps? v1.2 represented as 0x12 becomes 1 x 16 + 2 = 18 (decimal not hex) if I am interpreting this correctly...

[mhaeberli]

MikeTS,
currently I'm looking to get back the phones to pull their logs.
And planning to update the try / catch to print the actual exception ...
I'll post again if / when I know - the holiday break may put a crimp in figuring this out quickly.
Thanks,
Martin

[mikets]

MikeTS,
Our de minimus exception handler (empirically) effectively catches and dismisses the exception. So that it's not escalated to higher levels that terminate the OpMode immediately... Not saying that this is a clean approach...
Thanks,
Martin

Did you check what exception has been thrown? I am just curious.

[mikets]

Sorry, I was referring to "If you start the opmode again, you may have multiple instances of the same object from a "previous run" hanging around.". You were observing situations where this was an issue because the RC wasn't exiting when you thought it was. But if that's a problem for you, I think you'd see the same issue if the robot is merely 'restart'ed. Thus, the exit-behavior of the RC isn't exacerbating any issue which isn't already there.

FWIW, the current exit behavior of the RC is simply to finish() the root activity and let Android handle the actual management of the underlying process, which I understand to be recommended Android practice. This yields a loose correlation of the process lifetime with the app stack that you can get to from the lower right phone button: if the RC app isn't in that list, then you can be assured that its process isn't running; but if it's in the list, the process may or may not be running, as Android might have reclaimed it if it were running low on resources.

I made the observation that if I exit the RC app using the "3 dots"->"Exit", the "lower right phone button" still shows the RC app in the list. If I "re-select" the RC app from the list, it came back up and if I press "INIT", our opmode will initialize again instantiating our menu class. Then I notice, the menu sometimes doesn't show up as if somebody else is clearing the menu repeatedly. We finally made the menu class to check a static instance variable to make sure only one may exist, then the problem went away. So it is no longer an issue for us. Just an observation of this unexpected behavior.

[mhaeberli]

dmssargent,
I understand how 0x00 becomes v.0.0, and how 0xFF (255) becomes v15.15.
I remain stumped on the minor question of how 0x18 becomes v1.2 vs v1.8 (which is what I would have expected in the circumstances).
Best,
Martin

[mhaeberli]

MikeTS,
Our de minimus exception handler (empirically) effectively catches and dismisses the exception. So that it's not escalated to higher levels that terminate the OpMode immediately... Not saying that this is a clean approach...
Thanks,
Martin

[FTC0417]

Sorry Robert, what's the context of your comment? The thread has diverged a little so I am not sure what you are asking.

Sorry, I was referring to "If you start the opmode again, you may have multiple instances of the same object from a "previous run" hanging around.". You were observing situations where this was an issue because the RC wasn't exiting when you thought it was. But if that's a problem for you, I think you'd see the same issue if the robot is merely 'restart'ed. Thus, the exit-behavior of the RC isn't exacerbating any issue which isn't already there.

FWIW, the current exit behavior of the RC is simply to finish() the root activity and let Android handle the actual management of the underlying process, which I understand to be recommended Android practice. This yields a loose correlation of the process lifetime with the app stack that you can get to from the lower right phone button: if the RC app isn't in that list, then you can be assured that its process isn't running; but if it's in the list, the process may or may not be running, as Android might have reclaimed it if it were running low on resources.

[dmssargent]

You version number corresponds to the register FIRMWARE_REV returning either 0 or 255 (255 -> v15.15; 0 -> v0.0). Either way it seems that this can be treated as a sanity check as with the version number that is provided (namely "v1.2") the register should read 18. The code that can be preform the reading of version number is

ModernRoboticsI2cRangeSensor rangeSensor = <the means you use to acquire such a software object>
if (rangeSensor.read8(ModernRoboticsI2cRangeSensor.Register.FIRMWARE_REV) != 18) {
    // the sensor has not passed this sanity check, alert someone about this condition
}

By the way, if you really want to alarm someone that things aren't right if the controller app, you can always throw an uncaught exception on the main robot controller thread, which forces the app to restart (if programmed to do so), or crash and show an error dialog. A crashed app is not running in the background. However, to more experienced programmers, you can restart the app after killing the app pragmatically. The following is the fatal error handler from an older project on mine to re-implement some functionality of the Robot Controller: https://github.com/dmssargent/reimag...onHandler.java. It may serve to be useful.

[mikets]

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?

Sorry Robert, what's the context of your comment? The thread has diverged a little so I am not sure what you are asking.

[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.

[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]

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.

[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