Mentors will not let us use language the team wants.

Technical Programming
1

I am one of the 4 programmers on semi new team from Nevada. We have three instructors and they insist that we use Java. We all have experience with labview and want to use it. The mentors however refuse to even take in to account that we would be much more profecient and do a lot more with labview. The only reason the mentors want to use java is because they use it everyyear and know it. I think it is unfair they are only using java because they can code it and won’t let us use labview.

Also to make it clear, their is no reason besides that “that’s how it has always been done” for using java.

What do you think we should do?

2

Clarify the purpose of FIRST. I’d say engineers who know java, and have been using it for years are already following a science carrier path. The purpose is to give the students the experience of working on a realistic engineering project, and it’s probably a little late in the season for your programmers to learn an entirely new language. (Correct me if I’m wrong but: ) It basically boils down to either the students do the work, or the mentors do. Which do you think fits the purpose of FIRST more? If your mentors think they should be doing the coding, then you might want to have a talk with your team about the issue.

3

From a mentor’s point of view, it is much easier to support a team in an area where they already have expertise. You do no good for the teamif you are working in the dark.
Now, if they use Java every day, that is a REALLY GOOD THING!

Learn to use LV in the offseason.

Just my $.02

4

You’re kidding, right? Either that, or your mentors are. Java wasn’t even an option until the 2010 FRC season.

Since there has only been one year of Java possible, I think “that’s how it has always been done” is a very weak statement. However, if I were you, I’d respect the mentors’ decision and program the robot the way they want you to.

I would also consider “going behind their back” with a separate programming project using LabVIEW, just to show how capable you are, but I wouldn’t sabotage the Java effort.

5

In the 2008 season, our team’s mentors did a lot of the design work, and someone on our team got upset, and sent out a letter to all the mentors, telling them that it was the team’s robot, not the mentors’, and that the team wanted to do more of the design work. Since then, our team has had very little mentor support. Be careful what you tell your mentors, or they will not want to help anymore, and not having much mentor help makes the build season more difficult.

6

I’m the Mentor for my Team for both Software and Electronics.
I’ve been a low level ASSEMBLY language coder my entire career (30 yrs).

I personally don’t like any OOP(Object Oriented Programming), however, I refuse to let my personal bias prevent me from learning it or using it if that is the direction the TEAM wants to go. Hopefully both you the students and your mentors have a similar mindset.

So let me share my insights, thoughts, ask a few questions etc…
So now let me pose a few questions and some food for thought…

Question 1, Who’s doing the programming the Students or the Mentors?
If the Students are, then remember the Mentors need to be able to help you, guide you and support you.
If the Mentors are, then they should be teaching you so you can program yourself in the future.

Food for thought on Q1:
If the Mentors don’t know Labview they will be limited in helping and guiding you, but they can still help you.
If the Students don’t know JAVA, they will be limited as they must learn it.
Given this late juncture in the build season the choice in my opinion boils down to who is doing the coding, and with which language they are most capable in.

Question 2, What direction does the TEAM want to go in the future?
The answer to this will provide you the learning maps for the off season.

Food for thought on Q2.
If it’s JAVA, then the Mentors should teaching it to you.
If it’s Labview then the Mentors should learn Labview.
If it’s C++, then it’s a new avenue for both.

My own personal food for thought…

  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 place to point a finger at to get it corrected.

I have had this very issue in my professional career…
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 than Vendor A or Vendor B clear identify who’s problem it really is.

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

So now hopefully you can sit down with your Mentors and have an intelligent and rational conversation and make a unified decision for both this season and the future.

PS… I learned Labview because that was the direction my **Team **wanted to go, but I just easily could learn JAVA or C++, or even teach Assembly if that was the chosen direction.

Feel free to PM me, including your Mentors.

7

I would recommended listening to your mentors. I had a similar problem in which I preferred using c++ to lab-view but our mentor was goddess like with lab-view. Even though I was more proficient in c++ I decided to go with lab-view because my mentor could help me a whole lot more. So far this year, I believe I made the right decision.

8

A good lesson to learn. Your member that stated that it was the “team’s robot” and not the “mentor’s robot” made it pretty clear that they didn’t think the mentors where part of the “team”… and then of course, why should they help?

FRC Teams are a combination of students and mentors… all doing the best they can for the team. There is little room for this kind of petty bickering …you will lose your mentors…
listen and learn from them… try to convince them of your position/idea… but then when a decision is made… do your best to support it.

You will find in life that many times you won’t get your way… get used to it…make the best of the team’s decision

A good team player is extremely valuable… more valuable, in fact, than some loose cannon(s) no matter how “good” he/she/they think(s) they are…

I also don’t encourage you to EVER do something “behind the backs” of the mentors…
Tell them up front… they should not have a problem if you want to do extra work above and beyond… as long as you stay with the team plan…and get whatever assignments you have been given done first or at least on schedule.

This is no reflection on your programming group of course… I am just speaking in generalities.

9

I’ve seen this exact situation before. Our VEX teams are like 99% student-run. Last year they had a really great running robot with awesome autonomous programmed in EasyC. While the team as a whole knows EasyC very well, one or two students came forward (insisting they knew RobotC really well) and wanted to reprogram the VEX robot in that. This student attempted to reprogram the robot in RobotC, but ended up with code that only worked about half as well as the original code. Somehow, they also lost the original EasyC code, and were now stuck with a robot that barely worked, let alone dominate. This caused the team to incur many losses at their next event (they were previously undefeated).

So while the student who wanted to learn and use RobotC to program the VEX robot may have learned a lot, the team as a whole suffered from greatly diminished robot performance.

Here is my advice:

  1. Get the entire robot programmed in Java. Everything. Get teleop working, get auton working, get any sensors working.
  2. Save the code from step one, with multiple backup copies.
  3. If you still have time, now program the robot in Labview. Here is where you can prove to your mentors you can program in Labview. If all else fails, you still have working Java code from step one.
10

Like Alan and Art said, program the robot in Java. It is extremely hard for a mentor to help a team if they outside of their realm of knowledge. Once you got the Java program done, do a LV copy to learn from.

11

I work for NI as a member of the LV team; so you might expect me to tell you to ignore the mentors, mutiny, do whatever it takes to use LV to make your robot go.

But, that isn’t going to happen. I’d much prefer that you impress your mentors by showing them respect and enthusiasm. That would mean working with them to learn how to program the robot in Java. You may be able to convince them that you use LV to do the dashboard or process some logged data. But make the decisions as a team and be sure to learn from the mentors.

If all goes well, perhaps after the robot ships or even after the season, extend the offer to help the mentors learn LV. As a team, you will be so much better off.

This situation will come up again and again over your career. Sometimes it will be a language, other times a SCC tool or a code library. Learning to do it in a positive way, to improve the unity of the team, is a great skill, much more important than either of the languages in question.

Greg McKaskle

12

I’m going to parrot what has been said but add a twist. Respect your mentors for the competition season. During the off season make an agreement, the students and the mentors will reprogram the robot and trouble shoot it in Labview. They will do this together. The reason is simple, both parties will learn something and gain a mutual respect for each other’s abilities and strengths. I have never met a good mentor who thinks they know everything and can’t learn from students.

13

I’m supporting the advice given in this thread, especially Greg’s advice.

If you really want to do yourself and the team a favor, impress them by doing java, c++, and labview.

That is what we are trying to do this year, except the c++ will not deploy but that is a totally different problem for a different thread.

Do it all, turn into a software ‘NINJA’.

14

Follow what your mentors want. I will say however that recently I had dinner with an engineer from someplace (not saying who or where) and they stated that they used LV at their place of business (Major corporation). This person then went on to say they look for co op students who know LV. Politely, sit down with your mentors and agree to using Java but also nicely ask if after your season is finished if you could work together in LV. Maybe all of you can learn from each other and that is certainely a great thing!!

15

Hi, I’m Justin from Team 2057 here in Vegas (Arbor View) I suggest you do Labview as a rookie team if you have the experience. Either that or have 2 teams that each try to make it work, then use the code that works best in your opinion. If you have any questions about labview (if you plan to use it) just contact me and I may even be able to help your team out directly.

Best of luck. Labview saved our team last year and we’re doing it full-on this year.

16

My $0.02 as a rookie mentor: The students from the previous year are experienced in LabVIEW since it was used in previous bots, so even though I didn’t know LabVIEW, I learned (and am still learning) and am supporting the students in their coding the bot in LabVIEW rather than insisting that they program in Java or C++ (which are both languages that I already know). I have not done any of the code for the bot, nor am I planning to; I believe my job as a programming mentor is to keep the students focused and organized, to help them debug, and to help them communicate clearly with the rest of the team.

17

On many (if not most) teams mentors have the final say. I understand that this can be very frustrating at times, but realize why the mentors may be making this call.

From where you are, you have two options. Either compete with the mentors or work together.

Personally mentors often have to choose what they can support, because their time is hogged by other things too. For example with my ADK I have chosen to explicitly support Java as it is what I can support with my time available

I do have teams who have referenced my code who are using Labview and C++, but I told them that they were essentially on their own as far as implementing it in the other languages.

Your mentors, who probably have years and years of programming experience over you, probably made this decision as it was what they could support best. So rather than them saying, go ahead and write it in labview but you’ll be on your own, they said lets do it in java so we can utilize my expertise. And trust me that expertise is critical if you are going to try to have a successful autonomous.

What they are doing is risk management, and where it can be very frustrating at times, it is a critical element of design decisions.

It is unfortunate that it came in the top-down manner that it did. As I’ve always said, sometimes it is better to allow a team to fail than to enforce authority… and this can be the most difficult thing a mentor can do, but there are important lessons that are learned.

However, I think they are making this call in your team’s best interest as they realize if the code fails, the robot fails EPICALLY, and competition debugging is probably the most difficult thing a programmer will face. Having a mentors expertise will help and may even save your robot should this happen.

18

Too often I read that programmers feel they only need to know one way to code something; yet in the real world the reality is that if a programmer cannot adapt to the multitude of new languages and protocols, he/she will be come obsolete and out of a programming job within a few years. Typically this means odd consulting jobs for their language of specialty or movement into project management.

Consider this a lesson for both you and your mentors. You guys should learn Java. They should at least become more exposed to LabView. Which language do you choose for this season then? Whichever one gets the robot finished on time. The one that isn’t used should be ‘taught’ during the offseason. I predict that if the mentors truly are that stubborn they will only use Java in future years; so it wouldn’t hurt for the students to learn it now. Yet Alan is quite correct – their argument for doing so (if they really worded it as the OP has worded it…) is quite weak.