Java vs Labview

[Alan Anderson]

Originally Posted by yash101

While you can use LabView outside of FRC, you can't write a regular computer application with it. Sorry, LV programmers, but you can't write games. Java and C++ are much more portable and don't require that you use a National Instruments product.

I maintain "regular computer applications" that were written in LabVIEW. They run on a generic Windows computer.

The LabVIEW Dashboard is a "regular computer application" that doesn't require National Instruments hardware in order to run.

I don't have the spare time to spend on writing games, but I don't see any reason I couldn't do it using LabVIEW.



I do not dispute that C++ and Java can be more "portable" and more "general purpose". But you're making unfair statements about LabVIEW that aren't really helping the discussion.

[yash101]

Originally Posted by Alan Anderson

I maintain "regular computer applications" that were written in LabVIEW. They run on a generic Windows computer.

The LabVIEW Dashboard is a "regular computer application" that doesn't require National Instruments hardware in order to run.

I don't have the spare time to spend on writing games, but I don't see any reason I couldn't do it using LabVIEW.



I do not dispute that C++ and Java can be more "portable" and more "general purpose". But you're making unfair statements about LabVIEW that aren't really helping the discussion.

Yeah. I guess I worded that kinda awkwardly to the point of confusion. While LabView is a nice language to have in your toolkit, I do not think it will be as useful as Java or C++ because they not only work everywhere, They are available to everyone, run on literally any main platform, UNIX/BSD/Linux, Windows, etc. Also, being able to write your own code can give you a different perspective of the big picture. Writing code yourself means that you will place small puzzle pieces until the jigsaw puzzle is complete and works perfectly. However, as FIRST is concerned, I, myself (this is my opinion) dislike JavaME because it has what I don't need but the stuff I need is hard to find.

Whether you want to use Java or Labview is based on personal preference, but I believe Java is the way to go if you have locked yourself down to those two choices. However, if you want to take into consideration, C/C++ may be more likeable on the cRIO because it is full, not Mobile Edition!

I, personally don't have too much LV experience. The first FRC program I wrote was in LV, only to find out that our team was using C++ (Silly me ). However, I did find the interface quite confusing.

I hope this helps

[Patrick Chiang]

Originally Posted by yash101

However, as FIRST is concerned, I, myself (this is my opinion) dislike JavaME because it has what I don't need but the stuff I need is hard to find.

I heard that the new roboRIO next year is going to run the regular Java.

[Jared]

Originally Posted by Arhowk

This only applies for programmers who are inexperienced with computer vision. If you have two programmers with, lets say 3-4 years of experience in java and labview independently, the Java built (if we had a third using C++ he'd trump them all) will be faster and more percise. Note that in WPILibJ, some vision functions were missing and need to be wrapped

I'm not sure I agree. NI Vision for LabVIEW has all the same features and functionality as the C++ version, and the Java version is just a wrapper for the C++ version. The VI's and classes are equivalent between the two. Our 2012 vision code was made with vision assistant for labview, and we used the same vision assistant algorithm for our 2013 java vision system, which worked exactly the same way as the 2012 one. All the vision VI's have classes that can be accessed in C++ and Java that have the same functionality.

[Arhowk]

Originally Posted by Joe Ross

Why do you say that?

Maybe the algorithms are the same, but the raw speed is alot faster. Knowing what algorithms you want to use and simply typing them out is alot faster than dragging them from a box. Imagine typing this response by dragging a list of 100 words from a box into the text area. Personally, I've walked around Kettering and Traverse City and I didn't see a single LV team using a targeting system they built themselves.

As far as C++ over Java, dealing with pointers when handling images is so much nicer than dealing with complex structures.

Originally Posted by Jared

I'm not sure I agree. NI Vision for LabVIEW has all the same features and functionality as the C++ version, and the Java version is just a wrapper for the C++ version. The VI's and classes are equivalent between the two. Our 2012 vision code was made with vision assistant for labview, and we used the same vision assistant algorithm for our 2013 java vision system, which worked exactly the same way as the 2012 one. All the vision VI's have classes that can be accessed in C++ and Java that have the same functionality.

The Java wrapping for the C++ library is incomplete. Take this snippet for example

    //============================================================================
    //  Morphology functions
    //============================================================================
    //IMAQ_FUNC int           IMAQ_STDCALL imaqConvexHull(Image* dest, Image* source, int connectivity8);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqDanielssonDistance(Image* dest, Image* source);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqFillHoles(Image* dest, const Image* source, int connectivity8);
    //IMAQ_FUNC CircleReport* IMAQ_STDCALL imaqFindCircles(Image* dest, Image* source, float minRadius, float maxRadius, int* numCircles);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqLabel2(Image* dest, Image* source, int connectivity8, int* particleCount);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqMorphology(Image* dest, Image* source, MorphologyMethod method, const StructuringElement* structuringElement);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqRejectBorder(Image* dest, Image* source, int connectivity8);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSegmentation(Image* dest, Image* source);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSeparation(Image* dest, Image* source, int erosions, const StructuringElement* structuringElement);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSimpleDistance(Image* dest, Image* source, const StructuringElement* structuringElement);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSizeFilter(Image* dest, Image* source, int connectivity8, int erosions, SizeType keepSize, const StructuringElement* structuringElement);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSkeleton(Image* dest, Image* source, SkeletonMethod method);
        
        
    /**
     * Convex hull operation
     */
    private static final BlockingFunction imaqConvexHullFn = NativeLibrary.getDefaultInstance().getBlockingFunction("imaqConvexHull");
    static { imaqConvexHullFn.setTaskExecutor(taskExecutor); }
    
    public static void convexHull(Pointer dest, Pointer source, int connectivity8) throws NIVisionException {
        assertCleanStatus(imaqConvexHullFn.call3(dest.address().toUWord().toPrimitive(),
                                                source.address().toUWord().toPrimitive(),
                                                connectivity8));
    }
    
    /**
     * size filter function
     */
    private static final BlockingFunction imaqSizeFilterFn = NativeLibrary.getDefaultInstance().getBlockingFunction("imaqSizeFilter");
    static { imaqSizeFilterFn.setTaskExecutor(taskExecutor); }
    
    public static void sizeFilter(Pointer dest, Pointer source, boolean connectivity8, int erosions, boolean keepLarger) throws NIVisionException {
        assertCleanStatus(imaqSizeFilterFn.call6(dest.address().toUWord().toPrimitive(),
                                                source.address().toUWord().toPrimitive(),
                                                connectivity8 ? 1 : 0, erosions, keepLarger ? 0 : 1, 0));


    }
    //============================================================================
    //  Logical functions
    //============================================================================
    //IMAQ_FUNC int IMAQ_STDCALL imaqAnd(Image* dest, const Image* sourceA, const Image* sourceB);

~12 functions are API'd out in comments but only two of them are wrapped. For example, ~week ago I needed to rewrite our VP because the LED's from the white line arent close enough together to form a perfect rectangle so I needed to dilate the binary image, but NIVision.java had no dilate wrap.

[Phalanx]

This is a debate that has been going on since we've had a choice of multiple languages to choose from. There really isn't any "right" or "wrong" choice or one being better than the other when it comes to this particular environment. It's matter of preference, skill sets and risk.

Let me share a little of my background so you may understand where I am coming from with my analysis for the choice of language. I'm the Mentor for my Team for both Software and Electronics. I've been a low level ASSEMBLY language programmer my entire career (33 yrs). I personally don't like any OOP(Object Oriented Programming) whether it be JAVA, C++ or Labview.

However, these are the choices we have to work with. So let me share my reasoning for recommending Labview.

#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.

Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.

#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistaken on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?

My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together.
Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

[SoftwareBug2.0]

Originally Posted by Phalanx

This is a debate that has been going on since we've had a choice of multiple languages to choose from. There really isn't any "right" or "wrong" choice or one being better than the other when it comes to this particular environment. It's matter of preference, skill sets and risk.

Let me share a little of my background so you may understand where I am coming from with my analysis for the choice of language. I'm the Mentor for my Team for both Software and Electronics. I've been a low level ASSEMBLY language programmer my entire career (33 yrs). I personally don't like any OOP(Object Oriented Programming) whether it be JAVA, C++ or Labview.

However, these are the choices we have to work with. So let me share my reasoning for recommending Labview.

#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.

Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.

#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistake on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?

My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together. Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

There is something to this analysis. If you want to "color inside the lines" and have the best vendor support you should use whatever the vendor would have the most incentive to make work right. And that is Labview.

But the quality of support offered does not need to be the deciding factor. Last year, my team used C++ and had some issues. This year we're still using C++ but we've basically junked WPIlib and gone our own way. And life is beautiful now.

[Greg McKaskle]

E/ Just noticed your signature. Of course you cant diss LV when you're getting paid to write it!

Oh, I diss it plenty, but then we go about trying to improve it.

The story about the professional C++ programmer trying to do image processing was simply a counter example. She was fast at typing code. She could add print statements super fast. But they weren't the correct tool. By the way, the probe in LV is where you right-click on a wire, choose probe, and a window opens to show you the live image at that point in the processing chain. The program keeps running, you can move the target, focus the camera, tweak the panel values, add an additional probe, etc. It isn't a language feature, but an IDE feature because NI and LV sell tools to do this sort of thing. We also used to sell a C/Basic IDE and compiler, but that is now simply a library that plugs into MSVC.

but my main point is that if you're promoting the usage of LV as a language "used in industry," it seems misleading to someone who has no idea of the difference between languages. If you're planning on going into the industry with skills in programming, there are more diverse work options when you're working with a more well-known language.

The "used in industry" or "most popular" judgements don't carry much weight with me either. I think it is better to identify a strategy for evaluating the tools on a realistic task. Evaluate, choose, use and become proficient.

New task? Rinse and repeat. There is overhead in learning a new tool, and overhead in using the wrong tool for the job. Find the balance.

The evaluation period can involve asking for popularity or opinions, but that only gets you so far. If we substitute music for robots, which instrument would you learn? Is it a waste of time to learn how to play an instrument that isn't popular? Learning musical notation, theory, and lingo are valuable whether you learn the violin or piano, but neither will work well in a marching band.

and wouldn't even dare writing in LV

I think the topic here is productivity, not typing speed. The ability to progress from a problem statement to a reliable solution is common to much of engineering, industry, and life. LV's initial adoption was actually in instrument control. Composing and parsing packed arbitrary streams from oscilloscopes, DMMs, signal generators, scales, power supplies, etc. Programs would then be written to setup, evaluate, and sequence the instruments to automate repetitive testing. It is not that different from what you posted. So others have dared, succeeded, and their code has been running for decades.

As for the performance of the vision code:
By design, NIVision is divided into an inner library of kernel functions and outer rings of language wrappers. 98% of the processing time will be spent in the same code regardless of which language you choose. There will be some differences in allocation overhead and your own logic as to which operations to perform.

Back to the original topic. My goal is to get teams to learn a bit more about programming, computers, measurements, and control. And that means everyone on the team, not just the programmers. I kinda hope that all the robots don't look the same. I kinda wish they were more automated and more autonomous. I don't work in marketing or sales, so this popularity contest isn't really that exciting to me. I see amazing robots programmed in all three languages. And all the time I get to see kids gain confidence as circumstances require that they become the team programmer at the event and make the robot do stuff they didn't think they knew how to do.

Greg McKaskle

[Chadfrom308]

We have tried C++ from 2012-2013 and we used labview in 2011 and this year.

From my experience (and I should note that I know Java, Labview, and a little of C (Enough to get my arduino running cool things)) C++ is harder to change and debug than labview. With labview, if we need to see why something isn't running right, we just probe and run in RAM and we can find the problem in minutes. C++ always seems to take longer for our team.

It is also easier to follow the flow in labview, especially if it isn't a tangle. C++ isn't something I could figure out.

And in terms of speed: Your teleop loop is running at 50ms. As long as it runs that speed, I dont see an issue. We even have periodic tasks running at 10ms for some loops.

TL;DR: Labview is easier for our team and we get the same performance.

[BitTwiddler]

Originally Posted by Greg McKaskle

Oh, I diss it plenty, but then we go about trying to improve it.

Greg McKaskle

Greg,

I'd like to make a suggestion that I think would make editing in LV a little easier.

You see I have this love/hate relationship with the tools pallet. Sometimes I find that the tool auto select feature is very handy and at other times it just drives me nuts. Usually what happens is when I'm simply trying to use the pointer tool to select a vi in order to move or copy it but then milliseconds before I click the mouse I get too close to a terminal and it changes to the wire spool. Now I have to stop what I was trying to do and reach over to the keyboard to hit the escape key to shut off the wiring function. This really disrupts the flow of the work and I hope none of the students hear the comments muttered under my breath. I know I can turn the automatic selection off but then I'm constantly having to manually change tools. There simply has to be a better way of getting the right tool at the right time.

Anyway, one feature I'd like to see is a magnifier/zoom tool to help these 65 year old eyes to better see exactly where the pointer is with respect to the object I'm trying to work on whether it be a vi, a structure or an item on the function pallet. That would really be helpful. Especially on the typical driver station laptop with its dinky 13" screen.

Thanks for your continued support to the teams.

Dave Tanguay

[Greg McKaskle]

I'm not a neutral party, but you asked for opinions.

For your team?
I honestly don't know enough about your team to be able to make a recommendation. So, I'd say that you should look at the capabilities and ambitions of your students and mentors. It is quite easy to go through tutorials and program your robot in each of the languages and make your decision based on which language provided more successful moments. That is an intentionally vague description since success means something different for each team. In some cases it is a better robot, in some a better learning opportunity. Some want the easy road and some want a challenge.

Also, a bit of background.
What is LabVIEW? LabVIEW is a relatively popular domain specific language. It is generally not free and not targeted to general computing domains. People who program with LabVIEW don't normally consider their job title to be "LabVIEW Programmer". They are instead a physicist, a mechanical engineer, a test engineer, a robotics engineer, etc. This is true of many professionals who use Java as well.

FLL, by the way, has exclusively used a version of LabVIEW since the beginning. ROBOLAB, NXT, and EV3 all ship with a version of LV for young kids. ROBOLAB was actually an iconic language written in LV, but wasn't really a LabVIEW equivalent language. Additionally, WeDo the jrFLL language was designed for even younger kids. It is a cross between Scratch and LV and was written in LV.

My actual advice?
It isn't which tool you choose. What matters is how you decide to approach the task of programming the robot. I am thrilled when students truly understand how their mechanisms work and how their code plays an integral role. If only it could happen more often.

Greg McKaskle

[Patrick Chiang]

We were trying to decide on whether to do the reverse thing for next year (switching from Java -> LV), so we did an informal survey of the teams at our regional this weekend. Surprisingly, out of 33 teams, 3 teams were using LV, 2 C++, and most of the rest Java. It blew my mind how popular Java has become since it was introduced less than a year before I came into FRC.

We have used both languages, and here is a comparison from my experience. IMO, they both have their merits but I personally prefer Java, so that's my bias.
Java:
+ Easier to find and solve fatal bugs. When program fails, Java tells you exactly where it does and what you need to do to solve that problem, sometimes even if you have never seen that error before. Code errors are easier to post onto Chief Delphi and stack overflow than screenshots of your LV wiring.
+ Faster deployment cycle. 52 seconds on ours to be exact, yes we counted. The 4 minute LV re-deployment on our laptop can be a major problem if we have to make even a minor change in the elimination rounds. LV is also a memory hog, which is ironic because a lot of traditional programmers consider Java a memory hog.
+ More intuitive for "software engineers". Lines of code and all. Taught in AP CS and college intro CS courses. I've heard that LV is more intuitive for EE people with its resemblance to circuit diagrams.
+ Source version control. In a good IDE, revert your code to what you had at 12:34 pm on May 6th, 2007. The "undo" function for LV is very limited, and you can't compare code differences on GitHub or something similar AFAIK.
+ Documentation. You can browse through Javadocs on a browser, whereas my experience with searching through LV functions is a nightmare-filled trip into a Windows Help style interface. In Java Netbeans, you can hit control+space and have it come up with every available function for a certain device, listed by contextual relevance.

LV:
+ Click and drag. How much easier does it get? If you know "line-based programming" before you learn LV though, it can be a nightmare.
+ Easier to tune specific functions (ex: PID). You can add a bunch of controls to the frontend without adding much code. Sometimes Java's Smart Dashboard just doesn't cut it.
+ More support at our FRC regionals. The control system advisor team is filled with NI people. For Java problems, be prepared to consult your neighboring Java gurus.
+ Easier to implement concurrency. You can easily do multiple things on the robot at the same time. On the other hand, you can easily do multiple things on the robot at the same time (which can be unintended). I heard some teams using the subsytems thing in Java have this pretty easy too, but have yet to try that.
+ Sample code. LV sample code for FRC beats out Java sample code hands down, especially in the vision department. It's been developed longer, and it just covers more.
+ Vision. LV is better for vision development hands down. The fastest way to develop vision code in Java is to do it in NI's software, then copy the filters back into Java. The simplicity of it all is really one of the best unmatched feature LV has over Java.

For a decision, as others have mentioned it may be important to consider what the mentors and team already know. However, both languages are easily learned, and the most important factor is by far the personalities of the programmers:

If you have hardcore software writing students who know every single shortcut key available on the computer by memory, think wiring and electrical are hardware problems, and have 4 different flavors of Linux installed on their home computer, making them do LabView is going to end up in disaster.
Actual quotes: "why the !#%$ are these being executed at the same time", "give me a break, I just copied and paste and now every wire is broken", "I hit the limit on the Undo button so we lost everything we did yesterday"

If you have hardcore electrical students who know what every number on their 8-function multimeter mean (yikes), can trace 6ft long PWM wires through spaces too small for adult hands, and dumpster dive for broken down lasers in their free time (all real life examples), Java may not be the best idea.
Actual quotes: "frigging red syntax errors everywhere", "why did it only work the first time", and my personal favorite "I think we fried Java"

[wt200999]

Originally Posted by Patrick Chiang

LV:
+ Click and drag. How much easier does it get? If you know "line-based programming" before you learn LV though, it can be a nightmare.

LabVIEW tends to get a bad rap for its graphical nature. When the cRIO was first introduced to FRC in 2009 I saw the choice of LabVIEW and C++ the same as I saw the choice between C and EasyC on the old controller. I told myself that 'I'm too good' for drag and drop. It turned out there is a lot more to it than that. LabVIEW has some powerful constructs which do take time to master, and the front panel features make tuning/debugging incredibly quick and easy.

I would actually say that LabVIEW has a steeper learning curve than its text based counter parts in many ways. As in any langauge it is very easy to make bad LabVIEW code. It seems that a lot of people stop learning the language when they have some of the basics down, and we end up seeing massive VIs of untamed wires and flat sequences which become hard/impossible to debug and maintain.

In the end I agree about using the language that you have a mentor/student with a good understanding in. When you have an instructor with a good understanding of how things work, it is easier to teach it, and more importantly prevent big design mistakes early on.

Originally Posted by Arhowk

Maybe the algorithms are the same, but the raw speed is alot faster.

I would be interested in seeing the data behind this claim, or some type of metric. Do you have a side by side comparison of the raw speed for various algorithms? I would assume all three languages would be nearly identical since they all call the same functions. Honestly I would expect Java to be the slowest since it has to run on the JVM level compared to C++/LabVIEW which are both compiled to assembly with many optimizations along the way.

Originally Posted by Arhowk

Knowing what algorithms you want to use and simply typing them out is alot faster than dragging them from a box. Imagine typing this response by dragging a list of 100 words from a box into the text area.

Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.

Originally Posted by Arhowk

Personally, I've walked around Kettering and Traverse City and I didn't see a single LV team using a targeting system they built themselves.

Its all about iterative design. In reality nobody is building a vision system 'themselves'. All of the functions and ideas we are using are built from years of industry and academic research as well as learning from previous years.

Should every team be reinventing the wheel each year? Most teams use the same type of algorithm, which is what the targeting system has been designed for. The example vision code is a good starting point and having a working vision algorithm is a big accomplishment for many teams. We don't all have to dive into OpenCV on a BeagleBone to track the retro reflective tape.

[Arhowk]

Originally Posted by wt200999

I would be interested in seeing the data behind this claim, or some type of metric. Do you have a side by side comparison of the raw speed for various algorithms? I would assume all three languages would be nearly identical since they all call the same functions. Honestly I would expect Java to be the slowest since it has to run on the JVM level compared to C++/LabVIEW which are both compiled to assembly with many optimizations along the way.

That line was meant for writing speed, not execution speed.

Although, I know I have 3 CRIOs on hand to do vision processing, though I don't have any of the development software for LV. I'd be interested to see a speed test too. Guessing the fact that its Java ME and not SE, the order would probably be Labview > C++ > Java (but the times will be remarkably similar, as the C++ and Java vision libraries simply uproot to the LV libraries)

Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.

BinaryImage dilateImage = NIVision.dilate(threshholdImage, 3);

theres only so many functions to use.

Of course, this is an opinionated topic. Even so, I can't imagine doing something like our team's 2014 code in LV. We have 5011* lines spread along 31* files and selecting each of their functions individually is a pain, not to mention that our auton system is a vectorized system of quadruple key-value pairs generated from binary information read from files on the cRIO.

Should every team be reinventing the wheel each year? Most teams use the same type of algorithm, which is what the targeting system has been designed for. The example vision code is a good starting point and having a working vision algorithm is a big accomplishment for many teams. We don't all have to dive into OpenCV on a BeagleBone to track the retro reflective tape.

Petoskey Paladins won an award for an OpenCV Raspberry PI :O no idea what a BeagleBone is

I agree that not every team should be doing what the Paladins did but spoonfeeding the entire code to the programmer doesn't really teach him anything.

E/ Here's a snippet of code that took me a half hour to write in Java (few more to tune) and wouldn't even dare writing in LV

        public void execute()
        {
            if(!init){
                loopTimer.start();
                loopTimer.reset();
                init = true;
            }
            if(finished) return;
            SmartDashboard.putNumber("loopTimer", loopTimer.get());
            int numOfRunningCommands = 0; //Used to make sure that it still has commands to be run and doesn't loop forever
            long nestedIfs = 0;
            long nestedIfFalse = 0;
            long nestedIfTrue = 0;
            long nestedPauseStop = 0;
            long nestedPause = 0;
            
            Enumeration runningCommandsIteration = storageVector.elements(); //List of objects in the storage hashtable
            Structure nextCommand; //Temporary storage for the next object in the hash
            while(runningCommandsIteration.hasMoreElements()){ 
                nextCommand = (Structure)(runningCommandsIteration.nextElement()); //Retrieves the next element Object and typecasts it to TimedCommnad
                
                if(nextCommand.conditionalStatus != 0)
                {
                    Conditional cond = (Conditional)nextCommand.command;
                    switch(nextCommand.conditionalStatus)
                    {
                        case Structure.conditionalPause:
                            nestedPause++;
                            break;
                            
                        case Structure.conditionalEndPause:
                            if(nestedPauseStop >> (nestedPause - 1) == 1)
                            {
                                loopTimer.stop();
                                loopTimerStopped = true;
                                return;
                            }else{
                                nestedPause--;
                                nestedPauseStop = nestedPauseStop &~ (1 << nestedPause);
                                if(loopTimerStopped && nestedPauseStop == 0)
                                {
                                    loopTimer.start();
                                    loopTimerStopped = false;
                                }
                            }
                            break;
                            
                        case Structure.conditionalWhile:
                            if(nestedIfFalse == 0 //No nested if false?
                                    && !nextCommand.finished //Not finished?
                                    && nextCommand.start < loopTimer.get()  //Time is proper?
                                    && !cond.shouldRun(file)){ //Run the command. If it pauses, than pause everything else.
                                numOfRunningCommands++;
                                nestedPauseStop = nestedPauseStop | (1 << (nestedPause-1));
                            }else if(!nextCommand.finished && //Else if it should've run but didnt the command returned false
                                    nextCommand.start < loopTimer.get()){ //so disable the while.
                                
                                nextCommand.finished = true;
                            }else{
                            }
                            break;
                        case Structure.conditionalIf:
                            if(!cond.shouldRun(file))
                            {
                                nestedIfFalse = nestedIfFalse | (1 << nestedIfs);
                            }else{
                                nestedIfTrue = nestedIfTrue | (1 << nestedIfs);
                            }
                            
                            nestedIfs++;
                            break;
                            
                        case Structure.conditionalEndIf:
                            nestedIfFalse = nestedIfFalse &~ (1 << (nestedIfs - 1)); //removes the bit from nestedIfFalse
                            nestedIfTrue = nestedIfTrue &~ (1 << (nestedIfs - 1));
                            
                            nestedIfs--;
                            break;
                            
                        case Structure.conditionalElse:
                            /*if(nestedIfFalse >> (nestedIfs - 1) == 1)
                            {
                                nestedIfFalse = nestedIfFalse &~ (1 << (nestedIfs - 1));
                            }else{
                                nestedIfFalse = nestedIfFalse | (1 << (nestedIfs-1));
                            }*/
                            break;
                            
                        case Structure.conditionalElseIf:
                            if(nestedIfTrue >> (nestedIfs - 1) == 0){ ///making sure that another else wasn't returned.
                                if(nestedIfFalse >> (nestedIfs - 1) == 1)
                                {
                                    if(cond.shouldRun(file))
                                    {
                                        nestedIfFalse = nestedIfFalse &~ (1 << (nestedIfs - 1));
                                        nestedIfTrue = nestedIfTrue | (1 << (nestedIfs - 1));
                                    }
                                }else if(nestedIfFalse >> (nestedIfs - 1) == 0){
                                    nestedIfFalse = nestedIfFalse | (1 << (nestedIfs-1));
                                }
                            }else{
                                nestedIfFalse = nestedIfFalse | (1 << (nestedIfs-1));
                            }
                            
                            break;
                            
                        default:
                            System.out.println("[AUTON] Conditional type passed that does not exist. O.O");
                    }
                    
                }else if(nestedIfFalse == 0 //no false if statements
                        && loopTimer.get() < nextCommand.timeout + nextCommand.start){ //within time frame
                    
                    if(loopTimer.get() > nextCommand.start){ //if the command should be running,
                        if(nextCommand.command == null)
                        {
                            System.out.println("[AUTON] Null Command Passed! Woops. How'd that happen? Report to Jake");
                        }else{
                            nextCommand.command.execute(file);
                            numOfRunningCommands += 1;
                        }
                        nextCommand.hasStarted = true;
                    }else{ //else, the command would be running but it hasn't met its start point so the tcg should still run because it hasnt run that command yet
                        numOfRunningCommands += 1;
                    }
                    
                }else if(nextCommand.hasStarted && !nextCommand.hasRunFinale && nextCommand.timeout + nextCommand.start < loopTimer.get()){
                    nextCommand.hasRunFinale = true;
                    if(nextCommand.command != null)
                    {
                        nextCommand.command.end();
                    }
                }
                    
            }
            if(numOfRunningCommands == 0)
            {
                finished = true; //If theres no commands left, exit
            }
        }

E/ Just noticed your signature. Of course you cant diss LV when you're getting paid to write it!

[Greg McKaskle]

Imagine typing this response by dragging a list of 100 words from a box into the text area.

I can imagine it, but that isn't really the same task. Procedural languages require you to name variables. Wires are not named. For loops and case statements are one drag for numerous lines of code. The editors are different. The languages are different.

The first year of FRC I watched a C++ programmer with print statements streaming by at a million miles per hour. I started helping and they kept adding print statements and waving the target around. We eventually hooked the camera up to LabVIEW, probed the image, saw that the camera wasn't focused, that the C++ programmer was holding the target way too close to the camera, and that they needed to modify the color threshold.

The tools are different and that is a good thing. FRC is all about exploring and learning new approaches. I don't use LV for all projects and I don't use C/C++ for all projects. Make your own choice, but please don't misrepresent.

Greg McKaskle