Programs for the new FRC platform

[frcchile]

Team #2576

Hello, we are from Chile and we want to know which software can we use to program the new FRC platform.

Can you give us an opinion about which one is the best software for you

Thank you for your help

[keen101]

There are two choices.

1. LabVIEW

2. C and C++ (with the help of WindRiver/Eclipse)

I have almost no coding skills, so i think Labview will be easier to pick up for me. But, I've heard good things about both. If you have programmers familiar with c and c++, then WindRiver might be more comfortable to them. Otherwise, i don't think it matters really.
----------------------------

here are some LAbVIEW video's if you decide on that route.

these video's are pretty helpful. You could probably skip the first one if you want.

http://www.lvmastery.com/files/FIRST..._Part1(2).html
http://www.lvmastery.com/files/First...c12_Part2.html
http://www.lvmastery.com/files/First...12_Part3b.html

[frcchile]

Thank you for the quick answer

but the links are wrong ( file not found )

Thanks for help us

[Vikesrock]

These are the correct links

http://www.lvmastery.com/files/FIRST..._Part1(2).html
http://www.lvmastery.com/files/First...c12_Part2.html
http://www.lvmastery.com/files/First...12_Part3b.html

[Alan Anderson]

Originally Posted by frcchile

...which software can we use to program the new FRC platform.

The software you can use will be included along with the control system in the Kit of Parts: LabVIEW for FRC, and a WindRiver C/C++ environment.

Can you give us an opinion about which one is the best software for you

Best for my team is LabVIEW. I don't know what's best for yours.

[frcchile]

Originally Posted by Alan Anderson

The software you can use will be included along with the control system in the Kit of Parts: LabVIEW for FRC, and a WindRiver C/C++ environment.



Best for my team is LabVIEW. I don't know what's best for yours.

Thanks for your answer, can you say me why labVIEW suits your needs or why they chose

we do not know yet which choose, us would be useful opinions of people who already have made their choice

Thanks

[EricVanWyk]

If you have a LabVIEW expert, go with LabVIEW. If you have a C/C++ expert, go with C++. If your expert would end up dominating and not allowing the kids to program, go against their strength.

If you don't have a mentor expert, and you truly have a blank slate to work from, I would personally go with LabVIEW. I've stumbled through teaching C++ and LabVIEW (I'm not an expert in either), and I've found that people completely new to programming pick up LabVIEW quicker. However, that is just anecdotal - I'm sure the pendulum swings both ways.

[frcchile]

Originally Posted by EricVanWyk

If you have a LabVIEW expert, go with LabVIEW. If you have a C/C++ expert, go with C++. If your expert would end up dominating and not allowing the kids to program, go against their strength.

If you don't have a mentor expert, and you truly have a blank slate to work from, I would personally go with LabVIEW. I've stumbled through teaching C++ and LabVIEW (I'm not an expert in either), and I've found that people completely new to programming pick up LabVIEW quicker. However, that is just anecdotal - I'm sure the pendulum swings both ways.

Thank
My team hasn´t an expert member in labview and C/C++, Labview is a new program, the last year we work with other program. Now we be very confused.

you opinion is very important
Thank you for help

[LightWaves1636]

I would go with LabVIEW, although I wish for a zoom feature, I believe less problems will arise from LabVIEW than WindRiver because CRIO was originally intended for LabVIEW and if issues to occur, troubleshooting will go faster if you use the probe feature. Just some past experience of my fellow mentors applies to this as well.

[McGurky]

shes back up!!!

[kyungjin]

Real men/women program in text. <That's sooooo gonna be our club's T-Shirt next year though>

Just kidding...

Our team is going to go a different path with WindRiver (C/C++). It might be a bit difficult to pick up at first (even for an acquainted programmer like myself) because it is pretty heavily reliant on Object Oriented Programming but I'm pretty sure, that once you get used to it, we'll be able to have a bit more freedom in terms of some advanced features and quicker implementation (text versus GUI). Finally for me, maybe I'm just wierd, but it's a lot more simple to envision code through text versus graphics. But that's my personal opinion...

[koreabell]

you'll know you have 2 choices - NI LabVIEW or Windriver Workbench

for our team, we're going to try both at the same time, compare advantages and disadvantages of it.

for this year our main programming code will be based on C++ since i know better about C++ and I'm the main programmer.

the only reason I'm doing both is because the rest of the programming members don't actually know about C/C++, well nothing about programming, and I wanted to let them do it easy way, by looking graphically what's happening.

but if it appears that LabVIEW is better, we are (at least i am) willing to change to labview system beginning next season

by the way, I believe C++ will have more control over it(robot&its mechanism affected directly by software) and it'll give more freedom to programmers

[antoineft]

Our team has had the controller for the past month and we were in the same spot, wondering whether to go with Labview or C++. We put together sample programs in both languages and tested with last years robot. Not going to say anything about the pre-made WPI libraries as I'd say they are fairly equal. Here's some pro's and con's of each.

C++ PROS's:
1 - Coding is more familiar to older teams
2 - Better chance of finding a C/C++ expert/mentor than a Labview expert
3 - **not 100% sure, but I heard somewhere that C++ runs faster on the cRIO than LabView, don't quote me on that

C++ CON's:
1 - Visual feedback looks archaic when compared to what LabView can do
2 - harder to explain coding to a non-programmer


LABVIEW PROS's:
1 - visual interface (feedback) destroys anything you can do in C++ with the same amount of effort
2 - National Instruments support and tutorials are top notch, everytime I hit a dead end, I just searched on the NI website and found my answer.
3 - from an unbiased point of view, LabView is easier to teach to new programmers and easier to explain (once you get the feel for it, I've found LabView easier to pick up than I did C originally)
4 - **don't quote me again but I can see more control/innovation awards going to teams using LabView this year on the basis that it is new, and showing a cool looking LabView interface to a judge who doesn't have a programming background will "wow" them more.

LABVIEW CON's:
1 - For most teams (including us) this is our first time using LabView
2 - Won't be as much in-depth support from other team experts as most will have 10 years of experience with C type coding, and only 1 year of LabView
3 - The more hard-core text based (old-school) programmers you have on your team, the harder it will be to convince them to use LabView and the more they will complain about it... just my prediction

In the end, we chose LabView. If anyone else has more pro's & con's, I'd love to hear them.

Antoine Trabulsi
Team 2609

[Mike Soukup]

Originally Posted by frcchile

Can you give us an opinion about which one is the best software for you

Our team decided to program in C++ for multiple reasons.

All the returning students on the software team have become very familiar with C over the past few years and we already have a good curriculum developed to teach the new students C in the first semester. All of the software mentors have ~10 years of experience with C / C++ and we all use it at work so we are extremely familiar with designing and writing C / C++ programs.

We also have a large software team (3 mentors and 10 students) and we typically break up into small teams to simultaneously work on different features. In some cases, this requires different teams to modify the same files and merge them together later. This is trivial with a text based language and SVN, but is impossible with labview's binary file format.

The last reason is that we feel C / C++ is a more useful language for the students to learn than labview. C is an industry standard with compilers for hundreds of chips while labview is a propriety language supported by a single company. We'd rather not teach the students a language that locks them into a single supplier. Labview is typically only used for data acquisition and industrial automation while the uses for C / C++ are endless. Anyone going into a software development career will need to learn C / C++ or a similar language in college. We're giving the students a huge head start by teaching them the concepts and the language before they get there.

[Dave Flowerday]

Originally Posted by Mike Soukup

C is an industry standard with compilers for hundreds of chips while labview is a propriety language supported by a single company. We'd rather not teach the students a language that locks them into a single supplier.

To further illustrate this point, everyone should note that your Labview license will expire in January 2010. If you don't continue in FRC next year and therefore don't get a new license, all the Labview code you write this year will probably be worthless after that date. Workbench expires too, but since it is C++ code, it can be recompiled with a number of different compilers (including the original compiler that Wind River uses since it's GCC).

The temporary license we're being given to these tools this year is a dirty little secret that I don't see a lot of discussion about. It's another way that we're being short-changed with the new control system (in addition to no longer getting a new one each year). Consider the case in a few years where perhaps they switch to a new control system, and move away from National Instruments. If that happens, then at that point all the robot code that teams have written in Labview will no longer be maintainable unless those teams go off and buy their own Labview license. Maybe this isn't a big deal to most, but we do occasionally go modify the code on our old robots as we use them to test out ideas for a new season, etc.

In short, vendor lock-in == bad IMO.