I am at the Baltimore County VEX Competition, and my robot’s code is ready to go. At one match, the auto worked, stopped, started over, stopped, started over, etc. All batteries were replaced and all connections were made. Outside of the field and run by EasyC field controller, it works. However, on the field the jittery and restart happens. Earlier in the day the auto worked, but after the first match both fields produced problems.
Does anyone have an idea how to fix this problem? Ive redownloaded code, given both new batteried and backup batteries, checked all connections, yet the problem still persists.
Hope the competition is going alright aside from the autonomous issues. I’ll send this in the form of an email and reply, best bet is to email me back. We need to find out what is resetting your code and why. I won’t lie, without seeing your robot and code in person this might be difficult to troubleshoot.
Have someone on your team look for a programming rep. Many events have someone from EasyC there to demo products, help with inspections and namely to help teams with issues. At the 2009 World Championship we had an issue where our robot wouldn’t stop moving after the end of a match (whatever motor values were last given stuck0 and a rep was able to help us solve it.
I know some teams were having a breaker issue where the internal 1A breaker in the microcontroller would kill power when all motors were initialized. While I’ve never had such an issue, it is possible if you have 7-10 motors running at once, under some amount of strain and you’re not using the power expander. The result of such an issue would be: robot powers on fine until it’s fist move command, robot powers down, back up, attempts to move again, power down…
Unfortunately (believe it or not), I haven’t gotten the chance to play with VexNet myself. I’ll be receiving VexNet components with the college cortex beta package hopefully within the week. I know plenty of teams that have had issues with VexNet. See if you can find an experienced team willing to look at your code and robot setup.
I would also recommend starting with a blank competition template and add code to it until the error appears again. Start with just your driver control code, then add the autonomous. If the error comes up when the auton code is added back, then we know it has something to do with the autonomous code. This is the troubleshooting process / idea…
Competition went well, but definitely need to get this straight before Dallas.
Here’s what we have tried to fix the problem-
-Replace backup battery
-Reload VEXNet master code 10, firmware, then code
-Check all connections
-Run robot through auto with EasyC Competition Switch Simulator (worked fine)
We are only firing up four motors at the beginning, so that shouldn’t be the issue. We only had this problem when on the field, yet it worked entirely the first match and partially a later match (all other matches had the start, stop, restart, stop, etc. problem). Our competition did not run code tests on the field, but if the code works and the robot has worked at least once it should not be the field (plus we have been on two fields and same problems on each). There were no programming representatives there, and most teams used crystals so there was no other team who could help. We use EasyC to code. All proper templates, procedures, etc. were followed.
In addition to this problem (#1 priority), I have a second question. After a match the controller is in Game mode, but when we unplug it from the field the remote and microcontroller stay in game mode. When we try to turn off the microcontroller after turning off the remote, its VEXNet module stays in game mode and fails to shut down (usually if you turn off the remote and then the robot the module automatically shuts down). The only way we could get it to turn off was by turning off the microcontroller, pulling the backup and main battery and plugging back in all power connections (when we turn the microcontroller back on it goes to normal, non-game mode). I KNOW that this is not good for the hardware or software (and yes, this happened before we did this and we reloaded everything after each time we did it. After that it worked fine off the field but no on the field), but after looking through the manual and such there is no other way of fixing it. Is there a proper way to get the VEXNet module on the microcontroller out of Game mode without yanking the power?
This is what the VEXNet module is supposed to do - when it’s off the field (in non-game mode), it will shut down within a few seconds of the remote powering off. When it is on the field, it attempts to hold the connection for five minutes (I think?) before powering off. If you power the microcontroller off, you shouldn’t be hurting the VEXNet unit by pulling the primary and backup batteries.
I seriously, really, really recommend using RobotC assuming you know the basics of programming.
Also, I can’t comment on VexNet but you appear to have some blatant issues. I don’t know exactly how Vex Robotics, Inc. is dealing with issues like this but I would try to get some help from someone. Maybe a post here on the forum or a phone call during the week.
Krummel, visit PTD’s college pit while at Dallas and bug me, I’d love to meet in person sometime.
I KNOW YOUR PROBLEM maybe my robot had the same problem and it turned out to be the the contacts in the battery plugs for vexnet they were stretched out so we had to crimp the plug and all problems like that completely stop
Yeah our alliance partner (677) had a similar problem, but it happened while in driver control. Their robot ran autonomous, then stopped, and never went into driver until there were ~20 seconds left in the match. They replaced the vexnet system and everything worked fine after that, BUT the same thing happened to us on the same field and with the same plug, and when we messed with the cable, it started working again. Seems weird that we would both have the same problems with the same field but no one else had this problem (at least, they never brought it up).