Programmers: I Have A Challenge For You

[Radical Pi]

If I were doing this, my first project would be a defensive robot. It is actually the simplest to code IMO. Just take the camera image, do a color analysys to find a rectangle of the opposing team's color, and drive towards that. Once you factor in a pinning timer through an accelerometer to determine if you are still moving, you could probably have a decent autonomous defensive robot.

Next would be the offensive ball collector. I personally would think of using an array of IR sensors that can give you a rough map of what is in front of you. Finding roundish-objects would be a bit of a challenge on the cRIO, but a fun one at that (would it be possible to generate a rough IMAQ image to use the existing libraries?). Alternatively, if a team could use a second camera, they could mount one high for targeting and one low for an ellipse detection below the bumper for balls.

Once you have possesion of the ball, I think the rest would be fairly easy. Do a spin until you detect a target, do a color check below the target to make sure you are aiming at the right team (180 spin if wrong), and then the rest has been done by other teams this year.

Sensor-wise, I think a gyro is a given. If you zero it after every targeting calculation, you could easily use it for relative motion in targeting through a state machine. I think flow would be camera detection->calculate turn amount->zero gyro->turn->when finished, re-check targeting and repeat if necessary. After a gyro, I think 2 cameras would be much more valuable than most other sensors. As I said before, a high camera has been proven to be acurrate for goal targeting. A low camera (kicker level?) could work using another ellipse detection algorigthm. Against the field, the balls would definitely have enough contrast to detect, but the field walls I'm not sure about.

On top of the cameras, some form of possession detection would be good. For our system, we mounted 3 IR sensors around the ball entry area. 1 sensor above the ball indicates when a ball is in our kicker (would have used this for autonomous if we had time most likely), and then 2 sensors, one on the left of the ball and one on the right, tell us the internal position of the ball in the kicker. A similar system might work in the autonomous bot idea.

AI flow as of now in my idea: Spin randomly->check for balls, spin again until found->aim for nearest ball->drive until in possession->spin until goal found->check if is correct goal, spin around if not->aim for goal and kick->repeat

Input?

EDIT: one more thing: a compass wouldn't work too well in this situation. I would expect that as electromagnetic motors, a fair amount of drift would be seen in any compass operation, causing the accuracy of the compass to change depending on speed and direction of driving

[mwtidd]

Originally Posted by Radical Pi

a team could use a second camera, they could mount one high for targeting and one low for an ellipse detection below the bumper for balls.

I was wondering about this, how do you hook up two cameras? Can you do this with a network switch or is it another way?

[Alex.Norton]

to paraphrase the words of the preeminent voice in the field of computer vision when DARPA asked the somebody to make a computer that could see as well as a 5 year old child: "Could we try for 2 year old autistic monkey instead?"

I will realize that this view isn't very adventurous, but I'm a firm believer that taking small steps to improve ones programming is important, that and I wouldn't want my programmers to spend so much time on it that they fail their classes.

I personally would rather see my team automate everything except the basic movement of the machine. Make the machine collect the game piece, turn and score. I've programmed fully autonomous tank games and it can be very hard to design a system that can predict the actions of an opponent. I like having a human mind in the loop acting as a garbage collector and main decision maker.

-Alex

[Vikesrock]

Originally Posted by Radical Pi

Alternatively, if a team could use a second camera, they could mount one high for targeting and one low for an ellipse detection below the bumper for balls.

Why not use a single camera with a tilt mount? You could either try to find a mount height that allows for a single angle that will detect balls and another angle to target or you could determine a range of tilt values to scan over in each mode.

[mwtidd]

Originally Posted by Vikesrock

Why not use a single camera with a tilt mount? You could either try to find a mount height that allows for a single angle that will detect balls and another angle to target or you could determine a range of tilt values to scan over in each mode.

Ball detection was talked about in this thread:

http://www.chiefdelphi.com/forums/sh...highlight=ball

My thinking is by having a camera at the ball level, it would greatly reduce if not eliminate the shadow issue, allowing you to use the findEllipse method.

one design i did see which is a median between the two is putting the camera on a pneumatic, lower position for being at the ball level, top position for being high enough to see the goal.

[Greg McKaskle]

I'll try to sum up the icon and compile thing quickly so as not to interrupt the design of SkyNet.

My claim is simply that the machine instructions contained in those clumps almost certainly were produced by a traditional compiler using a traditional text-based programming language -- quite likely C.

Textual representation of machine code is usually called assembly code. The actual machine code is in fact a sequence of bytes, but not human readable in the slightest. The LV product contains a compiler which writes machine instructions into memory based on the passes over the graph -- no calls to gcc or asm, nothing up the sleeve.

There are actually numerous ways for LV to target a platform, the compiler is the most common, another is a bytecode/VM method used for small targets such as the NXT, and the third is a translator that does produce C or VHDL to more quickly be able to use vendor specific tools. So while this is a way LV to target VxWorks, it is not the method being used.

As for icons replacing text, I don't think that is the right comparison to make. In fact text is just a sequence of graphics. Textual and mathematical language is just as abstract, if not more so, than a drawing.

The issue is the expressiveness of the programming language. Would you rather write down a paragraph about the sunset or snap a photo? Is a map better than directions? Is a picture of food better than a recipe? It all depends on what you are trying to do. IMO, the best environment would let you pick based on the task. Did I mention that LV has had a formula box since 1.0?

And now ... back to SkyNet.

Greg McKaskle

[Chris Hibner]

Originally Posted by gvarndell

For the record, this didn't start out as a Labview discussion and I didn't lead it here -- nor did I want to.
There was first a claim that iconic programming was replacing text based programming.
I claimed that, on the contrary, text based programming is the foundation upon which iconic programming is built.
Icons (nodes if you prefer) graphically represent machine code.
AFAIK, other than compiling and/or assembling text files, we have no spiffier way of producing the machine code.

I never said text based languages would disappear. I said that they would fall away from being the norm, just like assembly isn't the norm today. When I started working in the embedded controls area, everything was done in assembly. Right after I started the company decided to do the first product done in C. You wouldn't believe how many, "oh, that'll never work" statements were going around the office.

Text to graphical coding is no different than the last evolution from assembly to C. Just like many graphical "languages" start out by auto-coding C, most C compilers start out by "auto-coding" the C to assembly. That doesn't mean that C isn't a higher level language than assembly, nor does it mean everyone has to know assembly to use C. Assembly is just the relic and the automation handles the details.

There also isn't necessarily a chicken-and-egg scenario. The original C compiler was most likely written in assembly or another high level language (like, say, FORTRAN). Current C compilers are written using the previous C compiler. In other words, you may need a different language to write the initial compiler, but as soon as you write that first compiler, you may be able to do away with it from that point on.

With all of that being said, text based programming is currently more efficient for coding than graphical languages in certain areas (as I said in the original post). For that reason, I don't see text based programming dying any time soon. What I do see is it will become less and less prevalent and it will only be used when there isn't a much better choice (much like when people use assembly today).

[gvarndell]

Originally Posted by Greg McKaskle

so as not to interrupt the design of SkyNet.

OK, I think we've beat the text vs icons issue far enough into the ground -- at least for this go-round

It is a distracting tangent to the thread.

I think all us software types are pleased that the kids (at least I hope it's the kids) are exploring the possibilities of software, so let's let them get back to it.

[Alan Anderson]

Originally Posted by Chris Hibner

The original C compiler was most likely written in assembly or another high level language (like, say, FORTRAN).

The first C compiler was written in B.

[gblake]

Originally Posted by davidthefat

Next Year, no matter the game, I challenge you to make your robot fully autonomous. ... 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

I haven't read this entire thread; but if the folks who have signed up for the original poster's challenge (and any who haven't yet) would like to get a little practice in before attempting this challenge with a real robot - I can make it possible for you to control one or all of the 5th Gear simulated robots purely through software - I did this myself for our Overdrive simulation, and it is definitely a learning experience that would be good prep for attempting to the same with a real bot - Do I have any takers?

Blake

Main 5th Gear Thread: Link to 5G Thread

[tsa256]

This appears to be a very challenging yet intriguing problem. From personal coding experience on my team it seams that creating a 100% autonomous robot would be very plausible. In past years, I've been able to implement code to completely automate driver twos job. Although one difficulty of this is if a sensor breaks or something fails driver two will never trust the code again.

As for a entirely autonomous robot, I agree it's possible but the logic behind it would be massive. I have no doubt it can be done; As the head programmer on my team I find myself automating everything I can with sensors. The two main limits keeping me from pursuing a robot with more autonomy or 100% autonomous robot is time, and resources.

I have no doubt other people have hit similar bottlenecks. As for me, I'm planning on structuring a very modular library of labview code to speed up this process and allow for easy implementation regardless of next years game

[efoote868]

Originally Posted by tsa256

I have no doubt it can be done; As the head programmer on my team I find myself automating everything I can with sensors. The two main limits keeping me from pursuing a robot with more autonomy or 100% autonomous robot is time, and resources.

In six weeks, with a budget of $5,000 of things that can go into the robot, using a normal skill set (high school programmers), it won't be done.



I used DARPA as an example early on in this thread - teams of professionals and graduate level students with near unlimited bankroll behind them, completing a task that is arguably easier/more straight forward.
It took them two years to complete the challenge.



Take this years game as an example, broken into its most simplistic macro steps.
(offense)
1. Find a ball
2. Drive to the ball
3. Kick or push the ball into the goal

That's very straight forward, until you toss in the fact that there are 5 other robots on the field. If you spent time completing all three steps in code and then testing, I say that's time wasted that could have been spent perfecting your autonomous mode, or spent making your robot the easiest machine to control on the field.



I don't want to sound like a nag or a nay-sayer, and I don't want to keep you from learning or failure. I'm trying to offer my words of wisdom having spent 4 years as a student in FIRST and a year as a mentor in FIRST.

There's a reason all cars don't drive themselves, this AI stuff isn't as easy as you think it may be.

[gblake]

Originally Posted by efoote868

In six weeks, with a budget of $5,000 of things that can go into the robot, using a normal skill set (high school programmers), it won't be done.



I used DARPA as an example early on in this thread - teams of professionals and graduate level students with near unlimited bankroll behind them, completing a task that is arguably easier/more straight forward.
It took them two years to complete the challenge.



Take this years game as an example, broken into its most simplistic macro steps.
(offense)
1. Find a ball
2. Drive to the ball
3. Kick or push the ball into the goal

That's very straight forward, until you toss in the fact that there are 5 other robots on the field. If you spent time completing all three steps in code and then testing, I say that's time wasted that could have been spent perfecting your autonomous mode, or spent making your robot the easiest machine to control on the field.



I don't want to sound like a nag or a nay-sayer, and I don't want to keep you from learning or failure. I'm trying to offer my words of wisdom having spent 4 years as a student in FIRST and a year as a mentor in FIRST.

There's a reason all cars don't drive themselves, this AI stuff isn't as easy as you think it may be.

You tempt me to prove you wrong - but I'll leave that to some group of enterprising students.

If you remember that we are building role models, leaders and careers; and that we are using robots and tournaments to do that; then I think teams and students can be outstanding successes in the time and money available to them.

Blake

[virtuald]

Originally Posted by Greg McKaskle

Textual representation of machine code is usually called assembly code. The actual machine code is in fact a sequence of bytes, but not human readable in the slightest.

Actually, there are some people who can read it. Very very very very few. But I know at least one. Its pretty ridiculous.

[Boydean]

I would be down with this. I know if I brought it up during a meeting it would be cut down pretty fast, but that doesn't stop me from working on it outside the competition to learn.

I see a lot of time spent in the parking lot with bot the next couple of months.