In my preliminary (self-)education about RobotC, I was mightily confused about what this whole “natural language” thing was, and how it related to the drag-and-drop (“graphical”) editor or “regular” RobotC. I thought I’d share that information here, in case others out there are considering RobotC and are not really sure what’s what.
When I installed RobotC on my computer, it created these 2 different icons on my desktop, which were the start of my confusion. Why was this confusing? Well, because you don’t actually need 2 separate icons; all roads lead to Rome, as it were. Both icons launch RobotC, and once in the program, you can switch from the graphical to the text editor from the View / Preferences… / ROBOTC Editor Type menu. That flyout menu gives you the choice of “Text Editor Only”, “Graphics Editor Only,” and “Text and Graphics Editor.”
But there’s one catch. If you create a graphical program, you can convert it to text-based using View / Convert Graphical File to Text menu option, but you can’t go back the other way if you change your mind about the whole concept. Keep track of your file names (like, keep a copy of the graphical file before you convert; it might do this for you, but just double check) so that you can retrieve your old program if you need to. So, graphical –> text: OK. Text –> graphical: not so much.
So it’s pretty important to figure out from the get-go which editor type you plan to use.
Graphical / Drag-and-Drop
Similar to easyC, RobotC’s “graphical” version is a drag-and-drop interface. For teams that are just starting out with both robotics as well as the concept of programming, this is probably the place for you. We started with easyC in our rookie year for this same reason; however, now that we’re more advanced and want to jump up to the big leagues, we need to go back to Square 1 of sorts and learn a whole new interface.
The options available in the drag-and-drop universe of RobotC are rather limited, IMO (unless I’m just missing something)—and much more limited than what’s available in easyC; since easyC is drag-and-drop-only, every command and function is available in the graphical function list.* So I guess I’d say that if you’re starting with RobotC’s graphical interface, try to step up to the next level quickly so that your team’s capabilities have room to grow.
* OK, well not every function; easyC bizarrely has sophisticated functions that you can only find in the help files, and then you must copy & paste them into a write-your-own-code function block.
Tip: when you launch the graphical editor, you may not see all that many drag-and-drop commands in the left-hand “Graphical Functions” column. The default appears to assume that you are a “Basic” user, and shows you only a limited list of items. I really don’t understand the concept behind even having this option, but I’d recommend immediately telling it that you’re a “Super User” in order to see the full complement of functions. You can do this from the Window / Menu Level flyout menu.
Once you create a program with this graphical interface, it looks something like the screenshot below, with large color-coded blocks. Things like if and while statements show up as a wrap-around colored block to clearly show which commands are inside that part of the program flow. Also, you can edit all of the blocks there, directly on the screen; in easyC, you have to double-click on the function block, which opens a popup window where you make your changes. In this case, RobotC seems more convenient.
Another benefit of this interface over easyC is that it is more compact. easyC is lovely from a graphic design perspective (I should know; I’m a graphic designer in my day job), with LOTS and LOTS of whitespace. However, from a programming perspective, on a small laptop screen, you just can’t see that many commands all at once on the screen, which makes debugging difficult. To see the whole thing at once, we used to print out the C code and review it all on paper because there seemed no other useful way. With the interface shown above, you can clearly get many, many lines of code on the screen at once. A plus.
Here’s a snippet of the function block menu from above. You can see that RobotC has created some multifunction items for you, like “backward” or “turnLeft.” These are equivalent to easyC’s “Smart Motor Tasks,” a pre-packaged set of actions given the motor setup you provide.
Why am I still talking about the graphical interface, when I’m supposed to be moving on to Natural Language here? Because these tasks are Natural Language commands, in graphical form.
Natural Language (NL) is RobotC’s “intermediate” level of programming, which is text-based and involves more typing of and reading of actual code. It allows programming that’s a few steps more sophisticated and has more options than the graphical drag-and-drop option (although the NL commands are also dragged-and-dropped, just in text form, as shown in the screenshot at right). You’ll see that the list underneath “Simple Behaviors” in the NL function list is identical to that above in the graphical function box.
So if your team is moving from easyC (or moving up from the RobotC graphical interface) and are still getting their feet wet, this is a great next step. The kids don’t have to memorize lots of commands, and don’t have to do all that much typing, don’t have to worry about forgetting semicolons at the end of each line, closing brackets, and the like. Compiling errors will surely be fewer.
In fact, teams can use the graphical-to-text file option mentioned above (View / Convert Graphical File to Text) to convert a program that they wrote previously, so that they can really track commands from one interface to another very clearly. It’s a good learning tool.
And that brings us to the 3rd, and final, option, what I’d call “regular” RobotC. Using it is a lot like writing a program in any other language—you type. So instead of dragging over a “forward” block (graphical or NL), you now need to type a line like “motor[MyMotorName] = 100;” for each motor in the chassis. (See my post from last week on programming a chassis to see the type of code that’s needed to program a joystick.)
So why do you want to build your way up to this version? Well, here the sky really is the limit. You can create your own functions and tasks to do make the autonomous or driver-control functionality whatever you want. You can even import libraries that other (very, very nice) people have made available to the public with sophisticated functionality that are basically plug-and-play (see my other post about Slew Rate). In addition to these complete libraries, you can also make use of the VEX and RobotC forums, and copy and paste snippets of code at will that other (very helpful) people have put out in the world. There are so many resources available to text-based RobotC users, it’s just amazing. Google search and ye shall find.
♦ ♦ ♦
So that’s where my team is now, moving from easyC to text-based RobotC (skipping over most of NL, though you can mix-and-match NL and text-based commands). It will be an adjustment, and it will probably be slow at the beginning, but my girls already see the much larger universe available to teams that use regular RobotC.