RE: Game Controller Issues

LegoMindstormsmaniac · February 28, 2013, 9:37am

Jake_Rampertab:

At a recent tournament my team’s robot got stuck running autonomous during the tie breaker of the finals in elimination. As the match started, autonomous began to run. part way through, something happened to the robot causing it to become unresponsive and leaving all motors in their last state. for the rest of the match the robot was stuck with all the motors driving in some direction and didn’t change to usercontrol.

Officials told us that this was caused by an infinite loop in the autonomous code which caused the robot to freeze. The inifinite loop was said to be caused by a sack being caught in a wheel stopping it from reaching its intended point. I don’t believe this is the case. the wheels of the robot were not near any sacks when it became unresponsive. furthermore, the arm of the robot shouldn’t have been affected by drive wheels getting stuck because it is run in a completely different task. within this task, there are safeties running to prevent the motors from driving past a certain region as it did. this makes me believe something witht he game controller caused my robot to become unresponsive because my program can’t cause the arm to become unresponsive. has anyone else experienced this? what could have caused this?

This sounds exactly like the issue many are complaining about occurring when using IMEs. It is a User CPU crash, believed to be caused by electro-static discharge. Here is the thread where this issue has been discussed: Possible Problem With RobotC (3.54)

~Jordan

jpearman · February 28, 2013, 10:55am

Sure does.

Jake, tell us more about your robot design, what type of wheels? Do you use the IMEs and where are they located? Was field control able to disable your robot at the end of the match? Are you using ROBOTC? If so, the latest beta will help but read my post in the programming tips thread, there may be a non-beta release of that version soon.

Jake_Rampertab · March 4, 2013, 12:16pm

we are using four mechanum wheels setup in the typical orientation for strafing

there is a single IME on each of the drive motors and all actively work

field control was not able to disable my robot, it ran the entire match and destroyed itself

i am using robotc v3.54
all firmware is up to date

jpearman · March 4, 2013, 12:32pm

All symptoms of user cpu crash caused by (probably) static. The new watchdog feature in ROBOTC V3.59 would have given you control of the robot back and at least allowed you to regain control during the driver control period. I would wait until the next official release before upgrading your version of ROBOTC as there are some other bugs in the beta that are being fixed.

I have an unproven theory that the static issue is worse on robots with mecanum wheels which was why I asked.

Jake_Rampertab · March 4, 2013, 12:34pm

ya i read through some of the links i was given and that looked like the general consensus.

is there anything i can do as of now to try and reduce the static build up? i am still unsure of what is causing the build up.

do you know if a new release will come out in the next two weeks?

jpearman · March 4, 2013, 12:40pm

I cannot speak for CMU, however, if pressed I would say yes.

Jake_Rampertab · March 4, 2013, 12:45pm

just an update for anyone else reading this thread:
https://vexforum.com/t/possible-problem-with-robotc-3-54/22882/1

according to this thread there won’t be an update before worlds

jpearman · March 4, 2013, 12:57pm

You are mixing firmwares.

VEX/IFI provides the master cpu firmware, currently at version 3.23. This firmware has a small issue that needs addressing where if it loses communication with the user cpu (there are two micro-controllers in the cortex) it continues to run motors at the last commanded speed and ignores field control signals to stop them. This firmware will not be updated this side of worlds as JVN stated.

The user cpu which runs the ROBOTC firmware is likely to be updated soon once the beta test period for V3.59 is over. The new ROBOTC firmware includes a feature that allows the cpu to reset itself and resume communication with the master cpu in the event that static causes a cpu lockup. The user cpu is more prone to static related issues as most of the IO on the cortex is connected to it. The IME communication is especially susceptible to static as 1. IMEs are powered from the same power regulatir as the cpu and 2. the I2C communications bus used goes directly to IO on the processor (no series resistors or anything, there are ESD protection diodes).