What Language To Use? [Archive]

Team 3705

12-10-2011, 00:30

Hi, I am one of the leads in charge of programming for Team 3705. We are trying to participate for the 2012 challenge, we are a fairly new team.

We used C++ last year, and did not have autonomous mode.
I want to look at other languages that we could possibly use. So, far I would love to use Python to program the robot, but there seems to be some issues.

Please comment on what languages we could use, we are fairly new. Most of the people that are in charge of programming the robot are not familiar with programming at all. So, I have to be able to teach them also including myself.

Suggestions? Comments?:]

EricH

12-10-2011, 00:32

Last year, you could use C++, Java, or Labview and be supported. Some people did write in Python, but had to write their own whatever-you-call-it to make it work.

Mk.32

12-10-2011, 00:48

C++/JAVA/Labview are the most popular, python is doable but it is relatively new and you will need to do a bit of extra work to get it to work, more info on the python select of the forum.

You should start with whatever language you and/orthe rest of your team (including mentors) know best. For us it was JAVA and it worked out quite well for us.

If none of you know one language in particular, all 3 has pros and cons. There are some threads about that if you do a quick search.

Team 3705

12-10-2011, 00:59

I really like Python, but I still think it needs work. We might just as well go with C++ again. But I will definitely try to test Python and see if it is something that we can use as an alternative.

Mk.32

12-10-2011, 01:02

I really like Python, but I still think it needs work. We might just as well go with C++ again. But I will definitely try to test Python and see if it is something that we can use as an alternative.

What off season is for.
If you have enough programmers, you can even have 2 teams, one that codes in Python and one that does C++. And for competition use which ever works better.

Team 3705

12-10-2011, 01:29

Well, everyone in my team is a newbie to all this. We lost our program lead last year.

So its all up to me, and we are lacking members on some fields. I am really worried about the state of organisation in my team.

No one has done collaborative development before. Last year it was a one man job. This year I am trying to spread out the work, but everyone is really new to programming. Since we are a team in HS, most of these students are in Grade Nine. For some reason, we are lacking more senior students with knowledge, which I plan on changing.

Some of the things that I already started doing is auditing last year's code. But I have much more to do. Would love to see someone else's C++, or just general code.

Tom Line

12-10-2011, 02:34

If you do a search here on chief delphi, you'll find people have posted their competition code. Likewise, many beta teams posted their code at the end of beta last year, which would give you a good bit of code to look at. You can find the beta forums at www.usfirst.org.

Tommy F.

12-10-2011, 07:45

I'm just going to put this out there:

If your team is interested in learning LabVIEW, there are great guides to get you started and keep you going at http://www.frcmastery.com/.

DonRotolo

13-10-2011, 19:20

If you think your team may be "struggling with programming", then I suggest picking a language that has a lot of FRC support already available. While Python may be cool, you'll struggle with it far more than with LabView, for example.

The choice for our team was mainly dictated by what the mentors knew, and that was LabView.

Remember that no matter which language you choose, there is generally no task that can't be done. So it becomes a matter of what is easiest to master.

Don

Duke461

13-10-2011, 21:22

For more of a comparison between the languages, read this thread:
http://www.chiefdelphi.com/forums/showthread.php?t=84890&highlight=programming+language

ratdude747

13-10-2011, 21:54

I'm just going to put this out there:

If your team is interested in learning LabVIEW, there are great guides to get you started and keep you going at http://www.frcmastery.com/.

+100

that is how I re-learned labview... that, and reverse-engineering the code for an old 2010 bot (and getting a better resultant code) worked out well.

for newcomers, labview would be my recommendation. but use whatever your team knows best.

Bryan Herbst

13-10-2011, 21:55

If there is any question about which programming language to use, I would follow Don's advice and stick with C++, Java, or Labview.

You will find that if you encounter any problems, there will always be a mentor or student on another team nearby that can help you with any of those three. If you go with Python, your choices for assistance will be far more limited.

Python is fun for the off-season, but I would always stick to an officially supported language for the competition, because the libraries for the officially supported languages have been heavily tested and you get the support of other teams.

Team 3705

17-10-2011, 18:33

JamesBrown

19-10-2011, 09:07

Look into getting a team Dropbox account, or something similar (if you haven't already). We use our Dropbox for everything. Our CAD is shared on there (CAD is very important to us since we use sheet metal), our code (with all previous versions, so we can revert if we mess up), as well as team pictures and videos for the marketing and Chairman's team.

Very good idea, however dropbox is not the best solution for software revision management. If you are programming in JAVA or C I strongly reccomend using SVN, this will allow you to commit changes, allow you to see who is working (or has worked) on what and you can always roll back to older versions. Both windRiver and NetBeans have plugins for SVN. I am not sure if LabVIEW supports svn but I do recall a thread discussing it a while back.

DonRotolo

19-10-2011, 13:12

My team also has a bad design team.
Is the team bad, or just their designs, or both? Or is it a case where the design is great, but just for a different game? Or is it a reliability problem? Or...?

You can't fix everything in software, but some rational and logical suggestions might be able to turn bad into good. How can we help?

AdamHeard

19-10-2011, 14:21

Sconrad

19-10-2011, 16:41

Thanks for all of your guys opinion! We will definitely look into using C++ and maybe LabView.

I would prefer C++ though!

I hope python is an option out there though, but who knows. I will try to experiment when I have the time.

My team also has a bad design team. So there is definitely a problem there also.

Anyways, thanks for the reply! Will definitely look at the various code out there.

Just keep in mind what the new programmers are going to know. If your school has some sort of C++ or Java (AP Computer Science) class, then that language is probably best for you. I am a programmer for team 122 and we get a lot of kids in our programming group whose only experience with programming is some scripting language like html. Therefore, Labview works well for us. Because it is all visual, Labview is relatively easy to teach to kids who are new to programming. Another advantage to Labview: Every function you will ever need is in a right-click menu, so it is really easy to learn by without constant supervision, which can be a huge help if you are short on experienced programmers.

I would recommend the method of splitting into two groups if for no other reason than your team will have experience in two languages and will be able to help more teams at competition.

Andrew Schreiber

19-10-2011, 17:18

Just keep in mind what the new programmers are going to know. If your school has some sort of C++ or Java (AP Computer Science) class, then that language is probably best for you. I am a programmer for team 122 and we get a lot of kids in our programming group whose only experience with programming is some scripting language like html. Therefore, Labview works well for us. Because it is all visual, Labview is relatively easy to teach to kids who are new to programming. Another advantage to Labview: Every function you will ever need is in a right-click menu, so it is really easy to learn by without constant supervision, which can be a huge help if you are short on experienced programmers.

I would recommend the method of splitting into two groups if for no other reason than your team will have experience in two languages and will be able to help more teams at competition.

Not to be a jerk but HTML is a markup language NOT a scripting language. If they know a scripting language it is actually really useful as they already know the basics of programming (variables, flow, logic etc).

Sconrad

19-10-2011, 17:33

Not to be a jerk but HTML is a markup language NOT a scripting language. If they know a scripting language it is actually really useful as they already know the basics of programming (variables, flow, logic etc).

You are right. HTML is not a scripting language. I meant markup manguage but the terms got jumbled up in my head (maybe humans do need more than 5 hours of sleep a day:] ) I have nothing against people who have programmed in any language, as taking up a language shows they are interested in programming and computers, which, IMHO, is more important than previous knowledge.

AustinSchuh

20-10-2011, 02:36

I'd estimate that over 80% of our Dropbox is CAD files, with about 4 robots worth of parts and assemblies on there (2010 x 1, 2011 x 1.5, 2011.5 x 1.5).

Our SVN repository has our CAD files in it as well as all the code. SVN works for CAD files as well.

Andrew Schreiber

20-10-2011, 09:40

Our SVN repository has our CAD files in it as well as all the code. SVN works for CAD files as well.

About the only thing you lose is diff-ing the files.

For reference, Git works as well. Use whatever works best for your team.

theprgramerdude

28-10-2011, 20:24

What off season is for.
If you have enough programmers, you can even have 2 teams, one that codes in Python and one that does C++. And for competition use which ever works better.

Don't do this. You can (and definitely should, if you have time and are considering multiple languages) do it during the off season to get a hang of each language and play around with which one is better/easier to code with, but if you do this during build season, you will not end up using better code. You'll end up using code that only has half the time put into it that it could have had, which usually implies it's not as great as what it could have been.

Joe Ross

28-10-2011, 21:14

Don't do this. You can (and definitely should, if you have time and are considering multiple languages) do it during the off season to get a hang of each language and play around with which one is better/easier to code with, but if you do this during build season, you will not end up using better code. You'll end up using code that only has half the time put into it that it could have had, which usually implies it's not as great as what it could have been.

It's definitely not the best choice for many teams, but for larger teams it can be a good choice. Team 67 won a world championship having run some competitions with c++ code and some competitions with LabVIEW code.

WizenedEE

28-10-2011, 21:23

apalrd

28-10-2011, 21:35

I want to know why people keep saying that python is sketchy and shouldn't be a first choice of language. It's not as if the motors will suddenly stop working, is it (assuming it's properly programmed and tested)?

Because it's not officially supported (so WPI/FIRST/NI can't help you) and very few teams use it (compared to LV, C++, and Java), so you have less community help.

Ether

28-10-2011, 21:39

I want to know why people keep saying that python is sketchy

I couldn't find the word "sketchy" in any of the previous posts in this thread.

The major issue is support.

theprgramerdude

29-10-2011, 00:05

It's definitely not the best choice for many teams, but for larger teams it can be a good choice. Team 67 won a world championship having run some competitions with c++ code and some competitions with LabVIEW code.

How can it be a good choice? While I am not aware of how Team 67 produced their code, the fact that they wrote good versions in both c++ and LabView simply proves that they write good code.

Unless the programmers know enough to write code in C++ and Labview and use each environments components interchangeably in the code that is used on the robot (highly unlikely), developing on both platforms means time is lost that could have been spent improving upon only one platforms existing code.

The exception occurs only when you have several programmers who are only fluent in one language, in which case, yes, it might be a good choice to split them up, although productivity-wise, it would make more sense to have them retrained in c++/labView, so everyone is using a single language and the entire programming team can actually work together, rather than having several teams not working together.

apalrd

29-10-2011, 10:20

In team 67's case, they had two independent groups programming (no common programmers). They had so many people interested in programming that a single team would have been too large to be reasonably productive (I fully agree with this opinion - Too many programmers on a project of this size is a bad thing).

I talked with 67's lead LV programmer from that year. After talking with him, about LabVIEW, he made no mention of any interaction with the C++ guys at all.

flameout

29-10-2011, 12:18

In 2010, we started off using Java. However, we wanted to use the camera tracking code, and somewhere in the native libraries or WPILibj, it was crashing (I recall getting some sort of error in Netbeans's debug console).

Therefore, early on, we switched to LabVIEW. This worked great, until the end of build season, at which point... -- the camera stopped working again (after updating the cRIO image). We also experienced issues with code downloads (the only available workaround was to reimage before every download).

As our code that year was relatively simple (because the default vision worked out of the box), it was within our capabilities to have coded in both languages (and C++ too, for that matter). Had we done so, we could've switched languages away from LabVIEW -- likely solving the code download issue (since Java and C++ use FTP, and LabVIEW doesn't AFAIK) as well as possibly restoring camera function.

I am considering writing code in multiple languages this year -- even if we only get vision (assuming it exists in the next game) working in one or two languages, it'll still be driveable should we encounter a killer bug in one of the cRIO's images.

Of course, this means nothing if you don't have programming time to spare -- after choosing a "main" language, don't sacrifice the quality or performance of your main code just to work on the backups.

Just my 2¢.

davidthefat

29-10-2011, 12:31

Here is my two cents: do not get caught up in the whole "which" language debate in the first place. Just pick one. The language you use will not affect performance of the robot (unless you are doing some memory intensive calculations and need to optimize). What is important is the way you think and come up with a solution. Regardless of the language, the solution is the most important thing here. Different languages will not hinder your ability to come up with that solution; chances are, you won't be using features specific to one language. For example, pointers; every object other than primitives in Java are essentially pointers. Don't be immature and say "oh, but I want to use pointers, so I must use C++". No. You also probably will not need inline assembly either. Java just makes memory management easier too. If your java program has a memory leak, you are doing something very wrong...

apalrd

29-10-2011, 12:31

We also experienced issues with code downloads (the only available workaround was to reimage before every download).

This is a common problem involving user code taking up too much of the processor (as the bootloader runs in low priority, it can not run at all if the user code does, say, vision all the time). The solution is to flip the "No App" switch, reboot, then download. It has nothing to do with the cRio image (although an update could've increased processing requirements somewhere to put your code over the edge, so to speak).

As our code that year was relatively simple (because the default vision worked out of the box), it was within our capabilities to have coded in both languages (and C++ too, for that matter). Had we done so, we could've switched languages away from LabVIEW -- likely solving the code download issue (since Java and C++ use FTP, and LabVIEW doesn't AFAIK) as well as possibly restoring camera function.

The real reason that LV dosen't reboot the processor to restart the code - It talks to the bootloader, which then restarts the user code. This allows for much faster code development while using the "Run" from Robot Main, as you don't have to reboot each time. When the LV user code is using too much of the processor, the bootloader can't run, and bad things happen (in the user code too - usually it struggles to run the lower priority user code, probably the cause of your vision issues).

flameout

29-10-2011, 13:26

This is a common problem involving user code taking up too much of the processor (as the bootloader runs in low priority, it can not run at all if the user code does, say, vision all the time).
I went back and looked at the thread that discussed the issue -- apparently, a LabVIEW issue nuked the vision, causing it to consume 100% of the processor (I say vision because, from what I recall, nothing else could possibly have taken up a significant amount of execution time, unless the LabVIEW update contained a compiler bug (which I doubt due to the nature of the updates)).

We did not change our code at all when we updated LabVIEW, so that rules out a mistake on my part.

I apparently missed the No App DIP fix -- the post came two days later, so I probably either forgot to check the thread or subscribe to it (we wouldn't have done any further programming after this point until regionals).

Thanks for the help.

Note: I still feel my point about using multiple languages (iff you have the resources to) holds, even if this one instance turned out to be a solvable problem (it would've been nice to just switch languages, rather than needing to scramble for a last-minute solution).