Did Anyone Accept the Challenge?

[theprgramerdude]

I believe the challenge was a worth goal; it surely can be done given a small team of experience programmers with the drive to make something this awesome. However, this game doesn't really suit a full autonomous. Can someone here tell me exactly how complex the code would be to sense out all the tubes flying around the field, and differentiate them from the field, the arena, and other robots? Last year would've been a great game to try it with (not as many objects to deal with, and a more limited space at any given time). This year would just be hell if you have anything less than 10 or 15 sensors, including all the code required to operate them all effectively.

[Geek 2.0]

Perhaps we should try a new goal, maybe for off-season events. I doubt we will be able to do this, but I would love to see someone give it a shot.

What if the challenge were not a fully autonomous bot, but rather a MOSTLY autonomous bot? lineskier put forth a good idea, by telling the robot to "FIND TUBE" and "CAPTURE TUBE", etc. Obviously, if it misinterprets, the error will just rack up and there will be problems on problems.

To avoid this, give the driver two buttons: "Success" and "Failure/Retry". If the robot succeeds in the command it's given, you tell it "Success". If it fails, you tell it to retry.

To be really impressive, have it learn from failure. Yeah, that sounds difficult, but it's possible, and not as complex as you might think. If it grabs the wrong color, have it tweak it's color detection settings. If it went the wrong way, tweak the heading.

So, what do you think? Anyone willing to take up the challenge? (Like I said earlier, unfortunately our team won't be able to do this yet, but maybe in the future).

[mwtidd]

Originally Posted by theprgramerdude

I believe the challenge was a worth goal; it surely can be done given a small team of experience programmers with the drive to make something this awesome. However, this game doesn't really suit a full autonomous. Can someone here tell me exactly how complex the code would be to sense out all the tubes flying around the field, and differentiate them from the field, the arena, and other robots? Last year would've been a great game to try it with (not as many objects to deal with, and a more limited space at any given time). This year would just be hell if you have anything less than 10 or 15 sensors, including all the code required to operate them all effectively.

Actually I believe this year would be easier than last year for several reasons:

The pegs are easier to see than the targets.
The pegs relate more information than the goals.
The tubes are easier to see than balls.

Fully autonomous would help if you had a full alliance involved in the cause. I think an autonomous capper could be faster than a human capper, so if you had a team dedicated to delivering tubes, and your only job was to cap them I think you could get the average down to about 10 seconds per find and cap by staying in your endzone.
One thing I've noticed a lot of is alliance partners bumping into one another. By putting an autonomous robot on one rack, and having one runner, i think it would free up quite a bit of the field.

Again you wouldn't want to try to watch the tubes flying around, but tubes on the ground are certainly detectable as the are large and have specific shapes. Open CV contains some shape matching libraries that could help there. You would drive around scanning for a tube that was on the field.

[mwtidd]

Originally Posted by JamesBrown

David and lineskier ot of curiosity how much experience do you guys have with programming autonomous robots? I think you guys are drastically under estimating the difficulty of this task.

Lets say 04 was the first time I was introduced to autonomous (glanced at it in 03, but basic sucks).
However coding was completely changed with the introduction of the cRIO.

That being said, I got the camera working for this game in about one nights of work. My biggest issue was our drive (2wd direct with only 1 cim per box). The arm didn't help either. If I was to try to accomplish this, I would have a long list of requirements for the robot. Something like 40 (swerve with a reliable arm)

Using real vision libraries, you could find the tubes, analyze the rack and cap.
The tubes make huge targets, and the pegs show up really well on the camera.

Using something like that which 33 developed where based on the tube, the arm goes to a given height would help.

I already have the structure to allow autonomous to work as a graph state machine, allowing me to create loops. So to do a fully autonomous robot, you would have to create maneuvers such as the following, and then it would progress through the graph.

FIND TUBE
CAPTURE TUBE
FIND TARGET
CAP TUBE
RESET...

I'm not saying it would be easy, but I think it would be possible if it was a goal from kickoff to IRI.

If I could score 2 ubertubes and one logo fully autonomous that would be my metric for success.
Probably the way I would start is by making a deal with the opposing alliance, "you throw three tubes in our scoring zone, we'll throw 3 in yours" This way I would never have to leave the area by the goal and deal with a defending robot.

More realistically I could set up the maneuvers for driver use. So the driver gets the tube in the cameras image, and then the tube capture is handled. Then the driver gets to the pegs, and runs the auto cap. Drivers are better than the autonomous at adjusting to their environment, tube captures and caps are fairly static so may be better for auto maneuver

[JamesBrown]

Originally Posted by lineskier

Lets say 04 was the first time I was introduced to autonomous (glanced at it in 03, but basic sucks).
However coding was completely changed with the introduction of the cRIO.

That being said, I got the camera working for this game in about one nights of work. My biggest issue was our drive (2wd direct with only 1 cim per box). The arm didn't help either. If I was to try to accomplish this, I would have a long list of requirements for the robot. Something like 40 (swerve with a reliable arm)

Using real vision libraries, you could find the tubes, analyze the rack and cap.
The tubes make huge targets, and the pegs show up really well on the camera.

Using something like that which 33 developed where based on the tube, the arm goes to a given height would help.

I already have the structure to allow autonomous to work as a graph state machine, allowing me to create loops. So to do a fully autonomous robot, you would have to create maneuvers such as the following, and then it would progress through the graph.

FIND TUBE
CAPTURE TUBE
FIND TARGET
CAP TUBE
RESET...

I'm not saying it would be easy, but I think it would be possible if it was a goal from kickoff to IRI.

If I could score 2 ubertubes and one logo fully autonomous that would be my metric for success.
Probably the way I would start is by making a deal with the opposing alliance, "you throw three tubes in our scoring zone, we'll throw 3 in yours" This way I would never have to leave the area by the goal and deal with a defending robot.

More realistically I could set up the maneuvers for driver use. So the driver gets the tube in the cameras image, and then the tube capture is handled. Then the driver gets to the pegs, and runs the auto cap. Drivers are better than the autonomous at adjusting to their environment, tube captures and caps are fairly static so may be better for auto maneuver

I was looking more for any experience with Autonomous robots outside of FIRST (well outside of the 15 seconds FIRST requires).

You are on the right track about what needs to get done, but you are drastically simplifying how hard it is to do. I would say that it is possible on an empty field with no other robots and only tubes placed by your HP to score 3 tubes plus Ubertubes, but that is far from playing the game. Consider all of the contingencies that a driver deals with during a match, tubes moving through the field of view, flat tubes that the bot cant pick up (Unless you have an awesome vision algorithm a flat tube is going to look identical to a full one) other tubes getting in your way etc. It is incredibly difficult to predict what could happen and to deal with it.

I do however agree that automating small tasks is the right path to head down. It amazes me every year how many teams are impressed by other teams arm presets or automatic aiming. This year offers two very beneficial game elements to automate, first, adjusting arm position for pick up or scoring, and second adjusting robot/deployment system to line up with the pole for the mini-bot race. Start by automating those and then work from there.

Originally Posted by davidthefat

I really have no experience, I believe that it can't be that hard in a such confined environment such as a FIRST game compared to the world. I was only planning on being defensive anyway. A fully autonomous robot could have been just a wall like pong. Just strafing with the bot in front

The FIRST game field is a relatively small area which you are right does make autonomy easier; however it is a dynamic world. There are at least 9 other players in the world (5 robots and 4 human players) this immediately complicates things. Look at the number of penalties caused by drivers playing defense this year. An Autonomous robot that plays defense would be a huge risk, what happens when you misinterpret data and all of a sudden instead of playing pong in front of the zone you are driving into and out of it? Sure you can try to defend against that (look for the lines on the ground but what happens if you get pushed inside the line (by a robot going to score, not intentionally so no penalty to them) then all of a sudden the robot wants to stay in the zone instead of outside of it. FIRST games are far too complicated to play autonomously.

Originally Posted by davidthefat

Eh, true, but we won't need to be calculating real-time to compensate for uneven terrain or some other stuff like that. I see no reason why this will not be possible in 1 year.

If I remember your old posts you want to map the area, because you are in a dynamic environment you will need to map in real-time to keep the map relatively accurate. Uneven terrain in a static environment is trivial compared to Robot-Robot and Robot-Game piece interaction in a dynamic environment. I am not sure what you mean by this will be possible in a year, if you mean that with 1 year to program and implement an autonomous bot you could play the FIRST game or if you mean that next year a team could do this during build season. Either way I would say that there is no way it is possible.

If you want an example of the difficulty of playing a game with Autonomous robots, look at robot soccer, that is much simpler than FIRST, one game piece, one way to score, and you get to control all of the robots on your team. Even the best robot soccer teams are still quite frankly terrible at the game, a team of identical bots driven by humans would beat the autonomous ones every time.

I know that there is always the argument that even if an Autonomous robot doesn't perform as well as a human driven one would it is still work pursuing as FIRST is not about winning a robotics competition it is about inspiring students. While I agree that is the message of FIRST it is important to keep in mind that FIRST is teaching students about engineering through an engineering challenge. As an Engineer I can tell you that when my manager gives me a task to create a control system for a human controlled manipulator he will not be impressed if I tell him it does half the job and only when it is not interfered with by outside forces that we know will exist in the environment, but it is fully autonomous. I didn't solve the problem; I just built something for the sake of building it. Identifying constraints and finding the best solution is 98% of what engineering is about, the actual coding, machining, or fabrication is a miniscule part of what makes a good engineer.