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.
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)?
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.
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.