Discussion of VEX Programming Languages

That topic that came up today about Flowol got me curious, and I started looking for other programming options for the Cortex. Flowol seems weird, but if you’re curious the information for using it is on page 42 of this document.

I actually found one more that was new to me, called “Risbee.” It seems to be written by some sort of French (maybe Canadian?) company, and lacks any sort of documentation beyond this one manual.

Has anyone ever used it before? It was written to make these work apparently, but the website says that it has the capability to control the Cortex, too. Looking at the blocks, it doesn’t seem to have an option for IMEs, but everything else is there.

So, with that in mind, how many options are there now? There’s the two new one this year, RobotC/EasyC, and these two that have popped up over the last two days. I found one for the PIC, but it says quite clearly that it’s incompatible with the Cortex on the home page.

Am I missing anything? Anyone here have experience with either of these two (three) other languages? Any interest in seeing if they’re any good?

I like ConVEX :slight_smile:

I mean, honestly, it’s basically up to preference but RobotC, EasyC, PROS, and ConVEX basically have everything you could want among them. I don’t see the point in these newer options.

I’m playing with Risbee now, and it’s… different. There’s no “programming logic” required. You don’t have the statements and the variables needing to be called in the same way. I can see how it would be simpler for new programmers to get into. And it’s free, so that’s an added bonus. If you wanted to get people who have NO idea how to program making their robot work, it might be faster than the “correct” way.

I’m just curious if anyone had used them and had anything to say, good or bad. We’re using PROS this year, and it’s doing everything we wanted to.

+1
ConVEX is the best I’ve used so far. I don’t consider EasyC to be a programming language. And RobotC is frankly a bit… ugly?

I just feel awkward using RobotC. Nothing against the language - it’s the IDE that bugs me. If they integrated it with Eclipse (and made it work in Linux) I’d have no problem using RobotC. But ConVEX has won me over now :).

I love the PROS IDE setup and I like their language but ConVEX has all of jpearman’s libraries prewritten which is just awesome.

We’ve never used any of those before. Can you ELI5 what we’re missing by using PROS?

Okay so things I like about ConVEX:

  1. “Motor and Sensors Setup” --> The array is sort of reminiscent of RobotC and makes it a bit easier to keep IMEs and such organized
  2. SmartMotor Library --> Keeps your PIDs from overheating and ramps motors for you. It’s also super integrated in ConVEX.
  3. PID Library --> Never actually used it but supposedly makes PID easier. I still like doing it manually.
  4. Apollo --> Easy way to view sensor data and to send commands to your code from a computer

I doubt many 5 year olds would understand that but perhaps you did :slight_smile:

Disclaimer: I have yet to actually upload and use any code from ConVEX or PROS.

What’s this Apollo thing? How does it work?

I suppose I’m talking about ConVEX debugging in general and it’s discussed in the ConVEX documentation

Oh, cool. A debug/terminal window.

Maybe we’ll play with ConVEX at some point and test a few of its features out.

Welcome to Open Source, hacking hardware that may or may not be Open Source!

For example, I have a Nook, and I run N2A on it. N2A was developed by an open source team to run on B&N hardware that hasn’t been exposed.

RobotC an EasyC have been given the access to to the internals of the VEX Cortex, so they have been able to develop great software.

Recently two groups have created software by diving into the internals of the VEX Cortex.

I’m a fan of Lua, and I’m working on moving Embedded Lua (eLua) to run on the Cortex

And a few others out there say they can run on the VEX Cortex.

So now you have software sources that you can pick from.

Cool Vex hardware, some polycarb and your choice of software and you are good to go.

My pick for 13-14 comp. RobotC. The new kids are new, let them show their chops with other teams. In 2014, eLua, since I’m working on it will be your language of choice :rolleyes:

You should test before you commit. Events are no place to find problems.

Our “D” team is using ConVEX and they have done some insane programming with it that works flawlessly and absolutely blew me away when I played with their test bot at our last meeting. Their sensors seem to work with greater precision than I have ever witnessed before. I can’t wait until they are done with their robot so I can see it in it’s full glory. I expect our “A” team to do well this year, but I think they can kiss any Amaze awards goodbye up against the robot with ConVEX.

Maybe once their robot is complete and has competed they will do a reveal. I am sure once it makes it’s way to South Texas you will hear about it. Once our Future Foundation robot is videotaped and entered into the competition I will be grabbing it to play with ConVEX myself.

Could someone throw a link my way for conVEX? I can’t find it on Google for some reason… :frowning:

NVM…I found it :stuck_out_tongue:

You missed Flowpro

http://www.youknowsolutions.com/

I played with this a while back (both flowol and flowpro pre-date PROS and ConVEX) but it was lacking compared to EasyC and ROBOTC. It’s another flowchart driven environment. What’s up with all the flow chart driven programs? I haven’t used them since the 80’s and that was for assembly language documentation.

The link is in my sig :slight_smile:

Are all 3 of these languages “safe?” As in, they won’t burn up my Cortex in any way if I were to play with them? I’m getting the feeling we’re going to have a lot of time to spare this year, and this could be fun.

We know that EasyC and ROBOTC are safe, they have been proven to work in competition.

I am confident the ConVEX is safe as shipped (by which I mean that, being open source, you have the option to change anything you like and possibly create code that would damage your cortex).

I believe that PROS is safe, the original b3 version (IMO) had a small issue that was corrected.

I think that for at least this season there will be some tech support on the forums for both PROS and ConVEX. In fact, you all know that I’m here often and answer questions on any programming issues no matter which firmware or IDE you all choose to use (just don’t post code the night before a competition, test early, test often).

I tried flowol earlier, no smoke, but I did not do any extensive testing of their motor control.

I have no idea if flowpro is safe or not, however, both flowol and flowpro are shown as programming options on the VEX programming page so I must assume that they have worked with VEX on the development and been tested by VEX.

Alright, cool. I might give them a shot later in the year.

When I started doing VEX all the way back in 8th grade, we used EasyC. As did every school in my county. I started heavily disliking EasyC right around my junior year. My senior year my school in particular switched to RobotC. Loved the change and what it allowed for me to do, and the year after everyone hopped on and we taught it at the summer camps that summer and the next summer.

Now with ConVEX and PROS I have a lot more freedom to explore some things with sensors for VEX U. Particularly looking at ConVEX and the different port configurations and seeing how much I can manipulate the processor.

In the end I think ConVEX will be my final choice, but RobotC is my fallback.

We at VEX are very excited by the development of user-created languages such as PROS and ConVEX. It is great to see our user community building their own tools to enhance the educational robotics experience.

Any of these tools which pass the software component of the robot inspection process are legal for use in the VEX Robotics Competition. It will be interesting to see what creative things our teams will be able to accomplish and what new educational opportunities they will be able to experience.

Of course, it is important to note that some of these tools are utilizing pieces of the VEX hardware and firmware which are normally hidden from the end user. Some of these pieces when changed can affect the performance of the hardware in negative ways. There are even parameters of the software which when changed can result in a failure of the hardware. Unfortunately, in this instance VEX Robotics is unable to provide warranty support.

Please, be mindful when experimenting.

We wish all the users of these languages nothing but positive experiences, and look forward to seeing other new developments in the future!

If you have any questions on this, please message me at jvn@vex.com

-John