My concept for a design on our robot this year would require a camera, or the kinect’s camera mounted on a 360 degree rotational plate powered by a motor, to constantly keep the square goal image in the center of the camera screen.
Basically I have no clue on how to even program image to recognize something, but once I do, I will need help on using the motor (controlled by a victor?) to keep the camera centered on this image.
Any ideas to help me?
what kind of motor are you planning on using?
Two years ago, the kit included a pan/tilt assembly, sometimes called a gimbal, which used servo motors to aim the camera independent of the robot base. I believe they are still for sell at AndyMark. Since a camera doesn’t weigh much, it doesn’t take much of a motor.
Greg McKaskle
The fundamental task isn’t too complex.
Imagine your camera code is responsible for telling you where the square backboards are in the picture. It’s capable of saying “The goal is way to the left” or “the goal is right in the middle of the picture” or “the goal is to the right just a little bit”.
A slightly more accurate bit of camera code might respond with degrees from center: “The goal is -12 degrees from center” or “The goal is +0.4 degrees from center” or “The goal is +40 degrees from center”
Essentially, you feed this information to a new piece of code, code responsible for physically rotating the camera. Its goal is to try and make the goal “0 degrees from center”
If the camera code says the goal is to the left, you rotate the camera left until the camera code says the goal is at about 0. If the camera code says the goal is to the right, you rotate the camera right until the camera code says the goal is about zero. At all times, this piece of code is trying to keep that number 0.
For a first attempt, you don’t need to get too complicated. if it’s extremely important that the camera always remain dead center, and get there as quickly as possible, you can use various techniques to achieve that, such as:
-If the camera is way off, spin the motor faster. If the camera is only slightly off center, turn it more gently. (PID is one way to do this)
-Try and detect how the goal has been moving the last few times and make a guess as to where it is going to be in the future
But for the most part, you can usually get away with a very simple piece of code that just turns the motor in the correct direction at a fixed speed if the goal isn’t in the center, and have a little “dead zone” that you consider to be “close enough” where the motor does not move.
Ahh. I get your goal now. You aren’t worried about where the robot is, you want the camera to be centered on a goal/target.
This is covered in the white paper under the position section. The typical coordinate system used in images processing with NI-IMAQ is 0,0 at the top left and the resolution X,Y at the lower right of the image. Fine for image processing, but not all that great for targeting or aiming. To translate to a new coordinate system, you first need to define what the new system is, and you are doing that.
To simplify a bit, the paper defined the new coordinate system as 0,0 in the center with the edges being either 1 or -1. This matches the joystick and servo range nicely and also tends to be something easy to remember for feeding into PID algorithms. To do the coordinate system transform I describe, you subtract the target location and the center of the image, which is half of the resolution. This gives you a system that ranges from resolution/2 to negative resolution/2. Next step is to divide by resolution/2 and potentially invert an axis if you wish. If you’d like to use a different system, you can then scale back to radians, degrees, or anything else you’d like.
If that didn’t make sense, please try reading through the white paper from the NI site CD/media/papers and see if that helps.
Greg McKaskle
It sounds like you are trying to use a motor as a servo. If you can use a hobby servo, your job will be a lot easier. If the Kinect is too much for the hobby servo, servo-ing a motor isn’t overly difficult. It is a matter of comparing your current position to your desired position and compensating.
First figure out how you are going to measure that position. Do you need continuous rotation, or is there a range you can limit yourself to? How will you know where zero is? This will help you decide between a potentiometer, an encoder, or something else.
Then decide on a way to use that information to drive your motor. Jaguars have several advantages over Victors here. They have much much better low end response, which is important when the position is close. Victors can’t do a good job of nudging here. Also, when driven over CAN they can perform all of the control loop on board for you. Then all you need to do is tune the parameters and then send new position set points periodically.
What I am going for is from my current research nearly impossible at this point. I was aiming to have an aiming mechanism always locked onto one goal so when a ball is fed through, it would always be on target.
It is far from impossible. It is very possible. In fact, it sometimes is used as the “hello world” for computer vision, along with color detection.
if you can find a highly curved mirror, you wouldn’t need any motor at all. We have talked hypothetically, but never actually enacted, this idea.
Point the camera straight up to the ceiling, but have a convex mirror pointed down at it that lets it see a distorted image, but an image all the way around. If you use some clever algorithms, you can correct for the mirror’s distortion and produce a 360-degree image to feed into your stock color/shape recognition software.
This is beyond my intelligence, and the rest of my team’s for that matter 
What an issue would be, is if my robot had to lose it’s y-axis offset (say it went over the bump or climbed the ramp) then the image would be lost, and programming this would take more intelligence than I have to spare. Could there be an easy(er) concept?
What I am going for is basically like an automated tank turret system that stays locked onto the goal while I go around and feed balls into it to shoot. I’ve already programmed for the distance to shoot, and the turret is designed, but the problem is automated aiming. This is far from “hello-world” for a high school programmer 
There is an example in Program Files/National Instruments/LabVIEW 2011/Examples/FRC/Vision called Servo Camera Example. It detected the pink and green fabric and aimed the servo at it. It is a bit difficult to setup, runs on the cRIO, but includes most of the code you are looking for provided you are only aiming the camera and hobby servos will work. If you are rotating a heavier mass, you will need a motor with more torque and you’ll need an encoder or other sensor that gives feedback.
Greg McKaskle
the problem with servos is that they are not continuous. I would opt for a servo to control the up/down motion and a regular “servo-ed” motor to control the side-to-side. This would let you turn all the way around (although your cable would wrap up).
Basically, to keep the camera set, you just need to find the target and find out how far away it is from the center of your field of view. Continually send instructions to the motor to move it to the middle.
The difficulty is actually mechanically attaching the camera. Without a fancy rotary brush thing, you would have issues with the camera cable being tangled up. If you measured the “actual” rotation of the robot with a gyro, you might be able to get away with a normal servo:
have a variable called “offset_angle” or something.
you will also (because you plan to use a servo) know the angle between the front of the robot and the camera. when the camera sees the target, you can use some trig to determine the angle between the line of sight of the camera and the direction to the goal.
subtract all of these angles to determine how far the robot is from the target (as an angle, ie. “if you turn 15 degrees to the right, you will be facing the target”)
You can turn in place and keep track of this angle using the gyro, even if you do not see the goal markings. With this setup, to keep the camera on-track without a continuous motor, point the servo to the “angle between the robot and the goal” Then it will point the camera towards the goal and if you turn around backwards where the servo cannot go, the camera will pan all the way around, turning away from the goal for a minute, and pick it up on the other side.
Did I ramble too much there?