Making autonomous accessible to all teams

[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?

[Tanner]

For my team, I didn't think about programming autonomous until the 4-5th week into the season. I knew what I wanted to do, but I didn't know exactly how I wanted to execute it. During the season when I was writing the code for the robot, I kept it in a format so that I could simply tell it what I wanted it to do, and the rest of the code would take care of it without me having to think about it. Combining this format with autonomous made it very easy for me to program autonomous including the various sensors that was required for the kicking system on the robot to work. Though, it did take me a regional to get it right due to lack of testing (mostly my fault though).

I think autonomous programming can be made easily enough if the programmer has made things modular (i.e. like I did) thereby reducing the workload when it comes to the autonomous part.

As an idea over the summer, I was thinking about teaching some interested programmers some of the thought-process that is required for programmign a FRC robot (or for that matter anything) with an arduino with a few sensors set up and perhaps a servo or two. It's a small and relatively cheap platform that is quite easy to use. To program it runs a C-like language, so it's not quite ideal for LabVIEW use, but I'm sure it could be easily modified for such.

-Tanner

[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.

[gblake]

Folks - I don't want to turn this thread into a navel-gazing session; but...

It is obvious from the honest reports in this thread that "autonomous" is both easy and hard. So that means that "autonomous" isn't really what you should focus on. There is something more fundamental to be uncovered and discussed.

Apparently "Making autonomous accessible to all teams" is a useful title, but it steers the conversation just a bit in the wrong direction; and that bit is an important one.

For any team or individual that finds writing, integrating, testing and refining autonomous code for their FRC bot easy, we need to figure out what differences exist between that team/individual, and teams/individuals who find it hard.

Once those root causes are identified (and it is likely to take some digging to get past superficial differences and get to the true roots of the differences) then we will be ready to create a new thread entitled "Changing ___ in order to prepare each team to do well in autonomous".

To those of you who are contradicting your bright and eager, but frustrated, colleagues by asserting that "autonomous" is easy; you are missing out on a chance to be good mentors.

Obviously a blanket statement that autonomous is easy, or that library XYZ or tool abc is easy to use, is at least partially wrong. Honest, bright, well-motivated people are telling you that they are having problems; and I'll assert that they represent a non-trivial fraction of the intended users.

The brainpower contributing to this thread needs to have a dialog that gets to the roots of why some/many people and team aren't being successful, and then give advice to the tool suppliers for improving the tools, and also give advice to tool users that will get them past their roadblocks so that they can become successful with the current tools.

If autonomous is simultaneously hard and easy, then just talking about "autonomous" isn't going to be a complete discussion. Let's dig deeper and find out what is really causing us to fall short of our goals.

Blake

[Alan Anderson]

Originally Posted by gblake

Let's dig deeper and find out what is really causing us to fall short of our goals.

My theory is that the shortfall can be blamed primarily on a lack of experienced mentorship. The people who are having real problems are unable to make use of the instructions. I do not believe the instructions are faulty, but I already know what they say so I might be blind to a significant deficiency.

My experience is that some very talented programmers merely do not learn well from reading the instructions. Once they are walked through the steps and shown how to apply the tools by a knowledgeable mentor, they can do well. They just need the mentorship in order to help them over the hurdles.

[Robototes2412]

Personally, I think that you need to learn how to walk before you run.

Autonomous can be done by recording what people do during a teleop match, programming it in, then excecuting it.

Using Java, you can use GRT's File IO class to do this. Make a String at the beginning of the class. At the end of each loop call:

fooString = fooString += "j1x1: " + joy1.getx1() + " joy1y1: " + joy1.gety1() + fired ? "    Fired" : "" + "      Time: " + edu.wpi.first.wpilibj.Timer.getUsClock();

Yes, i know i'm using a ternary operator here.

finally, set a button to call:

GRTFileIO.writeToFile("forAuto", fooString);

Then work on turning the log into a function, and volia.

Here is the GRTFileIO Class in case you need it:

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */

package com.shadowh511.mayor.utils;

import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import javax.microedition.io.Connector;
import com.sun.squawk.io.BufferedReader;
import com.sun.squawk.microedition.io.FileConnection;

/*
 * I copied this code from the GRT Framework
 */

public class GRTFileIO {
	public static String getFileContents(String filename) {
		String url = "file:///" + filename;
		String contents = "";
		try {
			FileConnection c = (FileConnection) Connector.open(url);
			BufferedReader buf = new BufferedReader(new InputStreamReader(c
					.openInputStream()));
			String line = "";
			while ((line = buf.readLine()) != null) {
				contents += line + "\n";
			}
			c.close();
		} catch (IOException e) {
			e.printStackTrace();
		}
		return contents;
	}

	public static void writeToFile(String filename, String contents) {
		String url = "file:///" + filename;
		try {
			FileConnection c = (FileConnection) Connector.open(url);
			OutputStreamWriter writer = new OutputStreamWriter(c
					.openOutputStream());
			writer.write(contents);
			c.close();
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

[taichichuan]

Hmm... Well, there is certainly some controversy over what constitutes a "robot". The Robotics Institute of America seems to believe that a robot's "common characteristic is that by its appearance or movements, a robot often conveys a sense that it has intent or agency of its own." I think that's where our autonomous mode comes into play. In fact, many robotics "experts" would not even refer to a teleoperated device as a robot in the first place.

That being said, I do feel that the significant difference between the "move 2 seconds straight ahead, kick, two more seconds, kick and then strafe to get out of the way" kinds of behavior and the "I'm in a green field, find a light colored, spherical object and acquire it, find something elliptical, kick the spherical thing towards the elliptical thing" kind of behavior. Which one of these represents true autonomous behavior? The answer depends on who you talk to.

On the one hand, even the former behavior is more interesting than simply sitting there for 20 secs waiting for the operators to "drive" the robots. And, there are certainly frameworks that can help implement the former types of behavior. So, at one level, we need to make sure that more teams are capable of at least handling the simple movements. How we achieve this as mentors depends on the makeup of your team in any given year.

What differentiates the latter behavior is the ability to use sensors. Understanding the concepts of a state machine, the gozintas and gozouttas on the robot, what the voltages from the sensors actually mean, etc. enable not only autonomous behaviors but also operator assists in teleop mode. Think of not being able to see a ball in the middle zone from the driver's station because of the bump. You're stuck strafing along until you get lucky enough to bounce a ball into your line of sight. But, what about being able to punch a "find ball and shoot it at the target" button? Now, you're able to seriously understand the capabilities of our robots. The KOP components are there to enable this kind of operation. We just need to know how to use them.

How can you create such behavior? Enable the students with knowledge and let them use their imaginations . What we really need is a detailed set of materials that describe sensor concepts, state machines, drive-train concepts, scripting concepts, etc. so mentors can have the source material to help teach the students what these concepts are and how they're applied. Here in the D.C. region, many of us (mentors) have been getting together to talk about what that kind of material should look like and how best to present it.

I don't feel that there's a silver bullet that makes autonomous easy. But, we can go a long way to demystify it for the students and ourselves. There is a lot of collective wisdom here in the FIRST community. We need to take steps to actually collect it, write it down and enhance it with some exercises (that use things found in the KOP) than can be easily reproduced.

We may not have to explain the concept of infrared radiation, but we should be able to explain how an infrared sensor works to determine distance. And, with the proper enhancements to WPILib or LabView VIs, enable students to use the infrared sensor. What they do with that knowledge is up to them (with our guidance, of course ). But, I believe that net effect will be more interesting autonomous play.

So, where can we start collecting this information? What form should it be in? How do you teach mentors to teach information that they themselves may not understand? All good questions. Anyone up for a mentor meeting at IRI or other events to discuss?

[FRC4ME]

In my opinion, autonomous doesn't need to be made any easier for several reasons:

1. It is already as easy as possible while still remaining a learning experience. As others have mentioned, creating a simple autonomous mode in LabVIEW or Java can be done in a few minutes just by reading the documentation. WPILib is already so high-level; to make the robot drive you literally call the drive() method. What's next? The playThisYearsGame() method? Too bad those types of prepackaged solutions don't exist in the real world.

2. Something has to provide veteran teams with a challenge and give rookies something to strive for. Saying that every team not doing autonomous is a problem is like saying that every team not hanging from the bar is a problem, and we should provide a hang-from-the-bar module in the KoP. Because, you know, that way teams can focus on what they want their robot to do, and not worry about low-level details like nuts, bolts, and metal.

3. FIRST is also about preparing students with real-world engineering skills and giving them an edge in the industry. There is no better way to do this than to give the students access to the very development packages professionals use. Stripped-down learning tools have their place (in classrooms, for example), but here in FIRST, I believe we should try to stick with the professional tools as much as possible.

On my high school team, I went from absolutely no programming experience to expert knowledge of C++ and object-oriented programming in one season, precisely because I had to do it myself. Granted, I had a wonderful mentor to help me out, but once again, the mentor-student relationship is one of the core values of FIRST. This is why I think the crop of "so easy a rookie can do it!" autonomous frameworks and initiatives that show up every season are misguided. It's wonderful that experienced teams wish to share their expertise with the community, but I think they should use that knowledge to release products intended to teach rookie teams about programming, rather than to do it for them.

[Ice Berg]

Originally Posted by Alan Anderson

My theory is that the shortfall can be blamed primarily on a lack of experienced mentorship. The people who are having real problems are unable to make use of the instructions. I do not believe the instructions are faulty, but I already know what they say so I might be blind to a significant deficiency.

My experience is that some very talented programmers merely do not learn well from reading the instructions. Once they are walked through the steps and shown how to apply the tools by a knowledgeable mentor, they can do well. They just need the mentorship in order to help them over the hurdles.

After watching my programming team over the past four years, I agree completely. For my first two years on the team we had a programmer who was nothing short of brilliant. This guy won national math competitions, and was a legend in my school of 3200 people. However, when it came to programming autonomous, he couldn't make our robot drive forward. However, he was working with no programming mentors at all.

For the past two years, we have had 1-2 mentors dedicated to programming, and the success of our programming team has sky rocketed. However, it isn't that these mentors are programming the robot, but that they are there when the students have questions.

I have lead the engineering team for the past two years and I can't possibly imagine doing it without our team of mentors. As Alan said, I think that the issue we need to address is not the actual programming language or environment, but the mentorship of the student programmers.

[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.

[davidthefat]

I say no, because its supposed to be a challenge, it separates the men from the boys. I don't see why you would even consider this... I am reluctant to say this, but no matter how advanced our autonomous AI is, a human can beat it any day

[Akash Rastogi]

I honestly believe that if a student who is brand new to programming has the motivation to learn, then they can learn how to program an autonomous. Motivation and guidance through even one programming mentor can help you accomplish so much.

I know for a fact that our swerve program would not have been possible without the guidance of our programming mentors.

I don't think more resources are needed for kids to fulfil these tasks, they need motivation and support. New kids on our team learned C and Java in three weeks prior to build by making their own effort to read hundreds of pages in C and Java manuals.

.