Intermediate Functioning Issues

Our team is having some ongoing problems with intermediate functioning. Over half of the times we run our autonomous, the robot loses connection and stops partway through the program. It sometimes happens immediately after the autonomous starts, though sometimes the robot works for ten seconds before dying. Other times we can run our autonomous perfectly, without changing anything between trials. We also occasionally disconnect when driving the robot with controllers, though this happens a bit less often.

Here’s some possibly relevant info on our situation:
The VEXnet key on the robot is in an open location
We program with RobotC
We use two robot batteries, plus a backup battery
Battery power level on the robot doesn’t correlate to connectivity
One common spot for the robot to die is one second after starting
Another spot is after manually pushing a button on the robot when it returns to the starting tile

Here’s what we’ve tried so far:
Switching cortices
Redownloading firmware
Switching VEXnet keys on the controller and on the robot
Running autonomous from a laptop and from a competition switch

Has anyone run into problems like this before? Does anyone have any suggestions on how to fix it? Thanks in advance.

Occasionally our robot will just randomly cut out as well. I just attributed this to the fact that we were using a “battery mod” for testing. If other people are encountering this it might be a vexnet issue, or just a weird bug or something. I have also noticed that it seems to cut out more often when the programming cable is plugged in, but that could just be a coincidence.

Are you encountering this problem only in autonomous mode?

Neither setup, programming cable or competition switch, seems less buggy than the other. And no, we sometimes disconnect when driving with controllers. We disconnect in autonomous significantly more often, however.

Is it actually disconnecting or are the motors just failing to work? If it doesn’t actually disconnect it sounds like in your case it might be motors over heating. We had this problem last year and cost us heavily at world’s. Our motors were mounted to low to the ground and did not have good airflow, so when they were taxed heavily the motors would burn out and we wouldn’t be able to move. If its actually disconnecting I would suggest making sure all your firmware is up to date, and maybe try resyncing your joystick and controller. I would also try different vexnet keys if the problem persists. Also, make sure that the vexnet key isn’t coming loose at all.

The motors aren’t hot. They’re all fairly in the open, and we have the problen when we first start using the robot after it’s been off for 20+ hours. Plus, if the motors were overheating, then the robot should die more often when being continuously driven by controllers than the by sporadic running of autonomous, however this is not the case. We’ve already redownloaded firmware and replaced our VEXnet keys. The VEXnet key on the robot is attached to the cortex by two extension cables but the connections all seem strong. Also, we don’t usually touch the connections between trials, so that wouldn’t explain why the robot sometimes works and sometimes doesn’t.

Try putting some sort of shock absorbing modification on the mounting places for the Cortex & the Vexnet key.

Even though the connections between cables “seem” to be strong, there’s A LOT of unnoticeable vibration on a robot.

What does the beginning of your autonomous routine do? If you are suddenly pulling power from a significant amount of motors, the surge might make the connection unstable. Try staggering the start of the motors in this case so it’s like “start 4 motors then start another 4” instead of “starting 8”.

Hope this helps.

The usb connections for the VEXnet are held together with zip ties. It is very unlikely that they are coming loose, but I will take a look the next time we meet.

Sometimes the connection does fail when we begin drawing power from eight motors at once. However, at the very beginning of our routine, we run two 269s for about a second and then start running four 393s (still spinning the 269s). It’s hard to tell, but the disconnection seems to occur when we start the 393s. Is starting 4 393s enough to cause a surge?

Thank you (and Thorondor) for the advice.

Are you sure that your backup battery is fresh and plugged in?

Have you thoroughly debugged your program? Are you running multiple threads in ROBOTC? ROBOTC is very powerful, but if you have multiple threads running they could be causing conflicts during auton if you do not handle them correctly.

All of the symptoms you have described lead me to believe it is something in your program.

Our backup battery probably has a low charge by now, which might explain the issues we have when it’s plugged in. But we do still disconnect when it’s unplugged and the two robot batteries are fully charged. We’ll replace it next time we meet and see if that helps.

I’m not the team programmer, so I don’t know if we run more than one thread. But we’ve had several people look at the code and nothing seems like it would cause this big or inconsistent of a problem.

A few additional comments.

The backup battery should overcome any drop in voltage of the main battery due to high current demands from the motors, thats the whole point of having it. In fact, you can (briefly) disconnect the main battery and the VEXnet connection should be maintained.

There really is no difference between autonomous control and driver control from the standpoint of the RobotC software. Yes, different tasks are started and joystick data suppressed in autonomous but otherwise there’s nothing special about the code. Motor control may have steeper acceleration in autonomous due to full speed drive being sent to the motors ( motor MyMotor ] = 127; etc.) whereas under driver control there is usually some inherent slew rate just because the analog joystick has to be moved by the operator. Perhaps try your autonomous with lower motor speeds as an experiment.

Have you tried to run in a different location? Some schools have WiFi “killers” to stop ad-hoc networks. Is there any other local source of WiFi interference such as a microwave oven near to where you are testing?

Yes, we will replace our backup battery and see if that helps. I’ll also pass on your programming suggestions.

Other teams in our club don’t have any connectivity issues and we didn’t have any last year, so it’s probably not the location. Ha ha we do actually have a microwave in our building space, but no one ever uses it.

Adam, I’m not sure if anyone else in the club uses the Vexnet key extension (I think most people just connect the key directly to the Cortex); if anything, this should only improve connectivity, but it’s one point of concern. If you can also eliminate the backup battery and the programming as possible causes, then you might want to test with different Vexnet keys, new firmware, then a new Cortex (in that order). We’ve had our share of Vexnet issues, though of a different sort, and have determined that it was a faulty Cortex.

maybe the cortex leads to the battery are loose
so the battery would “jitter” and lose the connection for just a brief moment, just enough to get disconnected

Yes, we use the VEXnet extension because we fear that our Cortex might be within a Faraday cage when our arm is down (we’d reposition it if we could). Our connectivity issues predate the extension. Actually, the extension was the first thing we tried when we started having connectivity issues and it didn’t make anything worse, so we decided to leave it. We can try connecting it directly again or changing extension cables and seeing if that makes a difference. We’ve already replaced VEXnet keys, the Cortex, and redownloaded firmware.

murdomeek, we found that our old Cortex had exactly that problem, which is why we decided to switch. At first the new Cortex performed fine, so we thought that was our issue, but it has since started producing the same error. The battery connection on the new Cortex seems solid.

Okay, just to make sure you don’t have a hardware or location issue, create a very simple project to just drive the robot base, and see if you still have connection issues. If you do, replace the extension cable and try again. If you don’t, have your programmers go through the code for bugs. Or, try using a USB extension cable with your existing code as a tether cable.


my team had a similar scenario yesterday at a tournament. the main difference i see is that we were using easy c. we tried the things that we were recommended to with no success. we ran our autonomous normally with no issue, then once the competition switch was switched to operator control our joystick lights we: joystick: solid green; robot: none; vexnet: solid red; game: solid green. thanks for any help!

Two related experiences:

  • I purchased 10 monoprice gold-plated 18" USB extensions, and vexnet doesn’t connect through any of them.
  • At Texas BEST Regionals in November, field 2 yellow had a dead spot. Unplugging the two Cisco wifi boxes on the game floor greatly reduced the occurance of dropped connections.

we have been using a usb extension too, however it is the same one that was used at the previous tournament that we attended, which had no vexnet dropouts.

Thanks to all who responded. Replacing our backup battery and directly connecting our VEXnet key to our Cortex seem to have done the trick. Just in time for our next competition, too.