Control Hub & Driver Station Disconnects

Software Control System
1

We have had an issue with our Control Hub and Driver Hub disconnecting randomly during gameplay. This has affected our matches and is getting frustrating. I had our team spend 2 hrs driving the robot so that we could replicate the disconnection as much as possible. I downloaded the robot controller logs and took a look at them. I can’t seem to understand why its disconnecting. Only thing I have been able to find is the following.

1-12 16:34:58.382   983  1177 V Robocol : received command: CMD_INIT_OP_MODE(10355) Teleop ArmV1
01-12 16:34:58.409   983  1178 I RobotCore: ******************** START - OPMODE Teleop ArmV1 ********************
01-12 16:34:58.439   983  1253 V RobotCore: thread: ...terminating 'OpModeThread'
01-12 16:34:58.458   983  1247 I RobotCore: Attempting to switch to op mode Teleop ArmV1
01-12 16:34:58.676   983  1247 D HardwareMap: Clearing which device instances have been retrieved
01-12 16:34:58.676   983  1247 D HardwareMap: Clearing which device instances have been retrieved
01-12 16:34:58.680   983  1256 V RobotCore: thread: 'OpModeThread' starting...
01-12 16:34:58.698   983  1256 I I2C     : Automatically initializing I2C device LynxEmbeddedIMU (USB (embedded); module 173; bus 0; addr7=0x28)
01-12 16:34:58.699   983  1256 V BNO055  : Suppressing I2C warnings while we check for a BNO055 IMU
01-12 16:34:58.703   983  1256 V BNO055  : Found BNO055 IMU
01-12 16:34:58.718   983  1180 V Robocol : sending CMD_NOTIFY_INIT_OP_MODE(442), attempt: 0
01-12 16:34:59.214   983  1256 V BNO055IMU: Now polling until IMU comes out of reset. It is normal to see I2C failures below
01-12 16:34:59.221   983  1256 V RobotCore: addr=false data=true arb=false clock=false
01-12 16:34:59.221   983  1256 E LynxI2cDeviceSynch: readStatusQuery: cbExpected=1 cbRead=0
01-12 16:34:59.222   983  1256 E LynxI2cDeviceSynch: placeholder: readStatusQuery
01-12 16:34:59.454   983  1177 V Robocol : received command: CMD_RUN_OP_MODE(10375) Teleop ArmV1
01-12 16:34:59.464   983  1256 V BNO055IMU: IMU has come out of reset. No more I2C failures should occur.
01-12 16:34:59.557   983  1180 V Robocol : sending CMD_NOTIFY_RUN_OP_MODE(455), attempt: 0
01-12 16:36:10.555   983  1179 E Robocol : exception SocketTimeoutException(Receive timed out): no packet received [java.net.PlainDatagramSocketImpl.receive0(Native Method)]
01-12 16:36:11.816   983  1247 E Robocol : exception IOException(Invalid argument): exception sending datagram [java.net.PlainDatagramSocketImpl.send(Native Method)]
01-12 16:36:12.238   983  1180 V UpdateUI: Network: active, disconnected
01-12 16:36:12.238   983  1180 I RobotCore: ******************** STOP - OPMODE /storage/emulated/0/FIRST/matchlogs/Match-0-Teleop_ArmV1.txt ********************
01-12 16:36:12.258   983  1180 I EventLoopManager: Lost connection while running op mode: Teleop ArmV1
01-12 16:36:12.258   983  1180 V NetworkConnectionHandler: Peer connection lost
01-12 16:36:12.267   983  1309 I RobotCore: saving match logcat to /storage/emulated/0/FIRST/matchlogs/Match-0-Teleop_ArmV1.txt

Looking at this, I see that we are losing connecting. I have tried being on 2.4ghz and on 5ghz channels and the issue persisted. Any advice would be appreciated. There seems to be a lot of errors in the logs as well, and I don’t know if I should worry about that. Robot Controller Logs are too large for pastebin.

2

The poles in this game are efficient electrostatic discharge devices, and there have been reports that disconnects are happening when a robot touches a pole.

Try to observe if there’s any pattern when this happens and follow the best practices here…

http://ftc-docs.firstinspires.org/hardware_and_software_configuration/configuring/managing_esd/managing-esd.html?highlight=esd

3

Two minutes later? Was this a snippet of the log to keep it simple or was there really a gap?

It might not be ESD, but WiFi. Check out the following:
Driver Hub Disconnectes - Software / Control System - FIRST Tech Challenge Community (firstinspires.org)

4

That was the actual gap in the log.

6

Yeah, 71 seconds later after starting the opmode you get the timeout, that tells me that it’s less likely a control hub specific problem and maybe a wifi environment issue instead. You’re definitely disconnecting, but finding the culprit isn’t necessarily easy.

Some questions to answer are:

  1. Do you have too much metal surrounding the top face of the control hub (where the antenna is)? This can cause interference with the communications.
  2. Is your control hub mounted to metal, or are the robot’s motors too close to the control hub? This is also a very common cause of interference.
  3. Using a wifi monitor like “WiFi Analyzer” on Android is the channel you’re using for your robot open? Depending on how much traffic is happening on the channel by others, you might be being starved. You should keep an eye on your ping, which is indicated on the driver station in the network circle - high ping means network communication is difficult (anything above 20-30ms on average is high).
  4. Are there any commonalities to when you’re losing connection, like when your robot touches something on the field or when the robot touches a field wall?
  5. Do you have a grounding strap on your robot?
  6. Is your Webcam plugged into the USB 2.0 port on the Control hub? Plugging it into the 3.0 port (with the blue tab) instead may help against ESD causing the wifi chip on the Control hub from being affected by ESD charges.
  7. If you take your robot home, does it have the same issues?

-Danny

7

1 & 2. Our control hub and expansion hub are mounted to plexiglass on each side of the robot. There is no metal close to the control hub but there is a motor above it (5 in).
3. We have used wifi analyzer both at comps and at our school and have switched channels, still experienced disconnections. Our ping never goes above 8-10 ms
4. I haven’t looked for any correlation yet, but will keep an eye out next time
5. We do not have a grounding strap. How effective are they of preventing ESD disconnections?
6. Webcam has been plugged into 3.0 and we tried 2.0 as well. Same issues
7. We haven’t tested at home, but our concern is the disconnections at matches. We have asked the FTA’s for channels that aren’t being used and it hasn’t fixed our issue.