Over the last couple months I have had a lot of issues with the three different cortex units that I have used on this competition robot. I am starting this thread to see if anyone else has had similar problems. With either a cortex controller or EasyC V4.
Here is what has been going on for me.
(1). H-Bridge on motor port 1 spontaneously blowing out (and puffing smoke).
This has occurred in the first and second cortex controllers that I have used on this robot. The first time this happened I wasn’t sure what to think. I replaced all the (2-wire) motors that had been running when the incident occurred, checked all my (brand new) wires, and installed a new controller. A couple days later the exact same thing happened. I find this very odd considering that none of my motors (to my knowledge) were blown or arcing.
(2). Robot intermittently locking up. (regardless of what code is running on it).
This has occurred in the second and third cortex units that I have used. I will be driving the robot and (about every half-hour) all of a sudden it will no longer read any sensors or user inputs and all of the motors continuously run whatever value they last received before the lockup. The Robot and Vexnet lights remain green. The only way to fix it is to restart the cortex (not something you can do during a match). When the robot locks up like this the only thing that does still work is the “Get Vex System Info” feature in the IFI/intelitek loader. During these times I can use this feature to verify that the system is still linked and all batteries are good.
(3).
Frequently losses Vexnet link. (All 3 cortex units)
This still happens (about every 5-10 minutes) with a completely new Vexnet System bundle.
(4). Frequent download errors. (All 3 cortex unit)
Though this is not as bad it is very annoying. Roughly one-third of the time that I try to download a program wirelessly, the download is interrupted during progress. I never touch anything and all other wireless devices are turned off. Usually the two unit are about 5 feet away from each other. After the download is interrupted it WILL NOT WORK until I have restarted both units.
I have taken all of this up with both IFI and intelitek. We have already eliminated any obvious problems that could be causing any of these. Let me close by saying that I never had this many issues with the old PIC controllers, but then again the cortex does offer much better performance when it is working…
we have had problem problem three A LOT and it is very annoying and it had better not happen during our competition in one weeks time. we are using a robot battery on the joystick, so we dont eat AAA batteries, and the connection cant be lost due to low battery voltage. [fyi we have modded the joystick about a month ago and used a half used robot battery and have not replaced it since]
the one think i think may be causing this problem is that the wifi keys may be over heating, or something over heating because i find it happens more and more frequently as we use our system. i also think its the wifi keys because it works while tethered. i doubt its our school network because we have used the old vexnet and that had no problems.
if anyone has a solution to this, that would be awesome, especially with a competition coming up.
the one other problem i noticed is the +/- 30 on the joystick’s joysticks.
During Game day at Dallas BEST robotics, three (of 28) teams reported Vexnet loss-of-link problems (problem #3 in your report). Swapping our their Vexnet keys with new ones fixed the problem (for the rest of the day anyway). At least one of the keys showed signs of being removed carelessly (bent).
BEST has a higher percentage of problem #1 (burnt motor drivers). RobotC old versions had a sw issue. No such issue has been debugged with EasyC yet. All BEST issues with blown motor ports have been attributed to shorted wires. Since BEST uses DC motors hand-wired with no protection, this is not unexpected.
We have some instances of issue #2 also, never debugged.
H-Bridge: We have been testing different combination’s of motors running on the Cortex, since you first contacted us and haven’t been able to damage a Cortex H-Bridge yet. I would check your robot to make sure there are no shorts/loose connections in your two wire motor connections. We haven’t tried shorting out anything yet or disconnecting a motor that is running.
We found the issue robotC had in it’s release version very early in development on the Cortex, that issue doesn’t exist in easyC. We implemented safety’s in the software to prevent shoot through on the H-Bridges.
Joystick: Have you tried the calibration procedure to recenter the joysticks?
Also,
(2) the robot lock up issue can still occur if I am tethering the robot instead of using the Vexnet keys.
(3) Tethering the robot does appear to eliminate the lost link issue (which still occurs with good batteries/connections and a 9V backup battery installed).
The way it’s going, I will almost for sure have a lot of problems with these issues at the competition that I am attending this Saturday.
We have been having similar issues. We could not link together at all at our last competion, until we went to USB cable connections. It was annoying, but got us thru the competition. Thanks for the suggestion of new vexnet keys, we will try them.
We have gone through several VEXNet keys, changed the wifi routers (and even disabled them completely), tried different versions of the Cortex (we are also about to try the new ones we got back from RMA from IFI).
I can confirm that #3 occurs a lot, but my frequency is about every 20-30 minutes on that one.
#4 is a given. We program by tether exclusively now.
#2 we have seen once every 2-3 hours. (We meet for about 4-5 hours, so sometimes we will see this once, sometimes we will see this twice).
Just as a point of reference we have created a simple tank drive program, with it sending Print Screens every 20ms and it’s been running on VexNet for over 2hrs. We have joystick connected to a 9v adapter and the Robot on the new 3000mah battery. We plan to run the system overnight we will switch the robot to a power supply tonight.
Check the system using a lot of print to the graphics display calls. I’m beginning to suspect that the outages might be due to a large number of debug graphic updates being sent down to the screen.
Currently we update the screen with the following:
state and lastState (our state variables)
Left middle right encoders (3 quad encoders)
sonar 1 and sonar 2 (2 ultrasonic sensors)
arm position, target arm position, delta (arm potentiometer, a static target variable, and the delta between the two)
touch sensor status (3 of them)
We’ve been generous with our printouts on the screen, so a lot of static text is being put up on the graphics display. I’m sure it is adding to the amount of data being transmitted.
Let me know if you guys think this might be the culprit.
Just wondering if your Cortex’s are the ones with the hump (version NC3)where the VEXNet keys plug in or are they without the hump (version NC2).
We’re experiencing the problem on a Cortex NC3.
I’ve also just had problems #2 and #3 happen to us while being tethered on USB. I’ve sent the relevant emails to the parties involved (I think we are talking to the same people anyways).
Also, I was wondering, did you ever have RobotC installed on the Cortex’s you are using or were they always EasyC? We initially had RobotC on our Cortex and then switched over to EasyC.
All of my Cortex units are/were the NC2 version. The one that I am currently using has the date code 10A09.
EasyC V4 (always the most up-to-date version) is the only thing that I have ever used on them. I am starting to notice a trend here. It seems that issue #2 and #3 happen more often if you are using very complex and/or larger codes.
This leads to the question, has anyone else had any issues with RobotC running on their Cortex?
i am programing with robot c, and i have had no problems with the connection being lost or anything along those lines, and a plus is that it downloads on wireless in about 1.5 seconds, which is nice when tweaking your code.
we have been loosing connection, but i am almost certain that it is caused by the vexnet keys overheating and shutting down because i have had both the cortex and the joystick on for around 1.5 to 2 hours and the worked, but then started to loose its link(and the keys got hot to the touch, so i replaced the keys and then it worked for another 1.5 to 2 hours. because of this evidence, i believe that all of our connection problems, and possibly yours, could be caused by the joysticks over heating.
Too bad our experience have been quite different. We started on RobotC and had to switch over to EasyCV4 because of the problems we were having with the connection dropouts (as well as a number of other RobotC bugs).
Also, we have just noticed connection dropouts WITHOUT using VEXNET. The robot and the Joystick were connected via a USB A-A cable.
As of now we have run our own code overnight 12hrs one night and 16hrs other. We have run Paul’s code for 4 hours and not had any drop out issues.
We have created a worst case program we have started running, two quad encoders, with two motors, and the ultrasonic, running the LCD Module showing the both encoder counts, and the Graphic Display showing the Ultrasonic, Encoder Counts, and the time running.
Yesterday I attended a regional event near Pittsburgh PA. By an interesting coincidence paulctan was also there. Of the 27 teams who attended the event roughly 10 were using the cortex controller with either RobotC or EasyC V4. I was able to ask all of the Cortex users whether they had had any issues with their unit. Every team except one (90%) told me that they were having problems with either issues #2 or #3 or both. It seems that the NC2 and NC3 versions have the same bugs.
Fortunately, I did not have any problems during the day (I ran the robot for a combined total of less than 30 min through the course of the competition). I am not sure why IFI is having trouble recreating these issues but other teams are definitely having the same intermittent problems during practice.
if it makes any difference, my team used cortex, programmed with robotc and we had problems during the day with code and breakers. we made it through the day and managed to make it to first place, the one thing we did, is disconnect the back up battery, which made all of our problems go away.
what i have to say to teams is to try running your system (connected to a competition switch) and then try it again without the back up battery. so this experiment is valid please let your system “rest” in between tests, because the vexnet keys overheat and shut down.
After more testing we found sending large amounts of Terminal data or Graphic Display may cause VexNet to drop out. So, for the mean time we would suggest that you turn those off during a competition. I suggested to Paul to use a digital input and a jumper to turn them on and off.
i find that the with easyc code the download takes a lot longer compared to robotc which is around 1.5 seconds. this increase in data transfer time(and amount?) may be one of the root causes of cortex dropping out during download. also, while downloading try to keep the two units close together, i would say within around 5 feet, this decreases download time and increases the odds of it not dropping connection.
i know that almost everyone is having problems with the cortex, and i did too, i was going threw what i changed/did and here is my list:
removed/didn’t use back up battery,
switched to robotc (smaller codding)
used a power expander to better distribute the motors(with the new hs motors, there is a lot of more power used and this distributes it better, also redistribute motors and functions evenly across breakers)
i also re-calibrated the joysticks(doubt that this is it but try it, who knows?)
i also re-wrote my code (copy and paste) in a new competition template (i don’t know, i did it so it goes in the list)
re-downloaded firmware,
i cant think of anything else i did to the system,
We have had VEXNet connection problems. We could walk around the field and see the VEXNet light go red on the Cortex. We put the key on an extension cable and were able to walk around the field and 10-15 feet away (full width of our room) without any connection problems. The key was warm when we moved it to the cable. We re-installed the key in the Cortex and had connections problems immediately. Switched back to the cable and problems went away. We tried this 2 or 3 times. The only time between tests was the time needed to power off/change to/from cable/power up/wait for sync. I don’t think that there was enough time between tests for any thermal buildup or decay. We had no problems when using the extension cable and always had problems when directly connected to the Cortex. The extension cable that we were using was for a Logitech wireless mouse. It had a base that we just sat on a flat plate on the robot. I would like to use a $3.00 six inch extension cable from Amazon for competition next week. I emailed the information to some of the people working on the event and asked if the cable could be allowed.
I would be very interested in knowing if this approach helps anyone else who is having connection problems.
this is very interesting.
using an extension cable has crossed my mind a few times, but only to move the key away from the metal. could it be that there is an element in the cortex (maybe the cortex chip) that is interfering with the transmission of the signal?
