Mysterious robot run abort.

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

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

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

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

[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

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

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

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

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

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

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