I don't think being a rookie team has any effect on the programmers
 

Ok I have not shown much enthusiasm about the autonomous kit stuff. Its mostly for those rookie teams I am assuming? Well I am against that whole idea, kind of showing pity towards them... I may sound evil right now, but just because they are a rookie team, that does not mean that they can't compete with he veterans... IDK where this idea came from, but I don't like the kit idea that people are doing. This is not some government run multi billion dollar project... Software pretty much costs $0 for us, its all electrical and mechanic that gobble up the money, I don't get how being under funded rookie has ANYTHING to do with programming... Yea this challenge was for individual teams doing it by themselves, the prize is vanity and pride...


Yes I am a very opinionated guy that is not afraid to speak my mind... Don't hate

Re: I don't think being a rookie team has any effect on the programmers
 

Often rookie teams lack programming experience and don't know where to start.

It's not even just rookie teams; sometimes teams just have member turnover problems and run dry. This is especially an issue when there aren't any software mentors to make up for it (like on our team).

Re: I don't think being a rookie team has any effect on the programmers
 

As I was not a member of a rookie team, I try my best to equate it to my own experience of being a rookie member of my team. True, not the same, but similar I feel.

I don't think that it's showing pity towards them at all. I think that everyone, including veterans, need a 'jumping off place' if you will, each year. The difference between the veterans and the rookies? The veterans have the previous year as a jumping off point, while the rookies do not. Over time, those rookie teams will take the new code that they have created each year, perfect it through iteration, and soon enough become veterans drawing on each year previous for improvement.

I apologize, I cannot understand what you mean here. Do you mean that because software apparently 'costs $0', that the rookies have access to the same materials, and thus shouldn't be helped any more than a veteran team? If that is the case, i must humbly disagree with your point.

It's not being under-funded that has anything to do with programming, it is the lack of experience. Again, having no experience in this competition is the most relevant handicap (with regard to programming) that a rookie faces. The key to creating a sustainable team that can last until they are considered a veteran is to ease the transition into the competition. You wouldn't give the same job to a wily old veteran with many years experience in engineering as you would a new student, fresh out of school, would you? Obviously, you're going to need to show that new member of the community how to do it (adequately) at least once, and then let them find out through experience. Furthermore, they can build on that experience in the future to form their own methods for achieving the end product, in this case, a solid set of working code.

In short, I must say that I disagree, and firmly believe that being a rookie team does have an effect on the programmers, as well as every other member of the team.

Re: I don't think being a rookie team has any effect on the programmers
 

True, but I was a rookie this year, I had no problem learning... Just Look at the $@#$@#$@#$@# API and documents... How is that hard? If you have ANY programming experience, you can easily use the API, its so well named and stuff, I just asked what the things were connected to and Bam, its in the API... People don't realize how important reading documents and the API is... Also the mentors had a "Let all the students do all the work and just assist them" type of mentality, I can say they were great, but they did not needed to help me directly with coding. Just some of my questions on technology

Re: I don't think being a rookie team has any effect on the programmers
 

While I'm not sure I would have said it like that, exactly, I understand where you're coming from here. I've had the same thoughts recently, reading through topics here and interacting with the community. It seems there are far too many projects going on with the goal of eliminating the need for rookie teams to do programming.

It's not that I don't understand the intent of these projects. Many rookie teams don't have a good programming department, or have only one student who is responsible for doing all of the programming. It's nice for these teams to be able to make their robot do basic teleop stuff like driving and kicking/shooting/etc. But autonomous? In my opinion, that's a challenge best left as just that: a challenge. Let the challenge of autonomous be motivation for rookie team members to learn programming and join the ranks of the veterans. As the OP said, unlike the build team, we aren't limited by financial constraints.

I'm not saying that releasing SDKs is a bad thing. It's awesome to see how different teams approach problems from different angles, and how unique program designs can make things easier in the long run. And don't get me wrong; 619 has its own framework that we intend to release later in the year. But perhaps we should be writing these frameworks not with the goal of making them "so easy to use a rookie can do it," but with the goal of helping motivated rookie team members learn effective program design as quickly and efficiently as possible. Rather than doing everything for them in some sort of black box, give them a nice inheritance tree to play with - one that effectively shows the benefits of oop while requiring the team to implement these concepts by extending the code given to them. Or provide a nice event handling system that shows teams how event-driven programming works while still requiring them to write, instantiate, and order the events. Right now, it's almost to the point that a team can call, "driveForward()," and the robot drives forward, and IMO that does not teach programming skills.

One example of what I would say is going too far is "converting" other teams' code to a veteran framework without them explicitly asking you to do so. Sure; after spending a season designing an awesome autonomous framework you may think it's the end-all-be-all of FRC programming, and that you're doing every rookie team a favor by "porting" their code. But what seems like the best solution to you may not be the best solution for everyone - remember that, because you designed the system, your opinion of it is inherently biased. What if a rookie team would rather learn how to design an effective autonomous solution, rather than just letting another team do it for them? What if ease-of-use isn't the only concern here? And that's assuming your system even is the easiest to use; some of the SDKs I've seen around here look like they would make it harder than the default code to do anything more complex than simple driving, especially when they lack comprehensive documentation.

Note: the above is not directed to any one team or framework. I've seen at least four or five teams releasing SDKs with the specific goal of reducing the number of lines a rookie has to write as close to zero as possible. Overall, I think the releasing of frameworks is fine, and it's certainly a great exercise for veteran teams doing the development. But teams need to keep in mind that their goal should be to help rookies learn how to program - not to do it for them - and that a system's users view that system very differently than the system's designers. That is all.

Re: I don't think being a rookie team has any effect on the programmers
 

That's the crux of your argument. What if the team has no one with any programming experience? What if they don't know what a do loop or an if-then statement is? What if they have no idea what an API is, or if they don't understand what a object oriented programming structure means?

I truly do not understand why people continue to make the assumptions that people are as capable as them, have as many resources as them, are interested in the same things as them, etc... FIRST teams have diverse memberships, some with no mentors, some with mentors with no engineering experience, some with mentors who have put robots on Mars, some with whatever money they can scrounge, and some with enough money for full time paid mentors. Let's not make assumptions about other teams capabilities and help those that ask for it.

I can't tell you how many times I actually helped myself by looking to help others overcome their problems. In complex systems you'll find that answering one issue for someone else may very well help you solve an issue of your own somewhere else.

Re: I don't think being a rookie team has any effect on the programmers
 

While I once again wouldn't have said it using your words, this post brings up a good point. At least WPILib is well-documented. Many of the veteran team SDKs are not.

Of course you need to show them how to do it once. What concerns me about many of the veteran frameworks going around is that they take a "black box" strategy; rather than showing rookies how to do it, they try to remove the need for a rookie to learn how to do it. That, IMO, is a poor strategy. Perhaps I'm just misunderstanding how many of the SDKs work; I haven't personally used any of them but have only read their project description pages.

Re: I don't think being a rookie team has any effect on the programmers
 

I do not see how a rookie team can "graduate" from the rookie status using development kits released by veteran teams... You are just keeping them there pretty much, they don't get the same experience and they need it too.

Re: I don't think being a rookie team has any effect on the programmers
 

I actually agree. All of the functionality in WPILib is there in the help docs, and the software comes with lots of example code (even if not all of it works). Providing more examples is a lot more helpful in the long run than a "black box" SDK would be in terms of making a team a "veteran" in terms of programming.

That said I don't really think one can expect the same from every rookie team as from a strong established one.

Re: I don't think being a rookie team has any effect on the programmers
 

Also I would like to ask what makes a team reach a "veteran" status?

Re: I don't think being a rookie team has any effect on the programmers
 

If that is the case, then I completely understand your reservations. In fact, I share them.

There is a clear difference between what I am talking about with regards to the original Kit of Parts (which is what I thought the OP was originally talking about), and Rookies using intense frameworks put out by Vets.

If the OP was talking about veteran teams putting out those frameworks, then I apologize. I personally feel as though that's along the lines of cheating, unless someone takes the time to go through and understand the framework given. Actually, if a rookie coder is able to go through and understand a framework it could very well help them along in their learning process, causing them to ask more questions, and find more answers.

In this case, I would completely understand the use of a framework. This is one of those subjects where it is difficult to come to a definite conclusion. There is a fine line between a resource allowing someone to compete, and being "too helpful" and staunching the learning process.

EDIT:

Also, to your question OP, I would define it as such: If you can consider a team sustainable from year to year, it is a veteran.

Re: I don't think being a rookie team has any effect on the programmers
 

You could take that same argument to say they shouldn't be programming (LabVIEW) at all if they don't know what a subVI is.

Even more so, that how Autonomous Independent is called is by a reference somewhere you wouldn't normally look.
I talked to a programmer at a regional who used Autonomous Iterative as his Autonomous Independent because he didn't see where Autonomous Independent was called in Robot Main.

Re: I don't think being a rookie team has any effect on the programmers
 

I would think that it would be more for the established teams that seem to have difficulties in autonomous. The vast majority of true rookie teams (rookie mentors and students) won't have the knowledge that it's there to take advantage of it. Take your team for example, your rookie year was 2001, and your autonomous barely works (manages to kick one ball out of three when you KNOW where the balls are and there's no defenders to bother you) 9 years later. An autonomous framework would allow you hopefully program a competitive autonomous mode by bypassing the development problems that many students don't even realize are there.

Re: I don't think being a rookie team has any effect on the programmers
 

Also, it is technically illegal to not make these resources available to the rookie teams if you make it in the offseason and intend to use it on your robot

Re: I don't think being a rookie team has any effect on the programmers
 

That is true, but Like I explained in my previous threads, I DGAFed this year, so I never used my knowledge to the fullest potential, I was just "Get it working" just the bare minimum... Also I was limited by the hardware, the kicker was only capable of kicking like 15 feet, thats 1 bump, and was no aiming the ball at all and the goal was to just kick 1 ball

Re: I don't think being a rookie team has any effect on the programmers
 

In my experience, your argument has a fundamental flaw: you imply that the disadvantage of being a rookie team is funding. To put it simply, it's not: several teams I know were better funded as rookies than as veterans. The veteran advantage is about experience.

Why does being a rookie have an affect on the mechanical, electrical, and other aspects of robot design? Because as a team grows older, they learn all kinds of things. They learn things about how to manipulate balls effectively, or how to optimize a drivetrain, or develop a set of methods for designing their electrical layout.
Software is no different. Teams learn how to write good drive control algorithms, use different sensors effectively, or create a strategy for writing autonomous mode software.
And it's not about code reuse: today, I can code a PID algorithm in five minutes flat. But it took me many hours of research and more than a few experiments before I really understood what was going on. Similarly, I spent many hours my rookie year developing a good 1-stick drive algorithm, but it's only a dozen lines of code. FIRST rules say I have to rewrite that every year - but that's trivial. The veteran advantage is not lines of code. It's knowledge.

I used to feel the way you do - that people were working to make programming easier, and I was going to lose my competitive advantage. I was wrong.

As a result, various libraries and frameworks and so forth can only be a good thing. It's not "babying" the rookie teams - effective tools raise the playing field for all of us.

For example, I could proclaim that the Linux command line is the true way, and that anyone who uses a GUI is a wimp. In fact, all the people working on GNOME, KDE, etc, are just showing pity to the clueless masses. The test of manhood is one's ability to rule the command line. It should be a matter of pride that you can use a computer. No! GUIs are useful software tools that have helped make computers mainstream, and have ushered in a whole host of applications. In the same way, higher-level robot functionality has the potential to bring in all kinds of innovations.

Re: I don't think being a rookie team has any effect on the programmers
 

Honestly, I'm not trying to make headway in autonomous so rookies can do it better; I'm doing it because I'm appalled at the lack of autonomous in FRC, and I want to make it easier for EVERYONE, including myself.
My basic goal is to bring the coding of autonomous up high-level enough where people can say "go forward until even x happens", instead of having to create a loop themselves and poll that data.
If you've ever used Applescript, you may notice it's plain English.
Okay, all the sentences have a fixed form, but it's really easy to understand, and it's pretty easy to think it. When people are new to programming, they don't automatically translate "wait until this button is pressed" into "poll this input in a loop, and stop if the value is true".
I'd like to make it have the simplicity of NXT-G, but with much more power and configurability. It's not low-level tasks are what make someone a software architect, it's the structuring of how tasks rely on eachother.

In addition to this, I'd like to be able to modify a canned autonomous by just modifying a text file. No recompiling, no redeploying. (I could even make a bug-checker for the file to see if it would be interpreted properly)

Re: I don't think being a rookie team has any effect on the programmers
 

Concurred. This year we decided to code in Java, but 1) we coded in Labview last year, and lost the code, 2) none of the mentors knew how to program in Java, 3) the only dedicated programmer on the team last year was never here to help us. Another programmer and I had to figure EVERYTHING out ourselves, from installing the software to imaging the cRIO to deploying code, with no help from the mentors. (I'm sure they would have gone to the ends of the earth to help us if we asked; we just never asked because it wasn't necessary.) We managed to get this year's robot driving within half an hour of it being finished, and finish the kicker code, middle wheel code (see photos of our robot to see what I'm talking about), etc. within 2 days.

I'm obviously bragging, but I wouldn't call either myself or the other programmer geniuses. We're certainly not expert programmers either. We just looked online for examples, copied them, and then dug into the API for more info. That worked for everything except camera code, which was a pain in the rear end, but that's another story.

Re: I don't think being a rookie team has any effect on the programmers
 

:ahh: Surprisingly, I did that this year, just go forward until the IR sensor is triggered then kick and stop moving and retract kicker... LOL Did not track the target or aimed at all... The flaw was in our old revision of our codes, was that the robot was going too fast so the IR sensor did not trigger and it kept going until it ran up against the tower, which got us a penalty, yea I learned from mistakes and fixed it, our goal was not to get the balls in, just merely kick and stop moving and compress air for teh tele op

Re: I don't think being a rookie team has any effect on the programmers
 

It's harder to be a rookie team member then a rookie member of a team because there are so many things you have to learn by your self in few days since you get the software in the KOP. Other team already have the software. That's the difference!

Re: I don't think being a rookie team has any effect on the programmers
 

^ Then again, this is only the second year with LV/WR/the new control system in general, and only the first year with Java.

Six weeks is plenty of time to get the software working, even if everything goes wrong (as it always does). Now if you actually plan to do some fancy programming, that's another story...