Programmers: I Have A Challenge For You

[gvarndell]

Originally Posted by the man

I think that would take away some of what first is.

Sorry. You think what "would take away some of what first is"?
What is FIRST to you?

[TJ Cawley]

I wish we could attempt this next year, but some teams that have the techology and money to try such a project, my cheers will be right behind you. no matter the outcome. but a safety switch would be good in case the programing went down and you had to manuever it yourself. here are my $0.02 and i wish teams that will try, the best of luck to you all.

[davidthefat]

Originally Posted by gvarndell

Not in response to any particular post, I love that this is being discussed.

I really hope FIRST will find a way to design next year's game such that clever software will stand a chance to share the limelight with clever mechanical systems.

I know some teams (1629 included) used software to _assist_ with goal scoring.
That is, the robot (under operator control) never decided to go for a goal.
Instead, the robot took a command to kick the ball and attempted to do a little fine-tuning on the aim -- using the camera; but this is a baby step.

Think about implementing "situational awareness" in software:
What does my universe (the field) look like?
How big is it and where are the fixed objects?
Where am I within my universe and which way am I facing?
Where are my friends and where are my foes?

These are robot smarts that should prove valuable to you next year, no matter what the game is.

I personally want to stay away from the camera. if you havent noticed, it had a big lag, IDK if that was just the data getting sent over, but I want to use IR sensors and Sonars instead

[gvarndell]

Originally Posted by davidthefat

I want to use IR sensors and Sonars instead

Good thinking -- I wasn't implying that camera vision was the best or only way to support situational awareness in a robot.

[randalcr]

That is a big challenge, and it's one that I'd be willing to accept! Lol, this will be fun.

[Chris Hibner]

Originally Posted by JamesBrown

Learn LabView, it is far from being a joke and is extremely popular in the field of automation. LabView is absolutely programming, it is easily one of the most powerful programming tools available. I have been programming robots for quite a while, in every thing from MIPS to LISP. LabView is as much of a programming language as any of those, every design pattern you can implement in C/C++ (or your choice of other OO languages) can be implemented in LabView. The students out there who bash LabView most likely have not taken the time to learn it and master it. Sure it is cool to hard code every thing, I remember bashing EasyC when I was in High School because it wasn't real programming. However, I guarantee that when you get a real job writing software your boss isn't going to care that you can write code in a more noble language than the one I choose, if my code is as functional as yours, and I can write it faster I will get the raise, the contract, or the job 100% of the time.

I'm going to second the godfather of soul.

Text based programming languages are starting to get to the point where assembly was 15-20 years ago (and punch cards before that). Everything is moving more in the direction of even higher level languages (i.e. graphics based).

In the field of embedded controls, everything is being shifted from hand-coded C to auto-coded model-based programming. In my current job and my last job we use Simulink and Stateflow to do all of our control design. When I left my previous job 4 years ago, we were already auto-coding the entire sensing and control algorithms from the Simulink/Stateflow models. At my current job, a good number of the control algorithms are already auto-coded from the Simulink/Stateflow models and the goal is for all of them to be auto-coded in the future.

Even for PC programming we're starting to see more graphical programming tools where you draw your windows and drag and drop menus and interface controls, then simply define the behavior of the interfaces and menus.

I don't know if we'll ever completely move away from text-based code (and in some cases, I think text based code is the most efficient method), but it would surprise me if software development was primarily text based 10 years from now.

For the on-topic part: there have been robots in the past that have played significant portions of the match autonomously. I once proposed a system to reward the teams with bonus points based upon how much of the match they played autonomously. I'll have to dig up that old thread and post it.

[EricVanWyk]

Originally Posted by Chris Hibner

For the on-topic part: there have been robots in the past that have played significant portions of the match autonomously. I once proposed a system to reward the teams with bonus points based upon how much of the match they played autonomously. I'll have to dig up that old thread and post it.

EXACTLY.

Autonomous has been pretty boring for two years because there is no point value to it. Give it value, and it will become interesting.

[Egg 3141592654]

I would like this to happen, but here are my 2 issues with this idea. Firstly, how do you track game objects and the areas to score? The program would need to have a serious if statement, or a periodic task to override the game piece searching code from the scoring area track code. We tried something like this recently with epic failure, aka we made a $5,000 doughnut preforming machine. Secondly, the robot would have to be as cunning as a human player to avoid silly penalties, like getting hit while kicking a ball making it go out of bounds.

Those are my little considerations in making our robot completely autonomous next year. I guess it also depends on what the game is next year as well because something like this puts drivers like me out of work. Good luck to those teams attempting this, I'm starting now so this way I'll only be 4 weeks late instead of the usual 5.

[gvarndell]

Originally Posted by Egg 3141592654

something like this puts drivers like me out of work

Relax, you'll still have a job.
I know the topic is fully autonomous robots but no FRC team is going to accomplish that in the near future -- unless the games become mind-numbingly simple.
Does cruise control make a driver unnecessary?

[slavik262]

To echo and summarize a lot of really smart people, there's a lot of problems with a fully autonomous robot. I'm listing them in order of importance (in my eyes) from greatest to least.

1. Time/People - As people have said, it took teams of grad students working around the clock to accomplish a simpler challenge (DARPA) than what you're aiming to achieve. Even if you start working now, you'll still need to tailor the AI to the game next year. You can't do that much in six weeks without a time machine. You're highly underestimating the complexity of everything the robot has to do.
2. Hardware - Autonomous robots have extremely beefy processors, usually custom-designed for the task. You have a 400 MHz PowerPC processor, which is not just controlling your robot's movement, but is also busy doing other things like communicating with the field. Consider how much power you would need to run autonomously. Think of what you would have to do:
   • Gather inputs from a large amount of sensors.
   • Formulate a "world view" of what is going on. Where is your robot? Where are the other robots? Where are the game pieces? What is your current strategy? What step in the plan for that current strategy are you in? How much time is left in the match? There's a lot of questions. You'll need to use complex algorithms to analyze your data (including slow image analysis if you're using the data) and even more complex algorithms to take that analysis and turn it into some useful strategy.
   • Act on that strategy. Use even more complex algorithms to determine if your strategy is working. Decide when to switch strategies or dynamically adapt to the strategies being employed against you by the other alliance.
   There's just not enough processor to do it all in real-time.
3. Your drivers will want to drive the robot. Arguments about "what FIRST is" aside, telling your drive team that your code can perform as well as they can is an insult to any human being. It may be a great off-season project, but don't you want to achieve your best during competitions? I'm not claiming that it's "all about winning" - but the competition makes it fun for a lot of people, and I can promise you that because of all the above reasons, an autonomous program developed by a few high school students with a year (maximum) of development time, running on FRC hardware, and within the context of an FRC game will not perform nearly as well as even the worst driver. You're removing almost any chance your team will do well if you run fully autonomous, provided the other alliance's robots so much as move. Is the rest of your team willing to accept this just so they can say that their robot is autonomous?

I'm sorry for raining on your parade, but it can't be done - at least not well. Ambition is a wonderful thing - never give up your dreams. But technological marvels aren't created with just a can-do attitude. It takes years of research, hard work, development, and custom hardware to finish the job. The people who think this is possible need to stop and be a bit more realistic.

Try something on a much smaller scale. An automated scoring algorithm would be great, and is a totally reachable goal. Work your way up, and see what you can do. There's a huge difference between playing a match "mostly autonomously" and fully autonomously in that the "mostly autonomous" option allows human drivers to position the robot, aware of the field and match conditions, before letting it go to work.

[Kims Robot]

I'll start this by saying its been a while since I have done any "real" programming. However, I did my masters degree in Robotic Intelligence and have loads of background knowledge here, in biorobotics, communications, etc.

I am excited that teams are considering this. FIRST should be about innovation.

Originally Posted by efoote868

I say this because having a fully autonomous robot may be *impossible* in 6 weeks, unless of course your team can come up with a 469 strategy

Originally Posted by Chris Hibner

For the on-topic part: there have been robots in the past that have played significant portions of the match autonomously. I once proposed a system to reward the teams with bonus points based upon how much of the match they played autonomously. I'll have to dig up that old thread and post it.

Its definitely NOT impossible. Im 99% positive that team 176 did it one of the years (somewhere around 2001??). They didn't use it in every match, and as far as I know they only ran it in practice matches, but boy was it fun to watch their drivers press a button and walk away and see that robot do "its thing". Could it account for every variable? heck no. Was it impressive for the amount it did? YES!!

I've played around with everything from controlling an FRC robot with my bicep muscle to writing up simulation code for a modular robot. Its all about how complex you make the problem. If you start from the highest level and have a robot that can incorporate a lot of sensors, not only for knowing about it's mechanisms, but for "seeing" the world around it, you open up entirely new doors. We have seen plenty of teams be able to do this in tiny pieces - balancing the ramp, scoring tubes, keeping the arm inside the box, running cool auto modes with avoidance detection. A fully automated match is really just as step beyond all of those. Heck there are some FLL teams that can do this, why cant the FRC teams?!?!

It does require big picture and strategic thinking to consider what you might "run into". Do you need to avoid other robots? what do you need to interact with? what are the possible decisions to be made? But teams already do a lot of this type of thing for the 15 second auto modes. No not every team does, but some of the teams do!

Would I suggest using it in Finals? heck no. As already stated, in this competition we aren't going to be able to process like the human brain. But could it be a fun and awesome challenge for a programmer to try for an offseason or even to "show off" in a practice match?? Of course!! And hey if its "really good" you might even get your drivers to run it in one of those "easy" matches.

Stop being afraid of trying things you might "fail" at. Just because something seems impossible, doesn't mean you shouldn't try it. As long as your entire strategy isn't based around it, I would say go for it. Have one set of programmers implement the "normal functions", and have the other go for the full automation.

[EricH]

What I would suggest, as you go for it:

Start by writing automation for certain functions. For example, when you have a ball, target and shoot. When you don't have a ball, look for one.

It'll be a lot easier to get blocks of automation that can be used by the drivers and then combine them into one completely automated program than it will be to write the whole program from scratch. (It'll also allow the drivers to take control if they need to.)

slavic262, it's almost a simpler challenge. DARPA had to travel a certain distance, with a full-size vehicle, via previously unknown waypoints. On an FRC field, we know EXACTLY where the boundaries and other things are, other than gamepieces and other robots. It can't be done, you say. People said the same thing about: manned flight, steamboats, space flight, connecting computers... If it couldn't be done simply because some people thought it couldn't be done, we'd still be in the Middle Ages or earlier. Also note that some folks do stuff where the designers would say, "That plane can't do that!"--but they're still doing it. The plane wears out faster, but it can be done.

Also note that nothing in the rules prevents you from building a custom circuit to assist the cRIO with its processing. If you wanted to do that, you could get more done...

[gvarndell]

Originally Posted by Chris Hibner

Even for PC programming we're starting to see more graphical programming tools where you draw your windows and drag and drop menus and interface controls, then simply define the behavior of the interfaces and menus.

I don't know if we'll ever completely move away from text-based code (and in some cases, I think text based code is the most efficient method), but it would surprise me if software development was primarily text based 10 years from now.

Underlying those little widget-y, icon-y things with various kinds of lines crisscrossing between them is text based code (or perhaps more accurately, the compiled binary representation of text based code).

Yes, the ubiquity of text based programming is loosing ground to 'software through icon connection', but we should not fool ourselves into thinking it's going away.
Its replacement hasn't arrived yet.

[Alan Anderson]

Originally Posted by gvarndell

Underlying those little widget-y, icon-y things with various kinds of lines crisscrossing between them is text based code (or perhaps more accurately, the compiled binary representation of text based code).

This turns out not always to be the case. A typical LabVIEW vi doesn't have a text equivalent.

[gvarndell]

Originally Posted by Alan Anderson

This turns out not always to be the case. A typical LabVIEW vi doesn't have a text equivalent.

What would be an example of a typical VI?
And how does the executable object code for it come to exist?