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]

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 (http://www.robotc.net/) 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.

[theprgramerdude]

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.

This is true. For example, at the 10,000 Lakes regional, I was unable to test my autonomous code until actually reaching the event, as we shipped the Crio on the robot and didn't have a spare. When I realized that I made a serious error in the code, I scrapped everything I wrote (this was 5 minutes before our first qualifying match, and I had spent the entire day before debugging to no success), and proceeded to use just four lines of code to run our autonomous for the entire event. It worked great, scoring 3 goals total while in the front zone.

The lines consisted of the following in the c++ autonomous periodic loop:
RobotDriveTrainObject->Drive(-1,0);
Wait(1.0);
RobotDriveTrainObject->Drive(1,0);
Wait(1.0);

This isn't hard to figure out how to use. The problem isn't that the code is obfuscated for simple controls (for other parts, yes, it is, hands down), but that the knowledge on how to do something like this isn't readily available. The WPI guides are pretty obscure in explaining how this works to teams that don't have students already proficient in c++/java.

[apalrd]

I think there is no problem with LabVIEW autonomous. I used Autonomous Independent, and ran my own loops within it, and see no reason not to. I had a system like NXTG that gave me high-level controls to do feedback on speed while driving straight and finish by distance, etc. and blocks to set data for the other modules to pick up (kick distance, shift state, chassis mode, kick, ball-O-fier). It worked really well. I am already planning on next year.

I wrote some code for a fairly new team at Troy. We were playing against 469 and wanted to try a sacrificial robot. They had mecanums, and volunteered. So in like 10 minutes (using their Classmate) I wrote a simple time-based routine that used Mecanum-Cartesian and Delay And Feed, in a flat sequence structure, and it worked perfectly. They made it into the tunnel, and 469 did not. 469 was able to get in in the last 20 seconds and win the match, and that was enough to push us from #1 seed.

I also helped a team that we mentored last year, with some autonomous stuff before MSC. I told their programmer to use Autonomous Independent, and string together Tank Drives and Delay and Feed's, and connect their errors. Since data flows over the error line, LabVIEW executes the VI's sequentially and that's all you have to do. He was impressed as this was much easier then the Auto Iterative he had at Detroit, which didn't work.


There is one giant flaw in the system that causes autonomous development problems, especially on LabVIEW. Every time you build code, it has to re-build the entire WPI library. Then it re-downloads the whole WPI library. This is painfully slow, and for minor autonomous fixes between matches this is often a giant problem. Example: While sitting next to the field in elims, I had a minor kick distance change to make. During auto, I wrote in the new number, and begun the build. It did not finish the build until after the robot came back to the "pits" (this is in Atlanta), the tether cable had been connected, and the classmate was booting. Then, it finished downloading in only like 2 minutes. It would be nice if it was easier to partition the WPI lib so it dosen't have to rebuild, or separate the autonomous code.

[dirienzo]

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 (http://www.robotc.net/) 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.

[kamocat]

Okay, so we mostly agree that a sequential, time-based autonomous is extremely easy. But that doesn't require any sensors. Why are sensors useful?
Sensors increase the repeatability of an action as other factors change (e.g. battery voltage drops or mechanism gets jammed) Sensors also allow the robot to respond to changes on the field, meaning the robot can operate based on intent rather than actuating by rote.
Higher levels of control are useful in connecting actuators to sensors in common and easily configurable ways. For example, in NXT-G, it allows you to tell the robot to go forward for a time, a distance (degrees), or until told otherwise. It even allows you to ramp the speed from the current value to the desired value. Likewise, the "wait" function is configurable for a time, or until a sensor is greater/less than a given value. Such high-level coding can save time and reduce errors.
As has been pointed out, all robots are different. Such high-level control needs to be extremely configurable to allow for the differences in sensors, strategies, decision making, actuator control, and wiring configuration.
In other words, it needs to be modular and extendable. I like the idea of separating it into Perception (http://www.chiefdelphi.com/forums/showthread.php?t=85072), Planning (http://www.chiefdelphi.com/forums/showthread.php?t=85073), and Control (http://www.chiefdelphi.com/forums/showthread.php?t=85075). (Linked are Chief Delphi threads about each one)

[JABot67]

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 (http://www.robotc.net/) 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.

[Nadav Zingerman]

Okay, so we mostly agree that a sequential, time-based autonomous is extremely easy. But that doesn't require any sensors. Why are sensors useful?
Sensors increase the repeatability of an action as other factors change (e.g. battery voltage drops or mechanism gets jammed) Sensors also allow the robot to respond to changes on the field, meaning the robot can operate based on intent rather than actuating by rote.
Higher levels of control are useful in connecting actuators to sensors in common and easily configurable ways. For example, in NXT-G, it allows you to tell the robot to go forward for a time, a distance (degrees), or until told otherwise. It even allows you to ramp the speed from the current value to the desired value. Likewise, the "wait" function is configurable for a time, or until a sensor is greater/less than a given value. Such high-level coding can save time and reduce errors.
As has been pointed out, all robots are different. Such high-level control needs to be extremely configurable to allow for the differences in sensors, strategies, decision making, actuator control, and wiring configuration.
In other words, it needs to be modular and extendable. I like the idea of separating it into Perception (http://www.chiefdelphi.com/forums/showthread.php?t=85072), Planning (http://www.chiefdelphi.com/forums/showthread.php?t=85073), and Control (http://www.chiefdelphi.com/forums/showthread.php?t=85075). (Linked are Chief Delphi threads about each one)

There is no doubt that sensors are useful in robotics (I would define a robot without them as a "machine", not really a "robot"), but you can't over-simplify things too much. NXT-G suffers from this a great deal; and creating anything more complicated than very simple sequential instructions (with the occasional decision making) is a pain. I'd hate to see that happen in FIRST.

[Chris27]

I think it would be helpful if FIRST provided a code library with a similar interface/feature set as Tekktosu (http://www.tekkotsu.org/). Personally I find that using state machines to model robot behavior is much more intuitive over typical C/Java code. Also the Takkotsu vision library runs circles around what FIRST provides you guys.

[kamocat]

There is no doubt that sensors are useful in robotics (I would define a robot without them as a "machine", not really a "robot"), but you can't over-simplify things too much. NXT-G suffers from this a great deal; and creating anything more complicated than very simple sequential instructions (with the occasional decision making) is a pain. I'd hate to see that happen in FIRST.
I'm not suggesting using a different environment. I'm just suggesting alternate frameworks that make control easier.
For example, with this framework (http://www.chiefdelphi.com/forums/attachment.php?attachmentid=9025&d=1271557746) I made, any action can be started or stopped with any of the following conditions:

immidiately
time delay
time in match
named value =, <, or >
named input =, <, or >
Completion of another action
Sucess of another action

This allows dynamically sequential actions, but prevents race conditions (actions are isolated by their mechanism). It's very flexible, but allows many common actions to be easily implemented.

However, this is just one method of abstracting autonomous control, and surely not the only method. I think the sorts of control people want to do are similar enough that they can be all part of a generic framework, and then programmers can start transitioning from preplanned actions to dynamic action planning.

[kamocat]

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 (http://kamocat.com/programming/soft_dev_FRC.pdf) which might help with this.

[mwtidd]

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]

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]

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 :D . 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 ::safety:: ). 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]

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]

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]

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.

.

[mwtidd]

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?docid=-5902573997861101882#

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

[Aren Siekmeier]

I find this discussion similar to this thread (http://www.chiefdelphi.com/forums/showthread.php?threadid=85834) 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).

[Alan Anderson]

If you really want to help the non-autonomous teams to get there, without the aforementioned mentor instruction,...

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

Our mission is to inspire young people to be science and technology leaders, by engaging them in exciting mentor-based programs that build science, engineering and technology skills, that inspire innovation, and that foster well-rounded life capabilities including self-confidence, communication, and leadership.

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.

[Andrew Schreiber]

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.

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.

[Alan Anderson]

In this case I have to say that making it simpler to do a basic autonomous would be beneficial in all cases.

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.

[Andrew Schreiber]

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.

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?

[sircedric4]

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.

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

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)

[Rion Atkinson]

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.


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*

[mwtidd]

We don't need to give the teams more tools. We need to give them personal support.

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?

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.

[Mori1578]

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

[oddjob]

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.

[Chris Hibner]

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

[Alan Anderson]

Alan, how long have you been programming?

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

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?

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 meant to imply technical and programming mentor support. ;-) Just because a team has a mentor doesn't mean they have a competent programming one.

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.

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

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.

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.


A basic but complete overview of the system, describing the control hardware, development environments, and software frameworks without giving distracting details.
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.
A "cookbook" giving specific "recipes" for implementing common tasks, preferably in conjunction with things like the LVMastery videos.
A complete tour and explanation of the software frameworks, pointing out each place where customization is expected or encouraged.
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.
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.

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.

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.

I think FIRST wants to provide the tools and then encourage the students seek the education.

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?