Re: Making autonomous accessible to all teams
 

I would compare FIRST to the senior level DB course I just took. WPI has 7 week terms, so it is a very close match to a FIRST build season. Rather than building a database from the ground up, we built extensions on an existing framework. It sounds like many of the objectors to an ADK of sorts are arguing that it would make it too simple. I would argue that this is not that case.

The DB package worked out of the box requiring only one class to be created to utilize it, I believe and ADK could work similarly. However the cookie cutter DB package was greatly lacking, if you were to utilize it you would want to build extensions.

For one of our extensions the goals was to create a deadlock prevention algorithm utilizing a loop finding algorithm. I use this example because if you utilize a state machine in your autonomous, you may want to find loops too. Any ADK would require teams to extend it, in order to accomplish anything beyond a sequential autonomous.

this is a video of our robot from '06, to accomplish this a state machine was necessary.
http://video.google.com/videoplay?do...3997861101882#

I am just saying that utilizing a framework such as an ADK, would give students a soft-eng perspective, and teach them how to build extensions to existing frameworks. Also it would give them the opportunity to delve into some higher level design learning ( I <3 the factory pattern).

Such an ADK would introduce students to:
Threads
Design Patterns
Soft Eng
Algorithms
State Machines
and I'm sure much more....

Re: Making autonomous accessible to all teams
 

I find this discussion similar to this thread in that an ADK of sorts would be an excellent resource for developing a working knowledge of how higher level code development and implementation is done, but by no means replaces the preexisting methods of writing autonomous scratch, which provides experience in a lower level of the process. And I think should such an ADK be developed, it would be used at the discretion of teams who are deciding whether they want to get into the nitty-gritty of doing it all themselves, learning the basics of what goes on in the autonomous code; or learning how to build off of someone else's packaged work to create more sophisticated, higher level programs (much like Assembly, C/C++, Java/C#, and on up).

Re: Making autonomous accessible to all teams
 

Why would anyone want to do that? Check out FIRST's mission statement:

While better-organized documentation is always welcome, the single most important resource that can be made available to teams is a good mentor. If necessary, divert some effort from fundraising and put it toward recruiting.

Re: Making autonomous accessible to all teams
 

Alan, heaven knows I agree that FIRST without mentors would be like the Fourth of July without parades. In this case I have to say that making it simpler to do a basic autonomous would be beneficial in all cases. In the case where a team has a software mentor they could then spend more time teaching concepts rather than doing implementations. In the case where the team does not they could spend more time finding a software mentor.

Now, the number one thing that needs to change in order for auton to be accessible to all teams? In my opinion points. The auton has to be able to swing a match if done well. Think back to 2006 (or 2008), many teams had autons because it was worth it. The last couple years (2008 excepting) it simply was either too hard (2005) or not worth it at all (2007, 2009) to try to score in auton.

Re: Making autonomous accessible to all teams
 

I guess I just don't see how doing a basic autonomous can be any simpler than it already is. It seems to me that teams unable to understand the directions for using the LabVIEW Autonomous Independent without someone holding their hand won't be able to use anything without help.

We don't need to give the teams more tools. We need to give them personal support. Whether that support helps them to use the tools they already have, or whether it comes with a new tool that they might end up being more effective with, is relatively unimportant.

Re: Making autonomous accessible to all teams
 

Alan, how long have you been programming? I agree with you that auton is easier now than it has ever been but we are not the people who are having problems with it. They need better support but they want more tools. I don't know, is it better to give someone what they want or what they need?

Re: Making autonomous accessible to all teams
 

I meant to imply technical and programming mentor support. ;-) Just because a team has a mentor doesn't mean they have a competent programming one. Making the documentation where any layman can find it and understand it is the only way I see getting all the teams playing autonomously.

I think part of the problem from this community now, is that those of us that are old hat at this robot thing don't remember how completely clueless most rookie and early year teams are. The simple fact is that many of them are so resource starved and thrown in the deep end that getting a working robot is a feat in itself. Most of them don't even know to come here for help, so all the spit balling we do here isn't going to help much. FIRST, the organization, needs to do some serious documentation indexing, put all that data on their MAIN site, and have obvious links to the helpers here. I think that's the only way you'll get the eyes that need the help, the help they need.

I am not so far removed that I don't remember the horrid scavenger hunt and the fact that FIRST continues to throw "gotchas" and updates in their examples and software. Now, personally, I see this as part of the challenge and I am never one to give up pursuing a lead when I have one, but many, many people are not this way. This is more a philosophical discussion then a problem to be solved. Do we want to make it so easy everyone can do it, or do we still want to have some challenge that they have to learn to do it?

The topic is making it accessible to all teams, which I feel is an awesome idea, but not one that will come about without serious compromises. Better documents and a code base that doesn't continously change can at least help those that want to learn, how to learn. (and I mean everyone from current expert mentors, to new "drowning" mentors, to the students themselves)

Re: Making autonomous accessible to all teams
 

Simply put. I don't have someone holding my hand. I can stare at labview hours on end, and I still don't understand it. I simply don't have a mind that is capable of it with out someone walking me through it. The problem? I simply don't know where to find someone to help me when the programming team is to busy to show up to all the meetings. So simply put, it's not always the idiots fault.

*Steps off soap box*

Re: Making autonomous accessible to all teams
 

I agree that nothing can replace the support of a mentor, however programming is not like putting together an erector set. Almost any shop teacher can act as an engineering mentor for this competition. I don't think the same is true for programming. I do not think there is way to guarantee every team will have access to a programming mentor.

What is hurting autonomous in FIRST right now is not the tools, but the education, and I don't think that FIRST wants to provide the education as many have pointed out. I think FIRST wants to provide the tools and then encourage the students seek the education.

My thoughts with the ADK would be that it would be both an open source framework, and an alliance-led framework. It would give us control over what we were teaching, and in doing so we could lead a For Teams By Teams programming education initiative. We could work to put together a video series and curriculum to help young programmers learn and act as the mentor base to many more teams than just our own.

Re: Making autonomous accessible to all teams
 

Autonomous is pretty simple, at least in the last two years (didn't check the earlier ones..)
Last year was my team's rookie year and because of many problems, we started two weeks after kickoff, exactly when I started studying Labview.
After a week or two, I was able to program a simple auto part.
All i used is NI's site, youtube videos and 0 mentors.

This year, we helped a rookie team and I taught them all the programming part in one day. None of their programmers had any exprience in programming, and after that day they programmed a nice auto part for this season (and of course all the other code).

So, in conclusion, I have to say that with enough time before or even during build season, enough resources and a little bit of help from other teams, each rookie team can do whatever they want~.

Re: Making autonomous accessible to all teams
 

I'd guess that many teams are not doing much in autonomous because the hardware is still being built and fixed as the robot ships, and fixed some more at the regional, and fixed again after every match. The programmers don't get much access to the robot.

I'm most familiar with the C++ environment and will only comment on that. The Eclipse IDE I dislike but it it is what it is. For a rookie to load up one of the demos is quite a challenge. I take it for granted, but it can be overwhelming especially when you have to set up the link to the cRIO and download and debug. Simple it is most definitely not. How many threads were there this year on getting the darn camera code to run? Well, you need this version of that with this version of this, add some crushed bats tail, add water, cross fingers. Precious time can be wasted on finding the library gotchas, and that's all time taken away from programming autonomous.

Why are there both simple and iterative templates? Iterative is the only one needed, considering that it can do what the simple one does plus more. Our autonomous code was about 3 lines, a state machine that read a table to control all the mechanics. We had grand plans to do lots of stuff in autonomous but the hardware became available to test on the morning of the regional, so surprise, not much was accomplished but we could push in balls and get out of the way. Not bad for 30 minutes of robot access. Perhaps example code like that would get more teams coding autonomous, but I'm not at all convinced that it's only programming that is preventing more autonomous robots. The bigger picture is that the smaller and newer teams run out of time.

For the teams that have the time to code autonomous but are are finding autonomous difficult, is there a concensus as to why? It's essential to know why. Perhaps start a thread with a poll to ask?

If this is an effort to "level the playing field", be prepared for disappointing results. Teams that appear to be larger than some entire schools (e.g. Uberbots) have more resources and will generally produce superior results than smaller and less well funded teams. There's nothing wrong with that, more power to them. All teams have equal opportunity, but someone will still come dead last and about half the teams will be below average.

Re: Making autonomous accessible to all teams
 

I completely agree, which is why more teams need to learn to use simulation to work on their software.

See http://www.chiefdelphi.com/media/papers/2331

I spent all of about 45 minutes writing that paper, so maybe it isn't all that clear. If people think that it may be useful but not in its current form, I'd be more than happy to modify and update it to make it more useful.

Re: Making autonomous accessible to all teams
 

My programming experience began in the mid '70s, using the MC6800 (the first Motorola microprocessor). [codger]I was writing software for radio-controlled robots before any of the students here were born.[/codger]

That's easy: give them what they need. I'm in this for their benefit, not mine, and I gain nothing by stringing them along. To give them something to replace what they can't use well does not help them if they can't use the replacement well either.

I understood what you meant. My reply might not have been clear enough: teams who want to do well in the programming area of the challenge should seek programming mentorship. Finding a competent programmer is not terribly hard these days. The real work is in convincing one to give of his time to a high school robotics team. That's why I put an emphasis on recruiting.

I agree that the documentation has become a little scattered over the past couple of years, though everything I used is reachable through links starting on the FIRST web site. It's the "and understand it" part where things really break down. We've seen that some people just don't make an easy transition from what they're reading to actually doing it unless they work with someone who knows what they're doing.

Putting in the extreme detail required for someone to start from scratch without additional assistance has two potential pitfalls. First, it bulks up the required reading to the point where it might be too intimidating. Second, it crowds the really significant points with helpful but less crucial ones.

Turning the existing documentation into a coherent resource with a good index and tutorial sections would be a great project for some of the people who currently want to write frameworks (which would require yet more documentation in yet more places, likely making the situation worse). I think a reasonable arrangement would be to split it into six parts.

1. A basic but complete overview of the system, describing the control hardware, development environments, and software frameworks without giving distracting details.
2. A collection of checklists calling out exactly what steps to take to install and set up the system, keypress by keypress, button click by button click, what to plug in and when, what wiring connections to make, etc.
3. A "cookbook" giving specific "recipes" for implementing common tasks, preferably in conjunction with things like the LVMastery videos.
4. A complete tour and explanation of the software frameworks, pointing out each place where customization is expected or encouraged.
5. A hardware manual, showing how to connect everything that is explicitly supported by the system, such as servos, motor speed controllers, ultrasonic rangefinders, quadrature encoders, switch-type sensors, etc.
6. A good reference for the library functions.

It's still not going to be enough for some of the teams out there who don't know they need help, don't believe they need help when they are told it is available to them if they want it, and even refuse help when it is freely offered. But that's a topic for another thread entirely.

Access to a programming mentor does not necessarily mean on-site tutoring. Quite a lot of teams got some useful mentoring this season right here in the forums. They just had to know where to ask, though that in itself is a perennial issue.

The dedicated and driven students will find the education regardless. It's the slightly less dedicated but no less important ones who need active guidance. It's as much a question of logistics as it is one of philosophy -- how do we reach the teams who don't yet know we are trying to reach them? There are team members who know they need help but lack both the knowledge of how to find it and the insight to ask others who do have that knowledge. How do we initiate personal contact with those members?