Control Hub and Driver Station Disconnects after initialization

Software Control System
,
1

Hello, I’m a member of team 21227 and we’ve been expirencing difficulties as our control hub and driver station disconnects after initialization. We’ve tried to replicate it by testing our autonomous for multiple hours, but it seemed to be pretty random. Our team is using a Logitech 720p camera connected to a USB 3.0 port. Our control hub’s firmware and OS are both also up to date. We’ve tried to interpret the logs, but have little sucess in deciphering what are the causes of the disconnects.

We are wondering if this issue is related to the camera’s memory overloading because it does not occur when running the autonomous program without the camera. If so, is there any way to decrease the camera’s memory usage by decreasing framerate or resolution?

Here is a sample of our logs:

We have also noticed that our logs shows OpModes that we didn’t run as empty or corrupt and show up as errors in the REV Hardware Client. Today, we noticed some new fatal errors that showed up in the REV Hardware Client and new errors like memory overloaded, but our most common erros still are from
01-15 14:52:47.854 to 01-15 14:52:48.082 in the log above. There is also usually a bunch of libusb errors before it.

Any advice would be appreciated. Thank you!

2

In your logs I’m seeing signs of ESD effects on your IMU:

  • 01-15 14:26:07.840 30702 31110 W BHI260IMU: getRobotOrientationAsQuaternion(): Failed to retrieve valid quaternion from IMU. Returning the identity quaternion.

And I think your camera is also being hit by ESD:

  • 01-15 14:27:38.555 30702 30974 D UvcStream: [stream.cpp:654] bad packet: error bit set
  • 01-15 14:27:38.556 30702 30974 E libusb : [132.380710] [000078fe] libusb: error [op_clear_halt] clear_halt failed error -1 errno 32

Your program/robot isn’t crashing, but your devices are being affected, and may not recover until rebooted. There’s nothing you can do at this moment for your IMU, but for your webcam I highly recommend using a resistive strap on any surface that your webcam is mounted to. Also make sure NOTHING outside your robot touches your webcam.

I don’t see any specific mention of the Control Hub rebooting by nefarious means in the logs, but that doesn’t necessarily mean there isn’t anything happening. Can you also provide your source code that seems to reproduce this (even if this is hardware related)?

-Danny

3

Thank you so so much for the help!

These were the programs being tested

(I don’t know why but some programs we didn’t run were also mentioned in the logs)

Can you please give an example of the resistive strap you are talking about and how should we implement it onto our robot? Thanks!

4

When Blocks enumerates the programs it is managing, it tries to open each program. If there’s a problem with a program, the log will reflect it. That happens regardless of whether or not you’re running the programs or not.

Sure. This is the strap I’m referring to:

The strap essentially tries to equalize the potential between the robot’s electrical system and the place where charge is building up (or will be injected onto the robot). If the potential can be equalized, the ESD consequences are greatly diminished (remember that charge jumps from areas of high charge to areas of low charge, and if the charge is equalized no charge will jump!). So what you do is connect this strap to an available XT30 port on your robot (the expansion hub is the most likely device that has an open port, unless you’re using a power distribution block) with or without an extension cable and connect the ring terminal to a surface you want to “equalize.” Generally you connect it to a metal surface or a plastic surface that perhaps electronics are also connected to. If an ESD charge hits that surface, the strap acts a little like a lightning rod, protecting the electronics as much as it can. It’s not an end-all be-all ESD protection mechanism, but it can greatly reduce the effects in many cases.

Here’s a link to an ESD article that describes one use of the grounding strap. Be sure to read the whole article for a lot more in-depth knowledge about ESD.
https://ftc-docs.firstinspires.org/en/latest/hardware_and_software_configuration/configuring/managing_esd/managing-esd.html

-Danny

6

Ohhh okay. Does that effect anything or is it just telling us there’s something wrong with the code?

7

We already installed that on our robot, and I don’t think we installed it wrong. Would wrapping the control and expansion hub in aluminum foil work in preventing ESD?

Also are there any other IMU that we can fix or that we need to be aware of?

Thank you so much!

8

It’s just telling you there’s something wrong with that program, it doesn’t affect anything unless you actually try to open or use that program.

It all depends on what your goals are. You can install it, you can install it correctly, and you can install it so that it’s actually useful. All three conditions may look the same, but have very different outcomes.

No, in fact that would likely make everything worse, and you’re likely to have additional problems that you’re not yet experiencing.

I’m sorry, I don’t understand this question.

-Danny

9

I don’t know if this addresses your question, but there’s a thread that describes using the Adafruit BNO055 IMU instead of the one built-in to the Control Hub. See Guide: Using an External IMU .

10

Thank you for your responses. For my last question, I meant that are there any other IMU problems inside the logs that we can fix?

11

Okay thank you. I’ll will look into that