VEX Cortex Problem

[BBray_T1296]

So a small part of our FIRST team is competing in the BEST robotics competition this fall. We placed 2nd at the Dallas "hub" and are set to compete at the Texas BEST level next weekend. The robots are controlled using the VEX Cortex control system. Today we ran into a very frustrating problem.

For anyone who is unfamiliar with the Cortex Micro-controller, it has PWM outputs, and analog/digital inputs. The controller is linked to the Cortex via two (cross compatible) USB wifi keys that sync together to control the robot. **The way the Cortex is set up, if the controller and the Cortex are not synced up, not a single line of my code will be executed. As soon as they sync, my code is initiated**

So yesterday after a class period of practice, we shut the robot off (properly), and set its battery aside for charging. The robot is locked up and tamper proof in our lab, only the teacher has the key (not even the janitor). Today, we get to class, hook up the battery, turn on the Cortex and controller, and "what's this?" once synced, nothing happens.

The way our robot is set up, there are 4 motors: 2 are coded so they are off until a joystick turns them on. 2 are set up so they run at half power always, unless a button is pressed to put them to full power, or a different one is pressed to stop them. Usually the latter 2 immediately start churning at 1/2 power as the controller links up (see ** above).

When the controller and cortex was turned on, the usual blippy, colored lights flashed until the blue lights flashed in the wifi keys, the 2 lights on the Cortex were green, and all 3 lights on the controller were green (as what happened yesterday [and every other time]).

We were puzzled. Nobody touched the software after yesterday and now the thing doesn't work. Here are the steps we took (tested at every step):

-Re-flashed Firmware on both the Cortex and Controller (version 3.23 before and after)
-Re-downloaded yesterday's code to the Cortex (controller doesn't need special code)
-Checked and Confirmed all electricity outside the Cortex flows as supposed.
-Created a new batch of code that runs a motor based on a joystick input^
-Created a new batch of code (using easy c for cortex) that runs a motor unconditionally^

This last step worked and successfully ran a motor as supposed. We shrugged off the problem and loaded our old code on it. It didn't work. So we reloaded the unconditional code again, but curiously enough, it didn't work this time.

No luck at all, the thing just didn't work. Still perplexed, we wondered if the controller was bad (we have an ample supply of controllers but only 1 cortex) so we:

-Re flashed the Cortex again (3.23)
-Got a second controller, put the same (3.23) firmware on it as the 1st one.
-Put the Wifi key from the 1st controller in it.
-Tried all 3 code files from above (yesterdays, joystick^, and unconditional^)

I can confirm that the Wifi keys were seated properly in their USB ports.

One thing we didn't do was tether the controller to the cortex (via provided USB cable) to check if the Wifi keys went bad, but other than that, all we can conclude is a Cortex failure.

^These programs are so basic in Easy C (one premade block correctly set up and an infinity loop) that the programs themselves cannot be flawed

If anyone has more steps to try or any way on how to fix the darned thing, even a small suggestion would be hugely appreciated

Sorry for the long post, but this is such a frustratingly stupid problem to have, especially with competition next week

[ttldomination]

Hi there,

Try this little document, that details some of the more technical steps you can look into to solving this problem.

I'd recommend tethering your controller and your cortex to allow them to sync and to perhaps reduce the middle-man to help you figure out the error.

Additionally, head over to vexforum.com and post over there as well. There, I think you'll find help from a more focused community and even VEX technical staff.

Hope this helps,
- Sunny G.

[Paul Copioli]

In addition, since you live in Rockwall you can always bring your robot and electronics over to our place to get some technical help. Our office is just off I30 at exit 89 in Greenville.

[Hjelstrom]

Some ideas:
- Maybe post a screenshot of the code to rule out a code problem?
- Check the wiring, are the motors connected to the ports you're trying to use?
- If you temporarily plug a different motor into the ports does it behave as you expect?
- Try it with a USB A-A cable, sometimes the wifi keys do go bad
- Lastly, dunno if this is against the rules for me to mention but I created these "motor testers" which our vex team (918) uses to isolate problems as being wiring/mechanical vs programming: RobotLogic motor tester

GregH

Originally Posted by BBray_T1296

So a small part of our FIRST team is competing in the BEST robotics competition this fall. We placed 2nd at the Dallas "hub" and are set to compete at the Texas BEST level next weekend. The robots are controlled using the VEX Cortex control system. Today we ran into a very frustrating problem.

For anyone who is unfamiliar with the Cortex Micro-controller, it has PWM outputs, and analog/digital inputs. The controller is linked to the Cortex via two (cross compatible) USB wifi keys that sync together to control the robot. **The way the Cortex is set up, if the controller and the Cortex are not synced up, not a single line of my code will be executed. As soon as they sync, my code is initiated**

So yesterday after a class period of practice, we shut the robot off (properly), and set its battery aside for charging. The robot is locked up and tamper proof in our lab, only the teacher has the key (not even the janitor). Today, we get to class, hook up the battery, turn on the Cortex and controller, and "what's this?" once synced, nothing happens.

The way our robot is set up, there are 4 motors: 2 are coded so they are off until a joystick turns them on. 2 are set up so they run at half power always, unless a button is pressed to put them to full power, or a different one is pressed to stop them. Usually the latter 2 immediately start churning at 1/2 power as the controller links up (see ** above).

When the controller and cortex was turned on, the usual blippy, colored lights flashed until the blue lights flashed in the wifi keys, the 2 lights on the Cortex were green, and all 3 lights on the controller were green (as what happened yesterday [and every other time]).

We were puzzled. Nobody touched the software after yesterday and now the thing doesn't work. Here are the steps we took (tested at every step):

-Re-flashed Firmware on both the Cortex and Controller (version 3.23 before and after)
-Re-downloaded yesterday's code to the Cortex (controller doesn't need special code)
-Checked and Confirmed all electricity outside the Cortex flows as supposed.
-Created a new batch of code that runs a motor based on a joystick input^
-Created a new batch of code (using easy c for cortex) that runs a motor unconditionally^

This last step worked and successfully ran a motor as supposed. We shrugged off the problem and loaded our old code on it. It didn't work. So we reloaded the unconditional code again, but curiously enough, it didn't work this time.

No luck at all, the thing just didn't work. Still perplexed, we wondered if the controller was bad (we have an ample supply of controllers but only 1 cortex) so we:

-Re flashed the Cortex again (3.23)
-Got a second controller, put the same (3.23) firmware on it as the 1st one.
-Put the Wifi key from the 1st controller in it.
-Tried all 3 code files from above (yesterdays, joystick^, and unconditional^)

I can confirm that the Wifi keys were seated properly in their USB ports.

One thing we didn't do was tether the controller to the cortex (via provided USB cable) to check if the Wifi keys went bad, but other than that, all we can conclude is a Cortex failure.

^These programs are so basic in Easy C (one premade block correctly set up and an infinity loop) that the programs themselves cannot be flawed

If anyone has more steps to try or any way on how to fix the darned thing, even a small suggestion would be hugely appreciated

Sorry for the long post, but this is such a frustratingly stupid problem to have, especially with competition next week

[midway78224]

We had this same issue after competing and SA BEST. It turn out to be that we had all our motors running on ports 1-4 and it overloaded the cortex. We had to run a couple on ports 1-4 and the others in 5-8 i dont know why but if you run all motors on all of the first ports or all of the next four ports that stop working after a while. Once we did this we havent had a issue any more.

Originally Posted by BBray_T1296

So a small part of our FIRST team is competing in the BEST robotics competition this fall. We placed 2nd at the Dallas "hub" and are set to compete at the Texas BEST level next weekend. The robots are controlled using the VEX Cortex control system. Today we ran into a very frustrating problem.

For anyone who is unfamiliar with the Cortex Micro-controller, it has PWM outputs, and analog/digital inputs. The controller is linked to the Cortex via two (cross compatible) USB wifi keys that sync together to control the robot. **The way the Cortex is set up, if the controller and the Cortex are not synced up, not a single line of my code will be executed. As soon as they sync, my code is initiated**

So yesterday after a class period of practice, we shut the robot off (properly), and set its battery aside for charging. The robot is locked up and tamper proof in our lab, only the teacher has the key (not even the janitor). Today, we get to class, hook up the battery, turn on the Cortex and controller, and "what's this?" once synced, nothing happens.

The way our robot is set up, there are 4 motors: 2 are coded so they are off until a joystick turns them on. 2 are set up so they run at half power always, unless a button is pressed to put them to full power, or a different one is pressed to stop them. Usually the latter 2 immediately start churning at 1/2 power as the controller links up (see ** above).

When the controller and cortex was turned on, the usual blippy, colored lights flashed until the blue lights flashed in the wifi keys, the 2 lights on the Cortex were green, and all 3 lights on the controller were green (as what happened yesterday [and every other time]).

We were puzzled. Nobody touched the software after yesterday and now the thing doesn't work. Here are the steps we took (tested at every step):

-Re-flashed Firmware on both the Cortex and Controller (version 3.23 before and after)
-Re-downloaded yesterday's code to the Cortex (controller doesn't need special code)
-Checked and Confirmed all electricity outside the Cortex flows as supposed.
-Created a new batch of code that runs a motor based on a joystick input^
-Created a new batch of code (using easy c for cortex) that runs a motor unconditionally^

This last step worked and successfully ran a motor as supposed. We shrugged off the problem and loaded our old code on it. It didn't work. So we reloaded the unconditional code again, but curiously enough, it didn't work this time.

No luck at all, the thing just didn't work. Still perplexed, we wondered if the controller was bad (we have an ample supply of controllers but only 1 cortex) so we:

-Re flashed the Cortex again (3.23)
-Got a second controller, put the same (3.23) firmware on it as the 1st one.
-Put the Wifi key from the 1st controller in it.
-Tried all 3 code files from above (yesterdays, joystick^, and unconditional^)

I can confirm that the Wifi keys were seated properly in their USB ports.

One thing we didn't do was tether the controller to the cortex (via provided USB cable) to check if the Wifi keys went bad, but other than that, all we can conclude is a Cortex failure.

^These programs are so basic in Easy C (one premade block correctly set up and an infinity loop) that the programs themselves cannot be flawed

If anyone has more steps to try or any way on how to fix the darned thing, even a small suggestion would be hugely appreciated

Sorry for the long post, but this is such a frustratingly stupid problem to have, especially with competition next week