The most recent Communications of the ACM has an interesting opinion article entitled “Preparing Computer Science Students for the Robotics Revolution” that mentions FIRST:
High school robotics contests such as US FIRST … emphasize the mechanical engineering aspects of the field at the expense of computer science … The public doesn’t always appreciate that the elaborate hardware platforms students construct must be primarily teleoperated because students aren’t being taught the kind of software that would allow their robots to act autonomously.
This is a bit unfair. It’s definitely true of FRC, but FLL is a different story.
The article goes on to talk about what’s missing:
Real robotics involves deep, computationally demanding algorithms. Machine vision, probabilistic localization and navigation, kinematics calculations, grasp and path planning, multi-robot coordination, and human-robot interaction (face tracking, speech and gesture recognition) are core technologies. Today these are found mainly in advanced research labs and graduate-level robotics courses, but they can be made accessible to undergraduates. The time to do that is now.
How can we as mentors, teams, and the FIRST community as a whole better encourage our high school students to explore these areas? I’m seeing progress on this just in the last couple of years in FRC: much more powerful robot processor, provided vision code, games more friendly to vision (2010 much more than 2009, although even in 2010 we didn’t see very much vision-based autonomous), even discussions on CD regarding fully autonomous robots. MatLab Simulink availability could help with the physical/kinematics modeling. Tweaks in future game designs could also help encourage student programmer involvement, excitement, and innovation in autonomy (e.g. higher autonomous bonuses? longer autonomous periods? aspects of the game which are hard to fully teleoperate?). What other things would help stimulate and maintain interest in the CS portion of robotics within FIRST beyond FLL?
Thanks again, Blake, for the wonderful simulator. I read the thread in your link, and I’m impressed at the direction things are heading.
For the topic of this thread: To get students more into the “brains of the robot” side of the project, we need to get more teams involved in various forms of automatic control other than simple timed motor commands. Whether the automatic control is in autonomous mode or during teleoperated mode to relieve the drivers of some tedious tasks, it’s still useful and a good learning opportunity. The problem is that: a) feedback control takes some time to learn and understand, b) experimenting with feedback control on a live robot takes a long time and can be dangerous (and make for some costly repairs), and c) the robot is almost never ready in time to allow interested team members to experiment and learn.
It’s my opinion that in order to get teams more involved in using control strategies, a good simulation platform is needed. This would allow the teams to come up with control strategies, implement the algorithms, and test them in the virtual world - all in parallel to the mechanical team designing and building the real robot. This would provide a safe learning environment for the controls people and it would give the rest of the team some confidence that the control strategies will work once the robot is finished.
I think we’re getting much closer to having simulation capability in FIRST. Thanks again to Blake for everything that’s come so far.
It all has to do with game design, in my opinion. Games have historically rewarded mechanical excellence over software accomplishments (how many field-centric holonomic drives have been on Einstein?). This is partially for pragmatic reasons: fully autonomous robots are really, really hard to get working well (like, DARPA and NASA hard). How many 15 second autonomous periods end up with more than half the field not moving, or driving in circles? FIRST is about inspiring - building cool mechanical systems is the low hanging fruit of inspiration for high school students.
That said, “if you build it, they will come”. If autonomous mode was consistently absolutely critical to the game (2003 and 2006 come to mind), the smart teams would realize that they need to spend more time on their software.
But like I said, full autonomy is hard. Now, “supervised autonomy” (think 2008) - there might be some potential there. I am a big fan of game tasks that a human operator simply cannot do all that well as a mechanism for increasing the prevalence of computer science in FIRST.
What if there was an opaque wall in the middle of the field, and your goal was behind it?
What if there was some sort of door that had to be opened? Fine motor skills are hard to orchestrate from ~27 feet away.
What if the game pieces were tens to hundreds of tennis balls - some colored blue, some colored red. Red wants the red balls in goal 1 and the blue in goal 2. Blue wants the blue balls in goal 1 and the red in goal 2. The balls are all mixed together when you pick them up. A semi-autonomous ball sorting technique would sure be useful, huh?
A simulation environment would be extremely helpful.
However, a bigger issue that I see is the lack of good Control Team mentors. I just finished my 6th season working with my 5th team, non of these teams had experienced or established mentors for the control teams.
Consistantly, I see mechanical engineers, industrial designers, and machinists working hand in hand with students of various abilities. This is great, and this is why every year we see less and less teams with robots that don’t function.
However these teams always seem to hand off to the Control team which consists of one or two students, no mentors. Admitedly it is difficult to find engineers with a background in embedded control and/or Automation. However it is unfair to expect these students to be able to create a product as good as what the mechanical team can produce without giving them the same level of mentor support that the mechanical team receives.
It is not uncommon to go to a regional and see one Control mentor supporting many teams (any one who has seen Mark McLeod at a regional understands what I mean). Mechanical mentors are often called on to help other teams, however there always seems to be enough of them to go around.
Many of my software engineer coworkers that I have introduced to FIRST have been hesitant to get involved precisely because they don’t feel there’s a significant control/software aspect to it (and hence feel limited in the contribution they could make).
I believe that the programming aspect can be plenty difficult as it is right now. My team has always struggled to get autonomous working properly, and interesting drive/control schemes such as mecanum drive make life more interesting for us programmers.
Part of the challenge is for the programmers to find something to do. This year, they could track the goals and pop up a green light on the dashboard when the driver was in an optimal shooting position/range. Once we teach our programmers to look for improvements such as these, they will find more work for themselves.
Unfortunately, the biggest block I see to our programmers these days are the limited autonomous periods. This year was horrendous- 15 seconds with absolutely no bonus reward for having a good autonomous? My team still went for it, but didn’t expend too much effort on improving our autonomous code because it just wasn’t worth it. FIRST needs to provide coders with a better stage for showcasing their talents. Longer autonomous (maybe 30 seconds) with a bonus.
I don’t think we can understate how difficult autonomous programming is, especially in a highly interactive game like first.
Back in school, I took a grad course in autonomous robotics, along with 29 other students. We essentially spent the entire semester broken up into teams of 3 build and programming small autonomous robots out of Lego’s and Handy boards, with one straight forward task - drive around an arena, pick up plastic Easter eggs, and return them to your “nest” (identified by a polarized light source). We competed 2v2, and there were probably 100 eggs in the arena.
It was rare to have more than 10 points in a match. In fact, it was rare to have more than two robots actually working correctly out of the 4 on the field. And this was from grad students with much more experience and much more time (a full semester, at least 3 hours spent on it per day, almost every day).
Now, all that said, it’s certainly possible for a team to build up the knowledge and experience they need to build successful, complex autonomous modes. It would require extensive knowledge and experience with PID loops and different forms of feedback. Spending time in the off season working with these, and over several years you could develop the capabilities to make an impressive autonomous mode.
But then what about the rookie teams? How do we make something so complex still accessible to them? How do we give them the time and resources needed to run their code on prototype/test robots in order to work out the bugs?
Our team has only been around for 4 years. I can still remember our first year, and the sheer joy we had the first time the robot actually moved. We tried to do an autonomous mode that year, but we didn’t have the experience, as a team, to be able to do it.
I was about to make this point exactly. While there are many users here on CD (and out there on FIRST teams across the globe) who are certainly capable of creating some good autonomous code, many teams simply cannot. This includes a fair number of veteran team.
This unfortunately is what I believe to be the reason that this years autonomous mode provided no real reward for good autonomous programming. As always, the GDC is stuck in an endless debate over balancing difficulty for those with the skill to create advanced autonomous robots and keeping the game accessible to those without that skill.
I really don’t know how to fix the problem. I agree with most of the posts here that one of the first steps is to get more dedicated computer science mentors involved. I also believe that the GDC needs to significantly redesign the game process to better accommodate advanced autonomous modes.
Get your CE co-workers involved in teaching the kids…even using the ‘canned’ solutions, they should see the value of their contribution in empowering the kids.
Ask them to try the autonomous coding, THEN ask them if there is no significant control aspect!!!
You are quite welcome - It has been and continues to be fun. Also it has been very much a team effort, even on Day 1 of the project there were two of us involved (one of the two Davids). Now there are several more folks contributing.
And - Just in case anyone is wondering, I/we agree. We have an OK simulation that makes a fairly fun computer game, and is a useful but imperfect tool for teams; but among other things we really, really need to beef up the accuracy/realism of the physics and of the robot designs. To that end, I’m going to ask for either a magic wand or ten pounds of No-Doze for Christmas
That said, the current code still makes a good place to wrap your head around both the simple and hard parts of autonmously playing a FIRST game. Back in 2008, when I “taught” the Java client (see this post Java Client ) to play simulated Overdrive fairly well (using brute force heuristics), I learned a ton about both Overdrive strategy and autonomous complexities. With that in mind, those of you who want to experiment in a safe learning/teaching environment should be peppering me with weekly emails and PMs telling me to hurry up and release a version you can insert your own code into.
Of course, by definition simulators are not the real thing; but simulators are useful; and one that can mostly satisfy many of the wishes expressed in this thread so far is available. Don’t get left behind when all the other teams start using it.
In addition to creating games that encourage more autonomy, I see two other ways that software development could be encouraged. The first would be to lower the price of a second control system. This would allow teams to create a programming testbed and develop game specific algorithms (such as target tracking) concurrently during the build season with mechanical design.
Even after the software has been developed it still needs to be transfered and adapted to the actual robot. This process, however can’t happen until the robot is mechanically and electrically complete. Unfortunately, because of the short build period this leaves very little time for programming. To fix this aggravating problem there could be a programming period after the main build period where only software, and perhaps minor electrical, changes could be made. This year our team was fortunate enough to have a second electrical system on which we developed target tracking software early in the build season, unfortunately, because the mechanical team kept improving the robot we never had the opportunity to transfer it to our competition robot. A separate programming period would mean much more time spent programming and thus the creation of robots with more sophisticated autonomous capabilities.
With respect to the question of what can we do to bring some of that graduate level research to FIRST, here are my thoughts.
As much as I’d love to see a game where auton can either “make you or break you”, I don’t think it’s practical. With the huge amount of teams (even veteran ones) who are afraid of writing code or just don’t have the “know-how” it could prove to be very discouraging.
But for teams like mine that have a lot of programming experience, games where auton isn’t important aren’t very satisfying.
What do we do?
How about create an award – one that will get you to Nationals (or a lot of pts if you’re in Michigan) – where you have to demonstrate that your auton works and gets the job done. This would be seen on the field. You’d also have to present your code for a code review and explain any development practices (agile, etc)/tools (git/svn, etc) you used.
I think that would encourage teams to not only write clever code, but also write it in a professional manner.
Along the same lines, how about something similar to what VEX has added to their competitions: an autonomous challenge run in parallel with the normal competition? Basically the idea is to run fully autonomous for 1-2 minutes, no other robots on the field, possibly with modified game rules and/or starting conditions. The winner of the challenge is the robot which scores the most points. The winner also gets a ticket to the championships. In VEX a team may have unlimited attempts to maximize their score, but I think that’s excessive (allows luck to dominate)… maybe 5 attempts? How challenging this is would depend on the game design, of course.
