Two of our teams from our school experienced problems at a tournament they attended yesterday. They were both running robotC 3.54.
What basically happened was at random points during the match, their robot would become unresponsive and the motors would continue at their original power.
However, this only seemed to happen on the USB based competition switch. They had been working with the stand-alone competition switch all week with no problems. I have come to believe that this is a problem with the Integrated Motor Encoders. Somehow the I2C communication is interfering with the competition control and taking out the User Microprocessor.
We are hosting a tournament next Saturday and don’t want this problem to come up at the tournament.
My team is one of those who had the problem, though out of ~10 or so matches, it happened only once.
675D (the other team) believes it is an outdated firmware for the competition control. Our code ran fine whenever we were not running through the field (i.e. through the standalone switch or the RobotC debugger window), but the distances for the IMEs would not always work properly during matches.
The problem that 675A (tutman96 posted the IME glitch before) had with the robot continuing based on its previous motor power seemed to affect my team once during user control. Our arm would continue to raise (no other motors would turn), though we don’t even use the IMEs during user control. The arm is completely connected to the robot via the power expander, so I don’t know if it’s the IME glitch or another glitch with the Cortex, because jpearman has mentioned before about the power expander problems.
The Cortex was definitely not doing this on its own - there is nothing in my code that tells the robot to raise the arm past its vertical position, and the Cortex was not responding to the joystick as we powered off the joystick to no avail.
My team 675 Delta is one of the other teams that experienced problems.
Any time that I ran my autonomous during the competition it would freak out. I have ran the exact same autonomous code at least 30 times on a competition switch and it did not flip out on me one time. However, at the tournament yesterday and the tournament we competed at in November also the autonomous overshoots, and the encoder appears to stop working correctly. (Im using the IME)
After, talking to the MC/Head Referee at the tournament he informed me that he had seen problems with people using RobotC at several other competitions also.
Still an unproven theory with no hard evidence to back it up.
I had run your software on an old NC1 (modified to be an NC2) cortex last weekend and after 6 hours of continuous running have not been able to find any problem whatsoever. So we are left with the only difference between our test conditions and a competition is the field control system itself. The differences between field control and the $20 competition switch are as follows.
The field controller outputs an additional signal to the joystick that forces the WiFi to use a different channel, this is to allow teams to continue to test and practice in the pits without the WiFi interfering with the matches being played.
Grounding will be a little different as the joystick ground will be connected back to the field control. There is a possibility that opto-isolators are used but my guess is probably not, I have not looked in detail at the design of an alliance splitter as I do not have one. As the robot is controlled wirelessly the difference in grounding will have no effect on the software the robot runs.
I have studied the field control vs the competition switch when I was making my DIY version. (see this thread). There is nothing I have ever found that would explain the issues you are seeing.
So, although I’m still willing to help determine what is causing these issues, I would prefer you did not assume this is related to ROBOTC as if that were the case this problem would be far more widespread.
I believe it is more widespread. A ref at the event said that they were having problems all season. However this has only been with people using robotc.
Can you explain more about the wifi being forced to another channel? Does this deal with the user microprocessor in any way?
With all due respect, the refs I have talked to are not very technical. I’m struggling to find the link to robotc. Perhaps they did not upgrade from the buggy 3.08 version, perhaps robotc users are doing other things, who knows. I do know we have 75 licenses at the school used for robotics class and have run three competition robots this season with zero issues. I’m probably one of the most advanced ROBOTC users for VEX and have spent numerous hours trying to duplicate the issue you and a very few others have been having with no success. Now that does not mean the problem is not real but I suspect it’s linked to hardware and not software.
I think you guys are coming in with some preconceived notions of what the problem is that is not letting you clearly identify what the actual issue is.
Can you provide anymore information such as:
How long you lost control for?
Was it the rest of the match or just momentarily?
How often did it occur?
Were other teams at the event effected or just the 3 GSMST teams mentioned in this thread?
I agree with jpearman that it is likely not related to RobotC, and is likely a hardware or communication problem.
929W in our area seems to have had this same problem a few times, that I have seen. How many IMEs are you using? 929W uses four on their drive, whereas we only use two on our entire robot. We have never had any issue with them, unless they are somehow all of a sudden causing our VEXnet connection to disconnect constantly.
Do you remember (I know it’s hard) the state of the cortex leds when this happened? Did you get the slow flashing red robot led indicating a user processor crash?
Are there any other common components between 675B and 675D? Do you share a joystick or anything like that? Did the same programmer write the code for both?
My demo robot is pretty loaded with most sensors, 5 IMEs, gyro, limit switches, three line sensors, sonar, 4000+ lines of c code and I cannot make anything crash. Using PID with motors on the power expander along with a pot can be problematic if main power to the cortex is lost. Was it just control of the arm motor that was lost or all motors?
As you are hosting your own competition next weekend this would seem to be an ideal time to use field control to debug this, will you have access to any of that equipment before or after Saturday?
The state of the lights were slow flashing red, green, and green/yello (competition). We all have our own equipment so we didn’t share a joystick. We also all programmed our robots on our own. Team D and I shared some code but most of it was written by ourselves.
When it happened to us, it was all of the motors. No motors would respond. We even turned off our joystick, to force all of the motors off (in the competition template).
I do have access to the field controller and was planning on doing some tests with it this week.
That doesn’t sound like ROBOTC is crashing, if I remember right only one led is flashing red when that happens, but slow red robot led is supposed to be user processor error so perhaps it is, are you sure it wasn’t fast red for low backup battery? I will try this later and crash robotc with a simulated field controller.
Is this the same equipment that was used last weekend?
At the peachtree ridge competition that happened in November, it did it twice, one on each of the two fields. If I am correct, watching the videos of all of the matches of 675B, it happened to them twice, one on each field.
It may not be relevant but at QCC we had an issue where we would connect for 2 seconds then lose connection then reconnect in eliminations ( this was before the match started and it happened to everyone…) they finally had to reboot all the field control computers to fix it… so I’m not sure if you guys had a similar issue or not… but let me tell you if this happens to my robot at worlds… and breaks anything then I would be super angry…
As a follow-up to what happened with our robot during our match last Saturday, I was not blaming RobotC for any issues. Team 675A told me to post here with my issue. What happened during user control (right at the last 15 seconds) was we were raising the arm (with the scoop turning as the code levels it out) and it just kept rising; the arm and scoop went way past its software limit, and if I remember correctly, all lights on the Cortex were green with one of them red (can’t remember if it’s flashing slowly or solid).
The Cortex was not responding to the controller. We powered off the controller at about the 7 second mark I think but the arm kept going on, until I powered off the robot right after the end of the timer.
EDIT: I just noticed this:
If you watch the computer screen when it shows 18 seconds, it blacks out, and that is exactly when the arm stops responding.
