Preferred Programming Language

[MrTimKlein]

Originally Posted by jkelleyrtp

We have a bad history for long deploy and build times with Labview... What is a better language for quickly changing and using code?

To respond to this direct question - Python.

Last year our lead programmer was more or less on his own so he used robotpy. In one practice session, we were tuning the control/drive system. He ssh'd into the robot and pushed edited files onto the robot as the robot was driving! Python dynamically accepts the new code on the fly.

Driver: Programmer, the ramp time for acceleration is too slow.
Programmer: hmmm... ok
D: Can you fix it?
P: I just did.
D: Oh yeah, that's great.

Notes:
1. This year, we have a lot of rookie programmers, so we're using Java because that fits the AP Programming classes some are taking.
2. RobotPy is improving. Last year it was awesome as a prototyping language, but it was hard to maintain the discipline to keep the code well organized for a team effort.

[Ether]

Originally Posted by MrTimKlein

Driver: Programmer, the ramp time for acceleration is too slow.
Programmer: hmmm... ok
D: Can you fix it?
P: I just did.
D: Oh yeah, that's great.

Is that really a good example?

Can't you do pretty much the same thing in any language, including LabVIEW? Just keep all your constants in a configuration file that your code reads at start-up, or whenever the driver presses a designated button.

[virtuald]

Originally Posted by Ether

Is that really a good example?

Can't you do pretty much the same thing in any language, including LabVIEW? Just keep all your constants in a configuration file that your code reads at start-up, or whenever the driver presses a designated button.

That takes a bit more effort to setup, and isn't quite as flexible.

I think for small programs/changes, deploy times in Java are comparable to python deploy times on the RoboRIO, so it's not a huge advantage like it used to be on a cRio.

However, the one place that RobotPy excels in that C++/Java don't currently match is off-robot testing + low fidelity simulation support. I can verify with the simulator that many types of code changes are going to work *without a robot* much faster than Java/C++ teams can (though, there are some non-FRC projects that are getting closer to that now).

I've heard LabVIEW has some off-robot testing support, but I don't know anything about it.

[Ether]

Originally Posted by virtuald

That takes a bit more effort to setup, and isn't quite as flexible.

True, but somewhat off-topic.

The narrow point being made was that the implicit implication of the given example (to wit, that similar functionality is not available in any form when using LabVIEW) is not persuasive.

[Arhowk]

Originally Posted by Ether

True, but somewhat off-topic.

The narrow point being made was that the implicit implication of the given example (to wit, that similar functionality is not available in any form when using LabVIEW) is not persuasive.

To a certain degree. I do concur with your sediments that it is not only manageable but efficient to store a deal of information in a config file but the question becomes this- how much data is in the config file? Let's say that instead of asking for the ramp rate to be changed, you are asked to change what the controls are, a sequence in auton, exponential factor on the controls, etc. and if you end up making your entire robot via config file you end up just becoming an interpreted language, a la Python.

My actual opinion on the topic is to go with whatever a mentor or the student knows, but I just do not believe that maintaining the same speed that you have in Python with Labview is unrealistic.

[Greg McKaskle]

If you are going to tune a PID, you likely don't know the values when you write the code. But many will write the code with constants/guesses, build, deploy, test, and repeat many times. A better approach is to run the code in the debugger, using the run button, to get the code into memory, run, test, abort, edit, repeat. Better still is to recognize that these aren't constants, not yet anyway, but unknown values that you need to discover. So use network table variables or front panel values instead of constants. This lets you tweak values with no file compilation, file download, or interruption. Once finished, you can change the code to use constants, or make the values be default.

This also works with vision, by the way. The vision example runs on the laptop with file images. Tweaking color cutoffs and limits doesn't require code changes at all. Inserting code to try something new is just a few seconds and you are up and going again. Code running on the roboRIO works the same -- you can tweak panel values very easily. Changing code is quick once you are in the debugger. Ditto for making changes so you can see what is happening when code runs. Prints or displays or charts of values help you understand how the code works and allow you to test it more thoroughly. LV panels are particularly good at this, but network tables is quite nice as well.

And yes, interpreted languages can be even faster once you learn how to take advantage of them, but be careful about state data in already allocated objects.

The key is to learn how to use the tools. And use whatever works for you. And if you only know how to use a hammer, ...

I see teams using all of the languages well, and I see cases with each of them where the user is still making mistakes -- and learning. FRC is a good place to do this and to learn how to do this in a productive manner.

And yes, you can easily do config files and dynamic plug-ins in LV or C++ or Java if you know that you need this.

Greg McKaskle