At the CSUN competition on Sat Dec 10 our 1508b robot failed to operate on all its matches. The robot red light was blinking. We had the autonomous commented out except for an allMotorsOff() statement. The robot is programmed in RobotC and operated fine off the field and passed inspection with the mode switch. We initially thought it was the controller and replaced all the batteries for the next match. Then it happened on the rest of the matches.
Was there a way the team could have gotten technical help from the field personel to debug the problem before they got into the next match? The fields were very busy so finding an unused field to debug seemed hopeless.
In looking at the code, the only thing I could see that should have been done is update to this years competiton template. I believe the programmer used last years worlds code and modified it for use in this competition so the template was not updated. Could this have been the problem?
I’m not 100% if last year’s code would’ve made any difference. There was, however, a team at my last competition who used the 2010 RobotC template and were out for most of the tournament until the officials gave them a copy of the 2011 RobotC program.
If your robot worked fine during inspection, I don’t see why having last year’s template wouldn’t have worked on the field.
Did you go back to your inspector again to test your code?
That’s unfortunate and how disappointing for the students. I wish I had known on Saturday, I’m sure we could have got them running, even if it meant swapping out the entire control system over lunch. Was this robot the good looking scissor design? I remember seeing that as we were alliance partners for one match.
A couple of questions.
Are they running with VEXnet or the 75MHz controllers? (I assume VEXnet but you never know).
Was everything working between matches?
Was your programmer using RobotC V2.3X or has he upgraded to V3.XX?
Is all the master firmware upgraded?
I cannot think of a cause for this if the robot was working away from the field. The competition template from last year is almost the same as this year. The only thing CMU has added in the current version is that any tasks you may have started during autonomous are now stopped before operator control.
The field control system is really very simple and does not depend on particular firmware or competition templates. If the robot works with the competition switch then it should work with the field control system.
There were two practice field up near pit F, not sure what facilitys were there though. You could have also tried using the skills fields to debug as I hear they were under utilized on Saturday.
If you need a second opinion on the code I’m happy to look at it.
Yes, they worked all morning getting it going and had to sit for 3 matches or so. I was looking forward to seeing that crazy thing in action. Especially since they were sticking slides out the rear about 7 inches every time they raised the lift:) When they get it tuned up we’ll post a video.
I was glad to finally meet you in person and I wish it had been earlier because I’m sure you could have helped. Unfortunately, I seldom get involved with the field software so couldn’t do the debug myself.
Vexnet, everything working between matches, V3.xx, and all the master firmware upgraded. But I will recheck this with them again tomorrow.
Good point. I talked to the 1138 field tech and he said we could wait till the selection break to try the field… Both of us didn’t think about the skills field.
Thanks, we may take you up on it.
I had the kids put the code functions into the new template. What I am worried about is that we still don’t have a way to test if this fixes the problem before our next competition in Feburary.
Do you have the manual competition switch? If not you are welcome to borrow one of ours, perhaps our schools could meet for a friendly scrimmage/practice before February, we have a field but not all the goals and game pieces so it would be a bit low rent.
I believe Ive seen this problem in quite a lot of robots. (Robot Light blinking red in slow intervals)
I’m a ref. at Puerto Rico regional competitions and I am still trying to figure out exactly what causes the micro to go into this “mode”.
Here is what i know so far about this problem:
The meaning of the slow blinking red light is “User Microprocessor Issue”
The fault appears most of the time when switching from autonomous to operator control and it doesn’t happen every time. From what Ive seen, some robots have the problem when we switch from auto to op before the 20secs, some when we switch after 20 secs and others when there is too much time between changing from auto to op.
It happens in easyC and Robot C.
I believe that there is something in the autonomous code that makes this happen and although i have not found exactly what causes it, I do know how to eliminate the problem at least so that teams can compete without the problem.
-The only way that I could eliminate the problem was to erase all the code in autonomous( Variables, Functions, comments), everything.
I know that if you start over, testing each segment of code and trying to repeat the fault you will find where the problem is.
I recreated the timing variation with the competition switch but during the competitions, in some matches the auto period was ended early because the robots finished their move and we were behind schedule.
Now there were robots that got the fault in normal game play. in those cases I used the competition switch to vary the switching times to see if under other conditions the fault did not happen and it turned out it didnt happen.
Another thing I noticed is that it only happens if you use either the comp switch or field, it doesnt happen with the comp switch emulator.
What I did with one team was erasing their code by segments and it wasnt until i erased absolutely everything that the fault didnt appear anymore.
Last night I tried several things to try and recreate the problem vamfun describes. Everything I tried failed, the closest I could get was removing the VEXnet USB key from the joystick causing an unrecoverable connection fault. It’s unlikely this is the issue, not going to happen in all matches and probably would happen in testing.
Anyway, I have a crazy theory but no way of proving it, however, we have to eliminate other possible problems.
Problem with the field control system/cables/field control software ?
Other teams would have experienced similar problems, our 3 teams played 18 qualifying matches, we did not notice any issues.
Problem with the competition template?
I’ve spent a good amount of time working with RobotC and posted some details of how the competition template works here. Any program will run in driver control mode, it does not need to be in the template to run, motors will be enabled/disabled by the field control system but the code will keep on running. I think it’s unlikely to be a software issue.
Batteries? Backup battery?
Certainly could be, but for 6 matches, probably not.
I had posted some details on the field control hardware here. The field control system has to split the control signals to the four teams, the first happens on the field control system itself, the second in the alliance splitters. There is the possibility that the alliance splitters use opto-isolators to drive the signals out to each team, this is just a theory, I do not have an alliance splitter so cannot investigate this, however, if this were the case then the opto-isolator would need power from the joystick to enable the output photo transistors. I do know power is available on the competition connector of the joystick (pin 8). If the joystick is damaged and power is not available then the enable/disable and auto/driver signals would not get to the joystick, however, the cheap competition switch would still work as it does not depend on this power. This is just a theory and I have no way to confirm or disprove it without access to an alliance splitter. If anyone has one and could post pictures of the board we could probably verify.
Chris, check for power on pin 8 anyway. perhaps there is a dirty or damaged pin. As I said, just a theory but the only one I can come up with that fits the symptoms.
Unlikely based upon evidence presented by me:)… HOWEVER… I now think the problem was from a bad VEXnet USB key.
I grilled the kids today to try to reconstruct the situation:
This occurred in only their last two matches. Another match they sat dead was caused by them not hooking up properly to the field. Prior to that their robot was inop during the early matches.
The robot was checked ok off the field before the first dead match but was not necessarily operational wirelessly before the second match.
We found one of their VEXnet keys had failed.
I tried the bad VEXnet key in several Cortexes and it led to a single blinking red light. (at least off the field)
So if the VEXnet key failed after they had practice tested ok prior to the first dead match , then this was probably the problem.
I am comfortable with this solution for now and I feel a little embarrassed that I didn’t wait another day to talk to the kids before posting. Anyway, thank you all for your help and I hope this thread can still help with the dead robots seen at Puerto Rico by sabydady.
So it was the vex net light, not the robot light blinking red. This would definitely be an easy fix. In our competitions we get somewhere from 4 to 8 teams that have bad usb keys. The keys are very sensitive and get damaged very easily, some tape might help minimize vibrations.
I don’t know if vibrations are as much an issue as overheating. We killed a Vexnet key by overheating – ran Vexnet for 2+ hours in practice without turning off the robot or controller. Now we make sure to break for at least 10 minutes every half hour or so.
At a robot demo we did at the state fair (with robots running 8 - 12 hours/day), we found 5 dead cortex/joystick carcasses from previous days due to dead keys (we were day 14 of 16 days). The PIC/crystal systems ran a 10-hour day non-stop (with only short rests for battery changes.
Why is it the overheating that you point out as the source of death for a vexnet key, rather than random/rain/abuse/luck/lifetime-wearout/ElectrostaticDischarge or some other source? With only one instance, its easy to jump to conclusions.
Can you expand on your state-fair report? I can’t tell if it is 5 dead on day 14, or 5 dead over the course of 14 days, or something else. Thanks.
You bet… I was just thinking that this is a poor human factors design. You would never find this type of ambuity in Lockheed Aircraft cockpit design. I was going to suggest a better design… but couldn’t come up with anything simple other than just putting the lights in the middle of a label or just using a single letter next to the lights eg J R V G. But I have a feeling its not worth their trouble to fix the design. The cortex lights are unambiguous.
I have had a similar problem with my robot at the Richmond competition, however the problem was isolated to the 2-wire 393 motors on my drive train. when i plugged into the competition wire the robot light immediately went red. i knew the battery wasn’t dead because the lift was still running full power. that also meant that the joystick was connecting to the cortex. I am using a vexnet controller and programming in robotc, does anyone have any ideas?