Vision Targeting for Aerial Assist 2014

[mechanical_robot]

Alright what are some ideas for vision targeting this year for the 2014 game? My ideas were to for autonomous use the hot zones to target.

Any ideas what are your ideas. I'm currently looking at the game/arena setup PDF.

[Hypnotoad]

It seemed pretty clear that that was the intention of the hot zone from the very beginning.

[faust1706]

Track the hot zone, the balls (calculate its speed and go to where it will be autonomously), track other robot and pass the ball so it will meet them in their path. Track opposing robot so you can autonomous move around them. Track the vision tape on the wall and index from that.

Not going to lie, this this very elementary stuff.

[N00bfirst]

Originally Posted by faust1706

Track the hot zone, the balls (calculate its speed and go to where it will be autonomously), track other robot and pass the ball so it will meet them in their path. Track opposing robot so you can autonomous move around them. Track the vision tape on the wall and index from that.

Not going to lie, this this very elementary stuff.

Not for us new to this.

[RufflesRidge]

Originally Posted by N00bfirst

Not for us new to this.

http://wpilib.screenstepslive.com/s/3120/m/8731

[N00bfirst]

Originally Posted by RufflesRidge

http://wpilib.screenstepslive.com/s/3120/m/8731

wow...

thanks a lot!

[MikeE]

Originally Posted by faust1706

Track the hot zone, the balls (calculate its speed and go to where it will be autonomously), track other robot and pass the ball so it will meet them in their path. Track opposing robot so you can autonomous move around them. Track the vision tape on the wall and index from that.

Not going to lie, this this very elementary stuff.

I agree that determining from the vision target if one of the autonomous goals is hot from a relatively defined stationary position is an easy task with already published examples.

But I don't see how you can possibly argue that tracking other robots and/or flying ball(s) is elementary. That betrays either a misunderstanding of how difficult it really is, or such a deep mastery of computer vision that you've forgotten how difficult it is to the inexperienced. I'll assume the latter.

[faust1706]

Originally Posted by MikeE

I agree that determining from the vision target if one of the autonomous goals is hot from a relatively defined stationary position is an easy task with already published examples.

But I don't see how you can possibly argue that tracking other robots and/or flying ball(s) is elementary. That betrays either a misunderstanding of how difficult it really is, or such a deep mastery of computer vision that you've forgotten how difficult it is to the inexperienced. I'll assume the latter.

I"m going to finish it as soon as I can so I can then outsource the code. If you do a cascade on the object, then you can calculate distance via sterio or depth. You can "measure" the distance traveled between 2 frames for this ball or robot, along with the distance on screen. Size you can assume that the robot's frame dimensions will be almost identical for every robot (or you could save that robot's dimensions when doing a cascade of them), you can measure the velocities in the other two, then use simply add all 3 and now you know it's velocity. Then you know how fast you are going to roll the ball at them, so you do a vector problem. This does assume that they will continue their speed.

The ball is a fairly easy. You already know how big the ball is (therefore its diameter). You could simply use the area of the ball to calculate how far away it is. It would take some testing, but it is very doable. Then the same math applies to the previous example.

[yash101]

Originally Posted by faust1706

I"m going to finish it as soon as I can so I can then outsource the code. If you do a cascade on the object, then you can calculate distance via sterio or depth. You can "measure" the distance traveled between 2 frames for this ball or robot, along with the distance on screen. Size you can assume that the robot's frame dimensions will be almost identical for every robot (or you could save that robot's dimensions when doing a cascade of them), you can measure the velocities in the other two, then use simply add all 3 and now you know it's velocity. Then you know how fast you are going to roll the ball at them, so you do a vector problem. This does assume that they will continue their speed.

The ball is a fairly easy. You already know how big the ball is (therefore its diameter). You could simply use the area of the ball to calculate how far away it is. It would take some testing, but it is very doable. Then the same math applies to the previous example.

The math involved is quite simple. You know the diameter of the ball in real life. You can get the diameter of the ball from theNumber of pixels out is wide. Use convexhull to find the balls and process them. So you will need a reference image showing how large 25 inches is. You can use this info to extrapolate the size and distance to three ball. This will allow you to find the distance to the ball and find the speed and acceleration.

This is simpler than what it seems. Have you gotten pence installed with python bindings or Windows c++?

Read 341's vision whitepaper!!!

[topgun]

Originally Posted by faust1706

I"m going to finish it as soon as I can so I can then outsource the code. If you do a cascade on the object, then you can calculate distance via sterio or depth. You can "measure" the distance traveled between 2 frames for this ball or robot, along with the distance on screen. Size you can assume that the robot's frame dimensions will be almost identical for every robot (or you could save that robot's dimensions when doing a cascade of them), you can measure the velocities in the other two, then use simply add all 3 and now you know it's velocity. Then you know how fast you are going to roll the ball at them, so you do a vector problem. This does assume that they will continue their speed.

The ball is a fairly easy. You already know how big the ball is (therefore its diameter). You could simply use the area of the ball to calculate how far away it is. It would take some testing, but it is very doable. Then the same math applies to the previous example.

If you didn't outsource the code before Kickoff you are to late and you can't use it on your 2014 robot:

R13 ROBOT elements created before Kickoff are not permitted. ROBOT elements, including software, that are designed before Kickoff are not permitted, unless they or their source files are publicly available prior to Kickoff.

I hope that you did outsource it before Kickoff as I am interested in seeing your techniques as a learning tool for my team's programmers. Please include a publicly available link to your source code.

[Hypnotoad]

I doubt there will be much practical use in tracking anything but the hot zone. Anything else and you're adding unreliable gimmicks to your code. Letting the drivers practice for a few extra days at picking up and shooting is most likely much more beneficial than a ball tracking algorithm.

What I'm worried about is the brightness of the led strips around the hot zone. It seems like they will be a bit dim to track. If anyone has seen stills of teams using the reflective tape, you will see that the leds have to be blindingly bright for them to be as easy to destinguish.

[RufflesRidge]

Originally Posted by Hypnotoad

What I'm worried about is the brightness of the led strips around the hot zone. It seems like they will be a bit dim to track. If anyone has seen stills of teams using the reflective tape, you will see that the leds have to be blindingly bright for them to be as easy to destinguish.

Then why not track the reflective targets?

http://www.youtube.com/watch?v=8-vZm...ru_5& index=3

[Hypnotoad]

Originally Posted by RufflesRidge

Then why not track the reflective targets?

http://www.youtube.com/watch?v=8-vZm...ru_5& index=3

Huh. I totally missed that part while looking through the rulebook. I guess ill read through it one more time. That's one less problem I have to deal with then. Thanks!

[MikeE]

I am seeing at least two strands of assumptions in this thread.

Identifying specific objects and tracking them under ideal conditions is an very interesting, worthwhile and fairly achievable project within the skill set of many capable teams.

Doing so in the real world on a robot, in competition, with intervening fast moving objects, variable lighting, possible network issues (if DS processing), another team playing heavy defense on you, then relying on the data to perform a critical dynamic function on your robot is a totally different scale of problem.

[Justin Shelley]

Since auto is the only part where a single robot can score competitively by itself i think it will be even more important than usual to score the max possible in auto. At weaker districts and regional teams that can score their alliance partners balls in the hot goal will be far ahead of most other teams. To me vision tracking of balls and hot goals in auto is a top priority