Twitchy response from PIC/RobotC

We are having some unusual problems with our robots.

Background: We are using RobotC 2.3 with the PIC. Robots have 4 motor drive train, two motors lifting a lift of some kind, and two robots have a motor for a claw. Most robots only using two high strength motors (one does it without using any) that are on the lifting mechanism. The ports for these motors are things like 1 and 4 or 4 and 8.

Issue: The robots seem to drive fine for about 30 seconds then become non-responsive intermittently with twitchy behavior from motors (very jerky movements and responses like “dropped” signals for a second). We are just practicing driver control when this happens and it seems to last for a while. However, it we leave the robot alone for some time (30 mins) it seems okay.

Solutions attempted: Batteries have been changed (often); firmware (master and vex) reinstalled.

Although is seems like the firmware fixes things for a brief time, the issue returns. Is it possible that we are drawing too much current on motors? It’s not like we are using more motors than any previous year. Any other causes? solutions?


You didn’t say if it was VEXNet or the crystals.

Crystals, make sure that the yellow antenna wire is not running along metal, it should be freestanding and up in the air. Make sure the transmitter antenna is screwed in the entire way and it is fully extended.

VEXNet - make sure that the dongle has clear access, that while you are driving it, moving the arm, etc that it does not become covered or blocked.

On a “won’t hurt to try” drive the robot some place else, preferrably where there is no other Wifi points (not other VEXNet, but regular wifi). We have a strange case that we are trying to reproduce where the robot is run in a WiFi “rich” environment (4 access points in a 20’ sphere from the robot) and it gets the twitch sometimes.


Double-check your code, too. Twitchy behavior is more likely to be a software issue caused by sending conflicting motor values in rapid succession. Let us know what you figure out.

Thanks for the responses…We are using VexNet and have recently tried it in a new location (our Gym versus our library).

I highly doubt it is code as multiple robots are doing it with very basic user controls, but will try to look at it.


Do the Vexnet LED stay green, or drop to red?
Do you have a fresh 9v backup battery plugged in?

Well, we still haven’t solved the problem and didn’t fair to well in the tournament.

VexNet never seems to drop on the signal (lights stay green). However, robot lights are red (while building, we usually don’t have the back up battery attached).

On suggested problem was that the RobotC (or IFI Master) firmware gets corrupted if the battery is low during downloading code. The solution is to (1) make sure a fully charged battery is in use during programming and (2) reinstall firmware if issue arises.

We have another competition in week and will be working very hard to solve the problem this week as we tweak mechanical designs.

I think the first major task we hope to accomplish is to program a full minute of possibly just driving around and move the arm up and down and see if twitchy issues occur during the autonomous. If the robot executes well, then the assumption is communication between receiver and transmitter is the main issue (not electrical).

Please continue to post ideas and thoughts!

More info on cause of poor robot response:

On one robot, we made a 1 minute autonomous program that has it drive forward, turn about 180 degrees and repeats until the minute is up.

After the 3rd or 4th turn, it was obvious that the motors were not performing the same on the turns (forward seems okay). For now, we are just using timing, but it was VERY obvious that the motors were performing poorly (about 1/4 turn instead of 1/2 and they were “struggling” - I’m afraid if we try to use encoders for the turn, the motors will stall for sure). Fresh battery and partially used battery tried. Both had similar response with a slightly longer time for the fresh battery to start to “struggle.”

Our drive train has a ratio of 3:5 for speed and uses four regular motors (each pair y-cabled) with two omni, two traction wheels (4") (traction on back). Also, the robot weight seems no heavier than previous years.

Although we are not using the power expander, we never have. This is the first year we have had such poor performance with motors after such a short time (between 30 seconds to a minute). Of course, when we add motors for mechanisms, the problem is worse. However, we aren’t even running anything else right now.

We also have similar response (actually worse) under tether for multiple robots. A simple four motor drive train and the motors just seem to get overloaded (mainly on the turns).

The motors do seem to get pretty warm under user control, but I don’t understand why they are “struggling” after only a few half turns of the robot? The robot power definitely seems like it has an exponential decline in power performance. This seems to be the main reason for poor/twitchy performance. Could it be poor batteries (batteries are always over 7.5V when checked AFTER using them); motors are just too old?

Could be current overdraw and old batteries.
Harbor Freight currently has coupons for cheap DVMs (< $3)
You can buy a pair of mating battery connectors and two DVMs; cut their leads short and make a parallel/series harness between the battery and the cpu to measure current(series) and voltage(parallel) during operation.

You could post your autonomous code, since you associate that with your problem.

You could try easyC and see if the issue goes away :D.