FIRST-Tech-Challenge
registerFilter and processAllClasses get called again.
While this issue has not happened to me, I've seen several teams have it, and there doesn't seem to be a particularly apparent cause / solution.
The following errors are produced on the DriverStation:
Class processing had already started when registerFilter() was called. You must
register your class filter before processAllClasses() is called in
FtcRobotControllerActivity.
processAllClasses() should only be called by the system. Any additional calls
are ignored.
These can only occur when the AtomicBoolean processAllClassesCalled on
org.firstinspires.ftc.robotcore.internal.opmode.ClassManager has been
set to true.
I would imagine that this is occurred by a soft restart of the application caused by a previously caught crash.
These issues are not caused by users manually calling this process again.
There seems to be a general consensus that this issue is caused by something to do with vision pipelines.
One team has reported that the issue was caused by low battery and a crash related to being unable to find their webcam.
It would be helpful for teams that have experienced this issue to add their experiences resolving it, and logcat files to this issue.
When this happens it spams the ds with the error then just disconnects the robot, sometimes reconnecting and sometimes not. It happens when we bump into stuff, presumably because there is ESD which temporarily disconnects the webcam which is running a processor at all times.
Since you mention bumping into stuff (and ESD) maybe you can avoid the error. Maybe it's ESD, maybe it is just a loose connection. If ESD or mechanical vibration reliably triggers the error, then maybe the error message is a symptom, not the cause.
This link specifically mentions not to use the USB 2.0 port with a webcam due to ESD on that port affecting wifi, use the USB 3.0 port instead. https://docs.revrobotics.com/duo-control/troubleshooting-the-control-system/troubleshooting-the-control-system#esd-mitigation-techniques
If you know your field has low relative humidity (below 40% at room temp) and is subject to static electricity (you often get shocked when touching the robot or field elements) you might what to treat your field to reduce ESD. Staticide should reduce the number and severity of ESD events as those can permanently damage electronics. see page 55 Appendix L: Recommendations for Static Mitigation https://www.firstinspires.org/sites/default/files/uploads/resource_library/ftc/tournament-director-guide.pdf You can also spray with water. This is free and might be something to try before getting Staticide.
FIRST has an ESD document here that has mitigation ideas: https://ftc-docs.firstinspires.org/en/latest/hardware_and_software_configuration/configuring/managing_esd/managing-esd.html
The Robot Wiring Guide has lots of advice on securing wires and strain relieving connections (including USB connections). Found here: https://www.firstinspires.org/resource-library/ftc/robot-building-resources
Other wiring things to check relate to XT30 connectors: https://docs.revrobotics.com/duo-control/troubleshooting-the-control-system/control-hub-troubleshooting#xt30-pins-are-compressed I've even seen the solder break under the wrap between the wire and the yellow XT30 connector. See if you can wiggle all the wires/connectors from the battery to power switch to control hub and cause a power cycle.
We have done every possible measure to prevent ESD, and if the power had a faulty connection, the robot would disconnect and restart, not spam 100 of the class processing and already started errors on the DS. I think the camera is much more sensitive than the rest of the robot, so a slight shock which would not disrupt the control hub can disrupt the USB signal, which causes the camera to momentarily disconnect, which causes this error.
Can you post a link to your code on GitHub? Also a link to a robotcontroller log file from a session where the error occurred?
That will let us know what vision processing you are doing during the event and the log may have some associated messages that might help.
If you're still having problems after applying Staticide (or water), and you've got a grounding strap and so on, then it might not be an ESD event. Otherwise there is more ESD mitigation you can do. You might want to confirm by checking humidity (I use an AcuRite temp/humidity monitor). If you live in a region where it's cold and dry in the winter then you probably should treat your field and address all the ESD mitigation measures.
Regardless of the cause, if this is a USB disconnect followed by a vision pipeline error then it would be nice to have a more helpful message, or even recover the pipeline processing if possible so it can continue without an error.
I think the SDK handles USB reconnects better than it used to, but it could be something in the vision pipeline doesn't handle webcam errors very well.
This is not an event that should occur on USB disconnect, regardless of reason.
This doesn't seem to be related to ESD, we had it randomly happen while testing camera without robot even moving or anything similar, and it only happened once in maybe 200 opmodes ran, and that's with usb hub that has a very good ESD protection too (plugged in usb 3.0)
Can we get a robot controller log file that includes the error? Also a link to the source code. Not much anyone can do if we can't replicate the problem or pinpoint where it's happening. That kind of error should have a stack trace in the robot controller log. I've never had this happen to me or my team.
I'll upload some logs tomorrow when I get back to the lab, the code is not public though. This never happened to me the last 3 seasons but somehow I see many people randomly having this error popup, so it's totally not a hardware issue (only thing new on the robot would be pinpoint odometry)
We had it happen multiple times today, I think every time it was when exposed electrical contacts were near metal. Literally all the log says when it happens is the registerfilter error and the robot startup messages, nothing else.
I do not think ESD is a root cause here, I think ESD is inducing symptoms of lifecycle problems. ESD can cause USB hiccups, which can then cause lifecycle events to be handed to the application. This would also explain why people seem to think it's related to cameras.
I experienced this today after installing a webcam. A robot restart made it disappear, however it took a couple attempts. It also happened after a mysterious error with a webcam not being found and 0 sdk intervention (it just, didn't process any frames in the vision portal)
Also started experiencing this error when testing a new camera. Our USB connection is intermittent at the moment (the "could not find camera with serial number..." message pops up sporadically on the DS), so the error might be related to that. We would appreciate a workaround so that our robot will not irrecoverably disconnect if this happens during a match.
