Making autonomous accessible to all teams

[kamocat]

Okay, here's another brainstorm thread.
How can we as a community make autonomous accessible/achievable to the majority of the FIRST community?

[kamocat]

Create resources:

• Create flexible and powerful methods of robot control
• Standardize method of inter-robot communication

Host workshops:

• Choosing the right sensor for the job
• Programming techniques
• Machine decision making
• Predicting movement of other robots

[dirienzo]

Originally Posted by kamocat

Create resources:

• Create flexible and powerful methods of robot control

What new methods do you think are needed? Or what methods supplied already need to be changed? A decent autonomous mode can be created by what is supplied by WPI, I think.

[Alan Anderson]

It's already dead simple to make an effective autonomous program using the Autonomous Independent framework in LabVIEW. Every team that asked me to help them was able to do it themselves only a few minutes after I showed them how it was intended to be used.

[Dale]

For teams without software mentors, the current FRC programming environments are just too difficult. While our team has never had a issue (since we have four years of computer science at our school) you only need to look at the number of robots on the field that just sit there during autonomous to understand that there's a problem.

There really needs to be something of the level of RobotC or even NXT-G (written in LabVIEW, by the way) for teams in this situation. LabVIEW is too much for some teams, forget about C++ or Java. A nice simple development environment and an easy to learn language is what it will take.

[sircedric4]

There was a toy I had as a kid that was called a Big Track. It was a toy tank that had a keypad in which you gave it a program to perform autonomously. Some sort of hand held easy computer with specific canned capabilities that plugs into the cRIO and programs it without other interfaces is the only way I can see EVERY team being able to do autonomous.

It may seem cold, underestimating the teams, but not every team can get an engineering or technical mentor, and not every team has students interested enough in computers to learn what they need to know to do autonomous. But this is a fact of life, that not everyone has the same resources and interests.

I think that FIRST is getting better at making autonomous modes that are worthy enough to pursue so that the challenge is there, but not so game breaking that only autonomous mode robots can win. I think keeping that balance is about all that can be expected.

[dirienzo]

Originally Posted by Dale

For teams without software mentors, the current FRC programming environments are just too difficult. While our team has never had a issue (since we have four years of computer science at our school) you only need to look at the number of robots on the field that just sit there during autonomous to understand that there's a problem.

There really needs to be something of the level of RobotC or even NXT-G (written in LabVIEW, by the way) for teams in this situation. LabVIEW is too much for some teams, forget about C++ or Java. A nice simple development environment and an easy to learn language is what it will take.

I'm sorry but I don't see how a simple Autonomous mode can be hard to write. You don't even need a year of Computer Science to know how to write it. I started learning Java during the build season and was able to write our Autonomous code. Like theprgramerdude, ours was about the same.

It just takes some time to learn the language, and read the documentation. There were some problems with the Camera and the tracking for us, so we decided to keep it simple.

[JABot67]

Originally Posted by Dale

For teams without software mentors, the current FRC programming environments are just too difficult. While our team has never had a issue (since we have four years of computer science at our school) you only need to look at the number of robots on the field that just sit there during autonomous to understand that there's a problem.

There really needs to be something of the level of RobotC or even NXT-G (written in LabVIEW, by the way) for teams in this situation. LabVIEW is too much for some teams, forget about C++ or Java. A nice simple development environment and an easy to learn language is what it will take.

I have to disagree. I hadn't used LabVIEW at all before the first week of build this year, and I was able to program multiple, successful autonomous modes by the time the build season ended. And I'm really not a programming genius either. The WPI Library, example code, and context help really allowed me to understand the way LabVIEW works, and I thought that going about editing Autonomous Independent VI was very intuitive and straightforward. By the end of MSC (the last competition where we used LabVIEW), our autonomous code was very advanced and used encoders, a pot, a gyro, and multiple PIDs. This proves that it doesn't take a really experienced programmer to use multiple sensors working together to implement an autonomous mode.

I've seen people on this forum complain that a team needs no programming skills, because everything is handed to them in the WPI Library. This might be true... If you want to use a simple tank drive or an arcade drive or holonomic drive or PID, that's all pre-programmed. I have to say thank you to the WPI Library, because without it, I would have had a much much harder time programming in LabVIEW. However I do think that in this advanced, high school level robotics competition with professional mentors, we should be using REAL programming languages and REAL programming environments. Not something like RobotC or NXTG that we're never going to see in our lives. Besides, we're learning about these more advanced languages in school and if not, the pre-knowledge of a language like C++ or Java or LabVIEW will vastly help for college courses and eventually careers in computers. Remember, this is a learning experience and preparation for college and careers in engineering, not just a robotics competition.

Perhaps the real reason why close to a majority of robots do not move in autonomous is that the teams did not have enough time to program or test their autonomous modes. Or, maybe they couldn't find the room or manpower to make a practice field. I could imagine many teams at the end of week 6 were just thinking about getting their robot together, or making weight, or getting their kicker to work, or adding a ball possession mechanism, or doing anything that the team considers more important than getting an autonomous working. I think that any team that has at least one dedicated programmer from week one can figure out how to do an autonomous, but whether or not there is time to debug and test it at the end of the season is a different story.

[kamocat]

Originally Posted by JABot67

Perhaps the real reason why close to a majority of robots do not move in autonomous is that the teams did not have enough time to program or test their autonomous modes. Or, maybe they couldn't find the room or manpower to make a practice field. I could imagine many teams at the end of week 6 were just thinking about getting their robot together, or making weight, or getting their kicker to work, or adding a ball possession mechanism, or doing anything that the team considers more important than getting an autonomous working. I think that any team that has at least one dedicated programmer from week one can figure out how to do an autonomous, but whether or not there is time to debug and test it at the end of the season is a different story.

You're probably right. Is there anything that can be done to remedy this?
I think the programming time tends to affect rookie teams the most, and isn't usually a big deal once programmers are familiar with the language. Our region holds pre-season workshops for such purposes, though many rookie teams are pulled together at the last minute. Releasing the WPI libraries before kickoff could be a big help as well.
But lack of time to test is something every team runs into. What about encouraging modular control systems that can be removed from the robot intact and used on a test setup while the robot undergoes mechanical changes? Educating on practices of testing algorithms on the PC? Modular code implementation? I have a software development guide which might help with this.

[mwtidd]

Originally Posted by kamocat

But lack of time to test is something every team runs into.

I think it would be interesting if FIRST provided a mini chassis set up, something that a student programmer could take home with them while the team worked on their chassis. If they provided several sensors, and a cookie cutter code for that test chassis it would be nice and I think it would help with the time issue. Also once the robot would ship you would still have a test chassis. I understand that it would not be nearly a one-to-one with the actual robot, but from discussion I don't think the fine tuning is why robots play dead, its because the "getting started" is something that is very low in many teams priorities, and fairly difficult to do.

As with any good programming language or technology there are tons of tutorials. However with FIRST these are few and far between. And the tutorials (sample code) that do exist are fairly intimidating.

I think the combination of an advanced framework that alleviates high level functions, a programming chassis, and tutorials would greatly lower the bar for getting started.

Based on this I would propose 3 steps:

1. Distribute a Test Chassis with very specific instructions on how to set it up.

2. Bundle a framework where all you have to do is define the parts of the robot
and the maneuvers.

3. Release a set of dozens of tutorials that your mother could follow and get working.

[efoote868]

This thread might've been more appropriate 3 years ago.

[mwtidd]

Originally Posted by efoote868

This thread might've been more appropriate 3 years ago.

Why isn't it appropriate now?

[efoote868]

Originally Posted by lineskier

Why isn't it appropriate now?

Didn't say that.


But, since you've asked:
Three years ago the challenge of programming the robot was so wholly different. Students had to use C, or easyC. They could not use Labview, Java, or C++.
They had to work with interrupts. They had to work with cameras that could only identify colors, not shapes. The values returned from the camera were only a bounding box, a density, and a centroid.
They could not use floating point arithmetic. They had a poor IDE, not like the labview or netbeans you use today.
They didn't get a laptop to interface to, they couldn't use USB joysticks (before the chicklet of course, which if I remember happened in '08).
Getting the robot to drive was a challenge.

We are leaps and bounds further than what teams had three years ago. Getting autonomous to work is about as much of a challenge as finding the appropriate tutorial.


That's what I mean when I say this thread would've been more appropriate 3 years ago.

[sircedric4]

Originally Posted by efoote868

Getting autonomous to work is about as much of a challenge as finding the appropriate tutorial.

And I think this statement is the fundamental problem. I have been mentoring for 5 years now, and if there's one thing I have learned about FIRST it is that finding the documentation, the tutorials and examples is the single biggest obstacle to overcome.

Every year, I show my students the 19 different websites they need to go to to find programming knowledge, the updates for the software, etc... I have yet to have a single student overcome that website scavenger hunt enough to program adequately. Many are bright kids, but let's face it, we are a society that only goes to the instruction manual after we have blown the product up. Make that instruction manual difficult to find, and the students won't even try.

If you really want to help the non-autonomous teams to get there, without the aforementioned mentor instruction, then somebody really needs to make a SINGLE repository of ALL the data, manuals and software. Index that data so anyone can find what they are looking for, and make no assumptions! Pretend that the person trying to program doesn't know what a class or method is, has never heard of C++ or Labview, doesn't know how to install the software, and make your tutorials start at that level.

Eliminate the scavenger hunt, stop updating the software every two seconds, and make sure your examples and tutorials work. That will help a majority of the people I feel.

[exprg:melonhead]

i kinda like the idea of leveling the playing field for everyone, but here's the issue: we are not here to prove who can win, but rather, we are here to learn. if you just hand a team an autonomous mode, and tell them it works, they'll use it. i know i would, only because i put so much into it. but what do you learn about programming in this situation? people need to realize that autonomous is not that far off from teleop. it just seems a little intimidating. really, i think the only thing to really do is try to help those teams that have a hard time with it. otherwise, by "helping" you may be doing their team harm if you just hand autonomous to them.