Being fairly new to Robot C, but having lots of C++ and C# experience, It would be nice if i could have access to the object oriented features of C++ in Robot C. Maybe in the next version they could update the compiler.
I recently had to program an EV3 lego robot using Lejos, a java vm for lego robots. It was a lot of work to do simple things like read variables and write motors because of the hurtles of calling the objects. In a platform where amount and type of motors and sensors are known what OO features do you imagine to be useful?
Asking for my own curiosity.
ROBOTC has some C++ features (for example, function overloading IIRC).
Perhaps you could give some specific examples of what you would like to see.
Correct me if i am wrong… But is’t RobotC based on C. C is a function based language. I find not too many reasons to use object oriented programming for robots. I am biased towards function based because I started with C. I find it fine to use functions like void () or task (). In robotics programming security is not much needed using a private function. Just my thoughts.
RobotC is a “C like” language. Yes it is based on C but has a few features that are more C++ in nature and a few omissions when compared with ANSI C. I agree with you, for most of the more straightforward programming that we do with VEX, OO is not necessary.
Python for VEX has performance issues.
Python vs RobotC benchmark tests
If you really want OO event driven programming for high school level robotics then do FTC because it’s just switched to Java on Android devices. Android Development Studio is the programming environment and perhaps even NDK in the future.
The [mostly] linear programming model of Robot C is great for getting started and I seriously doubt Robomatter will want to add proper OO features like C++ and definitely not C#. C Pointers were a relatively recent addition 
Edit: Forgot to mention that instantiating objects during runtime in FLASH memory doesn’t fly and the VEX Cortex runs code from FLASH. EC++ is a better fit but not really a lively contender anymore.
This intrigues me as I never considered making a motor object and saying “motor.forward” was a “hurdle.”
I personally had a much more fun (not to mention easier time)programming this robot, and more recently this one, than i did this robot.
Java 8 with WPILib, Lejos, and RobotC respectively.
Having lots of C, C++ and Java experience here with a pretty big smattering in embedded systems, I have mixed feelings about OO and VEX.
While this is a robot competition, it’s all about the learning. Key thing about OO is it “abstracts” away the details. You call motor.forward and the robot moves forward. Which is nice if you know how “forward” works. But if you are the roboteer building “forward”, the details matter. For the most part we are teaching roboteers how to build “forward”. Maybe after the end of 4-7 years the OO would help them program slightly faster, but I’m thinking not so much.
Lets take Cody’s Holo code. Small, tight, easy to use, it’s a good abstraction. You can use it without understanding how the code works. Which is OK, but it also explains why people don’t get good results when they build oblong robots and they don’t get good results. They don’t understand how forward works.
I love the WPI library, it was great when FRC had the PIC controllers, we used it. Back then, it moved roboteers off the metal and up a layer. The nice thing about the PIC system was you could bang away at the lowest levels.
Now with the Cortex (and in FRC the cRio and RobotRio) there is a ton of stuff running down there that you can’t see or get to. Which is a shame, since it’s important to know how it really works down there, especially if you are trying to build a new crop of engineers that need to build the next generation of systems.
So I’m happy to see your robot code that consists of a single call to “Match.Win”, but first roboters need to understand port[1]=127;
^^ Absolutely agree with Foster. With 30+ years in the embedded industry, I like the kids being down at the lowest level. I can see leaving drivers and such to the college level for now, but I would hate to see any more abstraction than the C language for the HS level.
It’s not as simple as updating the compiler. RobotC is like an IDE/compiler/language/operating system all wrapped up into one.
It will require substantial work to make this happen.
Yes Java.language.system.name.getName(); is a very System.out.println(“Verbose”); language. That was a design choice made by Sun to keep the language “safe”.
I’m NOT a fan of Java for many reasons but you seem to be confusing “Object Oriented” for Java. Java is a subset of OO, OO is not the set of Java.
Java is… well I do like that because of the way they handle memory and exceptions, it can almost always tell you what went wrong. This thing, on this line at this time blew the crap up for this reason. Very Very VERY nice.
But one of the costs of this super organization / locked down programming language is a hit in readability (and writability).
STILL Java being an easier yet super powerful (I have a program that’s written in Java that’s made about $50k now), language is perfect for robotics. I would ABSOLUTELY recommend Java as a starter language, because C is effing hard. C is brutal, C doesn’t care if you do stupid things, it’ll happily execute your mistake and blow up in your face without a single care in the world. Add REAL HARDWARE to this, and you can see the problem.
Java is a great choice to program in for beginners, and if you look at Vex as a learning platform and realize that LOTS of people come into Vex programs every year having never written a single line of code, you can see why having this OPTION is good.
FIRST doesn’t do options. They change their mind every freaking season it seems these days and mandate a new system to use each time in both FTC and FRC.
Good question, I have one answer…
PORTABILITY. If you model the robot as a thing, and that thing is native to the language.
Robot.motor2.setSpeed(50);
People can build OBJECTS that DO THINGS that can BE PASSED AROUND and EASILY INCLUDED into OTHER PROJECTS and that would be AMAZING.
Imagine James’s motor library, included with 1-2 files. That’s it. No paste this crap here, include those things there, set up these macros over here. No, just drop the freaking thing in and start using it.
- Function pointers
- An actual freaking linker and EVERYTHING, AND I MEAN EVERYTHING needed for multiple source files
- Objects
- Exceptions
- Several STL classes, IE vector
- C++11 for each, auto, lambda functions, etc
There’s a lot to want.
Uh… no it’s not. OK it’s not a “functional language” which is not quite what you said.
It code organization / hierarchy, you don’t make something private to stop the hackers, you make it private to HIDE it so you don’t accidentally call it in the wrong place, or have to sift through it in a proper IDE that does code prediction (IE, XCode, Eclipse, Visual Studio, CodeBlocks, etc).
Here’s one, JOBS.
People who can code in OO languages GET JOBS.
Freaking crazy right?
What if we don’t like FTC? What it the Tetrix kit blows chunks and FIRST is too politically motivated for our tastes? What if we don’t want to have to listen to Dean Kamen to talk for an HOUR about freaking LED lightbulbs?
I could go on…
Ha. That’s a good one. Yeah tell the DoD who’s still using Fortran and Cobol that they’re wasting their time because the world only consists of Android and Android programming.
Get a freaking clue, the world will NEVER revolve around one programming language. If anything, everything in the current state of things suggests that we should expect MORE languages. Like Go (which I’m going to try to pick up one of these days).
Right so we teach the thousands of kids something that’s kind of like what the rest of the world uses but not really? That’s stupid. Let’s bake misconceptions about how C works into their heads, that’ll prep them for their college CS program.
It’s true, this might dumb certain things down. But it’s all still there, you still have to wire the joystick to the motors, in the way that you want. It’s just, maybe motors go from 1.0 to -1.0 and the base code converts that to 127 to -128 and that’s then converted into PWM pulses, etc. Who cares, the same ideas apply. They’re still writing robot code.
Options and documentation. If people read my code, and think about it, and asked, or whatever, they should be OK. Most people are, it’s the ones that don’t want to have to understand it that tend to have issues. This process hopefully begins to teach those people the value of thinking and modeling things before you stand bolting stuff together and plugging in wires.
It’s a good point, but the Vex system is an abstraction itself. It’s why we aren’t all over at RadioShack trying to find the right crystal so we can solder together our joystick made out of three potentiometers we soldiers onto a lead pipe we found in the dumpster.
No one said abstract away everything.
It’s a good exercise sure.
I have a “Hardware Software Interface” class right now where they gave us a dev board on wheels and told us to go.
No radio, no controller, no rechargeable battery pack, MPLab IDE, ANSI C, you set registers to make the motors go.
It’s ridiculous. You could NEVER, EVER, EVER do Vex/FIRST with this piece of crap.
Should CS majors like me go through that? Yes once ever, after taking a course in assembly. Just so we have an idea.
Should the 20,000 Vex HS students who have never written a line of code and have no idea what they want to do with their life but are giving this robotics thing a try to see how it goes have to do that? [words I can’t say here] no.
Are you trying to scare them away from CS? Because that’s how you scare them away.
Let them enjoy the experience, let them learn, and later the college degree programs can smash them into little bits and crush their dreams and ambitions all while taking their money and depriving them their proper place in society.
Vex should have, C, C++ and Java all as mainstream supported programming options to be used at the discretion of each and every team and it should all be free and open source and paid for and provided by IFI and open to be extended or forked by the community and it should be done in a way that any major IDE can bind to it, namely XCode, Visual Studio, and Eclipse.
That’s where I stand,
-Cody
Wow. So while I was writing my post Cody seems to have said most things I wanted to, so I’ll put most of that in the garbage.
I do have to take personal offense to one of your statements though Foster.
Again, if you HAD worked with the WPILibraries you would know that there is no “Match.win()” or equivalent. There is, however, a structure (in Java and C++ at least) that makes programming more complex things such as swerve drives and custom PID controlled subsystems more logical.
Again, if you actually HAD worked with the WPILibraries any reasonable amount you would know that creating a motor object and then saying “motor.setSpeed(0.67)” is in no way more abstracted than port[1]=127. In fact, it is less abstracted because students can actually get into the source if they want to and check out how it works. Sometimes teams even port the libraries to other languages (Python and more recently c#) “port[1]=127” is specific to RobotC, and if students wanted to change it, tough luck. In fact, the whole point of RobotC is seemingly to make robot programming simpler for younger students who plan to make a tank drive or maybe mecanum drive system move, and possibly some mechanism. I would(do) argue in fact that RobotC lowers the ceiling quite a bit when it comes to robot programming, especially compared to Java and C++.
I use the swerve drive as an example again since it’s the most complex mechanism (to program) that I have seen yet in VEX. With RobotC you would need to either hard code each module’s functionality, or pass a struct into a function every time you needed to make a call to an individual module.
With an OO language you can make your own single SwerveModule class, instantiate them as objects ("SwerveModule frontLeft = new SwerveModule(port1,port2,…)
and then make calls such as "frontLeft.setVector(x,y);
Even with mechanisms that a robot doesn’t have multiple of, there is little difference in how you would program it as you can choose to hard code it or make a class for it (depending on your needs).
Again, the point of object oriented programming isn’t to make anything easier, it’s to give more tools to programmers who DO want to do something beyond the standard drive and arm.
tl;dr
Another cody rant. Everyone move along, nothing to see here.
Have to admit, you summed it up quite well.
Slow clap
So programming language options and their pros and cons can be debated ad infinitum usually with some religious conviction thrown in to add fuel. With current VRC/VEX-U rules there’s nothing stopping anyone from programming the VEX Cortex with whatever they want provided it integrates properly with field control. It’s just not easy.
Missed the boat there I’m afraid. FTC5110 robot was about 50% VEX parts last season. In fact this season we can even use 393 motors in place of standard servos. The build options are so far beyond what FTC was a few years back. Any build system is permitted.
Yep, he did a good job, I agree with most of what he wrote
Umm, sorry that you are upset. My last touching of the WPILIB was circa 2007/2008 (See the WPILIB link here and the main documentation link here. If you look at it you’ll see that most of the code / ideas behind the code that is in WPILIB from then is now part of the mainstream RobotC / EasyC. So yes I have used it, but in a time long gone.
I understand that FRC has made great strides, you can program in Labview, C++, Python, Lua, etc. Which is just great since programming mentors come in all flavors, so having lots of choices is good.
The Match.win call was made tongue in cheek. We used to start off each season of programming by going “what would be in Match.win”. Sort of like having the Staples “Easy button” and saying “when you press that button, what happens.”
In 2009 the FRC team that I worked with started doing swerve drive programming. http://wiki.team1640.com/index.php?title=4-Wheel_Pivot_Drive They did their prototype on the cRio, I did a demo system in C for the VEX hardware. As I recall it wasn’t that hard, but that was also 4 laptops ago, I don’t have the source. Granted in the 2015 revision of their swerve drive it’s much better / much faster. And I think they are still using Labview.
And I get your point, but I’m still on the low end of the skill curve with most roboteers. I’d rather see the time spent on fixing the existing bugs, making the robot/driver communications better, put an end to the “lets upgrade all the firmware just before worlds”, etc.
I like the new RobotC features, I like Modkit. I’ve run into a number of programmers that already know Scratch, so having that as a programming language is good.
But if someone wants to do all the work that Cody has outlined that’s great also!
It’s not open and worse off IFI likes to change things last second, which seriously screws over people using 3rd party environments.
It’s not fun to spend thousands to go to worlds only to find out that the latest firmware update wrecked PROS and now your code is basically worthless.
I’ve seen FVC go to FTC, both using VEX. Then TETRIX came along (which was a disaster) with it’s crappy Bluetooth (which was a disaster) then they added VEX and Samantha? after I completely gave up on it.
I basically know nothing about FTC or FIRST atm. Sorry.
TY
IDK let’s see what the new Cortex brings.
To reiterate everything everybody else just said, but somewhat shorter:
I think you’re asking for RobotC++, which apparently does not exist. According to everybody else, anyway (I haven’t experimented with different programming paradigms to have an opinion), robotics is function-based, not object-based. If you insist on object-based robotics, there are plenty of other languages and libraries to suit your fancy (many based on Java).
That answer your question?
So the problem here was a late firmware update (seemingly related to VEXnet 2.0 “security”) became mandatory for participation at the event. There was communication about the update prior and although a shorter than ideal timeframe was given to teams (and seemly commercial toolset providers too) it wasn’t major if you were paying attention. Suggest posting an official Q&A around January asking what cortex master firmware versions will be acceptable at the 2016 world championship event.
You’ve been around long enough to know the original VEX platform wasn’t great either. Plastic geared servo motors and crystal control wasn’t cool either. Every robotics platform evolves (or alternatively just dies). VEX EDR is a good platform now but I was unimpressed in 2008/9. FTC is a competition that permits teams to take the best (some debate here) of whatever construction platform they want but base sets of a couple of platforms are offered to new team. Samantha has been replaced and it’s all Android based with WiFi direct for communications. Probably the best way to summarise VEX vs FTC now would be constrained vs extensible. Both approaches have merit of course.
A new processor and a couple of extra ports. No need to change something that’s been well designed to fit a particular application.