Java vs Labview
 

My team is thinking about switching our robot code from Labview to Java. For the past two seasons, we have used Labview, and we have found it very appealing because of its ease of use. So far, we have used the navX gyro, encoders, limit switches, and PID control for our shooter and drivetrain. Another reason we have enjoyed using Labview over past seasons is that is very easy to learn and allows programmers to quickly modify and make changes to code. Over the summer, we want to experiment with vision processing and motion profiling. I should also mention that we have a small programming team, only 2-3 members.

What are the major advantages of using Java over Labview?
Does it take longer to program the same robot in Java than it would take within Labview?

Re: Java vs Labview
 

I have never used Labview so this is probably kinda biased. But being the only programmer (yes the only one) on our team I think java works perfectly.

I use command based, and it has worked perfectly for me. I am quite experienced with java though so it may have been easier for me, but its not to heard to learn. We have NavX MXP on the roborio, and it is super easy to use once you add the right plugins, we also use limit switches easily. I haven't personally used pid or encoders just because we haven't ever had to. The main advantage for me is that I know the code absolutely inside out, so if the driver all of a sudden screams at me from half way across the pits to add in a button that would make it spin around in circles for 19 seconds or some other random thing, I could add that in under a few minutes, command based also helps with this. I tried to add vision processing this year, but it totally didn't work for different reasons, though it isn't that hard to do. We also used mecanum wheels this year fyi.

Heres the github of my code: https://github.com/FRC-5752/FRC-5752-2016

Re: Java vs Labview
 

I'll offer a biased point of view from the LabVIEW side. From what I have done, implementing vision is easy in LabVIEW. In addition to that, I would suggest staying with LV because of how simple it is to understand. It is easy to find mistakes and fix them, and just as easy to add extra controls, etc. as in java.

The main argument for LV is that it is capable of doing what C++ and Java are, but in a more easy-to-understand and new-to-programming-teachable way. Think about new members.

Our programming team on 4557 also consists of 2-3 members.

Re: Java vs Labview
 

We use C++, but are thinking of switching to Java for the following reasons:

1) AP Computer Science is Java based. Some kids will come in with Java knowledge. I am sure there are great things about Labview. But, if you don't have to teach the students the basics, you are that much ahead.

2) Mentors don't know Labview. It is easier to get a Mentor involved (and productively supervising the students) if they don't have to learn something new.

Re: Java vs Labview
 

Yes, 2 of our students have taken APCS.

I was also wondering if there is anything that is significantly easier to program in Java, or that Labview cannot accomplish functionality wise.

Re: Java vs Labview
 

I don't know if LabView can achieve this, but this year we used Java to call a script on the roboRIO via command line to initialize mjpg-streamer to stream the cam to the Driver Station.

There are other reasons to use Java, too. I would argue better support with WPILIB being open sourced and the ability to use outside libraries which can aid in easier implementations for vision or motion profiling,

Re: Java vs Labview
 

Labview most certainly can stream the camera to the dashboard. In fact, our drivers relied on it heavily this year.

I would certainly argue with that. Our team's programming mentor knew LabVIEW prior to joining our team.

Re: Java vs Labview
 

For what its worth, we would definitely help you guys with the switch to Java if thats what yo u decide to do. We have been using Java for a couple of years now and really like it. Our programming team would be glad to head across the street and hold some sessions with your programming guys. Or you could come to the programming sessions we hold in the Fall.

It would also give me an excuse to get a better look at your robot :D

Re: Java vs Labview
 

Java will give you a faster compile than LabView (20 s as compared to 1 min). Command Based programing allows more distribution among programmers, and even when its just a single programmer, RobotBuilder simplifies things. There is no registration code for Eclipse as there is for LabView, so at home set up is easier for sans-cd computers.

Re: Java vs Labview
 

It really depends on your taste. Java is object oriented and LabVIEW is data-flow paradigm.

In LabVIEW, data is generated by predefined functions based on the inputs of the function, or by pulling data from some other input. This data is sent along data paths and operated on by other functions. The data is then either stored or sent out. The advantages of this is that it is a simple graphical programming interface, and that data processing is easy. The disadvantage is that routines and objects are more difficult to handle in state machines, e.x building a complex autonomous from simpler behaviors is more difficult than in Java.

In Java, data is either given by the programmer as a type or is pulled from some other input. This data is treated as an object, and is therefore defaultly stored as an object. Retrieving and handling this data is more difficult as a method is typically require to get or give data. Building routines and simple behavior to create complex behavior is easier in Java, at least in my opinion and having used both languages. It is a text based program as well, which means your data flow can be a bit harder to track.

I suggest you read more about each type of language as I have highly simplified the two paradigms and only overviewed them. Having used both languages independently and alongside each other, I can say I personally prefer Java and I assure you if you know what you are doing it does not take much longer to program a robot in Java, and it is easier to collaborate and set up multiple development environments in Java than in LabVIEW.

Re: Java vs Labview
 

Having used both, my experience is that LABVIEW makes it a lot easier to write functional robot code. However, as your code gets more advanced and complex, it becomes a lot harder to keep your code from becoming spaghetti. Java is much more suited to larger projects.

Overall, based on what you said about your programming team, I think you could go either way. Java is going to require a big commitment in the offseason, but can be a worthwhile investment because it makes it easier for your team to grow. However, it is certainly possible to do motion profiling in LabVIEW, it is just harder to code it well.

YMMV. Another huge factor that I have seen come in to play is that people who already know object-oriented, text based programming are much more resistant to LabVIEW.

EDIT: I should also mention that this is a heavy simplification of your decision, and there are a lot more factors that can come in to play.

Re: Java vs Labview
 

The FIRST offseason is a great place to learn new tools and to learn how to better use familiar tools.

If you think you have time. I'd suggest you take your robot that should be pretty stable, and reprogram it from scratch -- as a group or in small groups. I think you'll find that it goes smoother the second time, no matter what language you use, and you can identify some of the info that makes this possible. This is also a great time to delegate some stuff and let new students learn the ropes.

Use this as a time to learn Java and the framework. You may also find it useful when you find something confusing or new to look back at LV and look for it there.

If you really like the command-based programming, you can also look at using the new LV command & control framework.

If you are familiar with both, then when next year's game rolls around, you will be well prepared to use either language. You will also be able to help that many more teams or students if they have issues.

Greg McKaskle

Re: Java vs Labview
 

Oh. Forgot to add that to invoke a command,you use the System Exec node. This is in fact how the Java and C++ apps are launched -- from LV using system exec.

So if you wanna launch another process, that is all it takes. But of course communicating to it is another matter, which is why it is much more common to simply have a parallel loop in LV that does the other thing instead of parallel processes doing it. There are cases for another process, but for LV FRC, I'd generally go for another loop.

Greg McKaskle

Re: Java vs Labview
 

This is not a dig against LabView but:
There is no LabView at my financial institution.

You walk out of high school knowing Java/Python with some practice you could write software worth huge sums of money to support your future.

You walk out of high school knowing C++ as an embedded engineer or OS contributor you are in good shape. If you easily exchange that knowledge for C# you broaden your future more on the .NET bandwagon.

I can certainly see the value in LabView for engineering and automation professionally and everywhere I have used it was for that purpose.

So teach what you will, LabView can run your robot for FRC, but as far as I am concerned LabView is not positioned to be a core skillset for most people in the market. Now that I have my own robots: I fully intend to increasingly improve my LabView skills to make me a better CSA and Mentor. It may be a FIRST thing but you guys are the lot I am in with so it is a good investment.

FRC11 uses Java and from that experience, even before Mount Olive High School seriously taught programming as they do now, we sent students places after graduation with those skills as part of their toolbox.

Re: Java vs Labview
 

The most important factor in selecting the language used by your team is the language your mentor knows.

You can build an effective, winning robot program in any of the three supported languages. If you have great mentor support, you can even use Python.

I personally would find Labview skill a plus when interviewing CSci grads. It provides a different experience than the curly brace languages that everyone learns.

Re: Java vs Labview
 

LabVIEW for us is crazy easy to prototype ideas in and then graph outputs so we can view them. Graphs mean data and data provides answers to questions and allows us to iterate quickly with code.

We've talked about switching to C/C++ but just don't think it is worth it because we would lose a lot of that ability.

That being said, listen to what Greg said above and if you're going to do it then do it in the offseason or don't do it.

Also of note, we have an entire team dedicated to vision processing and programming in OpenCV/C so we use that as an outlet for those programmers who think LabVIEW is too simplistic for them to learn... though a lot of them come back around to after realizing how powerful it is.

Re: Java vs Labview
 

LabVIEW isn't an obviously useful skill if you intend to pursue a career in programming. But if you just end up needing to do a little bit of programming as part of your engineering job, and especially if you want to write programs to interface with lab instruments, it's good to know.

Re: Java vs Labview
 

Quoting this because it exactly reflects my opinions.

Re: Java vs Labview
 

I still stand with the LV crowd.

From the easy-to-use perspective, LabVIEW seems to be ahead: as mentioned above, the graphs allowed us to tune our PID controllers extremely quickly, and building the dashboard is also quick, as LV works well with graphic UIs.

Java is more applicable to the real world, and isn't that what FIRST is about? Inspiring and teaching kids to be successful in future STEM careers. However, at least for me, once I began starting to learn programming languages (I started with Python, then C++, LV, Java), each new language became very easy to learn. The thing is, it's not the syntax of a language that's hard to learn; it's the general structures of programming that take time to learn. The point is this: once you learn LV, you have set yourself up for success in learning any (or at least most) new programming languages.

Re: Java vs Labview
 

In general, LabView is easier for non-programmers to understand. That's a big plus.

I find LabView to be very straightforward. As long as you are doing fairly simple, straightforward, things, LabView is great. When you get into more complicated stuff, I found that I had to jump through hoops to store variables and loop through conditions. Java is much easier than that.

For example: Here's a proud moment of our code:

https://www.youtube.com/watch?v=roVc581joiA

We're the lower robot on the blue alliance. Our autonomous code lowers the arms, and then drives forward for a certain amount of time, and then the vision program kicks in and it goes toward the goal to try to make a shot.

You could do that all with a filmstrip in LabView. However, that isn't really what the code does. What we found is that we had an issue crossing the moat. Sometimes we got hung up. That was all about wheels and center of mass and all sorts of mechanical things, but we didn't have time to fix that, so we changed the program.

Lower the arms. Drive forward. When done driving forward, check the accelerometer values on the built in tilt sensor. If it appears to be on level ground, transfer to vision control. Otherwise, move backward briefly. Rest, and then gun it. Repeat up to three times.

That conditional loop is very straightforward in a high level language, but harder in labview. You end up with filmstips inside filmstrips, or custom VIs.
It is not awful. It's not incredibly hard, but your code ends up with a bunch of nested diagrams that are not easy to decipher. The java code was just a couple of lines, and worked very smoothly.

And then on top of that, we had a bunch of conditional statements for stability control, adjusting wheel speeds to prevent tipping. Reading and substituting PID values in certain cases, but not in others. Those nested if-thens are easy in Java. The LabView code gets pretty ugly.


Also, source code control is very difficult with LabView. If you have three programmers, you will be better off if you are using Git or SVN to share code, but that doesn't work as well with LabView.

So, my summary is that if you want to use your code to drive the robot and manipulate the actuators, LabView probably works. If you want to start doing fancy computation, move to Java.


Here, I will come to LabView's defense. I have used LabView professionally. I was working on jobs that analyzed noise and vibration signatures. I could use LabView to hook up my microphones, set a digital trigger, read a sound snippet, compute the FFT, and plot the power spectral density, and set a digital output, all in a few minutes of writing code. We used it a lot for prototyping, because it was just so much easier than writing "real" code. It even made it into some production systems when those were straightforward execution paths.

Furthermore, the word "LabView" on a resume screams "engineer" instead of "IT guy". If you are looking for jobs outside of the IT department, having LabView on your resume will raise the flag that this is probably someone comfortable with a voltmeter.

Labview is absolutely useless if you want to develop enterprise-style business systems, but, as you noted, when working with automation, it can be a very useful professional skill.

Re: Java vs Labview
 

I will concede that that is one of the more annoying things with LV. It frustrates me that LabVIEW is so hard to control by versions. I make updates to the code at home on my own computer, and, when I come back, I need to spend time integrating that with the actual standard code on our main programming computer. The backups onto 2 other computers and a flashdrive also get annoying, when, with a text-based language, it is much easier.

Agreed. :)

Re: Java vs Labview
 

What you describe does sound awful, it sounds like you are trying to take LabVIEW and turn it into a sequential language. Just because using the film strip works doesn't mean its the only way you can write your code in LabVIEW. In fact I would say the sequence structure is one of the worst features in LabVIEW and is a relic of older versions and methodologies.

If you want to move to more advanced LabVIEW code, don't use the film strip, especially as your main architecture. What you describes sounds like a perfect fit for a more parallel implementation, and the main auton flow a better fit for a simple state machine structure.

I completely disagree with this premise. LabVIEW is great for any level of sophistication you may find in FIRST. However, to achieve this you must go beyond the basics of LabVIEW.

Re: Java vs Labview
 

Related link on bad LV practices:
http://www.ni.com/newsletter/51735/en/

Note that #1 is overusing these flat sequence structures. To summarize the idea, LV programmers should rely more on data flow down wires rather than explicitly putting in filmstrips.

Re: Java vs Labview
 

Yeah I agree to the most important factor when changing different languages is what your programming team is more familiar with, for example if most of your students took AP Computer Science then you should probably use Java because they will be more comfortable with the language, but if your students are new to the programming field use LABView because its easier to understand and you already have experience in it so you can teach others. If you do decide to switch to Java write some robot code over the summer and test it out so you know during build season next year the team will still have the same features they had before.

Re: Java vs Labview
 

Well, LabVIEW is certainly capable of doing anything any other language is capable of, so it isn't a question of capability.

The thing is that if you have to go beyond the basics of LabVIEW, then you have to learn beyond the basics of LabVIEW, and that tends to chip away at the great benefit of LabVIEW, which is its ease of use and quick learning curve.

Of course that "learning curve" thing is highly variable depending on who is doing the teaching. If you have a good instructor available who knows how to do sophisticated things in LabVIEW, then the students' learning curve gets easier.

Each language has its own set of benefits and disadvantages, so there is no "this is the right way" of doing things. When our team decided to make the change from LabVIEW to Java, one of my great fears was uncaught exceptions turning the robot into a brick. Null pointers and missing break statements have caused very bad things to happen to our robot since we went to Java. We caught most of those in testing, but it did bite us rather hard in one match when a quick change in the pits left us stranded for most of a match one time this season.

Re: Java vs Labview
 

This is another point that I must disagree with. I don't think the basics or ease of use of LabVIEW are its biggest strengths. I don't even think it is that much easier to teach/learn compared to most other text based languages. In some cases early on I think it is tougher, specifically the data flow idea versus the sequential flow of a typical text language. And the requirement to learn beyond the basics is true in any language, I don't know why LabVIEW should be any different.

The biggest benefits for using LabVIEW are that the complex things are easier (and quicker) to do. This is really where the strengths of LabVIEW start coming out, especially in the context of FRC. It is built to allow rapid development of complex systems. NI would be hard pressed to find customers if their only selling point was that the basics are easy.

I agree, and my default recommendations for teams that are unsure on which language to use is to go with what their mentors know. Though for teams who want a challenge, learning more than one of the FRC languages is always a plus.

Re: Java vs Labview
 

Interesting. That's a perspective I haven't heard before, although it might be because of a different ideas of "complex". For doing sophisticated calculations and graphing, I preferred LabVIEW, assuming that what we were doing had a library available, but on the assembly line, the number of possible conditions we had to deal with made those LabVIEW diagrams awfully difficult to deal with.

Professionally, we always used it as a prototyping language, but when we had the real machine control, we used C or C++,or later we would C#, if the requirements would permit it.

It's always possible that I was doing it wrong, but I ended up cursing the mass of wires wandering about my LabVIEW diagrams, whether in FIRST or on my job, and I thought the nested if-thens were much cleaner and easier to understand.

To the original question: Obviously, as you can see from the differences of opinion, there's no right answer. If LabVIEW is working for you, don't fix it. Java and C++ are not "better". They're different.

Re: Java vs Labview
 

Re: Java vs Labview
 

#4 One that I am struggling with.... Is your decision, only for next year, or path for the team moving forward.

We are a labview team, we were a C++ beta team two years ago, as we contemplating the switch to C++, as some programmers had that experience. This was the year the roborio came out, and the beta documentation was tough, it did not make us want to swtich to C++ as we had a history of good Labview features in our back pocket, that would take sometime to get an equivalent built in C++.

But now, (as I understand it) labview is no longer an option at the FTC level, which means for the future, you will be feeding programmers at the FRC level, with primarily JAVA based programming, from FTC.

Re: Java vs Labview
 

So far, I think this thread has yielded a lot of good advice.

In the vein of leaning a tool better, let me comment on the nested if/else code. As you probably noticed, LV doesn't even have an if/else structure. Arguably, it would be easier to learn if it did. But those structures, in any language, lead to a large number of logic errors. So LV doesn't have one, ... skipped it, ... not dope.

Instead, the LV case structure can switch on a number, enum, string, or Boolean type. This allows, and hopefully encourages, you to combine inputs into a single selector taking you to a single diagram of code. In fact, if you follow this to its logical conclusion, you generally wind up making a state machine. State machines are not the beginner's goto tool, but they are taught in the LV basics class. At least I think they are. And for an assembly line control program, or any other mechanism with rigorous state definition, I'd encourage you to start with a state diagram, documenting and naming the states and transitions, and then coding with a state machine.

Similarly, many robot mechanisms would benefit from a state diagram and machine. I have written them many languages, and they are a great technique to learn and will make you a better programmer and engineer.

So, while not hard and fast rules:
Nested case structures are not the answer. The right number of frames for a film strip is one. Variables, you don't need no stinking variables. And custom VIs are the basic building block of all things -- they will provide you with what you need.

But seriously, if you find something hard to do in LV, please ask. Ditto for other languages. FRC should not be just a robot hackathon. Learning to program is way different and way better than learning a language.

Greg McKaskle

Re: Java vs Labview
 

We switched from Java to LabVIEW last year. My experience with Java was something close to an old disaster movie, except without the hero saving the day. There were many reasons why, but mainly it had to do with convoluted code structure and very painful slow debugging. Plus, the simulation and off-robot testing was practically nonexistent.

The switch to LabVIEW was fantastic. It solved so many of the structural and procedural issues we had with development of the robot.

The value of data and feedback cannot be overstated. PID tuning, which we did a lot of, was especially dependent on graphs and quick feedback (pardon the pun).

This concept keeps the horsepower where you need it. We tried to do this as well, but with limited success in our first try. We also used an Arduino for status and "bling" lights, which added another layer of programming for another skill level.

Also, to answer the comment about Java/C++ programming jobs. Yes, there are tons of them out in the world, but not all. Our team's programmer, the one that survived (and thrived) the season, has an internship at a local company that makes industrial process machines which run on LabVIEW, like so many of them do. Lab work? Industrial machinery and processes? LabVIEW.

Just so you know where I am coming from, my background is embedded control hardware with software development in C.

Re: Java vs Labview
 

Programing languages constantly evolve. Safe bet: The one you learn in high school won't be the one you use 10 years from now. Another safe bet. While there are a lot of jobs out there programing in Java, very few involve machine level applications. Good programmers transcend languages. The important focus is organized thinking to be able to break down complex concepts to executable code.

Our team programs in Java. The combination of it being the AP programing language, and available mentors made it the right choice for us. YMMV

Re: Java vs Labview
 

Just a couple of thoughts from the LabVIEW developer. I have been using LabVIEW for 13 years now and it is the main language that I program in.

It is used in the "real world." Mostly for test equipment automation, motion control, and data acquisition. I have used it for simple windows apps, to real time applications (like what is run on the roboRIO), to FPGA based applications.

LabVIEW does use data flow but also has object oriented capabilities. I would check out LabVIEW classes to learn more about this. NI even offers up examples of this that ship with LabVIEW as well as template frameworks such as the actor framework that you can reference.

I am just putting this info out there so people are aware of some of the capabilities it has that may not be known.

Re: Java vs Labview
 

Depends on the employer. Where I work, we place a low value on knowing any particular language, and a high value on being able to conceptualize, learn quickly and pick the right tool for the job.

If I need someone to build a large scale stream processing system, say to process a million messages a minute from deployed IoT devices, LabVIEW experience would be quite useful, no matter how the service was implemented.

Re: Java vs Labview
 

I've already been a part of two switchovers from labview to Java, and both times the team has gained quite a bit.

I could rant about all of the benefits we have received out of it, but many have already been mentioned in this thread.

One thing that hasn't been however, is that you can use both... at the same time. I give credit where it's due: Labview is phenomenal for viewing things. I've found that the graphing on the dashboard has in particular allowed much faster PID tuning.

Thankfully the WPILibraries give us a way to send data between robot code and Labview dashboards. This means you can have Java code running on the robot, and tune PID, and even do vision processing on the dashboard. Best of both worlds.

Re: Java vs Labview
 

I feel like java is more simple and easy to understand because the language in general is really cool. Labview is cool but, i have to go with Java#JAVAISLIFE

Re: Java vs Labview
 

We used to be a Labview team, but we switched to Java for a few reasons.

My top 10 reasons for using Java (in no particular order):

1. As others have mentioned, APCS teaches Java.
2. Java comes pre-installed on most school computers, and eclipse has a portable version of Java if necessary.
3. No license keys, no activations, no 2-hour installations, just pure, open-source bliss.
4. The job market for Java programmers is way bigger than that for LV programmers.
5. Git.
6. The computers could barely handle labview. The code took a solid 15 minutes to compile and deploy.
7. We found that Java has a lower learning curve once you start to use complex data structures. Variables in LV = :ahh:
8. Labview code quickly becomes spaghetti. With command-based programming and robotbuilder, Java is pretty nice.
9. The programming mentor knows Java.
10. Better external library support.

While LV has the advantage of being better for vision processing, there are other solutions that work, too (Roborealm, OpenCV running on RasPi or Jetson, GRIP, etc.). We haven't tried C++ because nobody on the team really knows it well, and the programmers are all trained in Java now already.

Re: Java vs Labview
 

We have used LabVIEW since it was available for FRC. We tried to make the switch to Java this year, but with my limited experience with it coupled with the fact that I was the only mentor for programming, it didn't go so well. We switched back to LabVIEW in the last week of the season this year, and all of the main functions of the robot were done within a day or two.

The thing about LabVIEW is that it is extremely easy to do parallel processing. You can literally open up Periodic Tasks.vi and run several loops in parallel without having to worry about starving the main loop of your code. (This is probably because of my novice experience with Java and written languages in general, but I couldn't figure out how to run control loops in Java to save my life. I was naive enough to write Thread.delay() in my Java code. Silly me.) In LabVIEW it's also easy to sequence commands using Notifiers and Sequence structures to make it really easy on the drivers.

Also, debugging and looking at data from the robot is super easy in LabVIEW as well. You can run the code from Robot Main.vi and then open up any file and see what value is being passed through a wire at any given time using probes. This makes debugging extremely easy. Graphs and Indicators are nice, too.

For programming a robot, LabVIEW is great. It has its cons, such as slow deploy and compile times, but all of the other pros make up for it.

For programming a robot AND learning more real-world coding habits, use Java or C++ (and Python!). Java and C++ compile and deploy quickly and you can still debug pretty easily by publishing variables to the SmartDashboard. You can also print to the roboRIO console and Driver Station. But it isn't as easy as LabVIEW.

Re: Java vs Labview
 

The thing that I dislike most about LabView is the necessity of installing the environment to program. When I'm out and about and thinking about robot code I can sit down and crank out c/c++/java in notepad++ or another text editor. LabVIEW doesn't have a small stand alone equivalent that allows me to program. It wouldn't even need to compile.

Re: Java vs Labview
 

It can be hard to objectively rank programming systems, so here's one way to look at it: in this thread so far the average team winning percentage from a comment that's neutral is 50.7%. The average for a comment that's pro-LabVIEW is 49.9%. The average for a comment that's pro-Java is 60.5%.

From this we can conclude that winning causes a more favorable view of Java.

QED. :)

Re: Java vs Labview
 

In regards to data structures I find making cluster type defs to be easy in LabVIEW and handle all the use cases I ever ran into. I guess I am curious what data type you are looking to use that LabVIEW can't do.

I agree LabVIEW code can look like spaghetti code. That is where good coding structure comes into play to make sure that is avoided so your code is easy to follow. Generally bundling data into cluster type defs and creating subVIs can help with keeping your code clean.

Re: Java vs Labview
 

How did you calculate this data? Just from this seasons record or a total record?

Re: Java vs Labview
 

My team has been doing Labview for the past 5 years and we love it. I find it is much easy to teach kid and the intimidation factor is much lower since all you are doing is drawing lines.

Over the past couple years we have been developing a cheap min Labview robots to help teach the kids. We found that if each kid has there own little robot they learn a lot faster. We also made a youtube series so they can take the robot home and learn to code. So far we have had great success.

We have are min bot release video her if anyone is interested https://www.youtube.com/watch?v=EFmnmp_VHHU

You can find are labview training classes here
https://www.youtube.com/channel/UCAY...mzYIDspSeCM3gw

Re: Java vs Labview
 

Are you still using the roboRIO to run these small robot? Do you make these available for other team to buy? Where would I get one if I did want to buy one?

Re: Java vs Labview
 

Follow the links. You'll eventually wind up at playingwithfusion.com where all is explained.

Re: Java vs Labview
 

No we do not use the roboRIO. We actually use a ChipKit wf32. It is basically a high power arduino with wifi. We do this to keep the price down allowing use to have a higher robot to student ratio. If you are interested in getting one you can get it from http://playingwithfusion.com/product...=65&catid=1009

if you have any question let me know or if you would like to see any other youtube video on programming Labview

Re: Java vs Labview
 

Another thing about LabVIEW compared to Java or C++ is that it is able to help people who have a hard time understanding written languages. I know that when I first started programming, I couldn't really grasp the idea of a class or a function and how they interacted with parts of a program. LabVIEW helped me realize that a sub-vi is just like a function: there's inputs which feed into a block of code, which then in turn output a set of data. Seeing that visually really helped me grasp written languages a lot easier.

Re: Java vs Labview
 

Java byte code is platform independent. It can be reverse engineered programmatically into UML and other diagrams. There are tools for Eclipse and standalone that can do this.

http://www.class-visualizer.net/

Re: Java vs Labview
 

Forgot to mention, but new tools such as JShell/Kulla are really lowering the Java learning curve.

Re: Java vs Labview
 

This is just from this season's records. I knew there were successful teams that used each but I was sort of interested see what came out.