FRC...autonomous or driver-controlled competition?

I got this topic idea from this thread: (“Capping Vision Tetras”)
http://www.chiefdelphi.com/forums/showthread.php?threadid=35033

Some of the messages from that thread really made me think about this whole “autonomous period vs. remote controlled period” thing. The debate going through my head right now is: should FIRST be giving more emphasis to the autonomous period (and extend it for more than 15 seconds?) or should it be leaning toward the remote-controlled aspect of the competition? I personally am still confused about this…I think the game still seems to be slightly unbalanced between the two. Even though I am in favor of extending the autonomous mode time, I can imagine that this would be an uninteresting move to make when we consider all of these teams that have no programmers…is that what we want? To leave them in disadvantage? Or to inspire students to expand their knowledge in autonomous programming? Well… what is FIRST’s objective, exactly? To turn FRC into a battle-bot game or an “AI” sort of contest?

What do you think?

Well, I think a longer Auto mode would be interesting to see. It gets you to a closer definition of “Robot” As opposed to a Radio controlled or Teleoperated vehicle. (Note: Im not trying to get into a semantics fight on what robot means! :smiley: ).

An idea i just came up with: What about a more “Supervisory” control system? By that i mean something like rather than sending direct commands to the motors via our OIs, something more like we have some sort of OI That has commands like “Seek Green Tetra” “Place on Right goal” etc. That might be interesting to see.

Personally, I would LOVE to see a post secondary version of FIRST. Yes I know there are some, but I haven’t seen any as well organized and as continuous as first. Plus FIRST always seems to have a fun game and nothing boring.
Think about it, you have Lego League, the FIRST League, and then a PS League. The PS league would have the harder challenge of more AI or the control scheme I mentioned above. Heck, you could have the FIRST and PS league play the same game, except the FIRST is radio controlled and the PS is autonomous controlled!

Without coming across as smart, I’d say FIRST’s objective for the FRC is to inspire the students, however that happens to be.

If they get the idea that an all-autonomous match would inspire more than a remote-controlled version, then by George, I think they’ll do it…

…but for now, I think that driver-controlled robots and some autonomous is the way to go, and the way they will go.

I personally strongly support a game dominated by autonomous mode. The competition in which we are currently engaged is often reffered to as “FRC” which stands for FIRST Robotics Competition. This would imply a competition in which robots compete. However if you read the thread linked above, or browse the programming forum you will find that the competition this year (and remember back to last year too) is nothing more than a remote control car building and driving contest. While this might be more interesting for some (spectators mainly), it makes the competition seem to be almost a fraud. I know that my club was founded as the “West Robotics Organization” rather than a FIRST team, and we joined FIRST because we needed a task. But we have recently discovered that for far less money we could build a robot based around a PC running linux, that would be very nearly infinitely more capable of autonomous operation than any FIRST robot, and for this reason this may be our last year participating in FIRST. While I have mixed feelings about this (I love almost everything about FIRST except for the lack of autonomous), I do have to say that at the current rate I will have to welcome a change.

While this might be more interesting for some (spectators mainly), it makes the competition seem to be almost a fraud. I know that my club was founded as the “West Robotics Organization” rather than a FIRST team, and we joined FIRST because we needed a task. But we have recently discovered that for far less money we could build a robot based around a PC running linux, that would be very nearly infinitely more capable of autonomous operation than any FIRST robot, and for this reason this may be our last year participating in FIRST.

Errrr… I don’t know what you are talking about. You can build a very capable robot that works using the controls that First provided that works solely using an autonomous mode. Not to mention you have to buy sensors, motors, and pretty much everything else. In the end you are probably going to end up spending the same amount that you will with First depending on what you want the robot to do. First robots fall under a form of robotics known as teleoperated robotics. Teleoperated robotics combine both human control and robotic control. You may be wondering what robotic control is there during driving mode but it is there. When you have a compressor on the robot it’s acting on it’s own, dipswitches, and pots are also forms of teloperated control. So why hasn’t someone gone beyond that. Who knows? To go beyone anything teleoperated would just be to complicated for a highschool student not to mention would really complicate the design of the game. I never liked this years autonomous code because it forces you to use the camera in order to detect the tetras.

You bring up some good points, but I still have to disagree. The RC is great for FIRST but it has serious limitations. The two main limitations are memory, and its inability to perform complex operations, or multiple operations at once. We can put together a reasonably good PC for $100, for another $200-$300 dollars outfit it with wireless network capabilities and one or more webcams. Then we can pick up all the sonar rangefinders we want for $30 dollars a piece (I am thinking of those Devantech something or others) get motors for another $30 a piece, piece together other sensors from old electronic junk laying around, a few hundred more for other electronic stuff, a few hundred for some encoders, a few hundred for chassis materials, and you are still only talking about a few thousand dollars. The materials I just listed are all aimed at building a robot based on the OAP project (http://oap.sourceforge.net) which is one thing we are currently investigating, but if you think about it rather than paying $5k for a kit from first you could put together a FIRST robot minus the control system for next to nothing, then put in a PC running linux with wireless network for a few hundred dollars, and there you have yourself a cheaper more capable FIRST robot. Now I understand that the control system is great for the actual competition, my point is simply that there is more to robotics than FIRST.

I think that the autonomous should stay 15 seconds, but it should have more options, more tasks, and the more difficult the task the greater advantage you have for the rest of the game. I think last years wast good. If you can cap the middle goal (which our team is hoping to do) its 9 points which is nice, but the 45 second delay was nice last year. I think that a team who display an extremly well planned out and intelligent autonomous should have a key advantage in the competition.(Maybe a section of a playing field which no one can see into with a task that would be completed inside.) That way it would encourage autonomous integration into the driving. Little ideas like that would make autonomous programming much more worth while.

You bring up a key point to remember. These are supposed to be STUDENT built machines, and many High Schools don’t have any real courses in programming, much less in C. The added pressure of Autonomus Mode results in Mentors such as myself doing a great deal of programming when we would/should be spending our time teaching the students.

Not that the concept of Autonomous Mode is at fault, but the lack of effective and easily configured software tools means that we are often working from the ground up. Kevin has made a great effort this year tward solving this issue, but the documentation was minimal, and it was difficult to figure out what his code was trying to do at times. We need a well documented set of tools (a written explanation of exactly how the function accomplishes it’s task, flow charts, algorithms, state diagrams, etc.) that can be EASILY adapted, and be used to teach our students.

It would also help if IFI would clean up their code a bit so the default software isn’t so cluttered. It’s a bit overwhelming when a kid who’s never written a program sees the default code for the first time. Most just get discouraged and walk away. An example would be to hide most of the initialization and just make us change (for example) the pin directions we want as outputs, or the baud rate on the TTL Serial Port. Also, give us a better I/O library! We’ve only got 6 weeks, and a kid shouldn’t have to learn how to build a buffer simply to get a character from the camera!

Steve

[quote=emusteve] These are supposed to be STUDENT built machines, …

Steve, are you sure??? Review some of the past speeches Dean has made. He wants to inspire, not necessarily educate or train. And he’s said it at either a kickoff or a Championship competition…if I remember correctly. (Perhaps at both!)[/quote]

i think FIRST needs to go one way or another because tweaking for both instances is taking up too much time and you must build a 2nd robot to be able to do that…

I think this would be a good idea, but working with a 5 week build season (stupid finals! :frowning: ) it would require much more foresight and planning to get the robot cranked out with a week or more to actually get the programming down.

I’m actually quite surprised our robot has all the stuff we needed in the code, since the rc is very restrictive in space, and we had only a few days to pull it all together (but the sophomore(!) who took over the programming is in an advanced trig class and AP Phys’ I was quite confident we/he could get it done in the time frame.)

Rombus, after our regional (Silicon Valley, March 24-26), contact me and I’ll tip you off on our ace in the hole, you’ll enjoy it. :wink:

There IS a very good advantage with a well-done autonomous this year, ie 17 doable points (knock-off one, cap vision tetra in center goal).
The problem I think is, that teams can get away without a good autonomous. Programming did not get as much team as we would like this year, because other things were more important. While it was crucial to get everything else to work, it was not crucial to get autonomous to work. Because even if you don’t have a good autonomous, “you’re at the playing field of the other teams.”
THAT is what is unfortunate IMO.

To take a different tack… Every year I think FIRST has to get “harder” to stay interesting. No mentor wants to do basically the same thing over the course of a decade, and even in my experience students loose interest in things once they “master” them. I think Autonomous mode is very important in that it gives veteran teams and student seniors an interesting and difficult goal… but rookie teams who write it off really won’t be penalized at all. I am very happy that autonomous has been added to FIRST in my time with the program—without it I’m not sure my last year in FIRST would have been half an interesting. This isn’t to say I don’t have some beef with this year’s autonomous task. Mastering the camera alone turned out to be a messy business, and 15 seconds really isn’t long enough to give most teams a fair shake at capping the center goal. Even with a human driver, I can’t see completing the task in much less than 10 seconds. Adding 5 seconds to autonomous wouldn’t so much “emphasize” autonomous as just make things more possible, this year at least. Of course changing something like that mid-year is a bad idea.

Speaking as a student preparing to leave for college, I would contend that anyone who believes that you can justify having mentors do a majority of the work under the premise of “inspiring” students is doing their students a huge disservice. I understand that in many cases students don’t have the skills required to make their building the robot practical, but in those situations I feel like the primary objective of the mentor is to give the students those skills as quickly as possible. I think FIRST has a duel purpose. When Dean talks about “inspiration” he is talking about changing the culture, and that means what happens outside of the bounds of our own team members. Internally we should be preparing kids to jump right in as college freshman with skills for doing real research and working internships.

I don’t believe that programming is that big a hurdle, even in terms of autonomous. I don’t have any formal schooling in c. I’m one of our lead programmers, and I designed the algorithms for our autonomous modes and for our macro arm functions. All that is required to be successful is literacy: understand if statements, case statements, #defines, and where you stick your function definitions. The default code might not be documented quite as clearly as it could be, but basically I see no reason why all teams can’t build the dozen lines of code needed for an array-based dead-reckoning autonomous mode. The biggest hurdle, it seems to me, is getting the programmer to understand what he needs to do to make the robot drive forwards for 5 seconds and then stop. Once you can do that, everything else is now within reach. Unfortunately to that end, chiefdelphi and our whitepapers seems much more helpful than the actual documentation of the code students are working on.

What I personally would like to see is more teams taking advantage of the power of autonomous functions during human control. The top articulation of our arm features a leveling function that reacts to the motion of the bottom articulation. Additionally, the driver has a set of buttons that bring the arm to specific locations for completing tasks with only one click. Perhaps instead of focusing on pure autonomous, FIRST games could encourage that type of human-autonomous cooperation during normal play. I can see game tasks that might require more delicacy than the drive can easily handle, or are completed around semi-blind corners from the driver’s station. That might be cool.

Yesterday I had to break the bad news to my team: The camera is not going on our bot. Too many problems. The first is where to put it. I wrote a program that I could adapt for our robot to use if I put the camera on top of our arm, and if I have time at our (one and only) regional I will set it up, but basically it aint gonna happen. But the reason I bring this up is that when I informed the dad who was there at the time (we dont have mentors) that the camera isnt going to be used he replied “but the camera is the coolest part!”. And really I realised he is right. A few weeks ago we had to demonstrate our schools “alumni association” (whatever that is) in hopes of getting a huge sum of money from them, and we decided to demonstrate the camera. The problem was that the camera wasnt working. So while I fixed the camera, the build team drove around the practice bot (which we never finished). But the alumni association was less impressed with the working driveable bot than they were with the dysfunctional camera. The best thing we did that whole demo was have a “busted” camera (it was actually the backup battery).

The moral of the rather long and boring story: People think sensors are cool. Their eight year old kid can drive a remote control car, as far as they are concerned robots with sensors and such come from “MIT or one of those places”. And while they may be impressed with our (admitedly programmable) remote control cars which we call robots, they know in the back of their head that “hey, that is cool, but that aint no robot. I seen robots. R2D2 was a robot. That thing there is an overgrown remote control car”. And while they are in some ways wrong on that, overall they have a good point.

Yes, I’m sure! If you want to just “WOW” kids and show them what can be done, take 'em on a field trip…Much more cost effective. If you want to give them the skills to do it themselves, THEN you belong here!

Our team is built on the philosophy that we’re here to give the students an opportunity to learn learn skills and practices in an environment that they can’t get anywhere else. Mentors, Parents, and Teacher work with STUDENTS who design an build the robot. The thing might work great, or fall flat on it’s provervbial face. It’s what is learned in the process, not the end result that is most important!

Student Designed, Student Built, Engineer Approved!

Ok, I’m off my soap box. Back to the Discussion at hand…

Steve[/quote]

emusteve is right. FIRST is a student based competition, and it should be about the students designing, building, and tweaking the robot. I know that are programmers are having trouble just getting the robot to work properly, not even considering autonomous. Most high schools and high schoolers just do not have the time or resources to create a fully autonomous robot. I am all for an autonomous period, and I am in awe when I see a program perfectly executed and perform the task it was given. FIRST should be about a balance between autonomous control and operator control. I don’t think that FIRST should go to a fully autonomous control. I’m sure there are many other competitions that are available for an autonomous robot.

I agree with you Steve. I took on the task of mentoring our programming team this year. Lots of code was written, re-written and scraped. In the end, we have a function that improves joystick control and switch feedback to keep from overextending our arm. Autonomous mode is simple extending our arm ( a three step move) and driving forward.

What is coolest about this is that all of the code was written by the students. :slight_smile: They learned how to use the IFI manuals to select a joystick input or designate a digital input. :slight_smile: :slight_smile:

I for one, have had enough of activities were the parents do and the kids watch. :mad:

I couldn’t agree more. We would rather have the students do the work and fail to get a robot together than have the mentors do all the work and win. We have a policy that no adult touches the robot during competitions except for things like helping to pick it up and move it around. All programming, modifications, and repairs must be done by the students. Of course, mentors are right at their side giving instruction. It works if the kids were involved during the design and build. Last year we made it to the finals in St. Louis and the Semi-finals at the Nationals as a youth-built Rookie Team.

I believe that what Stephen said hits the nail on the head. I don’t believe that FIRST could make the autonomous mode much more complicated without extending the time of the build season, and that is just something that wont happen. Unless a team has the resources to build a second robot, I know of teams who are hardly getting any drive practice, let alone time to write a complex code and still have time to debug and test. The length of the build season cannot be lengthened due to many reasons, mainly the mentors just cant take that much time off of work/families to sacrifice for the team. Another very valid point that someone mentioned is that because this is only a high school competition, the students do not get extensive programming experience. Now, if FIRST was a college competition, I can see it becoming much more involved, however since it is not, I don’t see a big change in the near future coming.

The point is not whether a big change is coming or not, but whether one SHOULD come.

In any case,
I see a lot of posts here seeming to imply that students are not capable of designing (with mentor help), and programming a functional autonomous bot. I flatly disagree. Our robot doesn’t do much during autonomous this year… but that isn’t because we couldn’t get it to work. It was because we couldn’t get it to work in the time we had: autonomous wasn’t given enough of an emphasis.
If FIRST designs a competition that does rely on autonomy a lot more, teams will HAVE to get autonomous working, and will work on it. Autonomous is a bigger challenge… not only for programming but for electrical and mechanical teams as well (All those extra sensors, well-built mechanisms needed for the robot to be able to function without humans watching over).

In general, going to a more autonomous-controlled competition will allow the students to learn more. It should not degrade to mentors doing the work and students watching, it should improve to students learning to get a tougher job done in the guidance of mentors.
And in the interest of not ranting forever, I congratulate FIRST on introducing the camera to autonomous this year. I think it is a step in the right direction. All they need to do is emphasize it more. Make it worth all the time that needs to be spent working on it.