Robot is losing communication in autonomous

when starting autonomous robot loses communication, we have to power down and back up. This does not happen all the time. we have a trained tensor flow model that we 3D printed. we are plugged in to USB 3

Greetings. I believe I was just speaking with REV Technical Support about your situation.

Any time you run into issues like this, it’s helpful to perform a root-cause analysis. This involves attempting to reproduce your problem with the least amount of code possible - this will help immensely in narrowing down the discussion.

I presume that your problem does not occur when you use the Custom TensorFlow OpMode sample, right (and inserting your TensorFlow model instead of using the default model)? If you think that’s a possible cause of the problem, ensure that your model works well in that sample, and then work your way up. Once you have identified where the problem might be, we can begin having a discussion and suggest solutions.

It might also be helpful for you to provide a copy of your Robot Controller logs. Can you create a Google Drive and share the link to that drive with your logs? If there’s a crash, we can at least attempt to determine where you’re crashing, and then we can begin to determine why you’re crashing.

-Danny

let me get with my programmers and get a copy of the logs. I was talking with my programmers a few minutes ago. They were thinking it was cause by them pressing there claw into position and moving the servos from the start position, for autonomous. could that be a possible cause, it only happens during the start of autonomous.

Just understand that there’s virtually no difference between an Autonomous OpMode and a Driver Controlled OpMode except for the expectation that there is no gamepad data when running in Autonomous (minus annotations and similar). If you’re having problems, it’s due to code you’re executing - regardless of what “mode” it’s running in. Meaning it’s absolutely possible to do the same thing in a Driver Controlled OpMode and determine what sequence of events/calls/commands “forces” the system into the bad state you’re experiencing.

I’m looking forward to seeing your results.

-Danny