Seeking advice for rookie programming

[MuskieProgramme]

Hello! I'm a member of the newly created FRC Team 6420, and am looking for advice on programming. I've been the main programmer for FTC for the past two years, using Android Studio. You can view my work for this year here.

I'm familiar with Java & IntelliJ, but our main mentor is recommending we use C++ because teams in the area use it and we will be able to get help. I have some limited experience with C++, and no experience with eclipse. I'm aware the Labview exists, but I really don't like any sort of visual programming. It seems exceedingly clunky to me.

So. What would you recommend? Are there online tutorials for FRC programming? How is it similar / different to FTC programming? Anything else you'd like to add?

Thanks!

[nickbrickmaster]

Welcome to FRC!

WPILIB ScreenStepsLive is the definitive FRC programming tutorial.

If you have experience with Java, I would personally recommend using that. Changing IDEs is a lot easier than changing languages. I've also seen some people using IntelliJ and Gradle to do robot code.

If you know Python (or don't, it's easy to learn!), that's also an option, using robotpy.

[msonnier]

There may be other opinions, but I would recommend staying with what you know -- in this case Java. The "pain" of learning C++ just isn't worth it. (And this coming from a mentor who knew C++ and had much more C++ experience prior to starting this mentor gig and having to learn Java). Also, if there continue to be FTC teams that you are drawing students from, you have the advantage of having incoming programming team candidates with Java expertise.

I mentor both FRC (2992) and FTC (8991 and 10337) teams for programming using Java, and we have found the advantage of having incoming FRC students with FTC Java experience to be a great jump starter.

I recommend you check out https://wpilib.screenstepslive.com/s/4485 which is the documentation for the controls and programming from last year. AFAIK the 2017 version is not yet posted (though there is some 2017 beta info at that same site).

Whether you use C++ or Java, you will likely be using Eclipse. It's not that different from Android Studio. Installation instructions at the above website are reasonably easy to follow. Its actually a bit easier to setup for Java than C++.

The API tutorial for Java is pretty decent. You will see a ton of similarity w/ FTC API for accessing hardware and driver station. The IterativeRobot base class is very similar to the OpMode base class for FTC.

While it may seem a bit more complex at first, I strongly recommend you look into the "Command Based" programming model. The "Robot Builder" tool that comes w/ the API is a good way to jump start into Command Based programming. My first year as a mentor, the team had lost all of its programming resources so we were essentially programming rookies. We switched that year from C++ to Java and started off doing IterativeRobot but switched partway through build season to Command Based as it makes Autonomous programming much easier (it enables a base class called CommandGroup similar to LinearOpMode from FTC). Command Based also allows easy multitasking for your robot, with each "subsystem" able to operate fairly independently, making your code easier to implement and troubleshoot.

Finally, make sure you take a look at the SmartDashboard tool and API. This is similar to (but much more powerful than) the Telemetry functions in FTC.

I took a quick look at your FTC code, and it looks good. I don't expect you to have any issues making the FRC transition.

Good luck and have fun
Mike

[euhlmann]

Disclaimer: my team is switching from C++ to Java this year

C++
Pros

• Fast (It's native)
• It allows you to do almost anything. For example, casting and copying data in ways Java doesn't allow

Cons

• It allows you to do almost anything. Which is bad sometimes (use smart pointers!)
• For FRC specifically, the compiler is unusually slow. Large projects can take several minutes to build
• To display errors, Eclipse basically parses compiler output. It sometimes doesn't work too well
• Exceptions aren't as sophisticated as in Java. Also I often think the creators of the standard library put making it beautiful C++ before making it actually usable to new programmers. It's beautiful C++ that I don't entirely understand. Luckily in FRC, you don't need to use the standard library a lot
• Debugging in eclipse is basically a GUI wrapper over GDB (a console program). It can be problematic sometimes

Java
Pros:

• Safer. It's more restrictive, but it has the advantage that the compiler will catch most problems for you (as opposed to C++ where you'll just get a random segfault)
• Simple standard library. And you can actually understand the source of most of it, unlike STL which is basically line noise that happens to be valid C++
• Less file spam. No need for header files, or dealing with cyclic dependencies since the compiler handles it all for you
• Compiling is fully integrated into Eclipse. It compiles as you write, and gives you instant feedback on errors. In C++, you have to explicitly use the build button before it displays most errors.
• Debugging is fully integrated into Eclipse, and it's awesome (SE even supports limited code hotswapping. I'm going to test if hotswapping works on ME at some point)

Cons:

• May be slower (it's interpreted / JIT compiled)
• It's more restrictive than C++, so some C++ may be necessary for performance hacks (eg, link in C++ pros above)

[MamaSpoldi]

Disclaimer/Background: I'm a software engineer with 30+ years experience programming in C and C++, but I know a fair amount of Java as well. I have been working with our FRC team doing C++ code for 11 years. I have no experience with FTC code.

I'm not going to tell you what you should choose, but here are are few points to consider:

• The syntax of C++ and Java is VERY similar. So if you are familiar with Java, then C++ is not a huge leap.
• All the points mentioned above by Erik comparing C++ and Java are pretty valid. I would especially emphasize his points that:

1. Java is interpreted and therefore does not run as fast as C++. This can be a significant issue depending on what you hope to do.
2. Some of the error messages are pretty poor but if you have local support (or CD support) it is not usually a big issue.
3. The C++ STL is clunky, but we don't use that in our robot code so this is kind of irrelevant (at least for us).

• If you already know Java, C++ is the next step in your learning process. I think the biggest mindset change is that C++ is pass by value and Java is pass by reference. This is related to pointers (indirectly) and it basically means that you cannot modify a parameter to a C++ routine unless you pass a pointer to the value.
• Whatever language you choose, you will have lots of resources available including the ScreenStepsLive mentioned before and mentors of local teams and here on CD.
• I personally am not a fan of the CommandBasedRobot base class, it requires a lot of infrastructure and relies a lot on tools like the robotBuilder instead of using more common coding principles. Our team uses SampleRobot (formerly SimpleRobot). The architecture that we use makes it very simple to use the same mechanism classes and functionality for teleop and autonomous. If you are interested, here is a link to our code from last year (https://sourceforge.net/projects/frc-team230-2016/). We would be happy to answer any questions you have. In addition I would be happy to send you a copy of the slides I use for the C++ programming "class" that I teach for our students who are interested in programming. I provides a fair overview of into our code architecture.
• Regardless of your choice there will be times you think it might have been easier if you had made a different choice. Resist the urge to second guess yourself... BOTH ARE GOOD CHOICES.

Good luck! Remember to reach out if you need help. We are all in this together.

Save
Save
Save
Save

[virtuald]

I agree with much of what has been said in this thread, but...

Originally Posted by MamaSpoldi

Java is interpreted and therefore does not run as fast as C++. This can be a significant issue depending on what you hope to do.

For 99.9% of FRC teams, this doesn't matter. Python is even slower than Java and you can build a high performance robot using it. If you find that you are running into speed issues solely because you're using Java, you're almost certainly doing something wrong and should reevaluate your approach.

[euhlmann]

Originally Posted by MamaSpoldi

the C++ STL is clunky, but we don't use that in our robot code so this is kind of irrelevant.

I did use it last season. It's not irrelevant if you plan on making a complex program, unless you want to roll your own lists/maps/etc

Originally Posted by MamaSpoldi

If you already know Java, C++ is the next step in your learning process. I think the biggest mindset change is that C++ is pass by value and Java is pass by reference. This is related to pointers (indirectly) and it basically means that you cannot modify a parameter to a C++ routine unless you pass a pointer to the value.

Keep in mind that to someone who doesn't already know C++, this statement may be confusing.
Basically, the general idea is that C++ provides several ways to store, transfer, and access data while in Java there's only one way. You don't really need to know this unless you plan on learning C++

[FlamingSpork]

My team has used C++ for the past several years, but we are switching to Java this year because it's the language our school teaches in a programming course and we're sick of pointers.

I've used both C++ and Java, and I'd say that Java is much easier to work with. Switching from Java to C++ might seem reasonably easy, but there's a bunch of quirks you will need to learn. Nothing is different with syntax, but, as has been mentioned on this thread, the ways data is stored is rather different.

[GeeTwo]

In your situation, I'll unhesitatingly recommend java. Unless you already know c++ quite well, or are working from a considerable existing code base, or are doing something requiring really tight optimization, the "advantages" of C++ over java are really just more rope to hang yourself. It sounds like none of these apply in your situation. Outside of assembler, about the only thing which can cause as much confusion as a pointer arithmetic error with so little effort on the part of the programmer is an abused FORTRAN common block, and for pretty much the same reason.

[BrianAtlanta]

Another thing to consider when selecting a language, sustainability. We have some good programmers, and they were thinking about switching from Java to C++. There were some robotics stuff that they wanted to try, that might require a faster processing loop than WPI-Lib. So we talked about it. Our high school teaches Java, so if they wanted to switch to another language, they had to be able to develop a program to teach future programmers C++. They then decide that they would stay in Java, since it fits with what the school teaches.

So TLDR, pick a language that's best for the club and can live one

[BenBernard]

There are lots of good arguments on both sides in this thread, but I think that sticking with what your team as a whole knows best will serve you better. When push comes to shove, your team needs to be able to sort out its own code issues--your neighboring teams won't be there in your pit when the inevitable competition-day bugs arise!

I'd also argue that you're more likely to get urgent programming help here on these forums than from neighboring teams--there's simply a MUCH larger pool to draw on here! Think about the number of responses you've received to this question here in less than 12 hours!

Either way you go--good luck! It's a blast!

[SoftwareBug2.0]

Originally Posted by BenBernard

There are lots of good arguments on both sides in this thread, but I think that sticking with what your team as a whole knows best will serve you better. When push comes to shove, your team needs to be able to sort out its own code issues--your neighboring teams won't be there in your pit when the inevitable competition-day bugs arise!

I'd also argue that you're more likely to get urgent programming help here on these forums than from neighboring teams--there's simply a MUCH larger pool to draw on here! Think about the number of responses you've received to this question here in less than 12 hours!

Either way you go--good luck! It's a blast!

Actually, I do end up in other teams pits from time to time when they have code issues. I suppose that how willing other teams are to help may depend on your region. PNW (where I am) tends to be pretty friendly and I would expect that the midwest (where the OP is) would be as well.

One thing that I will note is that the teams that need help are disproportionately using languages other than C++. This suggests to me that teams are more conservative about moving to it than they need to be.

[Oblarg]

Originally Posted by MamaSpoldi

[*]If you already know Java, C++ is the next step in your learning process. I think the biggest mindset change is that C++ is pass by value and Java is pass by reference. This is related to pointers (indirectly) and it basically means that you cannot modify a parameter to a C++ routine unless you pass a pointer to the value.

This is not quite right - java is actually pass-by-value; when passing objects it passes the value of the reference (not the reference itself!). If you reassign a passed parameter in a java subroutine, it will not change anything outside of the subroutine.

(I've heard some object to this by arguing that it is indeed pass-by-reference, but variable assignment in java is best interpreted as name-binding. But this is not how the language specification describes it.)

[SoftwareBug2.0]

Originally Posted by Oblarg

This is not quite right - java is actually pass-by-value; when passing objects it passes the value of the reference (not the reference itself!). If you reassign a passed parameter in a java subroutine, it will not change anything outside of the subroutine.

(I've heard some object to this by arguing that it is indeed pass-by-reference, but variable assignment in java is best interpreted as name-binding. But this is not how the language specification describes it.)

Yeah, I think every Java fan I've ever talked to has insisted that the language is pass by value but the fact that for objects you can only ever have mutable references to them means that all the benefits you'd expect to get with pass by value semantics are effectively destroyed.

[phurley67]

Hint: Programmers like to argue about their favorite languages :-)

On our team our mentors (myself included) prefer C++ as a language; however, our FTC feeder system (in Michigan FTC is generally a middle school program) is now in Java and our high school AP Programming class is taught in Java. Based primarily on these two factors we (the mentors) supported the idea of using Java even though it is not our personal favorite programming language. Prior to that we had been using LabVIEW which, while I will admit I never grew to love, I least felt I had a pretty good understanding -- but we never found it easy to create work flow that supported 10+ programmers without more discipline than we were able to maintain with high school students during build.

I would suggest writing up a pro and con for each language. Keep in mind your primary goals -- different teams can easily have different goals. For us it was choosing a language which will allow us to engage the most students (we have a large programming sub-group) and field a competitive robot. Other teams may want to prioritize the learning of only one or two programmers and they are personally going to get more out of using C++ or Python -- there is no one perfect answer.