Mysterious robot run abort.

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

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

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

[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

[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

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

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

[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

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

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

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