We are having an issue with our control hubs randomly disconnecting from the driver hub. We have had this issue across multiple robots with different hubs. The only similarities between them are the same pinpoint/Odometry and melobotics encoder. We dont have any USB devices only use uart and I2c ports with servo and motor ports. The control hubs are not daisy chained, and they have a grounding wire. Our coder looked at the logs and said there might be something with our Pinpoint shorting and causing watchdogs to restart the system. If anyone has the same issues or has a solution, it would be a big help.
Perhaps we can verify what you’re seeing if you provide us a link to your log files?
https://drive.google.com/drive/folders/1ps85-KXHTKJN56TXF2rEp6NYH3Mt8Vrv?usp=sharing
Sorry, here are the logs. I’m trying to get in contact with my coder to get what he exactly said might be the issue.
I just called my coder and he said the error he was talking about was in a different file but the files I provided was also in a match that the robot disconnected.
Yeah, what I’m seeing shows that the Control Hub lost communication with the Driver Station during the operation of the OpMode, and the OpMode aborted because there was no communication with the Driver Station device.
This is the log from an OpMode that aborted early:
02-08 16:30:47.418 963 1186 I RobotCore: ******************** START - OPMODE SampleAutonomousMain ********************
02-08 16:30:47.640 963 1186 D HardwareMap: Clearing which device instances have been retrieved
02-08 16:30:47.739 963 1201 V RobotCore: thread: 'OpModeThread' starting...
02-08 16:30:47.756 963 1163 V Robocol : sending CMD_NOTIFY_INIT_OP_MODE(219), attempt: 0
02-08 16:30:47.778 963 1201 I I2C : Automatically initializing I2C device GoBildaPinpointLocalizer (USB (embedded); module 173; bus 3; addr7=0x31)
02-08 16:31:30.798 963 1159 V Robocol : received command: CMD_RUN_OP_MODE(10546) SampleAutonomousMain
02-08 16:31:30.837 963 1163 V Robocol : sending CMD_NOTIFY_RUN_OP_MODE(637), attempt: 0
02-08 16:32:00.880 963 1159 V Robocol : received command: CMD_INIT_OP_MODE(10957) $Stop$Robot$
02-08 16:32:00.892 963 1201 V RobotCore: nack rec'd mod=2 msg#=0 ref#=0 reason=CANCELLED_FOR_SAFETY:259
02-08 16:32:00.904 963 1201 V RobotCore: nack rec'd mod=173 msg#=0 ref#=0 reason=CANCELLED_FOR_SAFETY:259
02-08 16:32:00.910 963 1201 E LynxI2cDeviceSynch: placeholder: readTimestamped
02-08 16:32:00.919 963 1201 D RobotCore: User runOpModeMethod exited
02-08 16:32:00.921 963 1201 V RobotCore: thread: ...terminating 'OpModeThread'
02-08 16:32:00.927 963 1186 I RobotCore: Attempting to switch to OpMode $Stop$Robot$
The key line is this one:
02-08 16:32:00.892 963 1201 V RobotCore: nack rec'd mod=2 msg#=0 ref#=0 reason=CANCELLED_FOR_SAFETY:259
For example, an OpMode that ran successfully is this:
02-08 16:51:21.959 959 1171 I RobotCore: ******************** START - OPMODE SampleAutonomousMain ********************
02-08 16:51:22.169 959 1171 D HardwareMap: Clearing which device instances have been retrieved
02-08 16:51:22.257 959 1203 V RobotCore: thread: 'OpModeThread' starting...
02-08 16:51:22.285 959 1203 I I2C : Automatically initializing I2C device GoBildaPinpointLocalizer (USB (embedded); module 173; bus 3; addr7=0x31)
02-08 16:51:22.293 959 1186 V Robocol : sending CMD_NOTIFY_INIT_OP_MODE(346), attempt: 0
02-08 16:53:28.715 959 1157 V Robocol : received command: CMD_RUN_OP_MODE(11442) SampleAutonomousMain
02-08 16:53:28.733 959 1186 V Robocol : sending CMD_NOTIFY_RUN_OP_MODE(1557), attempt: 0
02-08 16:53:58.795 959 1157 V Robocol : received command: CMD_INIT_OP_MODE(11853) $Stop$Robot$
02-08 16:53:58.823 959 1203 E LynxI2cDeviceSynch: placeholder: readTimestamped
02-08 16:53:58.830 959 1203 D RobotCore: User runOpModeMethod exited
02-08 16:53:58.831 959 1203 V RobotCore: thread: ...terminating 'OpModeThread'
02-08 16:53:58.838 959 1171 I RobotCore: Attempting to switch to OpMode $Stop$Robot$
02-08 16:53:58.841 959 1171 I RobotCore: ******************** STOP - OPMODE /storage/emulated/0/FIRST/matchlogs/Match-0-SampleAutonomousMain.txt ********************
Notice in the good case the user runOpModeMethod exited normally.
So now the question is why your device is disconnecting. Lots of possible reasons, some normal and some nefarious. But I look in the WiFi Log and I see some stuff that I am not liking:
02-08 17:07:13.427 1075 1075 I hostapd : wlan0: AP-STA-POSSIBLE-PSK-MISMATCH b2:b4:8a:93:48:3f
02-08 17:07:14.354 938 995 I FtcAccessPointService: HostapdMonitor: Received hostapd message: <3>AP-STA-POSSIBLE-PSK-MISMATCH b2:b4:8a:93:48:3f
02-08 17:07:14.452 1075 1075 I hostapd : wlan0: AP-STA-POSSIBLE-PSK-MISMATCH b2:b4:8a:93:48:3f
02-08 17:07:15.386 938 995 I FtcAccessPointService: HostapdMonitor: Received hostapd message: <3>AP-STA-POSSIBLE-PSK-MISMATCH b2:b4:8a:93:48:3f
02-08 17:07:20.433 1075 1075 I hostapd : wlan0: STA b2:b4:8a:93:48:3f IEEE 802.11: deauthenticated due to local deauth request
02-08 17:07:20.433 1075 1075 I hostapd : wlan0: STA b2:b4:8a:93:48:3f IEEE 802.11: deauthenticated due to local deauth request
02-08 17:07:36.375 1075 1075 I hostapd : wlan0: STA b2:b4:8a:93:48:3f IEEE 802.11: disassociated
02-08 17:07:36.375 1075 1075 I hostapd : wlan0: STA b2:b4:8a:93:48:3f IEEE 802.11: disassociated
02-08 17:07:54.039 1075 1075 I hostapd : wlan0: STA b2:b4:8a:93:48:3f IEEE 802.11: associated
02-08 17:07:54.040 1075 1075 I hostapd : wlan0: STA b2:b4:8a:93:48:3f IEEE 802.11: associated
02-08 17:07:54.052 1075 1075 I hostapd : wlan0: AP-STA-CONNECTED b2:b4:8a:93:48:3f
Are you using a phone or a Driver Hub? I’m seeing lots of deauth requests, lots of FTCAccessPointService errors, and whenever your ACS (Automatic Channel Selection) is enabled I see it selecting channels all across the spectrum. This immediately says to me your Wi-Fi environment is possibly too congested, or there’s lots of interference. There could still be issues elsewhere, but it’s difficult to tell without narrowing more down (that I cannot do from the logs).
-Danny
We are using a driver hub. That match both our robot and our alliance’s robot disconnected.
is there a good way to replicate ESD events?
Some folks have replicated ESD and EMI using DIY tools such as an electronic fly swatter, others have replicated ESD using a long-neck lighter (split it open, strip the wires, and zap away). This is if you cannot afford (or rent) an ESD discharge device (“ESD Gun”). However, I do not recommend doing any of these. ESD can damage your equipment. If you induce ESD into your equipment, you risk destroying it. In FTC we attempt to minimize the occurrence or minimize the impact (actually both) with our recommended strategies.
Both in the same match at maybe roughly similar times? Is that what you mean by that? Do you suspect ESD (did either robot touch the Submersible or the field wall at the time of disconnect)? I’ll caution that ESD is an easy scapegoat even when the issue isn’t ESD (not saying it is or isn’t, but I’d like to have more data if possible).
This is the YT link of the match. We are 5661 in blue, we disconnect towards the end, and our alliance disconnects in auto.