Programmers: I Have A Challenge For You

[sircedric4]

So maybe I missed it, but it seems that a VAST majority of the teams have a hard enough time getting their robot to just move forward and do one small thing during autonomous. How exactly would you do this challenge and still keep it rookie friendly?

Are we talking about seriously canned code here with simple GUI interfaces. For example I had a toy when I was a kid called a Big Track where you programmed what you wanted it to do, then activated it and watched it. It only had certain moves it could do and it was programmed from a small keypad. The point is that it had canned algorithms that required nothing but parameters. Unless someone comes up with code this simple I just can't see FIRST going full autonomous.

Now if the powerhouse teams are bored with their standard coding, maybe there can be an advanced FIRST like event at the college level that could do this kind of stuff. I have a hard enough time getting any of my students to even program teleop and that's easy compared to the 15 second autonomous mode. Now tell them the robot can't even compete unless they put a mars rover amount of code into it and I won't have any students left.

[davidthefat]

Originally Posted by sircedric4

So maybe I missed it, but it seems that a VAST majority of the teams have a hard enough time getting their robot to just move forward and do one small thing during autonomous. How exactly would you do this challenge and still keep it rookie friendly?

Are we talking about seriously canned code here with simple GUI interfaces. For example I had a toy when I was a kid called a Big Track where you programmed what you wanted it to do, then activated it and watched it. It only had certain moves it could do and it was programmed from a small keypad. The point is that it had canned algorithms that required nothing but parameters. Unless someone comes up with code this simple I just can't see FIRST going full autonomous.

Now if the powerhouse teams are bored with their standard coding, maybe there can be an advanced FIRST like event at the college level that could do this kind of stuff. I have a hard enough time getting any of my students to even program teleop and that's easy compared to the 15 second autonomous mode. Now tell them the robot can't even compete unless they put a mars rover amount of code into it and I won't have any students left.

Now really is that true? I mean if a programmer has any idea what he is doing, he can get the drive working just by looking at the API... I think new programmers don't look at APIs but more towards step by step applications of it like a tutorial...

Actually I believe you, there is this one "programmer" that has no idea what he is doing, and all he knows is if statements... Doesnt even know what a variable is really...

[mwtidd]

Originally Posted by sircedric4

So maybe I missed it, but it seems that a VAST majority of the teams have a hard enough time getting their robot to just move forward and do one small thing during autonomous. How exactly would you do this challenge and still keep it rookie friendly?

This is actually the goal of my ADK, which is a collaborative initiative to bring an autonomous framework that would be easy to use. What I realized this year is that dozens of teams programmed a drive forward and kick. Why not just have one team do it and share it. The goal of the ADK is to give you cookie cutter templates to create code that can run the same autonomous as another team.

we are looking for more teams to sign on (so far we have 4)
there are repositories for both java and c++, but I need a lead developer for the c++

here is a link to the project:

http://firstforge.wpi.edu/sf/projects/bobotics

[sircedric4]

Originally Posted by davidthefat

Now really is that true? I mean if a programmer has any idea what he is doing, he can get the drive working just by looking at the API... I think new programmers don't look at APIs but more towards step by step applications of it like a tutorial...

Actually I believe you, there is this one "programmer" that has no idea what he is doing, and all he knows is if statements... Doesnt even know what a variable is really...

Well there is the simple matter that with most rookie teams I have seen and is still true for our second year team, its that the teams are still fairly small. It doesn't surprise me that there is little interest in programming when you only have 15 people on a team. From our area, they are mostly interested in the actual mechanical stuff, which is perfectly fine.

We do have a couple this year that were interested in programming, but only when it was at the school meetings and only while you were standing over their shoulder. :-) They had no motivation to look at it on their own time even with the links and training presentations provided to them. The problem is that it is very difficult to give the necessary training in the programming when you only have a 6 week build season. There's just not enough time to be training and doing at the same time with small teams, unless the students are self-motivating and interested. (I do look forward to one of these mythical students that the people recommending this challenge have, it'll make my workload easier that's for sure.)

I think FIRST recognizes this which is why they went with the WPI libraries. The WPI libraries have been life savers in that they have let us attempt some cool things we wouldn't have the ability to do otherwise. (now if they could just get some good documentation and a decent "canned" example on every library function it would be perfect) And even with all these programming helpers, there is still half the teams at the regionals I have attended that are lucky to have a working robot. Remember that not all mentors are engineers or programming professionals, they are teachers and parents that might not have experienced this stuff before.

So unless you are talking about having some heavily canned autonomous modes that can be mixed and matched, I just don't see how FIRST could go with this as an entire game's goals. That is of course if they want to continue to let new teams play that don't have vast resources. Now if the teams that signed up are just setting challenges for themselves because they already have got the basics zipped up, well then that's a good thing and I look forward to what they come up with.

I am one that is in favor of raising the less capable up instead of bringing the high flyers down, but it has to be done in fairly small steps. Like some Star Trek Prime Directive, we can't give pre-industrial age men nuclear propulsion and expect them to know how to take advantage of it. Not without the education that goes with it. I really do think FIRST could do with a "varsity" and "junior varsity" level. And I feel that the level should be based on the resources a team has, the size of the team, and the mentor skills available to that team, but I don't know how you would split the teams up correctly.

[mwtidd]

Originally Posted by sircedric4

I really do think FIRST could do with a "varsity" and "junior varsity" level. And I feel that the level should be based on the resources a team has, the size of the team, and the mentor skills available to that team, but I don't know how you would split the teams up correctly.

FIRST has a history of teams wins losses and ties. I think it would be interesting rather than having a JV Varsity division, have teams of robots that you compete with throughout the comp. You could easily arrange these teams based on records. It would also bring upon an aspect of long distance collaboration which is critical in business and even certain college projects.

[kamocat]

Don't assume that many older teams have more programming expertise than the rookies. This will be a struggle for the whole FIRST community. However, we have some things to help us here.

1. A common platform spec, to make generic code independent of the robot.
http://spreadsheets.google.com/ccc?key=0AgYDudKXpgOzcFI5aW5EUVhnVVUxNUVuQTdZLWNIW Xc&hl=en

2. Canned moves, as you were saying. They can be stringed in a sequence with the error terminals. An alternative is wiring an enum array into a for loop, where a case structure executes the correct move (determined by the value of the enum).

3. Simple GUI interfaces: LabVIEW. Next year we will have LabVIEW 2009, with the addition of some nice features like snippets.

4. Collaboration, communication, sharing of resources. I do LabVIEW and control system workshops in my area. I try to collaborate with people to make sure the community progresses as a whole.

The point is to start programmers out from a very high-level view in autonomous: I want the robot to do this, then this, then this, then this. If sonar value is less than 20in, then turn right. Otherwise, keep following the line. And so on.

Of everything on the robot, programming is the hardest to explain, and so it needs the biggest push. We're not coding machine language anymore. A well-documented VI can be understood by normal people, so long as they know that data flows along the wires, and a subVI won't execute until it gets data from all its wired inputs. Block diagrams are a pretty clear way of thinking.

I understand your concern. It's a little scary to think of 6 150lb robots moving around a field without direct human control, especially with little testing.
FIRST sometimes challenges us in ways that we think are unnecessary, and there are some challenges we'd like in FIRST that aren't yet present. One of the major selling points of this control system is that it makes it more feasible to do a comprehensive autonomous. Autonomous is underrepresented in FRC; in FLL, it's virtually all autonomous, and FTC gets 30s of autonomous per match. I believe the reason FIRST hasn't made autonomous a larger portion of the match is not that they think we're not capable, but that they want to draw in spectators, and make the game interesting. They're struggling to balance between popularity and technical prowess.
I certainly won't stop them from encouraging new teams, but I'm going to push for technical proficiency in all FIRST teams.

The biggest one is how to solve a problem. It's a process. You must single out the problem, clearly define a solution, and test that solution.
Similarly, with code, you must define what you want to accomplish and how you are going to accomplish it before you try to code the whole thing. Take a look at my Software Development Process.



sircedric4, I do think one of the problems you're running into is people not understanding the fun, importantness, or awesomeness of programming. Often it can be hard to convey, because people assume it's simply geeky. People have streams of thought, and so do robots. If they can describe each decision the robot will make, then that's half the programming. It's like giving someone a set of instructions, but that person only knows what it's been told, and what it is told by the sensors you put on the robot.

[sircedric4]

3. Simple GUI interfaces: LabVIEW. Next year we will have LabVIEW 2009, with the addition of some nice features like snippets.

I will check this link out, but as for simple GUI interfaces, I have never found Labview code easy to read. Maybe its because I am used to text programming and think in pseudocode to begin with, but I have always found it easier to follow steps right down a page. I look at Labview flowcharts and my brain just freezes. There are just too many icons that don't mean anything to me. Where with text code I can at least recognize a word.

This is a problem I recognize, especially with people moving toward GUI stuff more and more everyday, that I am trying to remedy, but it is hard to "grok" once you've worn other coding tracks into your brain. It why I also have a hard time getting my head around object oriented programming, because when I learned everything was straight down the page and easy to follow. I mean I learned on FORTRAN and still use it and Visual Basic day to day. Most of the new stuff I do is written for VBA because everyone has Excel.

I'm just saying that just because some people can follow flowcharts easier doesn't mean everyone can. People all have different thought methods and I like that FIRST maintains all 3 code bases to support whatever your thought model is. And there is something that just gripes my open source heart when LabView is a 3rd party proprietary language when C++ and Java have free development environments. I think that whatever coding would come out of an all autonomous task would need to be useable by both types of coders, grapical and text based.

sircedric4, I do think one of the problems you're running into is people not understanding the fun, importantness, or awesomeness of programming. Often it can be hard to convey, because people assume it's simply geeky. People have streams of thought, and so do robots. If they can describe each decision the robot will make, then that's half the programming. It's like giving someone a set of instructions, but that person only knows what it's been told, and what it is told by the sensors you put on the robot.

You are right here, and its something I try to convey to my students, but getting the students to make a decision isn't always easy. I don't know if its reverse peer pressure and those that are really into it are afraid to shine and speak up or what. High school is a pressure cooker, seeing the difference in maturity level between a freshman and a senior, so it can be hard to get new information into their already overworked brains. :-) It's a lot of fun seeing the students change though as they become more aware of what they are capable of. I am hoping since I finally have some younger students and not just all seniors on their way out that some will grow into liking programming once they've been exposed to it and how important it is.

I imagine each team has to fight with attrition and changing high school environments and students, so once again I can't see a way to do full autonomous without some locked up, easy to understand, and pre-canned repository. We all live in a real world environment, with different resources, and I think from looking at the Regionals, this is a huge undertaking. Worthy for the teams who can do it, but as a game design goal I hesitate to try it.

[synth3tk]

Originally Posted by davidthefat

Actually I believe you, there is this one "programmer" that has no idea what he is doing, and all he knows is if statements... Doesnt even know what a variable is really...

Did you help him learn?

[ideasrule]

Originally Posted by lineskier

we are looking for more teams to sign on (so far we have 4)
there are repositories for both java and c++, but I need a lead developer for the c++

here is a link to the project:

http://firstforge.wpi.edu/sf/projects/bobotics

Given the complexity of the undertaking, I think it's better to focus on one project than to have two projects going in different directions. If some people here only know one language, I can help convert C++ code into Java code or vice versa, so that's not a problem.

[ideasrule]

Originally Posted by sircedric4

So maybe I missed it, but it seems that a VAST majority of the teams have a hard enough time getting their robot to just move forward and do one small thing during autonomous. How exactly would you do this challenge and still keep it rookie friendly?

I know that rookie teams are fairly small, but it only takes one competent programmer to write all the code in teleop and (at least this year) write a successful autonomous. It takes much more than one person to machine the parts and assemble the robot. If a team can't get one competent programmer, there's something wrong with the recruitment efforts.

Currently, teams with great mechanical skills or great strategies dominate the competition. Why shouldn't teams with great programmers be rewarded as well?

[davidthefat]

Originally Posted by synth3tk

Did you help him learn?

Actually he thinks he know everything and he doesnt listen and he says "I know" and Just don't like him personally. I cod something and hes right next to me watching, and when I get the code to work right, and the team leader congratulates me, he says "WE did it, It was team work" Obviously not... But he is older than me, and Its alright if he thinks he can do it...

[sircedric4]

Originally Posted by ideasrule

I know that rookie teams are fairly small, but it only takes one competent programmer to write all the code in teleop and (at least this year) write a successful autonomous. It takes much more than one person to machine the parts and assemble the robot. If a team can't get one competent programmer, there's something wrong with the recruitment efforts.

Currently, teams with great mechanical skills or great strategies dominate the competition. Why shouldn't teams with great programmers be rewarded as well?

Uh, I agree with you, great programming teams should be and are quite obviously rewarded just like good mechanical bots. But to continue your analogy, teams can still build the basic kitbot and compete, all I am saying is that you need that same level of head start if you are going to tackle this full auto as a game challenge. This goes back to the needing canned algorithms thing.

And as for recruitment efforts and finding competent programmers let's remember that not everyone has the resources, contacts, or interest and recognize that not every team can get a competent programmer all the time. I live in the real world and there isn't enough time in the day sometimes. As it is, our team does have one competent programmer and its the mentor your chatting with right here. :-) I can name 6 teams in my immediate area that don't have the luxury of a dedicated programmer and they get help where they can. I just think when setting up game designs, the GDC does remember to give a little consideration to smaller teams (which I would be willing to bet is the vast majority of teams, just not the powerhouse known teams) and as such I don't expect to see fully auto as a requirement anytime soon.

[AustinSchuh]

Originally Posted by sircedric4

I do look forward to one of these mythical students that the people recommending this challenge have, it'll make my workload easier that's for sure.

You and every other team around... 971 has been blessed to get one about every 4 years. Now that I look back and think about it, our current programmer at any point in time seems to be the one that finds the next programmer and trains them. If anyone has any tips on how to find self-motivated and talented programmers, I'm willing to bet that there are a lot of teams who would be interested in listening. Come to think of it, 111 might have some good ideas.

[ideasrule]

Originally Posted by sircedric4

Uh, I agree with you, great programming teams should be and are quite obviously rewarded just like good mechanical bots. But to continue your analogy, teams can still build the basic kitbot and compete, all I am saying is that you need that same level of head start if you are going to tackle this full auto as a game challenge. This goes back to the needing canned algorithms thing.

I don't think anybody here is saying that FIRST should require all matches to be fully autonomous. Some people, like me, think that autonomous mode should be made at least as important to the match as teleop. Right now, you hardly need any autonomous at all; if your robot is mechanically well-built and well-designed, you're going to win the match.

[gblake]

Originally Posted by lineskier

we are looking for more teams to sign on (so far we have 4)
there are repositories for both java and c++, but I need a lead developer for the c++

here is a link to the project:

http://firstforge.wpi.edu/sf/projects/bobotics

I'm curious who the four folks/teams are, and how you are organizing your assault on this mountain - Can you post a few of the project schedule milestones and high-level software architecture outlines? Those would be good fodder for this thread.

Blake