Programmers: I Have A Challenge For You

[davidthefat]

Originally Posted by Formerly Famous

See, I went to a LABView thing before the season started. I had to leave early. But I was able to pick up enough to read the language. And I am currently programming in my aerospace class. But even that is following a book. I have learned that it is easier to read than write. (I have been able to read JAVA for some time now. Writing is a whole nother story though...)

I tried doing a little bit of programming... Didn't work out to well... It would take all summer for me to program a tele-op mode.... That's with a mentor.

LABView is a JOKE IMHO, its like RPG Maker or Game Maker for robots... Its not programming. but IDK may be my mind just works that way and I caught onto C++ when I was 12... LOL

[Jetweb]

This is something I have been toying with for the last few years and in certain games it would defiantly be possible to do in 6 weeks. last year we were able to track a trailer in full motion, track orbit balls, and using a current sensor on our intake roller we could count how many balls were in our basket. and if i was allowed to put 4 sonar sensors on we would have attempted a full auto match at an off season (the drive team would never go for this in a real match)

Things to note:
- we were only able to get code to this level because we had a complete practice bot by week 3 and worked on it right up to our regional (and through our 2 competitions), which i think would be critical in trying to program something as complicated as a fully autonomous robot

- 79 made an awesome obstacle avoidance program using (i believe) 3 sonars at bumper level, which shows that real time obstacle avoidance is very possible without complicated LIDAR or anything like that.

- it is also very helpful to have a good mentor as previously noted.

Even if it doesn't work i have fun trying to figure out how to do it every year and if other people were trying as well I would be even more motivated to try and pull it all together.

[davidthefat]

Originally Posted by Jetweb

This is something I have been toying with for the last few years and in certain games it would defiantly be possible to do in 6 weeks. last year we were able to track a trailer in full motion, track orbit balls, and using a current sensor on our intake roller we could count how many balls were in our basket. and if i was allowed to put 4 sonar sensors on we would have attempted a full auto match at an off season (the drive team would never go for this in a real match)

Things to note:
- we were only able to get code to this level because we had a complete practice bot by week 3 and worked on it right up to our regional, which i think would be critical in trying to program something as complicated as a fully autonomous robot

- 79 made an awesome obstacle avoidance program using (i believe) 3 sonars at bumper level, which shows that real time obstacle avoidance is very possible without complicated LIDAR or anything like that.

- it is also very helpful to have a good mentor as previously noted.

Even if it doesn't work i have fun trying to figure out how to do it every year and if other people were trying as well I would be even more motivated to try and pull it all together.

Well we had practice bots from day one... but they were old robots, so they don't really count do they?

[Chris is me]

Independent of everything else, how do you plan strategy and cooperation with alliance partners? How do you track the positions of the other 5 robots and make decisions accordingly and on the fly? How do you adjust and optimize this strategy?

I'm sure if you had 6 weeks you could code a robot to autonomously run laps in Overdrive or something, but games really require more than that.

[Jetweb]

Originally Posted by davidthefat

Well we had practice bots from day one... but they were old robots, so they don't really count do they?

those are helpful to, but we were really lucky last year to have the real robot done really early and i believe that allowed for us to really polish our code.

[davidthefat]

Originally Posted by Chris is me

Independent of everything else, how do you plan strategy and cooperation with alliance partners? How do you track the positions of the other 5 robots and make decisions accordingly and on the fly? How do you adjust and optimize this strategy?

I'm sure if you had 6 weeks you could code a robot to autonomously run laps in Overdrive or something, but games really require more than that.

I like re usability of code very much, its just the Object Oriented Programming way. If you have to repeat your self 3 or more times, Its better off in a separate function. Probably will load a file that has the strategy, just modify it prematch without reuploading code

[mwtidd]

Originally Posted by Chris is me

Independent of everything else, how do you plan strategy and cooperation with alliance partners? How do you track the positions of the other 5 robots and make decisions accordingly and on the fly? How do you adjust and optimize this strategy?

Accomplishing this by yourself is nearly impossible, however if FIRST added the Zigbee module to the KOPs, alliance partners could communicate with each other.

[timothyb89]

This is something myself and a few friends were (somewhat seriously) joking about last year and a bit this year. In the end we settled on using an ANN and it got to the point where one was started, but that was about it. It's still something we're interested in, but I still have a feeling the best option would be to avoid AI entirely.

From my experience, it just requires too much processing power and storage space- for example, one of the bots that hangs out in our chatroom was recently outfitted with an AI, and its database grew to about half a gig in around two weeks from just working with text. Not only that, but searching through all that data to find the relevant bits would take up an entire core on a reasonably beefy processor. I'd hate to see how the cRIO would handle something like that.

Anyway, for a relatively low-powered device like the cRIO I'd have to recommend just hardcoding everything. That, and creative use of a bunch of sensors all around the robot. Without enough sensors I don't think a robot could reasonably compete with the (human) driver, but if used correctly, they could give the robot a good advantage. It'd be hard, but pretty awesome!

[Greg McKaskle]

I think a programming intensive off season project sounds amazing. The Guitar Hero project is an example of something that isn't a full robot, is a good stretch, and will definitely impress crowds.

My point is that the project you describe is comparable to RoboCup, which is graduate level research. Attempting to do the whole thing in an offseason is a bit naive, but if you break it down and focus on one aspect that you are most interested in, learn a lot about one type of sensor, or one type of control, or learn about Kalman filters or path planning, this becomes something that will have impact on your team and on your abilities.

If you don't think something like that is ambitious enough, coordinate it with a few others, but again, plan it out, layer it so that you can make progress one step at a time.

Greg McKaskle

[JamesBrown]

Originally Posted by davidthefat

LABView is a JOKE IMHO, its like RPG Maker or Game Maker for robots... Its not programming. but IDK may be my mind just works that way and I caught onto C++ when I was 12... LOL

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.

[Chris27]

Here's some better ideas:

Option # 1:
Given a camera image, label all robots. As in a FRC competition you encounter many different robots, you should be able to recognize a robot you have never seen before.
No fair covering it with colored tape or lights. I don't think many teams will allow you to do that with their robots.

Option # 2:

Don't give the robot an AI, just have it construct a world map and correctly position itself (localization) w/o having to put florescent colored tape/lights on every square inch of the game field. If a robot can't do something as "simple" as tell you where it is, you won't be getting intelligent actions from any AI. Do this with any semblance of reliability/robustness and I'd be impressed...

[efoote868]

Originally Posted by lineskier

Both can be accomplished by looking for the bumpers.

http://letsmakerobots.com/node/3843
(obviously would have to be ported to Java ME)

Except you're not playing defense against an alliance, you're playing defense against a robot on an alliance.

Also, I'm guessing that code won't work in every environment you put it in. Differences in field setups like lighting and backgrounds could kill it.
There's no rules saying a robot can't be blue and red, in a bumper fashion.
There may be field elements that are those colors too, like the bumps this year. They're long, they're rectangular, and they're the color of the opposing robot's bumpers.


Code that will take forever to write and forever to execute won't be as beneficial as say, making your robot super easy to drive and control.

[Bill_B]

I'm encouraged that there are folks considering an AI approach to FRC programming. I once thought that the 15 second autonomous period was a "waste". But that was based on it being largely ignored by the teams. Now that it has inspired more "serious" thoughts about programming among the teams, I applaud its introduction.

As to the supposed superiority of one language or system over another - just look at natural languages. French has been given credit as the language of love, but based on results, Chinese should be considered for that title, n'est pas? The more familiarity you have with differing programming environments, the better your resume will read.

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

[the man]

I dont know most of the fun for me, besides building the robot, is driving it.
Not every robot is atonomus in the real world, and our programers had a hard time this year, given they only had a few days to program the robot. I think that would take away some of what first is.