Log in

View Full Version : Programmers: I Have A Challenge For You


Pages : 1 [2]

sircedric4
09-04-2010, 14:14
I still find it surprising that you're the only competent programmer, but I concede that may be because I don't have much experience with teams outside my immediate area. Our school is medium/smallish, with 90 people in each grade, but we've managed to find 3 competent programmers this year, 2 of them dedicated. Our team isn't particularly good, certainly not a powerhouse, but any of the 3 programmers can write the teleop code within an hour (provided the drivers know what they want, the electrical stuff is connected correctly, the mechanics work, etc).

As for recruiting programmers, I think the best way to get them is to inspire them. Don't say they get to write the driving code and winning the game is entirely the responsibility of the drivers. Tell them they get to work on the camera, let the robot make intelligent decisions, or score autonomously. That's what got me enticed; I certainly wouldn't have joined the team just to make the robot drive.

Well part of this is that I misunderstood the original post and thought he was lobbying for FIRST to make an all autonomous game. I still can't see how anyone can expect that to work out as a mandatory requirement given the sad state of most regional's autonomous modes. Since I have reread it and he's just challenging teams to try it, well then more power to those that want to do it.

Well one thing your team has going for it is that you are from a low number team. I would bet that your team has been around long enough to become an institution at your school and a program that many students want to participate in, or at least have heard of. We're only a second year team, and though our Rookie All Start trip to Atlanta made some headway towards getting us known at the school, we still have a long way to go. We're still kind of unheard of in the area, so we have to overcome that. It's entirely possible the school has programmers begging to try something real-world but just don't know there's a robot team. We're not "school-sanctioned" like a football team so being able to announce things on the intercom and such isn't easy. We're still considered a "club" and there are different rules for them.

One of our goals is to try and get robots the same benefits as a sports team at our school, even having letter jackets for the students. That would open us up to more of the student base. We have given various demos around the school and all, but the interest just isn't there yet. Give us a few more years and we'll see.

I just think that everyone needs to remember that everyone has different stories and rules and requirements they have to overcome, and to not be surprised about anyone's limitations. :-) "FIRST is not fair" is one of those things you learn in your rookie year, and that applies at every aspect of the game. I imagine there are teams that have nothing but programmers and very few mechanical oriented students and mentors, we just happen to be the opposite of this.

MattSr
11-04-2010, 03:05
as you can see i am from 488, i will be a mentor next year but i still hope to be able to make a version of our code that could be fully autonomous and we could use when we aren't too stressed about winning the match depending on how well the auton works, it will probably be just me working on this with the help of maybe one more

its funny that this topic came up since a few weeks before the Seattle, WA regional, a few of the programmers and I were discussing this exact topic as a definite possibility with the sensors that FIRST is letting us use on our robots

theprgramerdude
11-04-2010, 11:44
Rather than the 5-second rule, I think a far better, and more adjustable, step for FIRST teams would simply be to expand the autonomous period past 15 seconds. Because, seriously, 15 seconds isn't enough to do anything worthwhile. It would make the autonomous a bit more important, and give some motivation to teams that decide "our drivers can make up for anything we dont do in autonomous."

Chris27
11-04-2010, 11:48
15 seconds isn't enough to do anything worthwhile.

Good thing we have teams like 1114 to prove you dead wrong :rolleyes:

Chris is me
11-04-2010, 11:54
Rather than the 5-second rule, I think a far better, and more adjustable, step for FIRST teams would simply be to expand the autonomous period past 15 seconds. Because, seriously, 15 seconds isn't enough to do anything worthwhile. It would make the autonomous a bit more important, and give some motivation to teams that decide "our drivers can make up for anything we dont do in autonomous."

I'm sure teams that decided to do that in 2006, 2008, and 2010 were playing the final match on Einstein.

kamocat
11-04-2010, 11:54
15 seconds isn't enough to take advantage of full-field awareness.
It's only enough time to do something and hope it works. (For example, if you fire a ball into the goals from mid- or far- field, you don't have enough time to go over there and make sure it actually went in.)

Kevin Watson
11-04-2010, 13:06
15 seconds isn't enough to take advantage of full-field awareness.
It's only enough time to do something and hope it works. (For example, if you fire a ball into the goals from mid- or far- field, you don't have enough time to go over there and make sure it actually went in.)
Back in 2004 we had an infrared beacon system that could be used to determine your position on the field and perform a fully autonomous action. It's demonstrated at about 1:40:40 of the kick-off video:

http://robotics.nasa.gov/first/2004/kickoff.htm

It used $10-$15 dollars worth of parts plus some custom code that's still available here:

http://kevin.org/frc/2004/

-Kevin

ideasrule
11-04-2010, 13:12
Good thing we have teams like 1114 to prove you dead wrong :rolleyes:

1114 didn't prove him dead wrong this year. 1114's ranking at any regional would definitely not have been different if they stayed still during autonomous. The robot was averaging 1-2 balls scored per autonomous mode. Our robot averaged 1 ball per autonomous mode, and despite being a much weaker team, the one match where that one score mattered was better known as the match where we got disqualified.

Chris27
11-04-2010, 13:52
1114 didn't prove him dead wrong this year. 1114's ranking at any regional would definitely not have been different if they stayed still during autonomous. The robot was averaging 1-2 balls scored per autonomous mode. Our robot averaged 1 ball per autonomous mode, and despite being a much weaker team, the one match where that one score mattered was better known as the match where we got disqualified.

Not as much this year but in Overdrive their auton alone could have won them 9/10 matches. I'm just saying its absurd to dismiss a 15s autonomous period as useless. I know there are not any bonus points this year for scoring in auton like in past years, but that was also the case last year. Before the season started many people on CD were also saying that auton would be mostly useless and the only really useful thing to do was to not get scored on. Not really meaning to toot my own horn but last year one thing that gave my team a substantial early advantage was that we were able to load up during auton. I think we set a good example of what could be done. I think a lot of the effort spent complaining about how FIRST views the role of autonomy would be better spent developing an autonomous mode that consistently scores 3-5 balls. That's nothing to sneeze at considering most alliances struggle to break 10 points.

Andrew Schreiber
11-04-2010, 14:26
Rather than the 5-second rule, I think a far better, and more adjustable, step for FIRST teams would simply be to expand the autonomous period past 15 seconds. Because, seriously, 15 seconds isn't enough to do anything worthwhile. It would make the autonomous a bit more important, and give some motivation to teams that decide "our drivers can make up for anything we dont do in autonomous."

2003, taking the entire stack on the top of the bump and then controlling the bump could win. (I wasn't around this year perhaps someone could figure out how much of a swing it could be)

2004, several teams hung in autonomous and then controlled the bar, they swung the match score up to 150 points (+50 for their hang -100 for their opponents not being able to hang). I guess that isn't serious.

2006, winning auton was a huge benefit. I saw many matches decided by auton alone.

2008, 1114, do I need to say more? Ok, 217. There you go. Auton could decide the match.

2009, on Einstein the final match autons consisted of loading up the bots to go dump a load into their opponents, not as important but it added many balls to the arsenal of the dumpers (or 217's shooter).

2010, 469 shows how useful a good auton can be. If they get set in auton you are pretty much down 4 points at the start of the match (They score 2 balls and then recycle them as soon as people start moving).

I would say that 15 seconds is plenty of time to do something important.

davidthefat
11-04-2010, 22:48
All who are trying this: I have a book for you. http://www.amazon.com/Introduction-Autonomous-Mobile-Intelligent-Robotics/dp/026219502X
The TOC:
Contents
Acknowledgments xi
Preface xiii
1 Introduction 1
1.1 Introduction 1
1.2 An Overview of the Book 10
2 Locomotion 13
2.1 Introduction 13
2.1.1 Key issues for locomotion 16
2.2 Legged Mobile Robots 17
2.2.1 Leg configurations and stability 18
2.2.2 Examples of legged robot locomotion 21
2.3 Wheeled Mobile Robots 30
2.3.1 Wheeled locomotion: the design space 31
2.3.2 Wheeled locomotion: case studies 38
3 Mobile Robot Kinematics 47
3.1 Introduction 47
3.2 Kinematic Models and Constraints 48
3.2.1 Representing robot position 48
3.2.2 Forward kinematic models 51
3.2.3 Wheel kinematic constraints 53
3.2.4 Robot kinematic constraints 61
3.2.5 Examples: robot kinematic models and constraints 63
3.3 Mobile Robot Maneuverability 67
3.3.1 Degree of mobility 67
3.3.2 Degree of steerability 71
3.3.3 Robot maneuverability 72
viii Contents
3.4 Mobile Robot Workspace 74
3.4.1 Degrees of freedom 74
3.4.2 Holonomic robots 75
3.4.3 Path and trajectory considerations 77
3.5 Beyond Basic Kinematics 80
3.6 Motion Control (Kinematic Control) 81
3.6.1 Open loop control (trajectory-following) 81
3.6.2 Feedback control 82
4 Perception 89
4.1 Sensors for Mobile Robots 89
4.1.1 Sensor classification 89
4.1.2 Characterizing sensor performance 92
4.1.3 Wheel/motor sensors 97
4.1.4 Heading sensors 98
4.1.5 Ground-based beacons 101
4.1.6 Active ranging 104
4.1.7 Motion/speed sensors 115
4.1.8 Vision-based sensors 117
4.2 Representing Uncertainty 145
4.2.1 Statistical representation 145
4.2.2 Error propagation: combining uncertain measurements 149
4.3 Feature Extraction 151
4.3.1 Feature extraction based on range data (laser, ultrasonic, vision-based
ranging) 154
4.3.2 Visual appearance based feature extraction 163
5 Mobile Robot Localization 181
5.1 Introduction 181
5.2 The Challenge of Localization: Noise and Aliasing 182
5.2.1 Sensor noise 183
5.2.2 Sensor aliasing 184
5.2.3 Effector noise 185
5.2.4 An error model for odometric position estimation 186
5.3 To Localize or Not to Localize: Localization-Based Navigation versus
Programmed Solutions 191
5.4 Belief Representation 194
5.4.1 Single-hypothesis belief 194
5.4.2 Multiple-hypothesis belief 196
Contents ix
5.5 Map Representation 200
5.5.1 Continuous representations 200
5.5.2 Decomposition strategies 203
5.5.3 State of the art: current challenges in map representation 210
5.6 Probabilistic Map-Based Localization 212
5.6.1 Introduction 212
5.6.2 Markov localization 214
5.6.3 Kalman filter localization 227
5.7 Other Examples of Localization Systems 244
5.7.1 Landmark-based navigation 245
5.7.2 Globally unique localization 246
5.7.3 Positioning beacon systems 248
5.7.4 Route-based localization 249
5.8 Autonomous Map Building 250
5.8.1 The stochastic map technique 250
5.8.2 Other mapping techniques 253
6 Planning and Navigation 257
6.1 Introduction 257
6.2 Competences for Navigation: Planning and Reacting 258
6.2.1 Path planning 259
6.2.2 Obstacle avoidance 272
6.3 Navigation Architectures 291
6.3.1 Modularity for code reuse and sharing 291
6.3.2 Control localization 291
6.3.3 Techniques for decomposition 292
6.3.4 Case studies: tiered robot architectures 298
Bibliography 305
Books 305
Papers 306
Referenced Webpages 314
Interesting Internet Links to Mobile Robots 314
Index



As you can see, it covers everything from the Perception to Logic and even drive systems

gvarndell
12-04-2010, 06:10
All who are trying this: I have a book for you.

:) :) :)

Doug Leppard
12-04-2010, 08:51
2003, taking the entire stack on the top of the bump and then controlling the bump could win. (I wasn't around this year perhaps someone could figure out how much of a swing it could be)

2004, several teams hung in autonomous and then controlled the bar, they swung the match score up to 150 points (+50 for their hang -100 for their opponents not being able to hang). I guess that isn't serious.

2006, winning auton was a huge benefit. I saw many matches decided by auton alone.

2008, 1114, do I need to say more? Ok, 217. There you go. Auton could decide the match.

2009, on Einstein the final match autons consisted of loading up the bots to go dump a load into their opponents, not as important but it added many balls to the arsenal of the dumpers (or 217's shooter).

2010, 469 shows how useful a good auton can be. If they get set in auton you are pretty much down 4 points at the start of the match (They score 2 balls and then recycle them as soon as people start moving).

I would say that 15 seconds is plenty of time to do something important.

I would agree. As a mentor I have been there for all auto years. If the game is designed right you can do a lot in 15 seconds.

2003 purpose, to knock your boxes to your side of field. Auto gave you a good position and start against your opponents.

2004 Purpose to knock down the balls early in game. Gave you a small advantage. But mostly if you moved during auto you go noticed. It was a fun one to do and watch.

2005 It was the tetra year and idea was to put the tetra in place. It was a bust. Almost no one could do much with it, too hard.

2006 Aim high place balls in corner or middle target. It was 1902's rookie year and we had a simple auto mode that consistently put 10 balls in corner and gave bonus points. Because of that we were 9-0 in Houston.

2007 Rack and Roll, place tube on rack. Many said it did not help. I calculated it made the difference in winning or losing several matches.

2008 Race around track and knock down balls. This was the most fun and challenging auto mode. Could make huge difference.

2009 Auto was hard and mostly in my opinion did not make a big difference unless you didn't move and you got nailed for not moving.

Bottom line auto modes are fun and most years make a difference. Longer than 15 seconds and it becomes boring because most teams do not even move during that time.

I think auto mode is important for a team because you stand out during that the 15 seconds awhile so many others just sit there.

kamocat
12-04-2010, 10:24
The thing I notice about all of those is that autonomous is always playing an assistive role to teleop. I wonder if that could be reversed?

toastnbacon
15-04-2010, 16:09
I love the sound of this, but I can almost guarantee my team won't.

gblake
18-04-2010, 20:38
I love the sound of this, but I can almost guarantee my team won't.
See post #231 Link_to_231 (http://www.chiefdelphi.com/forums/showpost.php?p=949065&postcount=231)

gblake
18-04-2010, 20:59
The thing I notice about all of those is that autonomous is always playing an assistive role to teleop. I wonder if that could be reversed?Another mentor wrote something like this during the Rack-N-Roll season - I'm paraphrasing:

Once you create a machine that can score a ring (or some other useful function) during the autonomous period, you use that capability like a macro to automate scoring during the entire match.

A good autonomous scorer, becomes a predictable/reliable tool for the drive team to use throughout teleop. It multiplies their effectiveness and frees them to think about higher level concerns, instead of the minutiae of the actions a machine can carry out on their behalf.

How about starting with this general mindset and then pushing it as far as we are able?

Blake

WJF2011
18-04-2010, 21:14
Understand this. This is a beatable robot. All robots can be defeated with strategy. - Alexander McGee

Please see team 71 in 2002:
http://www.youtube.com/watch?v=h4slvnvPHW8

kamocat
18-04-2010, 21:49
Once you create a machine that can score a ring (or some other useful function) during the autonomous period, you use that capability like a macro to automate scoring during the entire match.

A good autonomous scorer, becomes a predictable/reliable tool for the drive team to use throughout teleop. It multiplies their effectiveness and frees them to think about higher level concerns, instead of the minutiae of the actions a machine can carry out on their behalf.

Higher-level control?
Funny you should mention that.

One way I'd like to automate is the movement of the robot. However, since we don't have a touchscreen to say "go here", I've been wondering what the best way to do that is.
One idea is to have "canned moves" selected with a button and configured with a joystick.
In 2009, the canned moves would have been a non-slip turn, a trailer-swinging spin, or a backwards flip around the trailer.
(Each of these moves will work within certain parameters (speed, rate of turn, angle of trailer, weight of trailer vs weight of 'bot.)

Can you think of a simpler or more intuitive interface?

davidthefat
29-04-2010, 21:01
Anyone have any progress with this? LOL I really have not even officially started on it, just brainstormed and now I have AP tests and stuff... I don't have much time, Spring Football is coming up, final projects are due and wow...

theprgramerdude
29-04-2010, 21:38
Knowing that fully autonomous will be a big project, I'm focusing on recruiting replacements for the seniors that are leaving this year, and training whomever I can in basic c++/Labview while I can, since part of the decision making engine (which is critical) will have to be based on next years game.

Tom Line
29-04-2010, 22:37
Understand this. This is a beatable robot. All robots can be defeated with strategy. - Alexander McGee

Please see team 71 in 2002:
http://www.youtube.com/watch?v=h4slvnvPHW8

That WAS a beatable robot. If your robot was quick enough to get to them and knock them off center before they locked on, they were defeatable.

Many people said the same thing about 469 on einstein this year - that they were a lock with 1114.

It requires a clear understanding of the game and a good grasp of strategy, but any robot is beatable.

Chris is me
29-04-2010, 23:18
That WAS a beatable robot. If your robot was quick enough to get to them and knock them off center before they locked on, they were defeatable..

I've read in old threads that the "knocking them off center" problem was fixed for Championship.

Ian Curtis
29-04-2010, 23:33
I've read in old threads that the "knocking them off center" problem was fixed for Championship.

I'm not sure what the fix was but it couldn't have been a cure-all, because SPAM did it to them during Einstein Match 2. (http://www.thebluealliance.net/tbatv/match/2002cmp_f1m2) I don't know how 2002 was scored though. Did Beatty and Rage win anyways, or did they force a third match that TBA doesn't have?

Chris is me
29-04-2010, 23:38
I'm not sure what the fix was but it couldn't have been a cure-all, because SPAM did it to them during Einstein Match 2. (http://www.thebluealliance.net/tbatv/match/2002cmp_f1m2) I don't know how 2002 was scored though. Did Beatty and Rage win anyways, or did they force a third match that TBA doesn't have?

Everything I have is heresy from reading old threads, but I heard the second match was a combination drive shaft failure and the gate latches not working. The third match was won without Beatty on the field for the win.

CN-U-NEFCU?
30-04-2010, 19:48
This would be extremely difficult not only due to the intense amount of code and possible errors that could present them selves, but also because it would be hard to keep track of the robots position on the field due to Field obstacles getting in the way of items such as encoders, can anyone say bump?

theprgramerdude
30-04-2010, 20:13
Naturally, absolute values cannot be used, just like in full scale/industrial robots and control systems (thinking of aircraft). It has to be able to adjust and calculate for errors, and use multiple position sensing methods.

W1NG$
11-05-2010, 18:50
This is one amazing goal. I do find it annoying that for a majority of the match the "robots" are not really robots. Just a big RC car in the hands of a highschooler. "A robot is an automatically guided machine, able to do tasks on its own." I will talk to our programming team about this, Fo Sho!
I think what FIRST is really trying to do though is make the competition viewer and fan friendly. No one wants to watch a low scoring match of slow moving robots. If this goal could be accomplished while still keeping the games entertaining then that would be great. I think having the game part autonomous and part teleop is the best way to go, though it would be nice if they made the autonomous longer and worth more points.

oddjob
13-05-2010, 12:06
I think what FIRST is really trying to do though is make the competition viewer and fan friendly. No one wants to watch a low scoring match of slow moving robots.


... or a high scoring match. Who'd pay to watch robotically driven NASCAR or robot tennis? Not many. Even the Mars rovers are driven by commands sent from Earth, with some autonomy build in to the rover. (human said what?).

A fully autonomous FIRST competition would be a dud. It's technically brilliant, but has a very limited audience. Adding some automated tasks to human control does make sense though, such as camera assisted aiming and shooting mechanisms. In Formula 1 car racing the FIA is constantly having to evaluate how much of the car is to be driven by computer versus having the driver in control. They understand the fans want to see the drivers perform too, it's not just about who has the best engineers. The same applies to FIRST.

DaveS_1511
13-05-2010, 12:23
I agree with W1NG$, that autonomous should be encouraged but not be the whole match. Make autonomous a little longer relative to teleoperated or make autonomous scores count for more points.

For a more extreme idea, how about a detachable autonomous robot, so each team would have a teleoperated and an autonomous robot fielded at the same time - - - mayhem ensues!

Enigma's puzzle
13-05-2010, 12:54
Everything I have is heresy from reading old threads, but I heard the second match was a combination drive shaft failure and the gate latches not working. The third match was won without Beatty on the field for the win.

After talking to someone that drove against that robot the key to beating it was beating it to the middle goal and moving it off center or out of the middle of the field so it would then miss the other two goals. but you had to do this in autonomous. So the anti-Hammond autons were similar to the anti-Guerillas autons we saw this year.

JamesBrown
13-05-2010, 13:27
but you had to do this in autonomous. So the anti-Hammond autons were similar to the anti-Guerillas autons we saw this year.

I was under the impression that autonomous mode didn't exist until 2003. (I could be mistaken)

Doug G
13-05-2010, 14:44
You are correct, no autonomous period until 2003. You could still write some auto code, but not many did, just for operational functions and systems.

I remember Team 60 was like Beatty at SVR that year. You could beat them, but you had to control the goals before they got to them. I distinctly remember one team that drove at ridiculus high speed as soon as the match started and rammed 60 so hard it broke one of their four drive transmissions. There were no bumpers back then. I still haven't heard a robot collision like that since.

Back on topic... I think pursuing this challenge within the constraints of FIRST is a bit silly and maybe not as inspiring as you may hope. Sure it may inspire you and a few hard core programmers, but what about the rest of the teams. I think a better challenge (or an alternate one) is to offer up a Championship Autonomous Trophy or something for the best auto mode next season. Don't let it be decided by points though, maybe teams submit their best auto mode video clip (from a regional/championship) to YouTube, have a panel decide on the top five and then the FIRST community vote on a winner. Maybe we find a sponsor for it like what AutoDesk does for CADders. This maybe more inviting for more programmers of various levels and hopefully inspire them to take on more challenging adventures like yours.

kamocat
14-05-2010, 01:11
... or a high scoring match. Who'd pay to watch robotically driven NASCAR or robot tennis? Not many. Even the Mars rovers are driven by commands sent from Earth, with some autonomy build in to the rover. (human said what?).

A fully autonomous FIRST competition would be a dud. It's technically brilliant, but has a very limited audience. Adding some automated tasks to human control does make sense though, such as camera assisted aiming and shooting mechanisms. In Formula 1 car racing the FIA is constantly having to evaluate how much of the car is to be driven by computer versus having the driver in control. They understand the fans want to see the drivers perform too, it's not just about who has the best engineers. The same applies to FIRST.
If the robots are fully autonomous, then the issue becomes how well they interact with human players. The actions of human players and robots can have zero overlap, in contrast to the direct competition present in 2009.
I feel there is a limited vision of the individuality of autonomous robots, and an assumption that fully autonomous robots will make every match the same. If the robots are very repeatable, then make the field environment less predictable. Perhaps Guinea Pigs in exercise balls that robots must collect?
RC cars are not the future of robotics. I don't understand how we can get students interested in new engineering fields if we don't expose them to it.

angelawence11
14-05-2010, 08:20
The thing with making something completely autonomous is that other robots that may be teleoperated are completely unpredictable. Itd make defense difficult... wouldnt it? i dunno. for any team who can do it, good luck!!!

JamesBrown
14-05-2010, 08:32
I don't understand how we can get students interested in new engineering fields if we don't expose them to it.

I don't think it is necessary to directly expose the students to the fields, what FIRST does is tease them with a little introduction, and let them find their way from there.

We can't just force teams to build more autonomous robots and force them to function in more dynamic environments. We need to keep in mind that this is still a high school program, and the majority of high school programmers (and a lot of the mentors) don't have the necessary skill set to build and control sophisticated robots. There were teams this year, including very experienced teams (even original teams from 1992) who did nothing in autonomous. This year you could score >75% of the time by just driving forward in the front zone, and yet there were teams that couldn't do it. There were teams in 2005 that could not knock the hanging tetra off, and in 2008 that could not drive forward to cross one line. These are extremely simple tasks that teams are just not doing. Whether it is due to lack of time, programming experience, or anything else it is obvious we are not ready to make autonomous any harder.

mwtidd
14-05-2010, 13:33
the majority of high school programmers (and a lot of the mentors) don't have the necessary skill set to build and control sophisticated robots.

I've attatched a link to the trinity fire fighting robot contest.

This has not only a high school division, but also a junior division.

http://www.trincoll.edu/events/robot/

I think what is holding FIRST back is the way it encourages autonomous. First off unlike trinity, it is not really a requisite. As many have said the advantage of having a strong autonomous robot has been reduced greatly recently, which confuses me seeing as they invested in the cRIO. In the past we were given 15 seconds, and a good autonomous gave you a distinct advantage but did not at all guarantee a win (see 2004). Now we've been given c++, java, and labview but we're only allotted 10 sec, and in this game 3 points if you were lucky.

because of this movement it has forced a priority shift almost entirely to the engineering, which is why I believe you saw almost no autonomous this year... making programming an "if we have time" sort of thing. I would like to see a shift back to the 04/06 style autonomous, to give us and more importantly our teams the incentive for making impressive autonomous robots.

kamocat
15-05-2010, 16:39
I don't think it is necessary to directly expose the students to the fields, what FIRST does is tease them with a little introduction, and let them find their way from there.
I guess I just don't understand how that helps create more engineers. We've all seen Bill Nye the Science Guy, but does that make us want to be scientists? Do we actually pursue science with a passion due to him, or do we find inspiration in the technology we create?
With the millions in scholarships and the direct contact with professional engineers, I don't see how FIRST could justify saying "engineering is cool" and leave it at that. Connections, education, and experience are what help people become professionals. If you were a student, would you be interested in a robotics program if you only knew of it as a hobby, if you had no idea how to actually do it as a profession? If FIRST was just a game, would it be a fraction as important as it is? It would only be a sport.


We can't just force teams to build more autonomous robots and force them to function in more dynamic environments. We need to keep in mind that this is still a high school program, and the majority of high school programmers (and a lot of the mentors) don't have the necessary skill set to build and control sophisticated robots. There were teams this year, including very experienced teams (even original teams from 1992) who did nothing in autonomous. This year you could score >75% of the time by just driving forward in the front zone, and yet there were teams that couldn't do it. There were teams in 2005 that could not knock the hanging tetra off, and in 2008 that could not drive forward to cross one line. These are extremely simple tasks that teams are just not doing. Whether it is due to lack of time, programming experience, or anything else it is obvious we are not ready to make autonomous any harder.
In order to make autonomous more common, not only does its treatment within the game need to change, but its ease of programming. Programming autonomous should be no more difficult than planning a field trip. However, that's a community-based project. At the moment autonomous may be difficult for most teams, but that's something we can change. Do you want to help?

artdutra04
15-05-2010, 17:20
In order to make autonomous more common, not only does its treatment within the game need to change, but its ease of programming. Programming autonomous should be no more difficult than planning a field trip. However, that's a community-based project. At the moment autonomous may be difficult for most teams, but that's something we can change. Do you want to help?How do you make programming autonomous easier? There are thousands of different FRC robot configurations, every one different from the other. Different drive trains, different mechanisms, different sensors (or lack thereof).

Programming fully autonomous (or semi-autonomous) robots is difficult and takes a long time. It takes a lot of processor power, a lot of memory, a lot of sensors to make them "smart". Odometry calculations, matrix frame transformations, filtering of sensor data (such as with Kalman filters), forward/inverse kinematics, environment mapping, navigation and pathfinding/planning, etc. This is all high-level stuff that isn't even approached until the second half of an undergraduate engineering degree, and would be way over the heads of high school students.

And then to package this into a modular software package applicable to any FRC robot with simplicity that would make Apple jealous? If there is anyone who is seriously considering the effort to create this, they're probably in industry right now doing it to earn money, either for an existing company or a start-up they founded, because that final product would be worth serious $$$.

The only way you'd ever see any kind of really advanced autonomous or even significant-majority autonomous action in FRC is to use small, nearly identical robots. Shift the focus away from mechanisms and towards controls and programming. But this would cause major outrage in the FIRST community. Many of the students and mentors currently involved like to be involved because of what FRC currently is; there are plenty of other competitions where mechanical design takes a backseat to programming and controls, like the autonomous soccer competitions or Trinity Firefighting.

That being said, if autonomous in FRC was extended to 20 seconds long, and if there was a significant scoring bonus for achieving tasks during this time (especially with an easy task, a medium task and a difficult task, all rewarded appropriately with points), then you'd see a lot of teams out there with advanced autonomous modes.

Increase the return-on-investment for points scored in autonomous mode versus the man-hours of effort to get those points, and you'll see a lot more teams doing a lot more advanced autonomous modes.

Tom Line
15-05-2010, 20:09
I've attatched a link to the trinity fire fighting robot contest.

This has not only a high school division, but also a junior division.

http://www.trincoll.edu/events/robot/

I think what is holding FIRST back is the way it encourages autonomous. First off unlike trinity, it is not really a requisite. As many have said the advantage of having a strong autonomous robot has been reduced greatly recently, which confuses me seeing as they invested in the cRIO. In the past we were given 15 seconds, and a good autonomous gave you a distinct advantage but did not at all guarantee a win (see 2004). Now we've been given c++, java, and labview but we're only allotted 10 sec, and in this game 3 points if you were lucky.

because of this movement it has forced a priority shift almost entirely to the engineering, which is why I believe you saw almost no autonomous this year... making programming an "if we have time" sort of thing. I would like to see a shift back to the 04/06 style autonomous, to give us and more importantly our teams the incentive for making impressive autonomous robots.

I'm not sure I understand. Autonomous is 15 seconds. It was all of this year.

In addition, while many people didn't realize it, autonomous was absolutely critical this year to success. Much like normal soccer, ball control this year was absolutely critical. Getting your balls moved into your zone in auto gave you a HUGE advantage - even if you did not score them.

If you look back at the highly contested matches this year (heck, look at Einstein), without auton you lose. Without hanging, the team that won might very well have lost.

While it isn't worth the insane amount it was in '06, if you wanted to compete at the high end of the spectrum then you had a good autonomous.

As a great example - ours was malfunctioning during qualification rounds because we had to change the surgical tubing powering our shooter, and the new stuff had significantly different spring rates than the old stuff. Had we had it running correctly, our final seeding score might have made it a different ball game. In the playoffs, we got it working. Our semifinals matches would have been lost without us nailing the shots that we did.

Auton this year wasn't critical to playing the game, but it was crucial to playing the game at a high level. I think that is the perfect measure of it's importance, as it lets newer teams still compete, and powerhouse teams show off their prowess. (Edit - I am not suggesting we are a powerhouse. Far from it. But without a good auton we wouldn't have done nearly as well as we did this year).

mwtidd
17-05-2010, 00:42
I think that is the perfect measure of it's importance, as it lets newer teams still compete, and powerhouse teams show off their prowess.

Sorry for my mistake on the length of autonomous, and thanks for correcting me.

My comments were directed at two things, capability and priority.

I believe that high school students are capable of building an impressive autonomous as displayed by the trinity comp.

With regards to priority, Trinity forces autonomous and programming to be considered for all teams, where as FIRST it is "optional". As you said for all-stars it is also necessary, I can't tell you how many times our matches were decided in the first and last 15 seconds. If you look at my team, years we have autonomous we make it to the elimination rounds and years we don't have one we don't make it. So I totally agree.

My thoughts are though that as FIRST doesn't "require" autonomous, it falls down the priority chain for even experienced teams. My comments were with regards to FIRST making autonomous more "mandatory" and raising its priority. In doing so they would have to better support the programming in such a way that a rookie team could have an autonomous.

I think given the appropriate tools and learning channels (tutorials) all teams could produce very impressive autonomous robots, its just a matter of adjusting the priority with the engineers.

I also know the argument can be made that this isn't the responsibility of FIRST, I just wish i wasn't always debugging in the pits :)

JamesBrown
17-05-2010, 09:14
In order to make autonomous more common, not only does its treatment within the game need to change, but its ease of programming. Programming autonomous should be no more difficult than planning a field trip. However, that's a community-based project. At the moment autonomous may be difficult for most teams, but that's something we can change. Do you want to help?

I would be more than willing to help, however, I think that the solution to the problem is not making programming Autonomous simpler, it is teaching students (and in some cases mentors) the basics of programming and control.

Creating an effective autonomous that performs a basic task (i.e. dropping the hanging tetra in 2005, crossing 1-2 lines in 2008, or scoring from the first zone in 2010, or just moving defensively 2006 and 2009) is not difficult given the libraries first has provided. I taught myself to program for FIRST in 2005, by the end of 6 weeks our robot could consistently score in autonomous (by dropping the hanging tetra) by Battle Cry we could score twice in autonomous (drop the hanging tetra and put the preloaded tetra into the bottom of the middle goal). Since teaching my self to program in 2005, I have decided to pursue a career in Control and Automation. Needless to say my teams' autonomous modes have gotten more sophisticated as I went through college, but along the way I have seen/helped plenty of high school students learn to write code and wire sensors that let them create their own autonomous modes, beyond what I could do when I started.

Long story short, I don't know what you are proposing to do to make autonomous a attainable task for all teams, but feel free to PM me with more information. I think that a group of mentors and capable HS programmers spread out around the country could easily create a program and run workshops to teach teams with out the necessary mentor support how to program so they can write their own autonomous modes. However the more commonly proposed method, building libraries, or a scripting language for students to use, is ultimately curing the symptom (Teams that don't move in autonomous), not the problem (Teams don't have the knowledge/resources to write their own autonomous).

progal
17-05-2010, 09:16
When I responded to this before, I think I made myself unclear. I would love to take the challenge, but of course, I would have to talk to my team about it. This would be a very fun challenge, yes, but like I said before, team 1086 isn't going to participate unless said otherwise.

Sorry for the misunderstanding! :)

mwtidd
17-05-2010, 13:10
I would be more than willing to help, however, I think that the solution to the problem is not making programming Autonomous simpler, it is teaching students (and in some cases mentors) the basics of programming and control.

James, I have a few developers who have signed on with me for the Bobotics ADK, you can find it on First Forge, and I would love it if you could help out.


The ADK is set up in a way to make programming easier to learn. After someone learns the basics, they can do more advanced things like using an async event system, set up complex state machines, learn about the MVC and factory design patterns. The core of the program does most of the background work, which helps to lower the "getting started barrier", however it is highly extensible for advanced developers.

Robototes2412
17-05-2010, 13:29
Im sorry if this angers anyone, but I firmly believe that people need to start by sending raw pwm values to the speed controllers, then use the class, then make a class to control the victors, then work on autonomous. In order to program effectively, you need to tailor the code to the device by learning how it works.

Then you can use the Bobotics ADK.

Joe Ross
17-05-2010, 14:01
I've attatched a link to the trinity fire fighting robot contest.

This has not only a high school division, but also a junior division.

http://www.trincoll.edu/events/robot/

There are (at least) two features of the trinity competition that make it much more feasible to be fully autonomous.

First, there are no limitations on time to build the robot. The competitions are approximately the same from year to year. Thus you have a lot more time to work on autonomy. Not only does FIRST have a six week build season, and radically different games each year, but you aren't even allowed to reuse code (in many cases). In Trinity, you could build the robot one year, and just make software and sensor tweaks over the years. You can really learn from the best and directly apply those the next year.

Second, in Trinity, you're the only robot on the course. All the obstacles are things that you choose based on the point values. In FIRST, you have to figure out how to sense and avoid 5 other robots, who will be moving very fast.

gblake
17-05-2010, 14:03
Im sorry if this angers anyone, but I firmly believe that people need to start by sending raw pwm values to the speed controllers, then use the class, then make a class to control the victors, then work on autonomous. In order to program effectively, you need to tailor the code to the device by learning how it works.

Then you can use the Bobotics ADK.Don't forget how important it is to write the initial versions of these routines using assembly language; and and also only using locally developed device drivers, instead of skipping past that part of learning how the devices work.

Blake

PS: I have a spare Morse code key if anyone wants to use it to enter the 1's and 0's of their executables.
PPS: ;)
PPPS: There certainly is value in understanding a layer or two of detail below whatever layer of abstraction you are writing code for; but I'm not sure that you have fully articulated a compelling reason for why the path you advocate is the best way to learn to effectively program an FRC robot (or similar device). You have made an assertion with some merit; but so far I don't see it as a compelling argument.

JamesBrown
17-05-2010, 14:39
Im sorry if this angers anyone, but I firmly believe that people need to start by sending raw pwm values to the speed controllers, then use the class, then make a class to control the victors, then work on autonomous. In order to program effectively, you need to tailor the code to the device by learning how it works.

Then you can use the Bobotics ADK.

All of those layers are important to learn but learning them in that order is not the best option. Why not start at the top. Once you learn what a class does you can follow through by learning why and how it does it.

The beautiful thing about using an API is that you don't need to tailor your code to a device, you can write high level code while programmers with more time/experience/expertise can handle the low level platform specific code.

conceptsingh
17-05-2010, 14:54
wow that is very challenging because it like the robot have it own mind to play the game but it also depend on the field too because they change the measurement and what on the field too like this year they said that the bump height was 12 in but later when i check the online manual they change the bump height to 13 and a half in. So it basically depend on the game and what they want us to do.

mwtidd
17-05-2010, 15:14
There are (at least) two features of the trinity competition that make it much more feasible to be fully autonomous.

This is definitely true, my comments weren't regard with the challenge but rather that every team should be able to have an autonomous if they're given the proper tools and learning channels. I agree that trinity forces fully autonomous and thus maybe the analogy wasn't fully appropriate. My thoughts were that FIRST could do the same on a smaller scale. If they continued the model of 2006 it would have forced all teams to at least think about defense in autonomous.

Also as long as you make your source code public at the end of every year, you can reuse it as it acts as a COTS part.

There certainly is value in understanding a layer or two of detail below whatever layer of abstraction you are writing code for; but I'm not sure that you have fully articulated a compelling reason for why the path you advocate is the best way to learn to effectively program an FRC robot (or similar device). You have made an assertion with some merit; but so far I don't see it as a compelling argument.

I agree that assembly should be in there somewhere. I was trying to mimic my undergraduate education in the way I approached the ADK. First you learn the basics of programming languages, then you would learn basic soft eng techniques, and finally design patterns. I am not great at system level things like assembly. My hopes is that someone else could help with this end. Also I was not emphasizing this because I view the wpilib as the low level. My goal with the ADK is to provide high level object oriented design education.

This is a link to WPI's course flow chart
http://www.wpi.edu/Images/CMS/UGP/cschart-10-11.pdf

To summarize start with java, then go to C and C++, then go to soft eng and assembly, and finally go to OOAD(design patterns)

All of those layers are important to learn but learning them in that order is not the best option. Why not start at the top. Once you learn what a class does you can follow through by learning why and how it does it.

The beautiful thing about using an API is that you don't need to tailor your code to a device, you can write high level code while programmers with more time/experience/expertise can handle the low level platform specific code.

Good point. In retrospect looking at the WPI plan this is exactly how they approach it.

Robototes2412
17-05-2010, 16:20
*sigh*

What I meant is it is always a good idea to know how the device you are programming works. I don't have a college-level education in this stuff, I only know what I can reverse-engineer. I think that the best way to learn how these robotics platforms work is to try things, read manuals, and mess up. Failure is the best teacher.

I am currently teaching a couple freshmen how to hack at stuff. I had them start with a ps/2 mouse and an arduino, and they turned it into encoders for our robot.

"I don't believe in shortcuts! I believe in the almighty GPL!"

kamocat
17-05-2010, 16:34
*sigh*

What I meant is it is always a good idea to know how the device you are programming works. I don't have a college-level education in this stuff, I only know what I can reverse-engineer. I think that the best way to learn how these robotics platforms work is to try things, read manuals, and mess up. Failure is the best teacher.

I am currently teaching a couple freshmen how to hack at stuff. I had them start with a ps/2 mouse and an arduino, and they turned it into encoders for our robot.

"I don't believe in shortcuts! I believe in the almighty GPL!"
You do have a good point.
It's essential for the programmers to understand the underlying technology if you expect them to recover from failures. How can they fix a problem if they can't isolate or identify it?
Autonomous is certainly not how you start programming a robot. Start with learning how the system works. What is PWM? Why is it used as a data signal? How (and why) is it used to control the speed of the motor? What is the "braking" action of a brushed DC motor? Why can't the motor run at infinitely slow speeds? What are encoders and potentiometers? How does the health of the battery affect the performance of the motor? What is an FPGA? Why is it used instead of a processor?
I think the WPI library is fairly low-level, though if you wanted, you could periodically generate digital pulses with digital outputs. Having a standalone PWM-generator is also useful. We put a speaker on ours when we made it, so you can actually hear the square wave change as you adjust the duty cycle.

Anyways, understanding how the components of the system work is necessary to understand how the system can fail.

davidthefat
18-05-2010, 21:20
I think the priority should be the Robotic perception rather than locomotion. You can have the biggest and the strongest and fastest athlete, but if he is blind, he can be beat by a regular joe with 20/20 vision in a game of football or something.

mjcoss
21-05-2010, 17:32
I think that one of the biggest stumbling block for development of autonomous code is time. Programmers are usually the last folks to get their hands on the robot. While we can code things up, we must wait for the robot build process to get to a sufficiently stable point that we can grab the robot to run tests.

If the autonomous code is just a hand crafted set of instructions, then it must be tested, and refined many times to get it working properly. If the autonomous code is more of a state machine with transitions triggered by sensors, then this to must be laboriously tested. If it's an even more elaborate learning system, then the testing is even more intensive.

Bottom line is that there typically just isn't the time to do the needed testing. So some times just code up something simple, others never get around to putting anything into autonomous mode.

As far as the original idea of a fully autonomous robot, while I applaud the ambition, I suspect that it will be unrealistic for most, if not all, teams to be able to do that, given the empirical evidence of autonomous performance to date for most teams.

pSYeNCe
23-05-2010, 17:16
I think that one of the biggest stumbling block for development of autonomous code is time.

Bottom line is that there typically just isn't the time to do the needed testing.

This is precisely why I won't be able to accept the challenge. This last year I had one day to really test the code nonstop- all the other days I'd have it for a few minutes after grabbing it from the build team. I'd love to participate in this challenge- I believe it's a great one that would give any participant a lot of insight into programming- I can't due to insane time constraints. It's not plausible without the time to test.

davidthefat
23-05-2010, 21:51
This is precisely why I won't be able to accept the challenge. This last year I had one day to really test the code nonstop- all the other days I'd have it for a few minutes after grabbing it from the build team. I'd love to participate in this challenge- I believe it's a great one that would give any participant a lot of insight into programming- I can't due to insane time constraints. It's not plausible without the time to test.

You know what, I will just be the team leader and have a "software first" mentality. Just recruit more programmers. I would have an army of programmers, plus, I am the biggest and strongest on the team:D :p

Alan Anderson
23-05-2010, 22:37
You know what, I will just be the team leader and have a "software first" mentality. Just recruit more programmers.

The typical problem is not a lack of programming resources. It's a lack of robot.

There are two ways the TechnoKats have successfully dealt with this problem. One is to build into the schedule a set of "programming only" sessions. We did this a couple of years ago, with the programming group having absolute priority on the robot a couple of evenings a week starting in Week 3 of the build. The mechanical and electrical groups were denied permission to work on the robot during those times (though they were encouraged to be present in case something broke). This worked out great because we built a practice 'bot at the same time, so "the robot" was actually able to be used by two groups simultaneously.

The other way is to finish the robot well in advance of ship date so that the programmers have plenty of time with it. This also has benefits for the drivers, giving them plenty of practice time. And probably the best thing about being done early is that there's plenty of time to break the robot. :)

Chris is me
23-05-2010, 22:38
You know what, I will just be the team leader and have a "software first" mentality. Just recruit more programmers. I would have an army of programmers, plus, I am the biggest and strongest on the team:D :p

That should help, but by now I bet you realize the constraint here isn't whether or not you can get people typing fast enough. It's not work that just needs to be chugged through.

Doug Leppard
24-05-2010, 08:32
You know what, I will just be the team leader and have a "software first" mentality. Just recruit more programmers. I would have an army of programmers, plus, I am the biggest and strongest on the team:D :p

If you had an army of hardware guys would the robot be buildt faster? Usually not in fact it can slow the process.

I agree usually the robot hardware is not ready in time to do 15 seconds of a game much less 2 minutes.

Doug Leppard
24-05-2010, 08:35
Maybe this has been already suggested I haven't read all the posts.

How about having a post championships competition, like IRI where the robots are totally autonomous. Maybe have it at IRI as one of the vents.

This way there is more time to work on the robot post season.

Andrew Schreiber
24-05-2010, 09:18
If you had an army of hardware guys would the robot be buildt faster? Usually not in fact it can slow the process.


Yes, adding workers can slow a process. http://en.wikipedia.org/wiki/The_Mythical_Man-Month may be of some interest to you.

davidthefat
28-11-2010, 00:44
I am bumping this one up cause I honestly did not want to start another thread and as the kickoff gets closer, I thought people should see this.

I found a solution to the image processing problem.
http://microcontrollershop.com/product_info.php?cPath=154_170_268&products_id=3529

No battery: Legal
4 USB ports = Good
Runs Linux (The Arm 9 Linux uses 32 mb of ram, and this has 32 mb ram... So IDK...)


I realized I can not use the PS3 or a PC due to lack of voltage generated form the batteries... Don't they need a minimum of 110v? and the battery is 12 v.

It says it supports up to 4 webcams, but I do not know how well it can perform while processing images.
I can either just process the data and send the raw data obtained from the camera to the cRio and process the logic there or process the logic on the board. Thats a minor detail that can be experimented with.

Chris is me
28-11-2010, 10:46
I realized I can not use the PS3 or a PC due to lack of voltage generated form the batteries... Don't they need a minimum of 110v? and the battery is 12 v.

That's not exactly true. They need 110V of AC power, and the battery supplies 12 V of DC power. It's not really a matter of simply "oh, 110 is bigger than 12, guess I'm screwed". You could use a power inverter, though I don't think power inverters are FIRST legal...

Have you written any successful programming logic since your last post?

davidthefat
28-11-2010, 11:26
That's not exactly true. They need 110V of AC power, and the battery supplies 12 V of DC power. It's not really a matter of simply "oh, 110 is bigger than 12, guess I'm screwed". You could use a power inverter, though I don't think power inverters are FIRST legal...

Have you written any successful programming logic since your last post?

I honestly have not done any programming since summer. :o

Vikesrock
28-11-2010, 13:17
I am bumping this one up cause I honestly did not want to start another thread and as the kickoff gets closer, I thought people should see this.

I found a solution to the image processing problem.
http://microcontrollershop.com/product_info.php?cPath=154_170_268&products_id=3529

No battery: Legal
4 USB ports = Good
Runs Linux (The Arm 9 Linux uses 32 mb of ram, and this has 32 mb ram... So IDK...)


I realized I can not use the PS3 or a PC due to lack of voltage generated form the batteries... Don't they need a minimum of 110v? and the battery is 12 v.

It says it supports up to 4 webcams, but I do not know how well it can perform while processing images.
I can either just process the data and send the raw data obtained from the camera to the cRio and process the logic there or process the logic on the board. Thats a minor detail that can be experimented with.

Another option would be a mini-ITX motherboard. Some of them have a 12VDC jack for power input. I know a number of jetway boards in particular use this form of power input. If you use the default BIOS settings I believe you can run without a CMOS battery, but I'm not positive about that. Using a small SSD for storage you may be able to get an FRC legal computer running.

PAR_WIG1350
28-11-2010, 17:48
I honestly have not done any programming since summer. :o

When an artist works on something for too long, nothing about it seems to be good enough. It isn't until he leaves it alone for a while before returning that he can see what truly needs to be worked on.

--Me

theprgramerdude
28-11-2010, 19:24
Agreed with the above. I backed off of it, and instead have been studying the bigger picture of how to build a decent robot, as well as some of the sensors available for input. There's no reason to try all autonomous anyways if your robot just flat-out sucks.

davidthefat
28-11-2010, 19:36
Well I plan to get a hold of that GadgetPC sometime soon and start working on the cameras and stuff. I really wanted to try parallel processing with multiple cores, but I guess I can hold off for a while.

PAR_WIG1350
29-11-2010, 18:52
Well I plan to get a hold of that GadgetPC sometime soon and start working on the cameras and stuff. I really wanted to try parallel processing with multiple cores, but I guess I can hold off for a while.

Stick with what you know, especially that which you know but don't know that you know. Think about how you think. How do you tell what an object is? How do you know if it needs to be avoided? In humans, image processing occurs in the occipital lobes of the brain which communicate with the frontal lobes to determine what everything is based on stored information. In your system, the GadgetPC seems to be equivalent to the occipital lobes of the brain. The frontal lobes would be the CRIO, possibly the FPGA. This involves a lot of boolean logic.
is it a wall?
yes
{avoid}
no
{is it a robot?
yes
{do something, maybe add an extra "is it an opposing robot?" test}
no
{is it a scoring object?
yes
{pick it up}
no
{is it a goal?
yes
{score, if scoring objects are in possession}
no
{is it part of the field that can be driven over?
yes
{ignore}
no
{avoid}
}}}
Another important part of the brain is the parietal lobe--> processes other sensory information and builds maps of the environment

Motion would be controlled by another part of the system that uses all of this information gathered by the three "lobes" and maps out the best route to take.
-----------------------------------------------------------------------------------
**note** this isn't exactly how the human brain works, I'm just simplifying it to fit the application better and to avoid confusion of some people, myself included.
___________________________________________
I'm sorry if this is hard to follow or makes no sense, I had a hard time wording it, or even figuring out what I was trying to say, maybe I should take a break and come back to it later

davidthefat
29-11-2010, 19:27
Stick with what you know, especially that which you know but don't know that you know. Think about how you think. How do you tell what an object is? How do you know if it needs to be avoided? In humans, image processing occurs in the occipital lobes of the brain which communicate with the frontal lobes to determine what everything is based on stored information. In your system, the GadgetPC seems to be equivalent to the occipital lobes of the brain. The frontal lobes would be the CRIO, possibly the FPGA. This involves a lot of boolean logic.
is it a wall?
yes
{avoid}
no
{is it a robot?
yes
{do something, maybe add an extra "is it an opposing robot?" test}
no
{is it a scoring object?
yes
{pick it up}
no
{is it a goal?
yes
{score, if scoring objects are in possession}
no
{is it part of the field that can be driven over?
yes
{ignore}
no
{avoid}
}}}
Another important part of the brain is the parietal lobe--> processes other sensory information and builds maps of the environment

Motion would be controlled by another part of the system that uses all of this information gathered by the three "lobes" and maps out the best route to take.
-----------------------------------------------------------------------------------
**note** this isn't exactly how the human brain works, I'm just simplifying it to fit the application better and to avoid confusion of some people, myself included.
___________________________________________
I'm sorry if this is hard to follow or makes no sense, I had a hard time wording it, or even figuring out what I was trying to say, maybe I should take a break and come back to it later

I am assuming the bumper system is going to be mandatory again, so I thought that I can just do a color detection of the blob and decide with that info if that robot is an enemy or not. Also for detecting the objects, I have to think a bit more about that. I thought that just comparing colors is simple enough, but that can be very shoddy.

I been looking at the Machine Learning lectures by Andrew Ng @Stanford, I think that will give me a better insight on this.

I totally understand what you are saying, my mind thinks the same. What I was hoping I could do was use the PS3, but that does not seem likely.

There are 8 SPEs, only 7 are available, but thats fine. I was thinking each SPE was to be responsible for one part. All the SPEs can access the images without writing to it, so no problem there since all the SPEs would be only reading. Like 1 SPE can do the color detection, another do the distances of the objects, another do object recognition, and ect. They all relay that info to the PPE which will then compile the info and then do the logic. Then the PS3, through the ethernet, sends the instructions to the cRio.

Now that seems like a stretch, but honestly I like to aim high. I am 1/4 through the MIT PS3 lectures, I have learned so much just from that LOL.

If the PS3 is legal and the DC to AC inverters are legal, I can go ahead with this. Only problem, its my only PS3, do I want to potentially risk it getting crushed or something? I have 2 options too, run linux or go the homebrew way? I got a 60GB Japanese launch PS3, I still run linux on it, I have not updated it. The linux libraries for the PS3 are well documented and very thorough (IBM wrote them), but I would assume the homebrew route would have incomplete and shady libraries since its in its infancy. The down side of the linux on PS3 is the boot time, takes at least 45 seconds to boot up. The game OS only takes 2 seconds.

apalrd
29-11-2010, 19:55
... takes at least 45 seconds to boot up.

That's about as fast as the cRio anyway (seriously, it takes forever to boot)

biojae
30-11-2010, 02:43
Another important part of the brain is the parietal lobe--> processes other sensory information and builds maps of the environment


That's where SLAM (Simultaneous Localization And Mapping) can come in.
(or, a partial implementation seeing as the field doesn't change from one match to the next (hopefully),
and a full map could be made once)


Motion would be controlled by another part of the system that uses all of this information gathered by the three "lobes" and maps out the best route to take.


With a full map made, a path planning algorithm (such as A*, Dijkstra's algorithm, or others) could find the best path (shortest, least time, less obstacles, etc.).
And if this was constantly updated with current sensor information, it could try to find a route around other robots too.


I am thinking of using 2 60fps cameras as a stereo vision system.


Then the mapping phase would be fairly easy, as stereo vision can give you depth information.

This video shows an IRobot Create with a Kinect camera performing SLAM:
http://www.youtube.com/watch?v=dRPEns8MS2o

ptan
30-11-2010, 21:41
For what it's worth, you may want to check out CMU's intro to robotics course

http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/16311/www/current/

Especially check out Lab3 which has the some useful dead reckoning code (Yes, we are using their code in our robots).

davidthefat
30-11-2010, 22:04
For what it's worth, you may want to check out CMU's intro to robotics course

http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/16311/www/current/

Especially check out Lab3 which has the some useful dead reckoning code (Yes, we are using their code in our robots).

I purposely did not want to use the CMUCams because I honestly want to experience the process of making such algorithms. Because this is not all about winning. I first took this challenge to push myself and really dedicate and learn. I am also purposely staying away from OpenCV and other libraries for the same reason. Yes I have read in a lot of posts about why not to reinvent the wheel. I do it because I love doing it, it builds character and you learn a lot more than just reusing what some one has made. I push myself now so I don't have to push my self later, I wish I had learned earlier on. I wish I have learned it in elementary or middle school because that really is a valuable thing to learn. When I am doing my graduate work, the things I work on will not be canned projects like the ones we do in science class, I would be the forefront of my area of expertise. If I learn to do it on my own, its alot better than learning it too late. Its different from just plugging in the variables in a equation and getting the right answer than understanding why and how you got that answer. I believe the latter is what I strive for.

People will disagree with my mentality especially engineers, but I feel that is what I need as a student and as a person. My counselor told me that no one will just wait for me to help me, I have to actively seek help if I need it. I always think that if you reinvent the wheel, chances of you doing it better is greater than just reusing it. If you just reuse it, you will never be able to improve it.

Also if I fail, I learn, which in my book is success.
"I have not failed. I've just found 10,000 ways that won't work." -Thomas Edison

AdamHeard
01-12-2010, 00:32
I purposely did not want to use the CMUCams because I honestly want to experience the process of making such algorithms. Because this is not all about winning. I first took this challenge to push myself and really dedicate and learn. I am also purposely staying away from OpenCV and other libraries for the same reason. Yes I have read in a lot of posts about why not to reinvent the wheel. I do it because I love doing it, it builds character and you learn a lot more than just reusing what some one has made. I push myself now so I don't have to push my self later, I wish I had learned earlier on. I wish I have learned it in elementary or middle school because that really is a valuable thing to learn. When I am doing my graduate work, the things I work on will not be canned projects like the ones we do in science class, I would be the forefront of my area of expertise. If I learn to do it on my own, its alot better than learning it too late. Its different from just plugging in the variables in a equation and getting the right answer than understanding why and how you got that answer. I believe the latter is what I strive for.

People will disagree with my mentality especially engineers, but I feel that is what I need as a student and as a person. My counselor told me that no one will just wait for me to help me, I have to actively seek help if I need it. I always think that if you reinvent the wheel, chances of you doing it better is greater than just reusing it. If you just reuse it, you will never be able to improve it.

Also if I fail, I learn, which in my book is success.
"I have not failed. I've just found 10,000 ways that won't work." -Thomas Edison

I think you're getting caught up on this reuse concept. Based on your logic, pretty much every respected innovation currently on the market is not innovative, as it reused something.

Your goal of biting off 100 times more than you can chew is probably going to slow your learning process overall, there is nothing wrong with learning things in smaller steps.

Your ambition is good, your plan isn't so much.

Andrew Schreiber
01-12-2010, 01:00
That's about as fast as the cRio anyway (seriously, it takes forever to boot)

Which confuses me since the CRIO I have at work boots up and runs my code nearly instantly.

davidthefat
01-12-2010, 01:06
Which confuses me since the CRIO I have at work boots up and runs my code nearly instantly.

I think he meant the time it takes to connect to the classmate and have full control of it. Usually our robot has a 10-15 second delay when the green light comes up on screen and when it actually has connection

Andrew Schreiber
01-12-2010, 01:09
I think he meant the time it takes to connect to the classmate and have full control of it. Usually our robot has a 10-15 second delay when the green light comes up on screen and when it actually has connection

Which is not at all what he said. In the future we should try to be more precise on what we mean especially when complaining about things.

apalrd
01-12-2010, 11:16
Clarification:

45 seconds is about the total time it takes from the time when power is applied until the time which the complete control system is ready to be enabled, assuming the Classmate is already running. So, not the boot time of the cRio itself, but the entire robot-end control system.

Alan Anderson
01-12-2010, 12:09
I push myself now so I don't have to push my self later, I wish I had learned earlier on.

I have a high level of confidence that you will wish something completely different later on.

Trust me, you really don't want to set yourself up for a mindset of already having put in your effort and wishing to relax early. Ignoring resources now will only make you work harder to get to the same place others will be, and you will still have to "push" once you get there if you don't want to find yourself falling behind.

People will disagree with my mentality especially engineers,...

You got that right.

I always think that if you reinvent the wheel, chances of you doing it better is greater than just reusing it. If you just reuse it, you will never be able to improve it.

On the other hand, I think you got that part wrong. If you refuse to reuse it, you do not have the opportunity to make it better. You might eventually come up with something different that works better, but without building on earlier work you will find it takes a lot longer to succeed than if you had used the head start offered to you. In the meantime, others who did reuse it will likely already have improved on it before you get to that point.

I'm not belittling your goals. It's your plan for achieving them that I think needs some tweaking.

Foster
01-12-2010, 12:41
Which is not at all what he said. In the future we should try to be more precise on what we mean especially when complaining about things.

You must be new around here :rolleyes:

I'm a big fan of the "Stand on the Shoulders of Giants (tm)" I like to use other peoples ideas/products/code/etc. to get started. Once I have things in place that work I can start refining / optimizing small parts to make them better. I know that I can dig iron and coal out of a hill, but it does not mean that I want to make my own steel gears from scratch.

So from a few posts up. I would use the CMU camera and it's code. Once I understood how it worked, I would start changing sections out to make it better and better. While there are other platforms you can use, any of them are better than starting with:
main(){
}

as a starting point.

Andrew Schreiber
01-12-2010, 14:41
You must be new around here :rolleyes:

A man can dream can't he?

ptan
01-12-2010, 15:29
I purposely did not want to use the CMUCams because I honestly want to experience the process of making such algorithms. ...

hmmm... Interesting. The link I provided did NOT have any reference to CMUCams. It is a basic Introduction to Robotics class, where all the math and materials are put online. (My daughter is being a teaching assistant in this course next semester).

I find it fascinating that people here are jumping to conclusions without checking out the facts (or links in this case). CMU does NOT just make the CMUCam !!!

In any event, the course itself is useful to take a look at for the ideas and the math behind a lot of the robotics. Why do you want to go ahead an reinvent the math when you can just look at the math and find out if you want to use it, or better still, find something better!?

ptan
01-12-2010, 15:34
You must be new around here :rolleyes:

I'm a big fan of the "Stand on the Shoulders of Giants (tm)" I like to use other peoples ideas/products/code/etc. to get started.
...


Agreed.

As an Engineer, I can definitely state that in the Real World, you have to build on what other people have done. I don't see anything wrong with doing that in school or robotics competitions.

This reminds me of one of the Science Exhibits I once saw titled: Baking an Apple Pie from Scratch.

Step 1: Create the Universe
Step 2: Create Life on Earth
Step 3: Create Apple Trees
Step 4: ...

The point is, you have to start somewhere. Don't be too arrogant as to think that just because you didn't invent it, it is not useful.

DDSLoan96
06-12-2010, 20:36
What you could try doing is incorporating Kinect into your Robot as it has depth and color perception built in and that could help in a game that may be like Overdrive...just a thought

davidthefat
06-12-2010, 20:42
What you could try doing is incorporating Kinect into your Robot as it has depth and color perception built in and that could help in a game that may be like Overdrive...just a thought

Not exactly, you still have to write drivers for it and I am not sure if most of the image processing takes place on board on the Kinect or its processed on the 360 itself. Now it would be a pain in the butt either way. If it is onboard, there would be a fair amount of reverse engineering and getting the drivers to work, the second way, you have to program everything your self.

I am not going the kinect route like I mentioned before.

AustinSchuh
06-12-2010, 20:54
Not exactly, you still have to write drivers for it.

It's already been hacked, and there are open source drivers for Linux.

EricVanWyk
07-12-2010, 01:48
It's already been hacked, and there are open source drivers for Linux.

You forget that David prefers to create things himself. He'll create his own drivers just as soon as he finishes converting sand into processors.

Alan Anderson
07-12-2010, 09:45
What you could try doing is incorporating Kinect into your Robot...

It's very likely that the Kinect's depth perception hardware will be prohibited on the robot under the "no lasers" rule. We'll find out next month whether it's an option.

I'd like to find out if two Kinect sensors pointed at the same object would interfere with each other. Does anyone here know if someone has tried it?

Vikesrock
07-12-2010, 09:50
It's very likely that the Kinect's depth perception hardware will be prohibited on the robot under the "no lasers" rule. We'll find out next month whether it's an option.

I'd like to find out if two Kinect sensors pointed at the same object would interfere with each other. Does anyone here know if someone has tried it?

There is minimal interefernce between multiple Kinects when pointed at the same object as long as the devices aren't right on top of each other or pointed right at each other. We have not gotten this far at work, the above represents reports from the OpenKinect community.

Andrew Schreiber
07-12-2010, 11:22
It's very likely that the Kinect's depth perception hardware will be prohibited on the robot under the "no lasers" rule. We'll find out next month whether it's an option.

Haven't IR range finders always been legal? [Standard disclaimer about last year's rules]

mwtidd
08-12-2010, 01:39
I'd like to find out if two Kinect sensors pointed at the same object would interfere with each other. Does anyone here know if someone has tried it?

This video is first example I've found of two images being merged in a 3d environment. He talks about and shows the interference, which is fairly minimal.
Note the video is actually a 3d recreation, notice how at the end he is able to move around the space.

http://www.youtube.com/watch?v=5-w7UXCAUJE


also here's a video of mit's kinectbot
does 3d mapping and gesture recognition.

http://www.youtube.com/watch?v=dRPEns8MS2o

gblake
01-08-2011, 22:42
link to a 5th Gear "AI" FYI update in a related thread
http://www.chiefdelphi.com/forums/showpost.php?p=1071505&postcount=21

theprgramerdude
07-08-2011, 13:52
Has anyone tried yet to simply use the Crio as an I/O device, and use it to send all images/Sensor data to a super-extra-beefy laptop with a modern GPU that can handle all the thinking for it? I'd imagine using something like a few cameras and then trying to perform a SLAM on the inbound stream would easily exceed what the Motorolla is capable of doing, but easily within the reaches of a CUDA-powered laptop.

Suitster
03-04-2012, 18:52
Gravedig Post:
With the introduction of the Kinect this year, that may be a better system, as one could program it to recognize game objects and robots.
At least I think so.
I was thinking about trying this, but my summer project is getting a crab drive to work

gixxy
03-04-2012, 19:04
Our turret was fairly autonomous this year.

Camera would target goal, find distance and angle from target. Center to Target. Figure out what speed to use on the wheels from calibration points. and we would fire.

Everything else was Operator control: driving, ball collection, hitting the fire button, Bridge mounter.

But man that Turret was a blast to code.

I can't guarantee that we will make fully autonomous robot, but we already try to make the Robot take care of itself as best we can.

theNerd
03-04-2012, 21:32
Could we, as an awesome robotics community, create a github for this? Each team could push and pull his or her ideas....creating a truly Graciously professional union between our teams.

rebug
04-04-2012, 13:57
Wait, one question:

How in the world are you going to know where other robots are? You could do vision tracking (sound painful, but possible) or use the laser rangefinder that google used (easier to program, harder to build).

Anyway, in my senior year, I would like to do camera tracking for everything, and make it completely autonomous. I hope the game that year is good...

PS: To gixxy: why is Programmer.program() static? are you the only one?

Taylor1023
04-04-2012, 17:49
Wow. That sounds both amazing and painful. It's an interesting concept, that's for sure. The main programmer on our team might be up to the challenge (only problem is that he is a senior right now and will only mentor next year). This could be something for our programming team to work on over the summer though.

It would certainly make for an interesting match if all the robots were autonomous, but what would the drivers do? I'm not sure if a fully autonomous robot could pull off a last-second balance or miracle shot like this year. And if a robot this year were autonomous, how would it know when to balance or how to react to defending robots? How would you program it to know the difference between an alliance partner and an opponent?

The human element in matches is important. If an alliance partner needed help (say their robot was tipped over) the fully autonomous robot probably wouldn't help right the other robot. And then there's always some faulty sensor or something. I'm not saying this is a bad idea, I'm saying this would be hard to pull off and still win matches.

Still, I would be absolutely awed if there was a robot next year that had full autonomous and could still win matches.

shuhao
04-04-2012, 19:00
I've been pushing for this the entire season.. However our team has no electrical, so I had to take over that part.. Also we don't have the funds to go all out on sensors.. and our mechanical team do not have time to mount an advance sensor system..

It's not entirely impossible. It just takes 1 really good programmer (SLAM, planning, control), a really good machinist (sensor turrents etc.), and a really good electrical guy (sensors, control systems etc.) to work on exclusively the autonomous mode while everyone else works on everything else about the robot and a lot of money to do it.. 6 weeks should be enough. Though it will be pretty difficult to accomplish in the scale of FIRST, as the robots are big and the field are not always the most friendly in terms of localization. The worst part is probably tracking other robots.. Not impossible, but pretty hard as everyone has different dimensions (though bumpers are the same.. hmm)

Me and our main builder (who is probably one of the best machinist I've ever encountered), and an outside friend who's excellent at electrical are starting to do a smaller robot that could do SLAM and auto navigation. We're making the entire robot open source once completed. The current design is approximately 18in x 11in big.

2185Bilal
04-04-2012, 23:06
Team 2185 - The RoboRams
Are up for that challenge :yikes: