they all work just fine, its just more efficient to use java or c++

as for anything electrical, manuals or anything, check out the first website. Projectile motion is nessasary if you want to hit the top hoops since the mac height of the robot is below the top hoop.

OBJECTION. The max height is not the "max" height. You have to meet a certain requirement at the beginning of the competition, but when you're in the area, you can grow about 12 inches, and then you can even grow another few inches, as long as that last part can come back down (I think there's a restriction about the size of the last part, like no more than 5 inches in diameter, or something).

Also, I have to say that I quite like the Kinect, and I think that is going to be a very fun element to work with. I finally found all the SDK stuff that I would need on Linux and compiled an example (or 5) and will start looking at code tonight or tomorrow night. My other team members don't want to use it, though :/ They are proposing that we just use webcams (Since they should be able to lock on to the backboard, since it is reflective), but then you lose the depth perception. Not to mention, we're given this opportunity to abuse the Kinect, so why not?

I actually don't know how we are tackling the barriers, nor the teeter-totters. That was one of the two stations I didn't hit (I had gone to Shooting/Ball Collection).

The manuals are pretty informative, though there is a lot of information that can be hard to find. We found it really helped to write our own interpretations of the rules, and then compare them and find which ones seem the most correct. Also, be sure to check YouTube for the videos about the field, gameplay, the teeter-totters, goals, and using the Kinect, because that really helped us, too.

You can feel free to ask questions here; I know a decent amount about how the different parts are wired together, and have some friends who specialize in that I can lure over here to help. Of course, asking on Chief Delphi is a decent idea.




As you would say, OBJECTION. It's fun when you aren't forcibly pushed into using it by your team. Half the designs my teammates made during the kickoff banquet I just returned from included things along the lines of "Well, the programmers can just program some stuff for the kinect that allows arm movement recognition to control control angles.. and they can of course make a complex system for visual guiding using all these sensors...". After the third one like that, I got up and said "ORLY, so, I'M not programming every single idea you're coming up with... I didn't know you signed up to be the programmer this year. Here, you program it, I can catch up on tetris. K?". My argument is almost won.

I'm also working with robotics.

I don't know about this. From what I see in the rules, the only criteria is the robot must start at 60 inches high or under, must remain at the 60 inches or under height while on the "defensive half" of the court, but can get as high as 84 inches on the "offensive half" of the court.

Aha, found what I was looking for. Absolute height must bot exceed 84 inches. The height at the start of the match must not exceed 60 inches. Any appendage may not extend more than 14 inches beyond frame perimeter. Therefore, the robot can grow 24 inches after the start of the match, and then you can have an arm or similar exceed 14 more inches. I don't see anything saying that the arm is not allowed to use that 14 inches to go up (With the exception of this E rule, but I think the "no other part" refers to everything but an arm). Source: The Robot.pdf, Section 4.1.1, [R02].

Ashbad, while I can see that getting annoying, my team didn't quite do that (Granted, I was probably the one coming up with the cooler/improbably (Not impossible!!) ideas). Most of them know that programming certain elements isn't easy, and therefore they kind of let the programming requirements rest until the robot is actually built (A problem last year. We were building and programming at the same time... didn't work out).

No, I'm pretty sure it includes the arm too. The 14 inches is talking about going past the frame perimeter in the X and Y directions, while height has 24 inches instead of 14, but only when on the half of the court in which your baskets are at.

I was wondering what everyone thinks about the bumps and teeter things in the middle and if you think that you will be going over the bump or trying To go over the teeter. My team personaly the model we built In cad before the season is specificly build for pushing power and obstacles so will probably be just going over the bump

And I belive that 84 in is the max high no matter what

No, because the balls get recycled when they're scored.

By the way, does anyone know how many balls are in play in one game?

18 balls. (Each robot can hold three balls at a time, and there's 3 robots on each team, and two teams. 3*3*2=1

What strategy is everyone using, out of curiosity?

We are currently working on a custom dashboard system in java that would allow us to display way more info then the built in one. Here is the src for what we currently have. Right now it dosent have any network functions yet (those are being tested outside this). The dials are being fed artificial test data tho so we can test them.

download:
http://wildcatrobotics.com/files/Dashboard_src.zip

EDIT: forgot to add a runnable version of it
http://wildcatrobotics.com/files/Dashboard.jar

Thanks for showing me this!! The program looks great! How much longer will it take to have the networking stuff running?

If we get together for a meeting today we might be able to get basic networking running today

Just curious, how are you guys attacking towards designing the collection, storage, and deployment modules for the balls? What my team will likely be going with for deployment is likely either two spinning friction wheels, or one friction wheel against a flat surface for natural spin downwards (easier to control, less powerful). No ideas for storage/collection yet, but collection may also have something to do with friction wheels.

do you mean backspin? downwards spin makes me think of topspin, which is really really bad.


I would use cylindrical rollers with some type of high-friction rubber coating on them. Wheels are too narrow.

We currently have a setup that uses two normal wheels that can shoot over 35 feet. As for the feeder we have a few ideas that we are going to prototype

yes, *backspin, sorry


I would use cylindrical rollers with some type of high-friction rubber coating on them. Wheels are too narrow.[/quote]

Actually, when we tried them in previous years, they worked fine with things like this; we have yet to prototype it, but we expect it would work well with the general soft build of the balls.

wow. Well, that's unexpected. If it works for you, it works!!
isn't there a pretty small error tolerance for your drivers, though?

Has anyone attempted to get the Kinect on the Robot itself to use as a sensor?

I wish! My team told me that we aren't using the Kinect, which saddens me. I was really hoping to get to play around with it, some.

As for our strategy, we are going for a balancing robot that, if everything pans out well, will also deliver balls back to our guys during the game. We had originally planned on doing a 2 wheel cannon sort of thing, as well as a one wheel + wall + extra wheel for backspin one. Then, some day when our guys were talking to professional engineers, we decided against that for the more simple balancer

Also, we are still going to use LabView, unfortunately. Well, I guess I should say, we are doing the LabView one first, and if we finish fast enough, we can do another in Java, but that one would only be for playing