FRC...autonomous or driver-controlled competition?

[tribotec_ca88]

I got this topic idea from this thread: ("Capping Vision Tetras")
http://www.chiefdelphi.com/forums/sh...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?

[Rombus]

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! ).

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!

[Billfred]

Originally Posted by tribotec_ca88

Well... what is FIRST's objective, exactly? To turn FRC into a battle-bot game or an "AI" sort of contest?

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.

[russell]

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.

[Adam Y.]

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.

[russell]

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.

[mwtidd]

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.

[emusteve]

Originally Posted by tribotec_ca88

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?

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

[JudyVandy]

[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!)

[Stephen Kowski]

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.....

[KVermilion]

I think this would be a good idea, but working with a 5 week build season (stupid finals! ) 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.

[probizzle]

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.

[jimfortytwo]

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.

[russell]

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.

[emusteve]

[quote=JudyVandy]

Originally Posted by 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!)

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