Autonomous quits at random times

Hi all, we are working on our minute long autonomous and are running into a technical problem that we are having difficulties to solve.

I will post our code if needed, but I don’t know if it is necessary. Our state competition is about a week away so we are hoping to not divulge to much more than necessary. Basically, the code was working great the other day, then it started “quitting” at random times throughout the code when testing/practicing. The point at which the code stops appears to be completely random. We have tried pinning it down to a faulty sensor that may be giving a value that is kicking us out of a loop or something, but we cannot find any correlation. Also, sometimes when the code quits, various motors will remain “powered” at values that we did not specify anywhere in the code. It is as if the cortex is sending a completely arbitrary value to the motors once the code “quits”. (This only happens some of the times).

Other times, the code will run completely through, just fine. But ever since the issues started, it has been very few and far between that it makes it to the end of the code trouble free.

For context, we have a lot of sensors. 6 IME’s, 2 sonars, 2 line followers, 4 potentiometers, lcd screen.

Any suggestions would be greatly appreciated. We have currently tried:

Changing batteries
Updating cortex/controller firmware
Eliminating parts of the code to find faulty lines
Yelling

Update: We have discovered that while in driver control, occasionally if we hit a wall/fence hard enough the robot seems to lose connection for a second or so. Does this mean that we possibly have a flaky cortex causing all of the above problems?

I know the battery connection on the PCB has been a bit notorious for cracking and providing intermittent power. We never lose power, but perhaps it is just a millisecond disruption that causes a reset in the microcontroller…?

This might not have anything to do with your problem, but our autonomous kept quiting at random times as well. We put a bit of tape on the vex-net (holding it to the cortex) and it never cut out again.

Very good suggestion, we had not thought of that. We will try that right away tonight. (We are at practice now) Thanks for the idea.

I think you should post your code to see if that is the problem. If you need help pm me

We are currently switching out the cortex with one from another robot. We will do that and if it is still flaking out I will shoot you our code. Thank you for the offer.

So, we switched out the cortex and the problem is still present. It seems like a code issue, but that is very odd because it was working fine the other day and the when the code randomly quits it seems to be at random locations in the code.

I have attached our code file if anyone is willing to look at it we would be forever grateful. It is a very long code (1000+ lines) but the guts of our autonomous is programmed as a “void” statement starting on line 635. It is composed entirely of void statements that you will find located above line 635.

As I’m writing this and thinking I’m doubting that it is in fact a code issue, because even in driver control if we give the robot enough abuse the robot will seem to lose connection for about a second. That seems like it must be related to our problems when running autonomous…right? If we lose connection for a split second during autonomous the code will no longer know what line it is currently at, which is what seems to be happening.

Again, any suggestions would be greatly appreciated.

After the code quits is the “robot” led flashing red?
It sounds very much like a static issue, send me the code, I don’t know if file attachments are working.

I will check if the LED is flashing RED for “robot”, I do not think it was…but I will verify. I will send you the code shortly.

I also suspected static, if that is the case, is there a potential remedy? I believe at our state competition they spray a chemical on the field, but that doesn’t help us at home!

This is something that we have ran into multiple times and 95% chance of the problem is this(I don’t see your code attached so it may not be this, depending on the way your functions work): For functions that use a P control loop to complete tasks more accurately, sometimes the speed that it is assigning to the motors is too low to actually move the motors due to the load on the motors. Since the motors aren’t actually moving, the value stays the same and robot gets stuck in that loop. One way to fix this is to ovbiously add the D and I terms to the code, but if you do not want to do something too complicated, then you could use if statements to see around what speed the motors stop moving. Use if statements to basically say that if the speed is lower than that value, boost it by a number that will cause it to move. If you need help writing this code, just shout at me and I’ll be happy to help.

This can also be a result of the battery being low because when the battery is low, the motors need a higher speed to move the same amount of load, resulting again in the robot getting stuck in the loop.
Good luck!

First thing is to try and determine if it is static, it may not be, you may just have introduced some buggy code. Does the robot ever “shock” you when you touch it? Does this happen when hitting the field perimeter gently? If RobotC freezes and the watchdog timer resets the cpu then robot led will slowly flash red, but this does not always happen, sometimes just the IMEs reset to 0 and/or don’t count anymore. You have 6 IMEs, that’s a lot, how many IME cables in total?

1.) The robot definitely experiences shocks sometimes. It is very dry here in MN winter and we notice getting shocks occasionally.

2.) When the “drop” occurs the IME’s sometimes do not count anymore.

3.) Each IME run only has one cable, so 6 cables. (edit, one run has 2, so 7 total)

I’m going to go experiment with static shocks…see if I can get it to trip on purpose. That is sounding like a likely culprit.

Yep, based on that description, my money is on static I’m afraid. It caused me no end of issues during the sack attack season, we could hardly ever get the team robot through an actual skills run. btw, I see the attachment in the above post now, it wasn’t there earlier, delete it it you want to keep the code a secret.
some further reading.
https://vexforum.com/t/ime-technical-description-and-software-workarounds/23218/1

and some more
https://vexforum.com/t/esd-my-thoughts/23332/1

(remember, those threads are from 2013, a few things have changed since then)

Here’s something that puzzles me that doesn’t jive with the static train of thought.

Sometimes when the code “errors”, instead of completely stopping dead it will instead skip a specific line, then continue on to the rest of the code. For example, just now, the robot (in auto) dumped a cube, then it is supposed to bring the lift back down and drive forward for the next cube. But it never brought the lift down…BUT it did drive forward and try to grab the next cube (with the arm up in the air obviously). This has happened a few times now.

Odd. It is maybe static, but the above case seems weird in that context. Or can the microcontroller simply skip a line or two of code due to a shock (or get an erroneous sensor value which makes it THINK it already did a line of code)?

Regardless, thank you for your thoughts and the above links. We will dig into them and try to reduce static next to see if that is the problem.

Long story short…if it is static, will getting rid of IME’s for quad encoders most likely fix the problem? Is it the IME’s that somehow generate and carry the majority of the static?

Thank you for the suggestion, that was a thought of mine also. But we did verify that the code is not getting “stuck” due to motors not having enough power to get the sensors to the appropriate value to carry the code forward. We did have this mistake a few years back I recall. Thanks again for the suggestion.

Just wondering but you do have your nine volt battery in right? Im pretty sure that helps keep the power a lot during automated control. Correct me if im completely wrong on that but that is what i understand. Yeah it could also be a loose wire somewhere. But for us in the past we had this problem and we just switched our our nine volt because the one we were using was faulty and it went fine from there on out.

It could also be the spot where the battery plugs into the cortex/one of those battery extenders. We were having the same problem and he’ll we checked the battery connection and found that one of those little metal rings that the battery plugs into work Bend out; you may try bending those back in with a pair of needle-nose and then check your connection and try to wiggle the battery around and make sure it doesn’t disconnect.

i think i may know the problem

at the top where it says
#pragma autonomousDuration(60)

you need to make the value higher to maybe 120 or 180
also the numbers are seconds btw

autonomousDuration is not used anymore, timing is determined by the field controller (or competition switch). This pragma was only relevant for the old crystal radios.