HELP!!! VEX malfunction!!!

[ReapersRule]

My VEX robot hates me. At Savage Soccer@WPI, it drove off the field, but never seemed to work on it. Then, it got worse. Now it randomly goes into programming mode and autonomous mode while I'm driving. To make things worse, it has 3 different autonomous programs it switches between randomly. I have tried replacing the RX, reprogramming, both crystals and tether, different batteries.... What should I do?!?!?! :confused:


I am starting to want to kill it!!! :mad:

[Greg Needel]

First off, take a second and calm down. One of the important things to remember about robotics is that your robot isn't thinking on it's own it is only responding to commands that it has.

You touched upon a few different things that are going wrong and the trick is you need to isolate each problem to solve it.

The first thing I would do is re-download the master code. This will flash the firmware and upgrade your controller.

The next step would be to redownload the default code.

Then check all of your motors, RX connection and robot to make sure it is setup properly.

At this point try your robot to see how it functions. If any of the strange operations continue it is possible you have a faulty controller. In my experience there are very few times that the vex controller is at fault but it does happen.

If the robot functions the way that it is supposed to the problem is most likely in your usercode. Without knowing the specifics of your robot I can't give you any advice about that. If you reach this point I suggest you post your code or easyc file so that others can help you to find the problem.

Relax you have come to the right place and we are here to help.

[Akash Rastogi]

Uber-dumb mistake I made- check to make sure the radio wire isn't touching any metal :p

[DaveF]

We saw quite a bit of this at a VRC tournament yesterday where I served as the Field Manager. I am not sure what programming template and field control system is used for Savage Soccer, but we were running the VRC template and using the standard VEX field control system with crystals. The teams having this problem were complaining that the field control system was operating erratically and causing the robots to go back into autonomous mode during driver control. It was my understanding a couple years ago, and I do not believe VEX has changed anything in the last year or two, that once your robot runs the autonomous part of the template, it cannot re-run autonomous until the power on the robot is cycled to reset the microprocessor. The field control system cannot cycle your robot’s power or tell it to run autonomous again.

The programming template sits and waits to see a radio signal from your transmitter before autonomous starts. When we start the match, all the transmitters (sitting on the floor with power on, but no radio signal transmitted) are enabled for a period of time to start the running of the autonomous portion of your code (radio signal transmitted). Once the autonomous code is running, your transmitter is then disabled. Once driver control starts, the transmitters are re-enabled, so you can drive, until the match ends. No data from the field control system is transmitted through your transmitter to eh robot. All the field control system does is enable the transmitters to produce a radio signal.

So after that long description…. I started watching the robots very closely that repeatedly had problems yesterday. Many of them had 6 to 10 motors on them, and they were running many of them at the same time. The second before the robot would revert back to autonomous mode, the robot microcontroller would produce a low battery indication (red LED blink). What appeared to be happening is that the current drain on the battery was causing the battery voltage to drop below the minimum needed for the microprocessor to run (around5 V ?), and the microprocessor would shut down, motors would stop running, the battery voltage would recover, and the microprocessor would reset. It would see the transmitter signal and start autonomous all over again. You must remember that to measure true battery voltage (to determine if it is properly charged) the battery must be under load. When a battery is loaded more than its capacity and charge can handle, the battery voltage will drop quite significantly. You also say that it worked fine off the field. I bet that when you were testing off the field, you were not making your robot work as hard (pushing and doing other activities that make motors work harder and draw mor current). So you were probably not drawing enough current to cause a battery voltage sag.

So the bottom line is that I believe that at the VRC event, some teams were not vigilant about keeping batteries charged, and some were assuming that if they measure the voltage of the battery and it showed 7 volts (not under load) it was ready to go. At the VRC event these problems increased as the day went on yesterday- which probably coincides with teams showing up with well charged batteries, and having trouble getting one fully charged by the end of the day due t match schedules. In addition some teams have been using their batteries for upwards of 3 years, and their ability hold a good solid charge has diminished with age. To keep the VEX batteries usable longer, I know some teams have been using battery conditioners on them.

After all of that, I recommend you check your battery situation very closely. Good luck.

[ReapersRule]

I probably should have mentioned that I charged the batteries for over 24 hours, I have only 2 motors (squarebot. that's it). I have also switched out the controller. I redownloaded code, and even switched out the RX... that's not the problem.

It can't possibly be the controller. Before the robot was going forward 1 second, pause 1 second, forward 1 second, pause 1 second, repeat continuously. I turned off the controller, pulled out the battery, disconnected the reciever, and it kept doing it.

[Andrew Bates]

At this point if you have done everything that Greg told you to do head over to the VEXForum (http://www.vexforum.com/) and as for help their in the techinical support section (http://www.vexforum.com/forumdisplay.php?f=8). That forum is run by IFI, they created VEX. IF the controller is bad and it hasn't been 90 days since you got it then they should be able to get you a new one.

[RyanN]

Well, if you switched out all parts of the control system, and it is still having an issue, then I would point at your programming (probably the culprit) or at the field controls (but if it is working for everyone else, then it is probably working for you).

Sounds like your controller is crashing (as in it is going to programming mode, autonomous, and other things randomly). Weird things happen when you access memory that isn't supposed to be accessed and things will crash if you have something dividing by zero. Of course dividing by zero isn't the only that would cause a crash... Causing a variable to go over its limit will cause this error (int cannot go over 64000 something).

If you are only experiencing these problems on the field and not back at your pit, then I'd say it has something to do with the autonomous and teleoperated switch in programming.

My recommendation is start off with a clean slate and reprogram. Since you only have 2 motors, this shouldn't be too hard. For autonomous, you can probably copy and paste most of it, but look through it to make sure you're not doing anything bad.

[Dave Flowerday]

The teams having this problem were complaining that the field control system was operating erratically and causing the robots to go back into autonomous mode during driver control. It was my understanding a couple years ago, and I do not believe VEX has changed anything in the last year or two, that once your robot runs the autonomous part of the template, it cannot re-run autonomous until the power on the robot is cycled to reset the microprocessor. The field control system cannot cycle your robot’s power or tell it to run autonomous again.
You're correct that the field control system cannot cause a robot to re-enter autonomous. The field control system is only able to turn the robot's transmitter on and off, nothing else. Autonomous is controlled by a timer running inside the robot. Therefore, if the VEX microcontroller resets for any reason (too much current being drawn by the motors and buggy code are two common causes of the microcontroller resetting), the robot will restart its autonomous program. As hard as this is for the teams to accept, this is not the fault of anything external to their robot.

[Andrew Bates]

Teams that are competeing in any VEX competition should make sure to read the following page (http://www.vexrobotics.com/vex-robotics-competition-tips.shtml) created for VEX competitors by IFI.

[Anna B.]

I can attest to her robot having no obvious problems in the programming. Next time I see her I'll try downloading the master code again and we'll see where to go from there.
-Anna

[gorrilla]

maybe the pwm's are in the wrong port? happened to us:confused:

[Akash Rastogi]

maybe the pwm's are in the wrong port? happened to us:confused:

Highly doubt that since the problem is the random tele-op/opp cntrl switches. Is the robot really "twitchy" as well?

[GaryVoshol]

I seem to recall a thread from about a year ago on this subject. If the robot stalls out under some condition, when it restarts it goes into auto mode. Check for posts from last December or maybe January or February this year.

[gorrilla]

Highly doubt that since the problem is the random tele-op/opp cntrl switches.

thats what ours did when it was in the wrong place, we had to re-read the entire manual to fiqure it out:confused:


these tiny vex robots are so much more difficult to work with(for me) than the frc ones(i have big fingers and have a hard time picking up small objects)

[Andrew Bates]

I seem to recall a thread from about a year ago on this subject. If the robot stalls out under some condition, when it restarts it goes into auto mode. Check for posts from last December or maybe January or February this year.

Check out that link I posted earlier in this thread. That is exactly what you were telling him to look for.

[ManicMechanic]

I seem to recall a thread from about a year ago on this subject. If the robot stalls out under some condition, when it restarts it goes into auto mode. Check for posts from last December or maybe January or February this year.

Is this the thread you're thinking of?
http://www.chiefdelphi.com/forums/showthread.php?t=67325&highlight=batteries

[Anna B.]

We've figured out what was going on. Instead of using Rx 0 in the code, I used Rx 1. It's all better now. And, as usual, it was the programmers fault.
-Anna

[Andrew Bates]

I'm surprised that using Rx 1 caused problems. Although I have no basis for this from my experience when you Rx0 and you have two controllers set up the one that turns on last will have control. However when you use Rx1 control will always be given to the controller plugged into Rx1 on the MC.

[Jessica Boucher]

Using RX 0 will search for the live port and assign everything to it; so when youre using two controllers, you definitely want to stick to defining RX1 and 2.

Good to hear you're up and running again!

[EricH]

reported

[Led235]

just reprogram it.

[Joe Ross]

post 20 reported again