Re: ball cannon???
 

It seems as if you need an athletic team to be with this competition. I played basketball for 5 years so that I give me if I am a payload specialist a little edge. I think that it's going to be very different from what has been previously played.

Re: ball cannon???
 

i think that a cannon that tracks with the camera and stays on target, but is also controlled, at least to some degree by the driver would be the best cannon option. i know this would be bad for programmming.

Re: ball cannon???
 

This game was practically designed to be a shooter game. It was hinted to man a times in the kickoff that robot to robot contact (or robot to trailer for the purposes of scoring) would be very difficult to do and would require much time and coordination (and i don't believe the other team would be so keen about you scoring in their trailer)

The camera systems given to us along with the lazy suzan (and even the game video) is almost a direct notice to us: use a shooter! but the question is how you would make it effective?

unlike 2006 where you would fire at a stationary target, this year you must fire at multiple moving targets which you cant assume will be in front of or behind you. it would be near impossible for a pilot to aim the turret at an opposing robot, accounting for all the possible motion and angle, and fire a successful shot. We are, however, armed with an extremely powerful vision system this year, which can do advanced color and blob analysis at speeds inconceivable with the CMUcams.

The basic logic i have hammered out is you would have a camera mounted on a pan/tilt on top of your turret. This will give your cam a constant, known height. we are also assuming you have a well designed shooter with a control loop that can have an accurate firing distance and angle, as well as approaching those parameters in under a second. The camera is on the constant hunt for beacons that your team wants to shoot at. when it locates a beacon, there is a control loop that tells the camera to lock its pan/tilt such that the beacon is in the center(ish) of the feild of view. Servo/image error will then allow for the angle of the turret to be corrected for.

The interesting part comes with shooting. Both you and your target are (perpetually?) moving. to account for this, your software will need to be able to do motion prediction (probably using second-degree extrapolation of some sort), and using empirically or mathematically determined data, will be able to lock onto where the target will be. With a system like this in place, even a fast moving and evasive target will not be able to outsmart your turret... well unless its out of range or they move in a manner that second-degree extrapolation cannot predict.

Software is incredibly important this year! you can close your loops with far greater precision (double precision floating point values!!!!!) than you could in previous years.

Re: ball cannon???
 

our team was thinking about that today and we decide to try to build a harvester and turret for the balls. We are always going to try to make the auto detect thing work with the camera. Were going to start testing that theory later this week and see if it works.

Re: ball cannon???
 

No, you can only have one empty cell in possession of your robot, but the number of moon rocks is limited to however big the room in your ball holding mechanism is:)

Re: ball cannon???
 

Ok. I have to ask. I, too, have looked into using a vacuum to increase traction but I have run across a seemingly-insurmountable roadblock to the plot and it involves <R06>.

I had envisioned a tube or suction cup of sorts that would need to be pointed at the floor with a rubber shroud going around the edges that would just barely clear the ground. Here are my concerns though: 1) How do I make sure the shroud doesn't touch the ground, thereby violating <R06>, and 2) Will this even work to a good extent? Will there be too great of a loss of vacuum?

Additionally, I envision that the fan in the vacuum generator would suck air from under the robot and blow it out above it. Am I right in making this assumption?

Thanks!
-Matt

Re: ball cannon???
 

True! It would take so much time...and a master programmer...x]. My team was thinking of using a cannon also...i don't think its a good idea though...since with the robot sliding..=/..and a cannon that isn't that accurate..=/..geez how will this work together...><! HELP!..=D

Pros: Robot gets to shoot!

Cons: Will it work? Is it accurate?

Re: ball cannon???
 

It all depends upon the driver. IF that driver can successfully figure out how to drive your robot the way you want it on the slippery surface, then it doesn't really matter what launching/dumping device you use.


This competition most relies on:
1) a great driver with lots of practice and experience
2) someone on a basketball team
3) a good strategy involving your two alliance members.

Re: ball cannon???
 

Actually, the robot sliding helps a shooter design, not hurt. Due to the smooth surface and the CoF of the wheels, teams are going to be finding it very difficult to turn on the surface - once they start in a direction, they are going to keep sliding in that same direction for a while (a few seconds, a least). That means that a shooter system can assume a straight line travel vector, and compensate for the air time of the ball. If we were playing on carpet with last years wheels and robots, a shooter system would have no hope of hitting a target, as the robots would be turning and moving around too quickly.

I would say the playing surface is the only thing that makes a shooter system viable this year.

Re: ball cannon???
 

Keep in mind also that unlike the CMU camera, this camera is a true ethernet camera with a built in web server. I absolutely agree that an auto tracking turret would be best, and I also agree that it would be beneficial to have a driver controlled turret either for teams that are light on programming or in some cases where a manual override is necessary (maybe you want to shoot to the left or right of the light post).

This year's competition makes it easier for manual control since it would be possible to have a laptop deliver realtime video from the camera and have a co-pilot manually rotate the camera into position. The co-pilot would have a robot view of what he/she is shooting at.

Re: ball cannon???
 

I believe the reason why 1771 was able to create so much force was becuase they had an excellent seal on the ball.

F = P x A

So if you can gradually build up pressure over a large area you can create a lot of force.

But without a seal on the floor, it'll be pretty darn near impossible to build up pressure.

Re: ball cannon???
 

of course its legal there is no rule that limits how many moon rocks you can hold at once; only empty cells

Re: ball cannon???
 

my .02

in AIM HIGH we had a hopper on our bot and we had tryouts for human players and the kids that were good at basketball where really bad at shooting little balls over a big wall the best two were actually short kids. dont know if it was a coincidence or anything

Re: ball cannon???
 

After a lot of debate on our team, we seem to have settled on a turret launcher design. This is because a low powered launch can be used almost like a dump, so this gives you more scoring options, and a turret can be used to score anywhere, while a dump will most likely not have any sort of variety in scoring positions.

However, with this floor who knows what will happen.

Re: ball cannon???
 

Rather than having software choose how far ahead to lead the shot for the moving object, you could also simplify it at first so that the driver leads the shot right or left. Example: the camera finds the target, and the driver sees the angle at which the target is moving -- right to left across the front of the driver's robot. So the driver then presses one button to add a 3-4 degree offset to what the camera sees, such that the turret rotates to where the target is going. The camera still tracks the target and moves the turret as appropriate, but with the button down the software moves the turret to the target's bearing +/- the offset.

Defense corporations (such as Lockheed, the company I work for) spend millions of dollars on target motion tracking algorithms for precision targetting. This year's game doesn't require precision targetting (have you tried throwing the ball 27ft with any sort of accuracy?) so in the beginning I would plan on having a very simple way to adjust for moving targets. After all, if an opponent is moving at 10 feet per second they will more than likely crash into something, at which point they are no longer moving and are an easy target :cool:

Just my 0.02 though.