What do forum members want for VEX software development?

VEX V5 General Discussion Technical Discussion
#1

The recent announcement from Purdue that they have developed an alternative way of writing software for the cortex has generated much interest and excitement. I’m curious to understand what the underlying reason is for this excitement, is it simply the fact that it’s using the eclipse IDE? Or perhaps the thought of getting a development system for free?

Last year I posted a thread that explained how to create a user library using eclipse that could be then linked with an EasyC project.

https://vexforum.com/t/advanced-easyc-programming-create-a-user-library/21938/1

I had posted that following the creation of a document explaining how to use eclipse for all development by linking against the EasyC runtime library. That document was never released publicly for the simple reason that it would allow free development using the EasyC startup code and runtime library without a license for EasyC.

The compiler used by EasyC is gcc (Sourcery G++lite for ARM), these are free tools. It is the same compiler that’s now being distributed with the arduino IDE (1.5.2) for compiling sketches for the new ARM based arduino products. There is a good chance that it’s the same compiler that Purdue is using as well. The EasyC include files do not contain any form of copyright or EULA, so it could be argued that these are also free to use. The runtime library is a grey area, it also does not contain any form of embedded copyright and I find no EULA or any other license information in any of the EasyC program folder structure. Common sense tells us that it’s wrong to use the Intelitek intellectual property without paying for a license, I did not release my instructions on using eclipse to remove the temptation to have free development, however, if users are so excited by the possibility of using eclipse perhaps I should.

So back to my original question.

Is the excitement with the Purdue announcement due to being able to use eclipse with all of it’s included functionality?

Is it based on the potential performance increase?

Is it the possibility of free development tools?

Or is it something else?

2 Likes
#2

I am excited by the fact that it will run on Linux and Mac.

2 Likes
#3

I’m excited for a number of reasons:

  1. I’m a Linux user and RobotC is the only reason I still need to run a virtual machine. I absolutely detest this awkward combination.

  2. EasyC and RobotC really aren’t excellent IDEs - they’re IDE wannabes. With RobotC, there are bugs with formatting, code completion is awkward, projects are a total disaster, and it is just generally missing features which makes it difficult for me to go from working in a “real” IDE to this one. EasyC on the other hand is extremely difficult for me to use because of its drag-and-drop style.

  3. Sure you can do awkward combinations like the EasyC runtime and Eclipse, but it’s not seamless at all and still has the downside of requiring windows.

  4. With this open design libraries could become much more common to make tasks easier. I know I use the libraries you’ve written for RobotC, but libraries are just a hassle in RobotC. Debugging doesn’t work right, red lines for errors don’t work, it’s just a generally confusing and unnatural setup.

  5. I do not care about paying because, well, I don’t pay. My club does and we already have a RobotC license for all the 3.x versions so as far as I’m concerned I could care less about that.

  6. I’m a big believer in open source and I think that we should be able to modify our environment freely if we dislike something about it, especially since the environments aren’t exactly cheap.

  7. Eclipse also gives us the option of integrated version control systems which would be awesome for a club which may use some shared code and then some individual code for each of the robots. It would also make it easier to make changes and “go back” to when the code last worked without having to resort to external tools.

  8. If it were my personal money going into the IDE, I would rather spend $200 on this than keep using RobotC (although please don’t charge simply in the interest of finally having an open environment for everyone. But if you charge and give us the source code, solid documentation, and a good base of API functions, then go for it!)

So to sum it up:

YES!!!

No, but it certainly doesn’t hurt.

And, Yes

2 Likes
#4

Truthfully, I’m just excited about seeing something new being developed. I can do everything I’ve ever wanted to do with ROBOTC. I like being given the chance to develop in Eclipse. I’ve never really truly used Eclipse to its full potential and using PROS would give me that opportunity. Also, PROS uses the GCC, not a VM like ROBOTC.

Of course.

Not really, a couple of microseconds isn’t gong to make much of a difference for 99% of all robots.

Yes, especially the fact that you can use any general-use development environment (i.e. Eclipse, Notepad++)

1 Like
#5

There are certainly some downsides I can think of for the Purdue system, mainly:

  • Downloads will likely be slower than RobotC, especially over remote, because it will need to put all the code on the robot every time (just like EasyC)
  • Doesn’t appear that there’s any way to send debug data over wireless although I’m sure that someone will come up with a way quickly. Open source software tends to be developed quickly be the community.
1 Like
#6

Did I say windows only? No, you could do eclipse/EasyC under linux or OSX as well.

EasyC uses GCC, I think PROS will have a better runtime library than EasyC but otherwise it would be a very similar development experience. Don’t misunderstand, I’m excited to see alternative tools being developed as well.

This is what the eclipse/EasyC hybrid looks like.

[ATTACH]7393[/ATTACH]
eclipse_project_list.jpg

1 Like
#7

I’ve never used Easy C and we like Robot C because it is more like real programming where you type away. Robot C has its limitations but I am not sure where Robot C ends and the firmware begins so I am not sure if I can properly answer this.

For the more advanced users the Purdue thing seems like a bridge to real world software development versus Robot C.

However, putting a 6th grader in front of Robot C and letting them loose requires quite a bit of education that Robot C helps guide the user through configuration windows. Going right to Eclipse might seem even more daunting.

But by the time you’ve used Robot C for 3-4 years, you can be taught soemthing else that is something you might put on a resume to get a job for real world skills.

One click to download to the robot is great in Robot C (once set up and you’ve gotten through all the driver set up). So are the communication testers, and the communication support in recent versions.

The streaming of variables wirelessly to the controller to the debugger is the next great step in the programming evolution of students. (But it leads to an over use of global variables it seems). Improvments to the debugger might be good.

Saving the debug stream to a file is a wish list item. Beats havign to hookup an arduino via serial connection.

Free helps too as we’ve had license issues in our club. 80+ kids and growing.

Mac/Linux support is awesome - again for the more knowledgable users I think. Parallels works well enough for our Mac users.

What I would like to see most in Robot C is verison control integration, better support for multiple include files so I might be able ot compile and download while working in the include file, not the main one. This could mean tagging a tab as the one to download though or maybe a makefile of some sort.

I’d like more I2C interfaces so we can add whatever I2C sensor into the Cortex (although the IME is the only I2C sensor curently available but we use these for firefighting competitions too). Again, is that firmware or Robot C?

I would like to have some way of tagging an individual variable saying don’t stream this back to the debugger. (again, over use of global variables)

Lastly, is there some sort of thread execution logger to see if you have any pigs of threads? Expert mode shows you what thread is going right now, but it flies by pretty quickly.

1 Like
#8

Would like to have an easier way of syncing cortex/controller firmware :expressionless:

Also would like to see an easier way of getting the code from the cortex if you lose the original code (atm you can only get a screenshot I think)

#9

The computer that we leave in the Robotics lab at school runs Linux. I have to bring in my 12 pound laptop every day we want to program anything. This will just be easier.

Additionally, we are excited to switch off of using EasyC. We tried creating a program that involved threading this year and couldn’t find an easy way to do so within the constraints of the program. This should help us write better, more accurate autonomous programs.

Oh, and IMEs are causing still problems. My team has me rewriting all of our Autonomous modes not to use them after realizing they can cause rare disconnects. I would love to use them, but we don’t like the instability they cause.

#10

For anyone that doesn’t know, I am a Vex Hobbyist, and not on a Team…

I have not really used Eclipse, but I like IDEs, because everything is a Key Press away from being done…

Definitely!!! Even EasyC has poor performance and impediments in the Interface Library… RobotC you Trade Performance for Portability and Debugging…

Free is not an Issue to me… I have Licenses to ALL the PIC and Cortex Programming Environments… Open or at least Available Source, is more Important, so that Bugs and Inefficiencies can be fixed, without waiting for the next Release Cycle…

Choice is always good…

Choice in Development Platforms…
Choice in Operating Systems…
Choice in Editors…

It’s ALL GOOD!!!

#11

Definitely. Everyone loves eclipse and most find it easy to use. I use Eclipse and Visual Studio exclusively, they are both great IDE’s.

Who doesn’t love performance? If not definitely, definitely a plus.

Free tools are nice, we are certainly used to getting our development environments for free (along with everything digital for that matter). But I think it’s more that it’s open and community driven and supported (or will be hopefully) that is most enticing.

Let’s put it this way, if it was an eclipse plugin that had a pricetag of $50, I’d still be extremely excited.

We like seeing a third player, esp. an open one. It’ll make the other two rethink just enough to move the bar forward a little. Mixing things up after the cards have fell is awesome. Good on them!

Now I KNOW what you’re thinking, or at least I think I do… You’re going to get involved in some way, or roll your own - I just know it. :wink:

If thats the case, please do! You’re one of the titans of knowledge here, if there is anyone we want working on a new IDE, it’s jpearman.

-Cody

#12

Here’s my list of reasons why I like PROS.

  • Eclipse. A HUGE plus. The RobotC IDE is the worst IDE I’ve ever used.
  • Performance. Why not have the robot work better?
  • Integrated environment. Similar to the first reason. I’m constantly working on other projects in Eclipse, and being able to keep all of my projects in one IDE and keeping a streamlined experience would make my life so much better.
#13

We can see where many high school teams are coming from in this regard. For them, the Purdue Robotics OS offers the cross platform compatibility and Eclipse IDE with source control that advanced programmers would like to see. Improved multithreading might also benefit some teams. But the majority of the performance improvements probably won’t be noticeable for a high school team, except for a few improvements in the VEX Yaw-Rate Gyro and VEX Quadrature Encoder.

However, for us as a college team, PROS feels like a game changer. With easyC and ROBOTC, we could interface virtually nothing directly to the cortex. The serial ports dropped data if you went faster than a pedantic 9600 baud, and the I2C port was exclusively used by the Integrated Motor Encoder drivers. Due to the ESD protection resistors and capacitors on the Digital pins, the built-in SPI port could not be run at any reasonable speed. Most attempts at powerful features like PID velocity control and DSP on sensors (14-bit Line Tracker readouts, anyone?) did not work well due to the extensive timing overhead of the standard environments.

PROS changed the picture by opening up the Serial ports to reliable communication as fast as 230400 baud (possibly higher but we have not tested) and allowing the IME and other sensors to share the I2C bus under user control. Now our external sensors could be bused on the I2C port, or interfaced with a fast external processor that could dilute the information down and pass it in over a serial port. At that point, the multithreading and improved runtime library were just icing on the cake. We could finally utilize the full extent of the college rule set, and we plan to demonstrate this year that this is the real reason why PROS was built.

As for code download speed, PROS is currently much faster than easyC but slower than ROBOTC at this time, something that we will work on improving after the World Championship. We have not yet needed an actual debugger (breakpoint, single-step, or watchpoint capable), and do not believe that such a concept would be easy to implement. Debug data can still be sent over wireless using print statements to HyperTerminal or PuTTY.

2 Likes
#14

A new IDE is nice

EasyC is fast, but hard to program
RobotC is slow, but easy to program
Purdue’s software will fast, and easy to program

Free is good, if it is open source it would be even better, so every team could add some commands to it (I have some ideas already)

Just knowing that someone can reverse engineer the cortex protocals makes me know that is possible

#15

So the wireless programming kit does work it and you can send print statements as well as wirelessly program?

#16

I’m not sure why this didn’t work for you, I have no problems receiving data at 115200 baud using ROBOTC, just did a test and it’s easy to push 24 bytes @ 30fps between two cortex controllers.

Hmm, one SPI port is used to communicate with the master processor and runs at around 2.25MHz I think. The other two SPI ports do not, as far as I can find, match up with any of the external IO ports on the cortex. I had looked to see if these were available to interface to external SPI flash and I though I concluded they went to unused pins on the device.

I run a similar processor from Atmel (AT32UC3B0512) with three serial ports running at 921600 baud all day with no issues, you should be able to do the same with the cortex.

No, you really need access to JTAG or serial wire debug to do this. It looks like these are on test points in the cortex although there is a chance that they go to unused pins on the digital/analog header (which I think they did in the PIC). I poked around one day but did not figure out if they are there, IFI could save me so much time if a schematic happened to fall my way.

I’m not sure what to think to be honest, on the one hand I could certainly contribute code and provide interfaces to all sorts of sensors, adding plugins to eclipse could also be done but that would take some research as I’ve not worked with eclipse at that level. However, I also work closely with the developers at CMU and want to maintain that relationship. They have shared certain information with me under an informal form of non-disclosure, that is, we have an agreement that discussing certain things is off limits. Having or supporting a free open source development environment for VEX would impact to some extent their business and that’s not something I want to do. Anyway, the timing is good as all the interested parties will be in Anaheim next week so there will hopefully be a chance to have some good discussion on this topic.

1 Like
#17

I love these unsubstantiated statements.

EasyC really is no harder to program with than ROBOTC, just drop out of the flowchart mode and write everything in native C.

In most situations that matter, ROBOTC is faster than EasyC.

We have no idea how hard/easy Purdue’s software will be to use, all we have are a few screenshots and some snippets of code. The IME test was faster but I bet you 5 clothpins that’s because they are running it at 400KHz and not 100KHz, I’m not convinced that will be a reliable speed. The threaded workload test is bogus if you understand how ROBOTC tasks work, apparently they have a multitasking system that can execute and time slice three tasks of the same priority in 10uS. As their previous test showed that it takes 12uS to print “Hello” and one of their tasks was doing the same thing, it seems implausible. Don’t misunderstand, I’m sure they have done great work and it will be a viable way to program the cortex, but everyone hypes their own product and we need some independent testing before any real conclusions can be made.

1 Like
#18

I don’t want to say that “free” is what I’m looking for… the work that has gone in to developing EasyC and RobotC is definitely worthy of financial compensation.

On the other hand, the licensing structure of EasyC is… awkward… to say the least. It is easy enough for having EasyC installed on lab computers, but when a student wants to install EasyC on their own laptop, I have to be careful to ensure that I get the license code “back” from them at the end of the year.

I recognize the dichotomy in that statement… and that I don’t have a problem letting a student take a Cortex home to work on and getting it back from them at the end of the year. In comparison to many “locked” pieces of software, EasyC’s license management is reasonably flexible and they do a good job of supporting it.

But certainly a FOSS solution would be easier from a classroom/lab management point of view… and would save money for schools with multiple teams and tight budgets.

The bottom line, however, is that I have to be able to take someone who has never written a computer program before, and in the course of a weekend have them leave feeling that they are able to reliably make a robot move in the way they want. Syntax errors, library installations, inscrutiable error messages, intermittent bugs… anything that gets in the way of “easy” makes it just a little bit harder to recruit new coaches to VEX.

So while the FOSS licensing and all those fancy features are nice for experienced users, what I’m really looking for is ease of use and reliability… and an error message that says, “The lack of communication is likely due to a faulty VEXNet Key. Try replacing your keys with a ‘known good’ set and try again.”

Jason

1 Like
#19

We have had occasional issues with VEX Motor Encoders on chains with multiple long 4-wire extenders, most likely stemming from the fact that they are running at the higher speed. Since we ended up using only a few IMEs close to the Cortex this year, we have put this issue off for after the championship.

You are correct, PROS can’t time slice all three tasks in 10 uS. In this case (and in many other cases), though, PROS never needs to. Since all three tasks have the same priority, PROS will always schedule tied threads in order of increasing delay time. A sample of 20K of our SLOC from last year demonstrated that the most important delays to have low jitter are the shortest durations/fastest frequencies.

So the only jitter on the pulse task (as it will go before the other tasks whenever both become eligible to run at once) will be one context switch (4.5uS), the overhead of delay() exiting, and sending the pulse (1.15us). If we measured the 20 ms or 1000 ms tasks instead, the delay would indeed increase. The 20 ms task has between 15 and 20 us of delay, and the 1000 ms task has between 0 and 50 us of delay, but these tasks are much harder to measure accurately than the shortest one, thus the reason for quoting that statistic in the benchmark.

You are correct (and I hope that we made clear in the post) that benchmarks are somewhat artificial and don’t demonstrate everything about our developments. But I could not think of a better way to concisely describe PROS in a forum post without a teaser video (which I don’t have made) or a bunch of pictures (which I haven’t had the time to gather yet). Good thing World Championships is less than a week away.

2 Likes
#20

Taking it a bit back to the original post.

If I could use the PROS I would probably end up not even using eclipse. Eclipse is great for java development but I find it rather clumsy at C and tend to use simpler editors like Sublime Text. So I would just end up using the Makefile build system.

For AURA begin able to use something for free or hopefully a smaller fee than currently charged would be a huge plus. We don’t have a lot of spare money for things like RobotC licenses and can’t get uni to put them on the university computers because it would simply be to costly in our lab area.

A few people in this thread seem to have bough up source control as a reason for using PROS, we have used SVN for the last couple of years and recently switch to Github, I don’t see how RobotC or EasyC prevents you from using proper source control. Just because your IDE lacks source control there are many other alternatives like Tortoisesvn/git, that operate outside your IDE with great results.

Another benefit I could see, there is a course at Auckland taught with VEX robots (they use a different lab space to AURA so we can’t use their RobotC licenses). I could see lectures much more keen on the idea of expanding VEX use in the classroom if it used more familiar tool chains to regular C development and conformed correctly to standards like C99.

I am a Linux user mostly and I am currently experimenting with RobotC under wine, it installed and and run’s but I am yet to test connecting it to a robot. Being able to run the system complete on Linux without wine would be far better in the long run.

The final thing I think would be huge for us as a college team is the ability to interface any sensor we want, We currently have a project just in its infancy trying to connect a RaspberryPi to the cortex over I2C (trying to leverage the cortex auto polling the Pi for data rather than using UART to manually handle that), we are still in the planning and part sourcing stage, but the current idea is to mimic a chain of IME’s. However this would be point less if we had something like PROS were we could implement the I2C ourselves and not be concerned about confirming to an IME like spec.

A few final points, we have never had any issues with performance of RobotC and I don’t think something like PROS even though it might be faster at spinning our main loop will make a huge difference in the way we code. Finally the EasyC library mentioned in the top post, we have never owned an EasyC license so could have never had an EasyC compiler to play with but this is an cool idea, but I think the ability to really drill down to the heart of the OS running would be much more interesting and ultimately lead to way more awesome things using the low level IO, rather than just what could be accomplished by linking our own library.

1 Like