Quote:
Originally Posted by JamesTerm
Writing a goals class and breaking down the big picture to smaller pieces is the easy part. The devil is in the details at the bottom end.
|
Well, y'all are the experts, so I'd have to trust you on that. However, I have come up with quite a tangible and possible plan. The entire program will basically be split up into parts. Also, it will only have basic offense features. I a not thinking about making the entire thing pure AI/ML. A great portion will be basic IF's and ELSE's, where if the ball is ahead, go ahead, otherwise go backwards, etc. There is only one way where I think it would be efficient to use Machine Learning -- Best shooting spot, saying that the game is one in which we must shoot the gamepiece into the goal. The rest incorporates basic stuff, half of which I have completed. I learned some stuff in DLib, so it will be quite simple for me to write an application that has an amazing interface.
This gives me the question: If it is so easy to host a webpage without much processor usage footprint, would it be possible for us to give our alliance partners a web address where we can basically create a diagnostics system/chat system for each other to rapidly talk through?
Quote:
Originally Posted by MatthewC529
Exactly. We know it isn't impossible. It's just the feasibility I personally feel is being downplayed. The feasibility of creating a robot that adapts to a given game in a meaningful way I think requires you to be able to look at it as more than a little OpenCV and clever data gathering. The details are important. Everything seems simple in the big picture until you break it down realtime. Though you are not wrong in saying AI/ML can be deceptively simple.
You think of this as a game in code because it is a game. It's why I use iterative. Reminiscent of a game loop. But unlike a game it's a lot more difficult to handle AI and ML in reality, let alone competition.
Sorry for spelling errors. Mobile is not friendly to my hands.
|
I really do not think that I have explained my goals to well to everyone. There are three things that would be nice to implement:
-Automatic gamepiece collection
-Automatic gamepiece scoring
-Automatic driving algorithm so the robot automatically gets to a location requested by the driver
Those are all the things required to make the robot self-capable of possibly winning a match. I guess the gamepiece collection algorithm can get a bit weird because you would need to make sure that you do not hit a ball of the other team, and so you don't attempt to collect a ball present within another robot.
However, proper camera calibration will mean that the height to y axis in the camera , according to the ground. I believe that the relation would be linear. This would allow the program to tell whether the gamepiece is available for pickup!
Quote:
Originally Posted by StevenB
So, I'm a graduate student in electrical engineering, and have taken classes in machine learning, artificial intelligence, image processing, and computer vision. I've spent four summers in internships doing image processing with MATLAB and OpenCV.
Ok, I hesitate to call myself an expert, but I do know what I'm talking about.
I love MATLAB, and yes, it does let you do some pretty neat things with very little code. You can develop and prototype algorithms very quickly, and there seems to be a function for everything you want to do. I can't speak quite as highly of OpenCV, but it too allows you to quickly piece together a lot of computer vision building blocks to build new things. There are dozens of other great libraries out there too - stuff like ROS, VLFeat, PyML, and more.
But even with such great tools, I think you are radically underestimating the problem. Seriously, if you create a robot that can play Aerial Assist autonomously the way you're describing, you will have done enough innovative work to publish several papers and get a PhD.
I'm not saying this to discourage you. You've got a lot of passion and excitement, and a lot of great ideas, and I want to see something cool and innovative come out of it. You can do great work, and I look forward to seeing it. But I encourage you to focus your effort on a small piece of the problem. It may feel like a teeny, tiny, insignificant part. But unless you start with something small, it's hard to finish. I'm a dreamer by nature - like you, I have big ideas and grand plans, and I like to start new things. But too many of my projects have died shortly after I wrote down the grand vision, because I took on too much at once.
So, think about a small part of the problem, but also something you can get excited about. - Program your robot to catch a ball thrown to it by a human. Use an onboard camera (looks like you've already got one on your bot) to track the trajectory of the ball, and have the robot drive into position to grab it.
- Place a series of traffic cones (or similar large bright objects) on your playing field. Make the robot chase down the ball and pick it up without knocking over any cones.
- Program your robot to automatically score the ball after picking it up a random distance from the goal, while avoiding traffic cones.
- Build the multi-camera system you described, and program the robot to play defense. A robot with red bumpers is trying to pick up a red ball. Your job is to stay between the red robot and the red ball.
These are all things that are doable in a summer, but to my knowledge, no team has done these. Pick one of these, or something similar, break it down into tiny tasks, and see what you can do. Ask questions, read papers, and write some code. With enough dedication, you'll come up with something really great, and I look forward to seeing it!
Someone should go tell the RoboCup teams. They've been working on this for 15+ years.  |
Well, there are a few goals that I have in mind. This isn't to build a robot program that will convert the crappiest robot build into a champion bot, but instead to build a prototype that performs a bit better than a novice driver who knows little about the robot.
Driving through traffic cones is quite the opposite I am trying to perform. Catching the ball would be a challenge, but I know that it has been performed by quite a few teams. Catching a ball without knocking over cones is also past my goals. I am not trying to build something that is so accurate that it will never hit anything. I know that on the field, if the robot just touches, or maybe takes a small hit, nothing bad will happen. I just want to make sure that the robot won't generate a path through the wall! The main thing that will help is that the path will be regenerated constantly in a seperate thread, so if one error happens, the robot will be out of control for less than an eighth of a second! I want to build a multicam system, however, the processing power, resources, etc. will be beyond the reach for my team, so I want to stick with two high-FOV cameras and set up stereo vision!