I'm done with crap code from IFI, RobotC and EasyC

I would never question the time, energy, and expertise someone puts in to learning the current sensors, code, etc, especially you, Foster.

I’m sure there are ways to improve - which is the heart of your message, I believe.

More practically, though, IFI/VEX, Intellitek, and The Robotics Academy all have many ventures they’re working diligently on. All are successful in there own right in those many ventures. Having spent time with folks in all three “camps” personally, I’m convinced they’re expending what resources they can each year on this venture.

I’ve seen incredible growth in VEX over the years and incredible work by the global community in terms of programming/autonomy. The inspiration this is providing for tens-hundreds of thousands worldwide is truly amazing.

While I agree improvement can be made, I worry about expending too much energy in any one specific direction (sensors and code in this instance), how that might tax resources, and how that might drive up costs which could inhibit the growth/deny access to students at some point.

On the larger scale, this is wildly successful compared to all other student robotics programs, by all metrics which can only help build a stronger global future - code faults and all.

Namaste, gang. Let’s keep sight of large pictures here and inspire kids in a positive way with our time and our actions - especially when we’re frustrated.

theres a lot of issues that need to be looked at i think

I am convinced the success of VRC is directly attributable to the personal customer service found here, the accessibility of the staff at all levels, and the willingness to accept constructive criticism (this thread) and take said criticisms to heart & be inspired by them.

Long live this thread and the people who make them. Kudos for creating an environment in which respected members can bring up these issues.

1 Like

Please list the issues. I would really like someone to be specific as to what the problems with the firmware are (and I don’t mean more complaints about fundamental language constraints, its not c++ etc.)


First of all, if I were on your team, I would be ashamed to be represented by you.

We are mostly all students here, students who love VEX and who come onto VEX Forum to help people and to inspire each other. These kinds of comments, especially coming from a respected mentor as yourself, have no place being here. If you have a list of specific issues (as jpearman has been asking for), that would be different, and it would be acceptable. But a general put-down like this to VEX is not constructive. It is not conducive to the warm and helping environment this forum is supposed to harbor.

In my dealings with VEX, they have been very generous, very helpful, and very courteous. They are doing a great job, and no one should have to take this kind of abuse.

Even if there is something wrong with the programming languages we as students use, it’s still what we have to work with, and it’s what we have learned to deal with. You have seen what students can do with programming and the VEX system (1103 is a great example). If there is something wrong, it has not prevented 99% of us from doing what we aim to do. And besides, robotics is all about problem-solving and finding new and innovative ways to do tasks. If something in your system doesn’t work perfectly, find a way around the issue.

Lastly, the Forum is no place to call out VEX. We are here (as I have said) to help people, not to put them down. If you have a product complaint, contact VEX directly. My team has found VEX to be very responsive to what we need.

1 Like

well i think the most issues exist with the competition software or in the competition template. because as issues seem to be very prevelent in competition they are not as often occuring in the classroom setting.

losing a robot light is a big problem that i keep running accross when switching from autonomous to driver control

Well the competition template in ROBOTC is there for you to use or not as you wish, it is just that, a template. Having said that, I’ve never had any problems with it’s functionality.

I think most, if all not all, issues related to connectivity are caused either by intermittent hardware (ie. bad VEXnet keys) or other external RF interference.

we use easyc not robotc and keys that hace come directly out of the package should not have the problems that they do…

In a perfect world new VEXnet keys would not have issues, but this is the real world and with a consumer product that is probably built for $3 in China there will always be a certain amount of early life failure even with 100% QC of the product.

You can learn about the “bathtub” curve in this and many other documents.

In terms of EasyC, my experience is that the competition software seems to be stable. Do you have some code that demonstrates your problems?

1 Like

they really shouldnt sell them for more than $3 if they keep breaking as much as they do…

1 Like

While I think Foster’s post was a little aggressive, I can certainly understand his frustration. I have mostly stayed out of the discussion of these issues because I have not really had time to be part of a solution. While I am fairly new to robotics (4 years) I have spent my entire career (23 years) as a software engineer and project manager.

I have been disappointed in the quality of some of the software being released, especially with the limited options available. RobotC and EasyC are commercial products and as such I have high expectations from them. I primarily use RobotC and they have fallen short of the standard I expect from commercial software. Please don’t take this as simply bashing RobotC. There are a lot of great things about RobotC and it makes it very easy to teach young students robot programming. However, as a PM if I had released packaged software like some of the RobotC releases my job would have been in jeopardy.

My opinion/suggestion is that IFI require more stringent testing from their software partners and/or open up the option of an open source/community development platform for the Cortex.


1 Like

sorry i do not have our code because i am not our teams head programmer. ill talk to him and try to get it.

Jay, can you elaborate on this, what specifically needs improving? This is the ideal time of year to give feedback to CMU and sort out any issues before next season. You do have to remember that this is a niche product that is relatively inexpensive. Compared to some of the FPGA development software I use that costs me $4000 every year for a license (I’m looking at you Xilinx), ROBOTC is golden.

I “sort of” had development running using the Eclipse IDE and the same Sourcery compiler as EasyC uses, but decided it really was not worth the effort as, at the end of the day, I had pretty much the same functionality as EasyC could give me.

Here’s some EasyC development using Eclipse as the IDE.


I think this is a key factor here. Affordability and accessibility. Without a long sordid history lesson, the VEX Robotics Design System was originally engineered for FIRST robotics’ competition teams and then its intermediate competition program. Since then FIRST has chosen a different path for its intermediate program (and one could argue that path is way more expensive and filled with many more software issues than VRC, but I digress) and VEX developed its own competition events to honor its early adopters/users, which, through unprecedented growth, gave birth to the non profit RECF.

I’m fully confident that all of the folks involved, VEX/RECF/and the software partners, want to bring classroom and competition robotics to as many folks as possible around the globe and they are all highly cognizant of the cost structure. Obviously software and sensors are only two pieces of a very large puzzle and the growth of VEX speaks for itself in working toward that goal.

I’m sure that VEX and their software partners will listen to the salient requests posted here and will look at ways of improving in the software and sensor areas, but I’m also sure that the overall goals, vision, etc need to be considered and balanced with those decisions. Meeting the needs of a subset of users while maintaining a high level of satisfaction for all other users is a challenge not easily undertaken, but one the VEX folks have always stepped up to the plate to do.

1 Like

Still haven’t seen an example of software that “can’t get the job done.” Our experience with EasyC has been fine.

If you are using RobotC then how can you complain about the EasyC software?

I have been involved in the vex robotics system for the last four years and have used easyc all four years. As a programmer, I understand where you are coming from and not all systems are perfect the first time, sometimes problems do not come up in all the testing that has been done. RobotC and EasyC are improving their products everyday and most of the time it is IFI that holds them up. Not wanting certain parts of the code be available to these programming software’s.

Just give them a chance as vex is improving everyday!

My teams have used both RobotC for NXT (We did FTC our first year) and RobotC for Cortex. I have not personally done a lot with the versions since 3.00. I had veteran programmers on each team and worked more with them on code structure/organization than with use of the IDE. The couple examples that immediately come to mind have probably been corrected by now. In the 2.XX time frame we had one version that would disable/hide some menu items after performing a compile/download. In a subsequent version we could only successfully download if we had not edited any files since starting RobotC. This meant every code change required shutting down and restarting RobotC in order to test the change on the robot. We saw this same behavior on three different computers. My guess is that these issues and a few others we saw were the result of insufficient regression testing. What that has done is cause me to be skeptical of any new release.

I believe all my programmers ended up using 3.05 at the end of the season. I’ll check back with them to see if there have been issues like this since 3.00.

1 Like


If you want a positive response from IFI, RobotC, and EasyC, then give them a constructive, professional post.

I agree with dontworryaboutit. As a mentor, it’s your job to set an example for your students and for other mentors on this forum. Disrespect toward the people who’ve worked hard to bring you an affordable programming platform is not acceptable. I think you should post an apology to the IFI, RobotC, and EasyC software engineers, and start again with a more professional post.

1 Like


looking at it from VEX’s point os view, they might have a program that worked 99% of the time if they spent 30 hours a day, 400 days a year per person.

even i had problems with the software but i made a thread that told people what was wrong and what was going on at the time.
So why dont you post what ti problems were and MORE INFO ON WHAT YOUR PROBLEMS ARE. I want this fourm to have a reputation as a respectful and helpful place for the newer members

Link to the thread
coment on the thread Plz.
sincerely spartin:):):slight_smile:

I may have missed it (I only lightly grazed the thread) but what exactly is/are the specific situation(s) that has/have troubled you? You mentioned great designs that students build, only to be let down by software. If you posted specific programming hurdles that you havn’t overcome yet here on the forum, I’m sure the community would be glad to try to assist you in any way. Personaly, I only have experiance in EasyC, but the community knowledge base is broad and deep. We would be glad to help :slight_smile: