Competition Control Problems?

So on Saturday I was at a competition, and when our match started, naturally our auton ran. The problem was though, that our robot did something that was NOT supposed to happen. It spun around, shot a ball at someone, and crossed the middle line. After the match, we tested the auton again on the ground, but it worked fine. (btw it is supposed to toggle top and bottom flag, then climb platform). We then though it was because we had our phones. Next match we put our phones away, and asked our alliance to as well, and also triple checked that it was the correct program. When auton started though, it did the spinny thing again. We think that it has something to do with the competition control tower, but we dont know what. There is nothing in our code that would cause haywire. So, i am asking if this happens to anyone else, or if anyone knows how to fix. Thx!

so the auton always does something during matches, but never does it during testing with a switch? and did it behave in a way that was completely different than the code intended? I had something similar happen once, where a motor on our drive randomly started to spin when I wasn’t even calling that motor to spin in the entire program. only happened once or twice and it stopped when I re-downloaded the code.

Are you V5 or Cortex? How are you testing your auton outside of the match? From the V5 controller or with a competition switch?

Even if there was a problem with the connection in your controller I don’t know why it would run a different routine. I’s assuming you ran more than one match, how did it go in the other matches?

never tested with a comp switch, but i am planning to do it on tuesday. I will redownload and try though.

V5, Testing timed run on a real field, controller, and it did the same thing in other matches.

I don’t think there’s any way that the field control hardware could cause your robot to run a different autonomous routine. See this post for a detailed explanation of how that hardware works, it’s actually pretty simple. The upshot is that the field hardware has no knowledge or control over what code your robot runs; it basically just connects a couple of pins to ground and the code in the competition template reacts accordingly.

I don’t see how the presence of cell phones near the field would cause the sort of issue you described.

Did you recompile/reupload your code at any time during the competition? It might be possible that something in your program was inadvertently changed which altered the behavior of your autonomous routine.

never compiled or did anything to the code. Also apparently the cell phone cellular interferes with the connection from radio-controller

one of our teams has problems with auton if they connect to the field switch and start their program while 1) the switch is in disabled state
2) the switch is still set to operator control from the previous match.

The had very random (but repeatable) behavior during auton for their first tournament - in their case, it also drove too far (Double the distance) and had other random movements, resulting in a DQ. At first I suspected they had made an error in some changes, but that was not the case.

After the tournament, they discovered the sequence of switch settings/program start in later testing and we can reproduce at will.

This particular team is using PROS. I haven’t had the chance to detailed trouble shoot to see if there is something wrong with their template/initialization calls.

At the last event, they made sure that the switch was in the correct settings before they connected (they were also ready to raise the issue with the ref/organizer if the field settings were incorrect while teams were setting up and caused these types of issues) and everything was fine.

ok thx!

I am not aware of any way that the cellular signal from the phone would interfere. As far as I know, it is a totally different band. On the other hand, if there are people using wi-fi hot spots with their phones in the audience, that could potentially have an effect. The recommended connection procedure when arriving to the field is to have your robot and controller off, plug into the field, then turn on the robot, then the controller. The reason for this is, if you have the robot and controller on before connecting to the field, you are on a public VEX Net channel which is more prone to interference. Whereas, if you turn on the robot and controller after connecting, you are on a competition VEX Net channel which is much less prone to interference.

I am not sure what switch or field settings you are referring to. Tournament Manager only disables or enables your ability to connect to your robot before driver control begins.

does anyone know anything about my problem with cortex it also deals with comp control problems

the form name is diconnecting remote to cortex please help!!!

Sorry, I meant the Competition Switch settings in their testing. If the program is started while Disabled & Operator Control, then the Switch is moved to Autonomous before enabling, the autonomous performs different movements than coded. In normal startup sequence, their auton is very accurate and precise run to run.

I haven’t used the tournament manager software, so unfamiliar how it handles state between matches and if it’s possible for a team to plug into controls at field side while TM is sending a Disabled / Operator Control state . But they can reproduce exactly what happened on the field from the 1st tourney through manual operation of our control switch.

I do have to dig into their competition template and PROS code to do some debugging (became a low priority once they figured out the sequence of events)

Can you think of any scenarios where Tournament Manager could be sending Disabled, Operator control signal to the field as the teams initial plug in and start their program?

Further down in the thread I linked above, there’s some discussion of the potential for cell phones near the field to cause interference with robot-to-controller communications. The upshot seemed to be that WiFi and Bluetooth communications posed a particular risk on interference since they use the same 2.4GHz frequency band, and that devices near the field (e.g., in drivers’ pockets) pose a much greater risk of interference than devices in the audience since signal strength drops with distance squared. So, I could potentially see a cell phone near the field blocking communications between a controller and robot, but I think it’s less likely that radio interference would cause a robot to still run autonomous, but run a routine that behaves differently than expected.

Side note: This is an interesting and useful tip I hadn’t heard about before. I often see teams follow the opposite procedure (turn on robot and controller, wait for them to connect, then plug in to the field), I guess under the impression that their robot is less likely to connect if the controller is plugged in to the field for some reason. I’ll be sure to mention this the next time I see a team waiting to connect before plugging in.

I can. @jpearman scoped the control signals in this post, and found that before the match starts the Auton/Driver Control signal switches repeatedly. Quoting his post:

However, I don’t think that the state of the autonomous/driver control line should affect the behavior of your robot while it is disabled as you described, if only because the rapid switching behavior seems to occur before every match, and most robots run their autonomous as expected when connected to a field.

(Disclaimer, I’m definitely not an expert on radio transmission and interference, the above is mostly speculation and educated guessing based on my understanding of various other threads.)

For at least V5, the robot is aware of the difference between driver and autonomous position on the switch while disabled. If a robot is coded such that it only watches those two and not the enabled state, this can affect the program’s behavior.

Just as a final followup, the team went through the code, and found some initializations in their operator control code that were not set at the beginning of the auton code.

Those parameters weren’t being set at beginning of auton, so normally auton worked fine. But when the operator control loop ran first, the op control initializations impacted the auton movements.

They are changing their auton code to always reset those initializations just in case they encounter the situation where the robot program starts in operator control before moving to auton. (The team is using PROS).

1 Like

Several of my teams are having difficulty with this as well. Does anyone have any code they are willing to share? Thanks!