Inconsistent Autonomous Results

I am helping coach a middle-school team on their autonomous program. The program was developed in VexCode as a block-based program. The program is very simple and executes commands like driving the robot forward and backward, turning the robot, adjusting the velocity of a motor, spinning a motor, and adjusting the drivetrain velocity. There is no conditional logic and the program runs each command before the next command runs (ie there are no don’t wait commands).

What the kids have encountered is the robot inconsistently executes their program. On some runs, the program runs exactly as expected. On other runs, the robot fails to spin the motor, or the robot executes the first few movement commands and stops, or the robot doesn’t turn completely and stops. I’m at a bit of a loss on how to help them troubleshoot if they are facing a hardware issue, a software issue, or a problem with their code. They have tried to create a new program from scratch but they’ve encountered the same inconsistencies. They don’t have any problem controlling the robot in normal driver control mode. I don’t know if it is related, but the kids have also noticed the controller periodically loses link with the robot, sometimes before they execute the autonomous program and sometimes during the autonomous run. It usually connects back to the robot fairly quickly, but occasionally they need to reboot the controller and the brain to get it talking again.

I’d welcome any feedback on the best way to identify the issue and ensure the program runs correctly every time.

Welcome to the forums!

One thing that I like to do when checking out a robot is to make a jackstand of sorts and test that the robot is behaving as I expect. This gets the robot up off of the surface I’m working with (important to make sure it doesn’t drive off the table :sweat_smile:). With this setup, you can try things like driving the motors forward at full velocity and check for friction or other issues.

Occasionally, folks have reported inconsistent behavior with a low battery, so make sure the batteries are appropriately charged, and try different batteries; older batteries of the Gen 1 variety may not deal with heavy current draw well.

Also, keep in mind that especially with the prevalence of video games, the kids almost automatically overcome robot deficiencies, unless they’re screaming obvious. This is part of the reason that I encourage the jackstand approach to check behaviors without the robot being able to move around.


Post the code and we will be able to better help you.

Losing links is usually due to radio buried in metal or faulty cable.

1 Like
  1. Make sure your firmware is current because it’s required and may help with the overall performance.

  2. Post their code. Hard to talk about specifics w/ no code.

  3. Have to watch for ‘conditional’ statements in code like turn X degrees and then do something. If you never reach X degrees, the code will halt and wait.

  4. Display the current status of motor degrees, watts, temp, etc to the brain. Then put 5 second pauses between ‘moves’. You can check the brain (motor) status during this 5 seconds, and if the bot moves strangely AFTER the pause, the readings from the brain may give you valuable insight into what’s going on.

  5. And related to item #3… make sure there are no conditional statements that must be met before a motor will move.

  6. In general, on the ‘start’ block, I would declare all variables used and set them to 0, set all motor stopping modes, set initial motor speeds, etc.

  7. Add code comments… this is just ‘good programming’ and makes debugging MUCH easier. It also makes it easier for a non-programmer to read the code and understand what’s going on.


@lacsap and @turbodog, here is the second set of code the kids tried.

@lacsap and @turbodog, here is one set of code the kids tried.

@EngineerMike, great idea on the jackstand. The kids did something similar to this early on with one of the kids holding the robot while another tested the controls. I did see a few people mention issues with batteries so I had the kids switch to a fully charged battery but the results were similar. To your comment on video games, I agree that the kids have mastered the driver control mode and haven’t had any issues with that part of the competition.

lacsap, for the radio issue, the brain is mounted on the top of the robot with no metal enclosing it. Which cable should the kids consider swapping to test if a cable is part of the issue? I’ll post the two code attempts from the kids in the next two posts.

@turbodog, for #1, we confirmed the brain firmware was at the latest version. For #3, I assumed the robot would make a best effort by turning the drivetrain motors the expected amount and then execute the next code. How do you solve for this type of issue? Without introducing extra sensors and conditional logic, do you tell the turn command not to wait before executing the next command and simply make the next command a wait statement? For #4, this is an excellent idea. I encouraged the kids to add print statements as they reached specific portions of the code to see if the code executed completely. Printing the bot readings at each stage would take this idea further. For #6, the kids partially took this approach in the first iteration of their code and moved away from it in the second attempt to see if it had any impact. Unfortunately, there was no change.

Thank you all for the quick and thoughtful responses.

1 Like

The code is not giving the bot time to come to rest before moving to the next step. at best, this causes jerking/tipping/inconsistency. at worst this can cause a bot (still moving) in one direction to give incorrect degree readings as it tries to accelerate in the opposite direction.

I’d put some wait statements between moves. Maybe just .25 second or so… long enough to give a slight pause before the next move.

As far as ‘move x degrees’ goes. If you don’t hit the desired target, the code stops. Either 1) make SURE this won’t happen or 2) move to a time-based move… move X seconds. That way it will ultimately move to the next code block regardless.

There’s also a ‘timeout’ function, but I’ve not used it.

If they are working w/ auton… I’d really recommend finding my ‘auton toolkit’ post. You can make auto runs that are 95% correct on the first try.

@turbodog, I had suggested adding 1 second waits in the code after each of the movements as we discovered this was necessarily in the virtual skills challenge. The kids tested a few iterations with waits and found that it didn’t make the code execute any more reliably so they ended up removing them.

The timeout function tells the robot to stop a move command if it hasn’t reached it’s destination by the timeout value. The kids don’t realize it, but this actually messed up what they were trying to do at the very end of the autonomous run. I planned to have them look at the documentation and think through this function versus the results they see from the robot with the idea that it would get removed from the code.

I’ll see if I can find your auton toolkit post to review it.

Some more thoughts after looking more carefully at the code:

  1. turn speed 150%? it either ignores values above 100 or maybe overflows and ends up with some unknown value.

  2. the ‘start’ block is redundant w/ the motor speed commands… i would put the motor speed in start only and go from there.

  3. i would declare initial conditions for ALL functions I am using in the ‘start’ block: turn velocity, drive velocity, motor stopping modes, roller stopping modes, etc.

  4. print commands are best if they are preceded by a ‘screen clean’ command

  5. i’d like to see the ‘start’ commands for the first code picture… might be some clues in there.

  6. finally… sometimes blocks gets messed up and you have to redo and code… like there’s corruption in the code ‘behind’ the blocks you see.

  7. and one more thing… i’d recommend code versioning so it’s easy to track changes. we are naming the code with the team members’ initials, robot version, and code revision

So Fred and Mary, on their first bot the the season, 3rd code revision would be: fm-a03

1 Like

For #1, I’ve pointed out a few times to the kids that the documentation says -100% to positive 100% are the accepted values. It appears the velocity ends up at 100% when they set the value above 100%. In the second set of code, the kids accepted that and kept the velocity values below 100%.

For #2, I agree with your comments on redundancy. I think some of this is the byproduct of many iterations over a span of time. I’ll guide the kids to do all the setup in the On Start section. The kids do want to change the robot velocity over the course of the run as they’ve run into issues with the robot hitting the roller too hard, bouncing back, and not making contact with the roller to turn it. For this part of the run, they wanted to drop the velocity significantly to make sure the robot didn’t bounce back and maintained contact with the roller.

For #3, great advice. I’ll share this with the kids.

For #4, I was going to give the kids guidance to try adding a “\n” character to make sure the lines were readable. If that doesn’t work well, I’ll guide them to clean the screen instead.

For #5, there was no start block for that set of code. I guided the kids to try to keep the code as simple as possible to see if that helped resolve any of the issues. Unfortunately, it didn’t.

For #6, I looked at the code behind the blocks to see if I could see anything like that. I didn’t see anything obvious, but that is why I suggested the kids try a new program. Unfortunately, the brand new program was just as inconsistent.

For #7, great guidance. We were changing the names of the files from v1 to v2, etc, but there wasn’t really a rhythm or reason behind when the code changed versions. I’ll share your suggestions.

Only other thing I can think of is that maybe it’s related to the controller disconnects…

Not sure how an auton program w/ respond if it loses communcations w/ the controller… seeing as how a controller is defined as being present.

You can edit the code and remove the controller… just put the auton commands in the start block and see what happens.

If a controller is present, meaning if there is a VEXnet radio connection to a controller, when a program is started. If the connection is subsequently lost all motors will be stopped. It’s irrelevant if the controller was configured in code or not. If the opposite is true, that is, no VEXnet connection when the program is started, it’s assumed that the robot is fully autonomous and motors would not be stopped. Obviously for a competition robot in a match, a VEXnet connection has to exist so motors would always be stopped during the 15 second autonomous phase of a match.

If motors are stopped in this way, any drivetrain actions are usually aborted.


While the autonomous program failed to run consistently in the competition on Saturday and in our normal practice space on Sunday, the autonomous program ran flawlessly every run in a different practice space tonight without any changes to code. Outside of being in a different space, the only thing different was we pushed a new program temporarily to the slot we had been using and then pushed the program back to that slot. There were no changes to the robot and we used the same battery as the previous tests.

Does anyone know what frequency VXnet runs on? I’m wondering if there was something that interfered with the VXnet frequency at the tournament and in the practice space but not in the space we used for testing tonight? I’m happy everything worked as expected, but concerned I don’t know what caused the problem to ensure we don’t encounter it again.

VEXnet uses the 2.4GHz band. There are many narrow band channels each supporting up to 8 robots. If you had connection loss during a match the VEXnet radio led would show red rather than green (this doesn’t happen when you are on a practice field, only when under match control). You can also check for loss of connection in the brain’s event log.

Obviously other devices share the 2.4GHz band, that’s why EPs are encouraged to disable any WiFi that may be using 2.4GHz and avoid running other sources of potential interference such as microwave ovens.