We had a tournament today and in the match, our robot did not move in opcontrol. We know it was not the code as it worked the rest of the day and we checked immediately after and it worked (the code had not been changed at all). However, the ref said that it was our code and did not let us prove it. While our alliance partner was entangled making the match 1 vs. 0. Resulting in us not moving on in the tournament.
There is nothing that says the ref HAS to do anything. They probably should have checked the software, but they don’t have to. I believe that you could have touched you robot however since it hadn’t moved at all.
They were telling us that it was the code’s fault.
if you know for certain your code wasn’t the issue, it seems most likely to me that you simply disconnected. This is something that can occur during matches, and (correct me if I’m wrong someone who knows the rules better than I do) but I don’t think there is anything in the manual that calls for a replay if a robot disconnects. unfortunate, but just how it is.
it could also be that your radio/battery became unplugged or dislodged, although you probably would have noticed that.
Our radio continued to blink green and when we tested it it still worked.
Also our alliance partner was trapped for more than 5 seconds but the refs said it was not on purpose even though the opposing robot didn’t try to leave and this caused a entanglement once they did. (At least i believe this was match affecting)
Also our robot moved in auton.
That is against the rules even if it isn’t match affecting. You are always responsible for the actions of your robot, whether intentional or not.
But, the refs are right in the call for the opcontrol since there is nothing in the rule book that forces them to really change the rules even if there was a failure on their side. That’s just the way it is.
Ok but the trapping would have dq the other alliance then right?
sure, if your opponents did trap for more than 5 seconds and it was match effecting it should have been a dq. given that your alliance was already down one robot though, I somehow doubt that the entanglement would altered the outcome of the match.
since the entirety of our knowledge on the situation is from your recounting, we cannot make an accurate claim of what should have happened during the match, we’re just telling you what the rules are.
That depends on your definition of “match affecting.” Since you said that it resulted in 1 against 0, one could argue that it was match affecting. Alternatively, the ref could’ve thought that you weren’t moving just because you didn’t feel like it so they believed it wasn’t match affecting. They could’ve also felt like it was just trapping in garbage time(meaning that no matter what your alliance did, you weren’t going to win) making it not match affecting.
Have is an absolute. There are very few circumstances where an automatic dq is awarded. Most dq’s are based on match affecting. If you get trapped for 6 seconds but you were going to lose anyway then it is not a dq. Missed calls happen its unfortunate when they do but it’s not the end of the world.
The main thing our team got frustrated in was 30-40 seconds in the match was already 1 v 0 but thanks for the clarification.
It would be very hard for the ref to replay this match under the described circumstances simply because you are already down one bot. If your partner also wasn’t able to move that would be different but since it was just you, the likelihood of this being a field error is slim, as frustrating as it may be.
Yeah we’ve looked at the code and tested it after and it worked. The main thing I was just wondering was the trapping for the future.
I recommend you start with re-reading the game manual, searching for any relevant Q&A, and watching the referee training video. That will hopefully give you a better understanding of what to look for in future matches.
Since you indicated the Radio was blinking green, there was connection to the tower. What pattern was the radio blinking during Driver control?
Given that your robot moved during Autonomous, the referee probably concluded that your robot was responding to tower signals. Hence the conclusion that at that point that the fault was in the software running in the Brain (probably not well stated if you came away thinking you wrote buggy software). The Tournament software (either a computer or raspberry pi) only sends a signal to both towers to raise a signal to robots connected to the tower - pretty straight forward tech.
It has been about a year since I have set up a competition field - so memory might be a little rusty.
These are unfortunate setbacks, and you are right to learn more to be ready for future competitions.
It was blinking in the normal pattern and this had us confused as it had worked before and after when tested also we used pros so we just name our function opcontrol. I would like to add after the match it said link lost until we restarted.
Make sure all your batteries have the updated firmware. Recently our team has experienced a similar issue whenever we use a battery without the proper firmware. What seems to happen is the robot stays in the disabled mode when the driver control period starts. Once you update battery firmware (this is what we found to be the problem) you should no longer have an issue, however if it happens again you should be able to restart the program from the controller and the robot will start correctly in the driver mode.
Did you report this to VEX support? I am not sure the firmware would behave in such a non-deterministic way - @jpearman?