Programmers: I Have A Challenge For You

[davidthefat]

Originally Posted by Radical Pi

I'd tell you that front is whichever way the camera is pointing.

I was referring to when you go forward on teh joystick, which side goes forward.

[efoote868]

Originally Posted by davidthefat

I was referring to when you go forward on teh joystick, which side goes forward.

Me too.

[davidthefat]

Originally Posted by efoote868

Me too.

So you are saying it goes forward relative to the driver's POV? Oh I see...

[davidthefat]

Ah $@#$@#$@#$@#... Robotics is too addicting, I have halted my game that I have to turn in the end of the year for my AP Comp Sci class... Better not slack off on that

[Alex.Norton]

The biggest problem that I can see here (assuming all of the sensor, code, etc...) works perfectly is the development of an Artificial Intelligence. How does the machine decide when it is prudent to go for a game piece, heck how do you choose to go left/right at any given moment.

The AIs that I have worked with in the past used hundreds of runs to get good predictive and training data. How do you get your machine this type of data against a good opponent? Getting a machine that can run around an empty field is one problem. Getting a machine that can play against even another AI is extremely difficult. As an example I'm currently working on a biomimetic vision system that will runs of data sets well in excess of 10,000 images and despite this it can still only tell the difference between a zebra and a car 80% of the time.

The next major hurdle that I can on the horizon is processing power. From this discussion it would seems that most people want to bet on the camera for most of their more complex sensing needs. Doing this will involve object recognition (ball, other bots) integrated with position control to accurately place the robot on the field. Doing real time image processing (I haven't seen the NI libraries for this so I don't know what functions they do have) that must process and recognize objects takes a amazing amount of processing power. Power that I'm sure the cRio doesn't have, especially considering how much I've heard about the camera slowing the robot down too much.

If somebody has a proposal for how to solve the processing problem I would be happy to work on a project like this. Sadly I don't have access to a robot so I would need to work more from the strategy end. If somebody feels like organizing this PM me.

[mwtidd]

Collaborative Development.

To everyone looking to work with me on the ADK, i have created a FirstForge project (Bobotics ADK)

The framework is very basic, but very extendable.

In there there is the ADK,
and then a sample Robot (Bob) which is built utilizing the ADK library.

My hope is that it is simple enough to pick up quickly, the goals of the project are two fold: Bring autonomous to every team, and successfully implement a basic fully autonomous proof of concept.

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


*oh and its written in Java as I feel it is the easiest to learn.

[gvarndell]

Originally Posted by Alex.Norton

If somebody has a proposal for how to solve the processing problem ...

Stack the deck and reduce the horsepower required.

For example, for tracking other robots, require that every participating robot computes, and broadcasts, 5 or 10 times per second, its location on the field and its acceleration vector.
This could be a tiny little network packet tagged with robot ID.

Is this less sexy to contemplate than full realtime vision on each robot?
Sure it is.
Is it almost infinitely more doable than full realtime vision on each robot?
Duh.

Constraining the problem domain is the only way this is going to fly.
Even so, the enormity of this undertaking only seems apparent to some.
Perhaps that's a good thing...

[alexhenning]

I tried one in 09, but unfortunately I the robot wasn't ready until ship day and it had too many quirks (mostly relating to the camera). We ended up never using it. I'll try again next year if I have enough time with the robot. To help with this it would be nice if FIRST revealed the scores on the board + time left, so that your strategy could change when you were winning and losing.

[theprgramerdude]

Originally Posted by Alex.Norton

The biggest problem that I can see here (assuming all of the sensor, code, etc...) works perfectly is the development of an Artificial Intelligence. How does the machine decide when it is prudent to go for a game piece, heck how do you choose to go left/right at any given moment.

The AIs that I have worked with in the past used hundreds of runs to get good predictive and training data. How do you get your machine this type of data against a good opponent? Getting a machine that can run around an empty field is one problem. Getting a machine that can play against even another AI is extremely difficult. As an example I'm currently working on a biomimetic vision system that will runs of data sets well in excess of 10,000 images and despite this it can still only tell the difference between a zebra and a car 80% of the time.

The next major hurdle that I can on the horizon is processing power. From this discussion it would seems that most people want to bet on the camera for most of their more complex sensing needs. Doing this will involve object recognition (ball, other bots) integrated with position control to accurately place the robot on the field. Doing real time image processing (I haven't seen the NI libraries for this so I don't know what functions they do have) that must process and recognize objects takes a amazing amount of processing power. Power that I'm sure the cRio doesn't have, especially considering how much I've heard about the camera slowing the robot down too much.

If somebody has a proposal for how to solve the processing problem I would be happy to work on a project like this. Sadly I don't have access to a robot so I would need to work more from the strategy end. If somebody feels like organizing this PM me.

In terms of processing power, I was already thinking about how to overcome the (ironic) limits of the Crio. Back in '07, a team was planning on attacing a full computer to their robot to do calculations. I was thinking like-wise for this project.

My current idea is as follows. It would involve a DC-DC converter connected to the PD board, which could then plug straight into the ATX connector on a motherboard. Example:http://www.mini-box.com/M4-ATX?sc=8&category=981
A proccesor would then handle several inputs from various sensors that the Crio can't handle. A CUDA-based GPGPU would be able to handle most calculations from the cameras such as pattern recognition and positioning.

What do you think?

Back to the 10,000 Lakes Regional as my team needs the current Auton code done.

Edit: and IMHO, I believe Java would be a horrible language to create a fully autonomous robot, as it's slowness and inefficiences would handicap even the best system. It's why I chose to use C++ this year again.

[45Auto]

As long as your definition of a "fully autonoumous" robot consists of something on the order of simply finding a game piece and kicking it in the direction of a goal you at least have a chance to be succesful. Many of this year's and previous year's robots already do that in autonomous, no big deal to run it for an additional 2 minutes.

However, don't expect your robot to do very well in competition. A game designed for competely autonoumous robots like FIRST TECH CHALLENGE or FIRST LEGO LEAGUE is much simpler than the games FIRST designs for their top level of competition.

Remember that you are part of an alliance. Your inability to co-operate with your teammates to maximize each robot's potential would be the equivelent of a football player running whatever play he feels like without co-operating with the rest of the team. Don't expect it to work very well.

Using this year's game for an example, how do you in intend to determine whether your robot should be going after a ball or blocking an opposing robot? How do you decide when to come over the bump into the front zone and assist in scoring? How do you decide when to come over the bump into the front zone and block the opposing alliance's blocker bot so your striker can score? How do you know if your alliance partner has moved to the middle and you need to move to the far zone to clear balls from it? If you do decide to block an opposing robot, how do you know it's not dead and you're wasting your time on it? How do you know that your alliance's striker bot is broken down and you need to move forward and score? How do you know both your alliance mates are on their back and you need to flip one back upright to have a chance to get past their blocker bot and score (this happened to us in the semi-finals, we won the game 2-1: http://www.thebluealliance.net/tbatv...2010la_sf2m2)?

These are just some of the decisions I've made as field coach on our team this year. They're all pretty straight forward and simple, but impossible to make without an overview of the game situation. I'd be interested to hear how you intend to implement any kind of awareness of the tactical situation into your robot. You can pre-program a game plan into it, but without an overall awareness of the game, you'll discover the truth of an old saying that's proven itself through the years: "No plan survives contact with the enemy".

I think it's great to inspire people to work towards fully autonomous robots, just don't lose sight of reality. Many of your teammates will probably want to do at least reasonably well at their competions. In the real world, your robot will be a liability to it's alliance.

[ideasrule]

I vote for C++ too. Not only is Java slow, the WPILibJ has no libraries for file access or for more than basic vision processing. Java also doesn't allow low-level access to memory.

[efoote868]

Originally Posted by ideasrule

I vote for C++ too. Not only is Java slow, the WPILibJ has no libraries for file access or for more than basic vision processing. Java also doesn't allow low-level access to memory.

You know that embedded Java programming is little more than accessing low level, native functions through a JNI?
Also, the fact that it doesn't allow low-level access to memory is a feature in most cases, making it harder to screw up.

More important than picking a language is figuring out the algorithms themselves, which may be as simple as "drive here, do action x, turn"... etc, with the smaller pieces left to teams to implement.
But then again, you don't know what the game will be, so its incredibly difficult to make meaningful decisions on strategies.

Best of luck anyhow. I feel like I've been a negative nancy for too long with this, I'll only post in this thread from now on if I can offer help

[Alan Anderson]

Originally Posted by theprgramerdude

Should we start a sign-up list for those that want to do this over our 8-month break?

What break are you referring to?

[mwtidd]

Originally Posted by Alan Anderson

What break are you referring to?

Earlier in the thread there was discussion about working on the project in collaboration rather than individually.

Right now I am starting up a Java team to build an ADK(autonomous dev. kit).

It would be nice if the C++ team could get a lead too, this way we could combine our efforts to provide an ADK in both c++ and java.

The java project is on first forge : http://firstforge.wpi.edu/sf/projects/bobotics

[ideasrule]

Originally Posted by efoote868

You know that embedded Java programming is little more than accessing low level, native functions through a JNI?

Yes, I found that out after spending enormous amounts of time trying to use the native vision libraries with Java. The result was definitely not pretty (the vision code was many times longer than it would have been with C++), and got even uglier when I had to create my own C file to read from a cRIO file.

A program written in C can easily be run on a cRIO imaged for Java, but as far as I know a Java program cannot be run on a cRIO imaged for C.