At a tournament yesterday our robot would run fine when we weren’t plugged into the competition field but the second we would plug into the field the robot either wouldn’t work at all or would cut out after roughly 30 seconds.
At school we run our robot for almost half an hour straight when we program and practice driving and it never burns out unless we have a pushing match against a resisting robot for roughly 20 seconds.
We use this Competition Switch when we hold scrimmages against our B and A team and we never experience problems.
I have looked through our code multiple times very thoroughly and there isn’t anything that should cause this.
A friend of ours (from a different team) told us it could be that our master code wasn’t up to date so before the playoffs we updated both the vexnet controller’s master code and the brain’s master code. The next match we still had the same problems.
One of the judges said that when four robots are plugged in that it might be too much and a robot may be sending a charge back to the system and in turn disabling our robot. Is this even possible?
I can post my code if anyone needs it (EasyC V4).
I can answer any other questions.
I just really want to know what happened and what I need to do to prevent it because my team pretty much got ripped off competing in that tournament.
The one time (out of four) our autonomous worked and we had control for the whole 2 minutes we won 25 to 22 with a broken alliance and two working enemies.
Anyways I really need help with this because the tournament was nothing but frustrating and my team doesn’t want this to happen again.
If anyone could please help me with this we would be VERY VERY appreciative.
I’ve heard of this type of thing before but no one has ever really managed to root cause the issue. There was a whole thread here, although this one was finally determined to be a bad VEXnet key.
The field controller has a 0v (ground) and three control signals into the joystick. The first signal simply tells the joystick that it is in competition mode, one pin of the 8 pin connecter is shorted to 0v to indicate this. The other two signals tell the joystick if it is enabled or disabled and whether it is in autonomous or driver control modes. I posted a some information about field control here.
So first to ask some questions.
How many competition fields were running?
Were you in the same alliance color and zone for each one or did you start in different positions? Really what I’m asking is were you always plugged into the same field control cable or different ones. It would be unusual to be in the same position each time but you never know.
Did any other teams experience the same issues as you?
Did driver control mode always start?
Which master firmware are you running, the latest for EasyC would be 3.17 but many teams are still running 3.16 which seems to have been very stable. Hopefully you were not upgraded to the 3.20 version that’s floating around.
Were any RED led’s showing at any time on the cortex or joystick?
And finally, sorry we have to ask, were the batteries good, did you have a new 9V backup battery connected?
I am going to answer all of your questions in the order you asked them.
There were two fields set up. We played on the Right field 3 out of the four qualifiers and the Left one only once. When we played on the left field our robot ran perfectly but whenever we played on the right field our robot had major problems.
Our robot is an “Interaction Robot” so we played that zone the entire day. (Red and Blue). We made sure that after one match with a failed plug in cable that we would switch cables so we would have a different cable almost every time.
In our very first match our robot didn’t work in the first half of the match and our alliance was working and the second our robot started working our alliance’s bot shut down. I heard multiple cases that day of people’s robots not working but it seemed like our robot got the short stick and only worked one out of our 4 matches.
In our first match our autonomous didn’t start and we couldn’t control our robot till the last 30 seconds of the match. In all the rest of our matches our autonomous worked but our driver control cut out after anywhere from 15 to 45 seconds. (This excludes the one match we won and had control of our robot the entire time.)
As far as the master code, I do not remember at this moment but I can get that back to you as soon as I get to school on tuesday.
Yes, we did have a few red lights most of the time but I don’t remember exactly which ones were red, green or yellow.
And we did replace our main batteries frequently but I never thought to replace the backup battery. (Stupid on my part) Could this have been a problem?
Thanks for the reply and hopefully we can find the root of this problem.
Other teams were having similar issues but it seemed that our team had issues way more then others.
We were replacing both controller and cortex and power expander batteries regularly but we forgot about replacing the backup battery. I don’t know if it was dead or not. Could this have been a problem?
If it worked perfectly on the left field, but not on the right field, it sounds like a problem with that individual field. Did the other teams with problems play as often as you did on the right field?
You said it stopped during pushing matches. I want to know the exact configuration of your wheel base:
How many motors are you using on your wheels?
What type of motors are you using on your wheels?
How are these wheel motors wired (are they in a power expander)?
Are there any gear ratios on your wheel base?
We had very similar problems to this, with details in this thread.
We thought it was a problem with the field but in the finals we mostly played on the left field and we started to have problems there too.
We have a Mecanum Drive 1:1 gear ratio using high strength chain and four 393 motors. All of these motors go directly into the cortex. 2 are on motor controllers and the other two go straight into the two wire ports.
When our robot cut out it wasn’t just our drive train. The entire robot wouldn’t work as if someone disabled driver control.
This happened to so many teams at our tournament last Saturday that they had to switch over to competition switches to run the matches. A lot of teams would run fine until the moment they plugged into the tower. One symptom we saw was that the joystick vexnet key was hot to the touch. Some people were saying it could be wifi interference within the building. This didn’t seem logical to me because I thought it would affect everyone uniformly. Some teams found some help when changing vexnet keys out. All the bots that shut down did it in the same manner you have described.
Well then our backup battery probably wasn’t low because our robot linked up and our robot worked perfectly fine off of the competition switches.
As far as I know we were the only team this happened to more then once. My driver did not notice that the vexnet keys were hot. I also had to take them out to re download the master code and all of that but the keys did not seem to be hot at all.
So in reality you played more than 4 matches overall (qualifiers and finals) and had problems on both fields.
This type of problem is very hard to solve unless you can find something wrong with the robot. Lots of theories will be suggested, bad WiFi, motors overheating, low batteries etc. but as the exact conditions of the tournament cannot be recreated you may never know what happened. Test the robot on Tuesday with as close to yesterday’s conditions as possible, use the same controller, the same VEXnet keys, same backup battery and see if you can reproduce the problem.
Could it be that our brain and controller weren’t on the right master code? or something like that? Would that cause a problem if our controllers and brain had a different master code then the other robots?
No, very unlikely, the field control is working identically to the competition switch as far as firmware is concerned. The joystick detects if the enable/disable and auto/driver signals are high (+5v) or low (0v) and acts accordingly. The only difference is that the competition switch is passive, ie. it just uses a switch to connect the signals to 0v or not (allowing them to be at 5v via a pull up resistor) whereas the field control is active, the signals are driven by logic (or transistor or something, I don’t have one so have never looked closely)
If the cortex and joystick were on different and incompatible master firmware and could not communicate with each other then you would have (hopefully) noticed that between matches. EasyC is pretty good about checking firmware versions before you can download user code unless you have disabled that feature.
Was there any wild driving going on? Once our more energetic driver rammed the tower while trying to get a barrel in the corner goal and our alliance’s robots cut out, causing a match restart.
Similar Problems happened to us in new Hampshire in November, we were the team to beat and we got eliminated quarterfinals due to the problems we found out the cortex we received from our local collage team as a gift was a beta version one (the top was flat, the vexnet key was not raised) we invested in a new control system to assure this would never happen again, i know the bundle is pricey but if its costing you wins at competition its worth it. i saw the video of your robot and I’d say its worth buying a new control system your robot looks really good.
The first-generation (flat-top) Cortex units either have “NC-1” or “NC-2” printed on the bottom. The earliest had “NC-1” on them and *some *of these had problems. I have an NC-1 here that has worked perfectly ever since I received it, and it is one of the first Cortex controllers shipped. The “NC-2” versions included a fix that make them the same as the newer “NC-3” pop-top units.
“Flat-top” does NOT mean beta.
Most NC-1 Cortex units are fine.
The NC-2 and NC-3 Cortex units are the same inside the case. VEX said they released the pop-top to improve range.
i have experience this exact issue at all of our competitions this year. i have switched out our cortex, our joysticks, our vexnet keys, and just about everything else (even rewritten our entire code). this issue is persistent and is something i have NOT been able to duplicate with the switch simulator.
