How many Robots at the nationals had an operational Camera Track Autonomous?

[Charlie]

Ok so now that the season is over would any of you that programmed in labview be willing to send me the code for tracking? i could never figure out how to track properly.

[Bongle]

Originally Posted by Charlie

Ok so now that the season is over would any of you that programmed in labview be willing to send me the code for tracking? i could never figure out how to track properly.

We were in C++, but our general idea could be adapted to Labview:

You need a gyro and the camera

1) Set up a PID controller to maintain your robot's heading at some set target (sensor input: gyro. setpoint input: some variable, let's call it targetHeading. PID output: a virtual joystick's x axis).
2) Whenever the camera detects a target, set targetHeading to (your current heading + angle offset that the camera sees the target). The robot will point itself at the target.

Having a PID heading controller is also useful if you want to run along the side of the field against the wall to pick up balls. With human control, robots tend to spin off because of the higher-grip carpet. With a heading controller, it automatically adjusts your motor's power levels to maintain its orientation relative to the wall, allowing for long runs of picking up the balls that gather on the outside of the field.

[gwytheyrn]

We had our camera tracking working for our second to last match I think, and we scored 6/7. Our robot had our camera mounted to our turret, so we could estimate the error in angle based on the position of the target in the image. We would add that error to the angle that the turret was pointing (found by potentiometer) to get our final error. And since your PID loop really just needs error, this will skip the need for a gyro to a point, since it won't remember target location.

[Bongle]

Originally Posted by gwytheyrn

We had our camera tracking working for our second to last match I think, and we scored 6/7. Our robot had our camera mounted to our turret, so we could estimate the error in angle based on the position of the target in the image. We would add that error to the angle that the turret was pointing (found by potentiometer) to get our final error. And since your PID loop really just needs error, this will skip the need for a gyro to a point, since it won't remember target location.

As I understand your system, your potentiometer is fulfilling approximately the same purpose as our gyro. It is providing a heading of the object that does the shooting. Since we can't use a potentiometer to figure out our robot's heading, we have to use the gyro.

[gwytheyrn]

I wish that were exactly the case. Unlike a using a PID+gyro, our system returns to going straight when there is no target in sight (or continues turning at the same rate, depending on how we want it) whereas with a gyro you can remember an angle and PID to the angle, effectively turning to the last known location.
Otherwise, they work in essentially the same manner