Programmers: I Have A Challenge For You

[sircedric4]

Originally Posted by ideasrule

I don't think anybody here is saying that FIRST should require all matches to be fully autonomous. Some people, like me, think that autonomous mode should be made at least as important to the match as teleop. Right now, you hardly need any autonomous at all; if your robot is mechanically well-built and well-designed, you're going to win the match.

Well Aim High was basically the game you are looking for. I didn't get to Atlanta that year since it was my rookie year as a mentor and I was in way over my head, but a decent autonomous pretty much won the game for you at least at the regional level.

Now maybe at the Nationals the auto mode wasn't such a game winner but I know that the bonus for scoring the most on autonomous was enough to equal the points during the match. I actually liked that game because the autonomous mode wasn't difficult to be worthy of a good chunk of points. I mean we competed well at our regional and all we did was turn on our shooter. It was aimed by hand and good for 3-4 balls which usually won us our matches.

But the thing is, even when autonomous was worth so many points that year, there were still only 2-3 robots that did it at the Houston Regional that year. The balance that FIRST has been trying to figure out since then is how to make auto mode worth enough to pursue, but not enough to leave those without programmers hopelessly behind. They went from auto being useless in Rack and Roll, to their hybrid mode, to last years where you had to at least move or have your team sunk by human players. I think that this year is a good balance.

You have to do some auto unless you want to contest those balls with your opponent in their own home zone, but your robot can also score as well. Now if you want to use that same model and extend the time or put it towards the bonus round then I am all for that. I liked the balance this year in auto consequences, and also that it doesn't leave those that can't score behind too far to catch up.

[MJ Miller]

I'm a mentor for Team 1421 and Computational Scientist who would be happy to help with this project. I look forward to hearing more about it.

MJ

[mwtidd]

Originally Posted by ideasrule

Given the complexity of the undertaking, I think it's better to focus on one project than to have two projects going in different directions. If some people here only know one language, I can help convert C++ code into Java code or vice versa, so that's not a problem.

The initial goals of the project require both a Java version and a C++ version. We are trying to develop a code base for easy programming of Mechanisms(Drives, Arms, Shooters...), Maneuvers, and an Event System. The architecture should be able to be utilized by teams regardless of what language they are using. So don't look at it as two projects, look at it as one architecture in two languages. (i.e. Hello and Bonjor accomplish the same goal, but by being able to say both you increase the number of people you can say hi to)

Originally Posted by gblake

I'm curious who the four folks/teams are, and how you are organizing your assault on this mountain - Can you post a few of the project schedule milestones and high-level software architecture outlines? Those would be good fodder for this thread.

Blake

I am a mentor for team 319, and a senior of CS @ WPI.
History of 319 autonomous successes: pull 10 pt ball into field in 05, shoot 9/10 in 06, knock a ball in 08, shoot 2/3 in 10. The teams have recently signed on to the first forge project so not much has been organized but will be soon (I have a competition in 2 weeks for $1200 which i am trying to get to start the first FRC team in Haiti).

The goals of the project are to first get the basic architecture down so you can implement a cookie cutter program in one day.

Second phase would be to implements a more intelligent system (possibly working off some form of decision tree), which could play a match of Breakaway offensively.

Third phase would be to implement some form of localization and communication (Zigbee module) so robots could communicate with one another.

See above for basic architecture idea, but more complex is described on the firstforge page. The idea is that maneuvers are the same for every robot, and same with basic mechanisms(a drive drives, a arm raises and lowers, a shooter cocks and shoots..) by using maneuvers that can pass, fail and timeout (decided by the mechanisms) you can create a state machine of maneuvers which should work on any mechanism based system. All the programmer has to define is how the mechanism actually executes a given task, and what it believes a pass or fail to be, alternatively you can do it all on timers through the timeouts, and then the mechanism just runs that operation until it receives another.

The importance is in a simple but extendable architecture.

Originally Posted by MJ Miller

I'm a mentor for Team 1421 and Computational Scientist who would be happy to help with this project. I look forward to hearing more about it.

MJ

If you are looking to help that would be awesome! I am so excited by the response from teams looking to work collaboratively, I feel this is one area where FIRST has been held back ... (why for all the secrecy among teams??). As the awards that are given out are not actually monetary, I would like to see teams work together much more. But thats besides the point...

for anyone even considering working on this project please sign up for a first forge account and register under the ADK project, this is where all the tasks will be organized and delegated.

http://firstforge.wpi.edu/sf/projects/bobotics

cheers to all!

[kamocat]

I can't say if my team is up for making a fully autonomous 'bot, but I'm more than happy to help in the planning and coding (LabVIEW) for a system to make an autonomous implementation easy for all teams.
You can reach me at kamocat@gmail.com.

[Brandon_L]

It would completely depend on the game. That, and my team might not be that happy about it. Our driver would step forward to control it and he would have no control. I can see his face now.

If I do it, it wouldn't be used at competitions, just for lolz.

I'm in.

[gblake]

To all of the posters who have said that ... their team won't like ..., I have a suggestion. Get permission to use one of your team's current robots to do some software work, and start learning.

You aren't asking the team to stake their next several seasons on the success or failure of creating a fully autonomous robot. You are instead scheduling some time with the robot to get some useful work done. Work that will be educational, and will contribute to both the team's and the community's body of knowledge. My guess is that the robot can be up on blocks for most of the time.

Once you are initially successful developing a few small and useful improvements (small steps first, big steps once enough small steps can be combined), put a smile on your face let your team know that whether or not you (and team mates) can make the next-season robot work better during the autonomous periods, or assist your drivers during tele-op, is no longer an open question. The code for doing it is already done and is on-the-shelf for next season. That should be a good day.

My point is not that you need to "go rogue"; but that you simply need to confer with the team mentors/leaders and let them know you will want to schedule some off-season time for using the robot (safely) to do some ordinary, simple, code integration and testing. If it is possible for a team to say that is a bad idea, then I'll be dumbfounded.

Sound good?

Blake

[mwtidd]

Originally Posted by gblake

The code for doing it is already done and is on-the-shelf for next season. That should be a good day.

Make sure you post any code made in past seasons or the offseason in a public repository linked to CD or first forge, otherwise it doesn't register as a COTS and is illegal to use according to the first rules.

[ChaosX73]

Originally Posted by davidthefat

Next Year, no matter the game, I challenge you to make your robot fully autonomous. That means autonomous during tele operation period too. Anyone up for that challenge? That would challenge your skills and dedication to the robot. That means no more just drive up 3 feet, kick, repeat type of coding. It would have to be a lot more thought out and will have to use real life robot coding. Its not really a robot if its not autonomous, its just an over glorified RC car if its human controlled. And if you are still sceptical, FIRST pretty much writes the libraries so that even a guy that picks up a programming book can code the robot in a week or even less... Well IMHO you can't learn programming from a book, sure you may learn the language and syntax, but you have to have experience to actually program. Programming comes with experience, and the way FIRST makes it, you get minimum experience as a programmer programming these robots. I will be announcing to my club next year that we want to try this. Just post your opinions and I will add to the list if you want to take the challenge.

Teams That Are Willing To Take The Challenge:

*Team 589 (Just Me As Of Now)
*Team 33
*Team 2503
*Team 1086

You would be a programming god if you could do this. I was the programmer for my team's autonomous, and it took me longer than the allotted six weeks, although that may be because this was my first year of official programming. Although I have thought about this concept before, it almost seems like we'd be making our own AI system, and we all know what happens then...

[davidthefat]

Originally Posted by ChaosX73

You would be a programming god if you could do this. I was the programmer for my team's autonomous, and it took me longer than the allotted six weeks, although that may be because this was my first year of official programming. Although I have thought about this concept before, it almost seems like we'd be making our own AI system, and we all know what happens then...

Honestly it only took us 2 days to get the autonomous right, the day before the competiton when you have to get inspection and stuff and the first day of autonomous... I think you over complicated it

[ideasrule]

Originally Posted by ChaosX73

You would be a programming god if you could do this. I was the programmer for my team's autonomous, and it took me longer than the allotted six weeks, although that may be because this was my first year of official programming. Although I have thought about this concept before, it almost seems like we'd be making our own AI system, and we all know what happens then...

It took us longer than 6 weeks to get it right too. The reason was that we misread the rules and thought the balls were placed randomly on the field. Once we found out that wasn't true--which was after ship date--it took only an hour of coding + testing time during our first regional to get autonomous right.

That said, it was interesting to see the robot drive to the ball based on its own vision, turn, and take a shot. I really wish we could have used it during the competition.

[lemiant]

During the off-season this year or next year, someone should hold an all autonomous event.

<rambling>
I wish first would make a game with way more. but it would sort of wreck their "no robot left behind", since for some reason there isn't enough support for beginner programmers.
</rambling>

But I digress, anyone up to host an all-autonomous off-season?

[kamocat]

I like the "Perceive, Plan, Control" paradigm that was mentioned earlier, and I think it's time that we break the conversation up into those three topics.
Should I take the liberty of starting a thread for each of those?

The "control" discussion is almost solely about the Autonomous Development Kit.
In essence, what is the code structure for controlling mechanisms?
It needs to be able to handle both sequential and simultaneous tasks, with a variety of control parameters for each task. (For example, a ball kick must be able to be triggered by the completion of another action, or an input, or after a time delay, or during a certain time in the match. Similarly, it must be able to be stopped by any of those.)

The "plan" discussion is the most complex of the three, as it deals with analyzing the situation, and there's a range of levels that this can be done on.
Here's a couple of examples (in first-person robot):

• Where should I move next?
• Is now a good time to kick, or will that robot get in the way?
• Should I block or score?
• Is it worth it to go over the bump?
• Will I get penalized if I go into that section of the field?

The "perceive" discussion entails what sensors should be used for what purposes.
I'll list some things an autonomous 'bot might want to know:

• Where am I on the field?
• Where are the robots around me? (what alliance are they?)
• Where are the balls around me? (on the floor, presumably)
• Where are the goals? The bumps? The towers? The walls?
• Have I flipped over?
• What are the other robots doing? Do they need help? (Inter-robot communication)

There are also simpler things, implemented into the "control" section, liked "have I completed my kick" or "is my arm fully extended", usually potentiometers or limit switches, that are used in feedback to make sure the action is completed. Unless someone's doing something exotic like using a non-contact thermometer to tell when a motor is stalled, I don't think these need to be discussed with the rest of the sensors.


As many have said, the scope is huge. I don't plan to do all of those things in "plan" and "perceive", but the first step is to consider the "how" so we can determine what is and is not feasible.

[biojae]

Originally Posted by kamocat

The "perceive" discussion entails what sensors should be used for what purposes.
I'll list some things an autonomous 'bot might want to know:

• Where am I on the field?
• Where are the robots around me? (what alliance are they?)
• Where are the balls around me? (on the floor, presumably)
• Where are the goals? The bumps? The towers? The walls?
• Have I flipped over?
• What are the other robots doing? Do they need help? (Inter-robot communication)

There are also simpler things, implemented into the "control" section, liked "have I completed my kick" or "is my arm fully extended", usually potentiometers or limit switches, that are used in feedback to make sure the action is completed. Unless someone's doing something exotic like using a non-contact thermometer to tell when a motor is stalled, I don't think these need to be discussed with the rest of the sensors.

This is where the GDC may play nice again, and bring back something like the 2 freq. IR beacons.
But, even if they don't there are simple ways for determining where you are on a field using encoders (Assuming the wheels don't slip. Hard for last year).

Using kinematic formulas:

S = (Delta Left + Delta Right) / 2
Delta Theta = (Delta left - Delta right) / wheelbase
Theta = Theta + Delta Theta
X = X + (S * cosine ( Theta ) )
Y = Y + (S * sine    ( Theta ) )

This satisfies one item on the list, but only slightly.

As far as knowing where other robots are, that would need a lot of DSP, or an external observer telling the bots where they are, or all bots to communicate with each other

[gblake]

Originally Posted by lemiant

During the off-season this year or next year, someone should hold an all autonomous event.

<rambling>
I wish first would make a game with way more. but it would sort of wreck their "no robot left behind", since for some reason there isn't enough support for beginner programmers.
</rambling>

But I digress, anyone up to host an all-autonomous off-season?

Great idea!

Let's carry it out in a way that will let us try walking before we try to run.

I'll assert that it would be easy to produce a fully autonomous competition using Vex or Tetrix equipment and fields; and that it would be reasonably easy to replicate that competition set-up in many geographically diverse locations around North America and the rest of the planet.

Before any instinctive reaction takes hold and you reject this suggestion as being too unlike FRC, think for a minute.

The reduced diversity found in the the Vex/Terix equipment suites, the greater simplicity of the Vex/Terix computers, and all of the other factors that make a fully autonomous Vex or Tetrix match unlike an autonomous FRC match are all good things for people who want to take on David's challenge.

Working with, and succeeding with the simpler, Vex or Tetrix equipment will lay a solid foundation on which to base the FRC attempts. There will still be plenty of work to do when the project members graduate into FRC attempts; but many of the "Doh!" realizations and many of the collaboration-process SNAFUs will have been shaken out of the software and out of the project teams processes.

Think it over. Walk before running.

Blake
PS: This would not replace my earlier suggestion to use a simulator or appropriate video game as a learning tool. A Vex/Tetrix competition would complement also using a simulator.

[the programmer]

through my 3 years in FLL, I realize that performing routines like getting a ball, aiming, and shooting is something that's very realistic, so my suggestion, treat teleop like 08's hybrid mode and give the drivers different routines that they could run and just a normal teleop