My team has been working on a 1 minute autonomous program for months now, and we keep having one particular issue. Most of the time when we run the program, it stops partway in, waits for about 2 seconds, then restarts the program completely. It seems to happen in random spots now, and much more frequently than it used to. Is anybody else having similar issues? Any help would be greatly appreciated.
Sounds like it may be VEXnet disconnects. What are the controller and CORTEX lights when it happens?
You are describing what happens when the watchdog timer resets the user cpu. The cpu crashes, around 2 second delay and the code restarts.
So are you using ROBOTC? Do you have IMEs installed? What about mecanum wheels? Have you noticed any sparks when touching the robot (ie. any static on the field) ? If so, search the forums for advice on using anti-static spray.
You are not the only one. We see this all the time. Very very frustrating. Other robots on robot C v3.62 and v1.0 keys are not seeing it.
We have 4 IME’s on the wheels which are omni wheels all around.
Vexnet 1.0 keys with the debugger On 4.0 firmware, and can run on Vexnet 2.0 keys as well.
We also see the first run while connected to the debugger failing and on Vexnet 1.0 keys (since V2.0 does not have deug). All it is doing is backing up a few inches and running the intakes at that point. No touching metal or anything. So reset and try again. Does not happen nearly as often on a competition switch or 2.0 keys (although we have had a few sporadic resets on v2.0 keys) :mad:
The other problem times with the debugger hooked in are about 28-35 seconds in for some reason. That touches the bridge at that point.
We are in the winter months now so it is very dry in the room. We consistently get static discharges when reaching in the goal tube and touch the wing nuts that hold it to the wall.
I would really like to see a clamping diode on the IME’s to try and eliminate the static discharge issues.
We are seeing something very similar. We are using RobotC and VEXNet 2.0 keys with updated firmware. Our programming skills will sometimes start out at the first line of the code and suddenly jump down a couple of lines without executing the commands in between. We have posted our code and nobody has been able to find any faults that would cause that behavior. We even replaced our cortex and did not see a different behavior.
Are you saying this only happens with V4.0 firmware? Or are you saying it’s your particular robot with the problem and others on the same firmware are working well?
That makes no sense, can you send me the code or an excerpt with an indication of which lines are skipped.
This is also happening to us. Our programming skills and autonomous like to sometimes just skip lines of code. Instead of driving forward, lifting, outtaking then backing up, it would lift, outtake then backup (skipping the first move). It’s random to. It doesn’t skip the same line of code twice.
We have the VEXnet 1.0 keys. Any suggestions? Should I try re-downloading the firmware?
I can not say definitively one way or another. Three robots are on Vexnet 2.0 with the downloaded V4.0 firmware using Robot C v4.06 and the rest of the club are on Vexnet 1.0 and on Robot C v3.62 and associated firmware that comes with 3.62.
The Vexnet 2.0 folks are experiencing far fewer Vexnet drop outs when in competition mode. However, we have seen resets spordically even in that operation too. The Vexnet 1.0 keys on the v4.0 firmware are causing debugger related drop outs but then again, they happen with the debugger connected on v3.62 as well.
These debugger based drops may be due to the 3+ year old Vexnet keys finally showing their abuse. Or it could be 2+ hours of continuous running at practice does not help either (we noticed the keys get warm too but I can’t say if this inreases the occurence of drops/resets or not). Reset the field! Try again!
We’ve tried USB extenders, rubber banding in the key to hold the connection, even new cortexes.
It is tough to separate PTC trips from the Vexnet ones though as abuse of motors is rampant over a few hours of continuous use of 10x 393 motors.
or the I2C static…
The mystery continues. State championships is Saturday so the number of testers will drop considerably (and may go to zero).
In response to jpearman: We are using robotc, we have 2 IMEs on the rear wheels, and we are not using mecanums. We have some issues with static on the field as well. Also, we have experienced the other issue mentioned where the program will skip a certain action and continue the program. This has become less frequent but it happens on occasion.
Can you also send me that section of code so I can see what commands are being skipped. My suspicion is that you are testing an encoder count and the encoder has been reset back to 0 (also a static problem) or something like that.
The program skips over the drive forward when we have this issue. It seems to be a problem only when driving short distances (approximately 300 clicks or less)
flipdown(1000);
nMotorEncoder[RR] = 0;
nMotorEncoder[LR] = 0;
while(nMotorEncoder[RR] < 270 || nMotorEncoder[LR] < 270)//forward to pick up buckies on wall
{
motor[RF] = 50;
motor[RR] = 50;
motor[LF] = 50;
motor[LR] = 50;
}
motor[RF] = 0;
motor[RR] = 0;
motor[LF] = 0;
motor[LR] = 0;
flipup(1500);//pick up buckies on wallA very interesting comment. Would you mind elaborating on why/how static might reset an encoder count? And maybe provide suggestions on how to work around that problem?
Recently, we tested our robot’s Programming Skills software on a field that appeared plagued by static and not only did we see our robot apparently skip parts of the code but it also appeared to not pay attention to its encoder counts. The behaviors were erratic/irreproducible and unpredictable. Other teams seemed to be having similar problems with their Programming Skills software on that day, too. :eek:
Have you already used the IMEs before this point in the code?
What I suspect happens is as follows.
Lets say the code starts, all encoder counts are 0. You drive to a position (-500), then you use nMotorEncoder[LR] = 0; What happens internally to ROBOTC is that an offset is stored, if the actual encoder count is -500 an offset of +500 will be stored so that when summed they are 0. Now assume that static causes the encoder to reset, the actual encoder value is reset to 0 but ROBOTC may not know that and still uses the stored offset. The position of the encoder is now read as +500 due to the offset and code is skipped. This would be a rare condition, but could happen. You can work around this to a certain extent with software (I will dig up a link later), but the root cause is probably IME reset due to static.
We do not use the integrated motor encoders. Is it likely that we’re seeing a similar problem with just the normal encoders? Can their wiring scheme reset the encoder counts similarly to the IMEs?
This is the first use of the encoders but it does happen in other spots. That issue has become less common, though, so we are more worried about the restarts affecting our run.
Not in the same way. The IMEs contain a small micro-controller, this can be reset independently from the cortex, it’s been a while since I did any form of testing with these (a year I guess, always seems to be around February) so I forget exactly how ROBOTC reacts but the I2C bus will generally be reset and counts set to 0 (which may make my theory below invalid because that should cause the internal offset to be reset as well).
The quad encoders are used directly by the cortex, if the cortex were reset these counts will revert back to 0 but the program will also start over. Loose wires could make the quad encoders intermittent.
Thanks. That’s good to know.
I wonder if static discharge could appear as an electronic pulse on a quad encoder cable. Or if the “lightning” flash of a static discharge could be picked up by the quad encoder optics as a pulse?
Been having the same issues for the last 6 months.
Skipping lines of codes, random resets.
For the most part its manageable, and has definitely gotten a lot better as its gotten less dry. Also took off two of our IMEs and switched to a potent on the lift. In December, it was impossible for me to run programming skills without a drop out every other run. Now its about 1 time in 10, which I have learned to live with, just hoping we’ll have enough luck to avoid it on saturday when doing programming skills ^^
Our robot for worlds will have quad encoders instead of IME’s. Maybe that will help us some.