|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
||||
|
||||
|
Re: Did Anyone Accept the Challenge?
Quote:
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 Last edited by mwtidd : 14-03-2011 at 23:07. |
|
#17
|
|||
|
|||
|
Re: Did Anyone Accept the Challenge?
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.
|
|
#18
|
|||
|
|||
|
Re: Did Anyone Accept the Challenge?
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). |
|
#19
|
||||
|
||||
|
Re: Did Anyone Accept the Challenge?
Quote:
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. |
|
#20
|
||||
|
||||
|
Re: Did Anyone Accept the Challenge?
Quote:
Once I raise the money I'll be putting together a 4-speed swerve drive. it wouldnt need an arm at first. It would simply drive to a tube, and then drive to the peg column where that tube would be worth the most. Ideally such a task would be accomplished by 2 separate teams... one for the drive, one for the arm. So work could be done in parallel rather than in series. or even better 3, adding in a team for the vision system, as it would dictate to the drive and arm. Last edited by mwtidd : 15-03-2011 at 10:44. |
|
#21
|
||||
|
||||
|
Re: Did Anyone Accept the Challenge?
Quote:
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. Quote:
Quote:
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. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|