-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
6.1 Causes a soft reboot on the E5 Play #79
Comments
Would it be possible to provide a video of said behavior? |
https://drive.google.com/file/d/1ufhvSyGSilHeCMRR6J-8My_pzS_xUA5X/view?usp=sharing Video uses FTC-Dashboard just to demonstrate that you can still run opmodes. The app does still crash with a completely fresh installation. No dashboard dependency. No new opmodes. Etc. Further clarification: They're e5 plays. However, #60 seems to be a control hub so I'm assuming it's not device dependent. |
Model: e5 play |
Wow. That video left my mouth open. Thanks for taking the time to make that. A hunch from a quick look at the logs is that it might be related to sound playing. Can you please turn off sounds in the RC settings and try again? Please provide logs from that run as well, if it still crashes. |
I'm curious why you think this is related to #60. That user was reporting intermittent crashes during an OpMode run, but you're reporting consistent crashes on DS connect. |
I did notice that the DeadSystemException was preceded by the "did not receive expected priority boost on time" but that didn't really surface anything on google. The crash still occurs with the sound off. It seems that it still attempts to play the sounds. Just at 0 volume. https://gist.github.com/NoahBres/2e2b0cd3b3365a71ea7a8d7b6caf643a |
@NoahBres Ooh. Please try turning off the 5 GHz warning in the RC settings and see if that works around the issue. |
That does prevent the crashing! |
Yeah, this is the smoking gun then
|
Did you turn off sounds, the warning, or both? Edit: oh, I missed your other message |
Turned the sound back on. It works fine! Turning the 5GHz warning off seemed to prevent the crashes. |
Same here. Turning off 5Ghz warning fixed the issue. Only happens on Moto E5 RC after DS connection.
|
I know y'all have this all figured out already internally but just in case anyone stumbles upon this issue and was curious: The app causes an OS soft reboot on the E5 when this particular line is called:
However, a blank app with the same Workaround: |
Adding 100 ms delay fixes the issue, but probably creates some other downstream issues.
Do we need to check 5GHz support in every loop iteration or it can be done once and stored in a variable? |
This issue will be fixed in the next version of the Robot Controller app. |
SDK v6.2 has been released, which fixes this issue. |
…teleop-start Jackrevoy/teleop start
The 6.1 SDK will cause a soft reboot after a while. It only seems to be caused once the RC phone is paired to the DS phone. I can force run opmodes via FTC-Dashboard completely fine when the connection between the RC and DS is severed. But, once I make that connection, within a minute or two, regardless of whether an opmode is running and regardless of whether the phone is plugged into an expansion hub or not (I am using phones + expansion hub, not a control hub), the phone will soft reboot. It is definitely a soft reboot because the tcpip server still lives after the reboot. Plus the reboot is much faster than a normal one.
(#60 is unrelated)
I believe issue #60 is actually related to this. The behavior they describe is exactly the same as mine. However, the match logs they provide have no indication that anything actually crashes.The app will crash regardless of whether an opmode is running or not.Most likely because the OS has killed the app's logcat monitor(i have no clue what im talking about). The log I posted has the same error as #60, "unexpected exception thrown during lynx communication" but that's only because I ran an opmode in that sample.Behavior is completely normal on 6.0. Behavior is still prevalent in a fresh clone of 6.1. Behavior is still relevant if I keep the FtcRobotControllerActivity the same as 6.0 so it's an internal SDK specific problem.
Relevant errors on line 655:
https://gist.github.com/NoahBres/2f8e310106f5a7c1496b5632098d6327
The text was updated successfully, but these errors were encountered: