How far have you gotten on coding the camera tracking?

[Sean Raia]

Our team is mostly finished. We just need to debug and make it more efficient.

[Daniel_H]

We are still trying to improve the response delay, the robot takes sometimes half a second to react. The camera's FPS is almost never above 10, but I don't know if this is an issue in the robot or just the laptop communication.

We also need to make it work in different light conditions.

[fordfiler6]

To update, I'm on the same team as Sean.

We can now successfully find a flag, check if its friend of foe, and track the motion of that flag if it is a foe.

We are going to work on code to decide which flag to use if more then one is present in the field of view. Hopefully get a good start tonight

[Redneck]

We've gotten our camera to successfully find the pink/green flag, determine which alliance it's on and track appropriately. Our problem now is with getting the robot to follow it - when we try to have the robot turn and drive towards the target, only one side of the drive system responds properly (the other just sort of twitches back and forth).

[weinbergmath]

Hi everyone,

I'm posting two videos of an older robot with the new control system tracking the vision target.

Video 1 - http://www.youtube.com/watch?v=9l64T6wc1Lg

Video 2 - Labview Screen View - http://www.youtube.com/watch?v=HdyzfuzJs-w


We used the Two Color servo tracking vi from NI, and dropped it into the Robot Main vi to control the drive motors of the robot. Please contact me if you have questions on the implementation. The program is set to steer towards the target and maintain a certain distance, which will be adjusted to be at the correct distance to allow our manipulator to drop the moon rocks into the trailer.

I'm not thrilled with the program's ability to track the colors, particularly the green color, but we will continue to test and adjust as time goes on. You can see the intermittent tracking of green in the second video. We will be transplanting the control board to the new robot to tweak it for the new wheels very soon. I expect to be able to take the outputs of this current program and feed them into a traction control algorithm.

On another note, I want to say how enjoyable it has been teaching my students to program the robot using Labview. Most of the programming team has almost no programming experience, but something about Labview has made it less intimidating. The students really seem to enjoy looking through the various functions to find what they want to use, while finding other ones along the way that might be useful later on. Even more interesting, this year's programming team is almost exclusively female! If Labview was the missing factor in getting more girls interested in programming, I will gladly add it to the list of reasons I'm glad we made the decision to use it this year.

One more comment - has anyone found that the camera resets itself when the motors change rapidly? The only cause that makes sense is some sort of noise getting into the system. We changed our tracking to include the PID.vi from the control toolbox, and the system was resetting any time there was integral gain. The camera would reset, and the cRIO would keep doing whatever it was doing just before the camera went out....disabling and re-enabling at the driver station would stop it from moving completely. Please let me know if you have had similar experiences.

Evan

[Arefin Bari]

Our programmers are having great success with the camera. We asked them to write a code called, "Kill the Driver Mode." Our programmers have been spending time to track any color shirts they have been wearing lately so they can be chased around for the last 20 minutes of the meeting. =)

[Doug Leppard]

Thanks for sharing this.

[Greg McKaskle]

I'm not thrilled with the program's ability to track the colors, particularly the green color, but ...

First off, great job getting it integrated. It looks awesome. You probably know this already, but if you disconnect or make the update of the image display optional, your code and camera will run quite a bit faster. That was what the example was doing.

The green color of that fabric is indeed less predictable than the pink, which is why the pink is the primary color by default. For debugging, you may find it useful to switch the first color to green to see the entire green mask. Then tilt the target towards and away of the camera to see if the issue is with the green getting to bright, too dark, or something else. Usually it is either a bright streak or a dark streak.

Once you know how to make it fail, and while it is still running, open up the Find VI, click on the HSL debug switch, and now you can hover the mouse over the green portion of the image to see what the pixel values are in HSL. This will give you an idea of how the different orientations differ, and how much you'll need to lower the saturation or brightness on green to get it covered. You may also decide that you don't want to change it if it is due to tilt which you don't expect in a game.

The debug HSL button is not something I'd leave on for real usage, by the way. It works identically, but slower because of the display, and because of the explicit HSL conversion of every pixel. For normal operation turn the switch off, the threshold will still be done in HSL, but only enough math to perform the threshold.

Greg McKaskle

[paulcd2000]

We've gotten the Camera tracking a pink and green target, identifying which team it is, where it is and how far away it is, and it's all in a modular code block. We modified the Single Color Tracking Example and then added servos and position data.

[Comatose]

What does HSL stand for?

[Sentient]

Hue/Saturation/Luminosity. It is just another way to represent colors than RGB.

[Dr. Manhattan]

I, as the most active of one of three programmers on my team, have made no progress at all. Especially since this is my first time ever using labview, so I'm entirely self taught.

Any help would be greatly, hugely appreciated.

[s0crates]

I, as the most active of one of three programmers on my team, have made no progress at all. Especially since this is my first time ever using labview, so I'm entirely self taught.

No progress into making the robot follow a target, or matching the target?
If you're having trouble making it track with the standard gimbal and two color tracking demo, try finding somewhere there is more light - opening the windows where we are made a huge difference. It also took a lot of tweaking of hsl values.


btw see you at the regional :)

-jonathan

[TheOtherGuy]

We're still having fun trying to get the response time to be faster, but I believe we've reached the highest efficiency we can get before ship. I tracks like no tomorrow, but when the target is moving we're having trouble leading it... We messed around adding in a PID lead/lag loop, but we're only having moderate to no success with that. Has anyone else gotten it to successfully lead a moving target? Any thoughts on that?

By the way, I'm very impressed with the support the community has on the camera this year! Here's a shout out to all the incredibly helpful NI folks that have provided time and resources to ensuring this season's success with the new system!

[Dr. Manhattan]

No progress into making the robot follow a target, or matching the target?
If you're having trouble making it track with the standard gimbal and two color tracking demo, try finding somewhere there is more light - opening the windows where we are made a huge difference. It also took a lot of tweaking of hsl values.


btw see you at the regional :)

-jonathan

We tried testing it with the full range of color available, yet for some reason the green doesn't show up at all. So far I have no clue why. And for some reason the servo's aren't moving while on gimble tracking mode, I assume they're supposed to and have no clue why.

And yes, see you there. :D

[s0crates]

We tried testing it with the full range of color available, yet for some reason the green doesn't show up at all. So far I have no clue why. And for some reason the servo's aren't moving while on gimble tracking mode, I assume they're supposed to and have no clue why.

And yes, see you there. :D

The way I did it when it absolutely failed to pick anything up was to start with the range 0-255 for all 3 (hue, saturation, and luminance) and narrow it down from there. Slow, but it works.

Did you put the jumpers next to the servo pwms? Are the pwms in the program the correct ones/where the servos are plugged in?

-jonathan

[Greg McKaskle]

If you aren't having any luck with the colors, you might try the NI Vision assistant. It is an easy way to bring in an image and check out the pixels in HSL. Ideally, you get in the habit of grabbing a couple photos in different orientations, different amounts of light, etc. Then you get a better feel for the range of HSL values needed to cover the different lighting.

Greg McKaskle

[Dr. Manhattan]

Did you put the jumpers next to the servo pwms? Are the pwms in the program the correct ones/where the servos are plugged in?

-jonathan

Yes, I know that the pwm's are correct because we have code to be able to control them with a joystick on the same pwm channels. I'm checking it out now and seeing if we can get it to work, but a lot of our focus is on the encoders at this point in time.

[mikeqfl]

We have our camera tracking ok. It commands a motor to turn a turret to keep the image in the center of its field of view. The problem we are having is the camera/turret is constantly oscillating back and forth trying to find the center. Any ideas of how to put in a PID loop into Labveiw? I am not up on the programming, just trying to help our programmer out.

[s0crates]

We have our camera tracking ok. It commands a motor to turn a turret to keep the image in the center of its field of view. The problem we are having is the camera/turret is constantly oscillating back and forth trying to find the center. Any ideas of how to put in a PID loop into Labveiw? I am not up on the programming, just trying to help our programmer out.

It sounds like it would be easiest for you to just have a dead zone in the center of the image - if the target is within a certain bounding box in the center of the image don't try to adjust it any further. Rather than try to center it at the center pixel, aim for a box around the center. It oscillates because the image changes slightly frame-to-frame.

[cooldude8181]

It took us a very long time to finally get it to the point that it worked, but we do have it working...

[Lord_Jeremy]

We ran into some pretty massive problems. No matter what we seemed to do, the camera would intermittently find a color (or two) for a few seconds, then x and y would immediately go to maximum. We assumed it was centering on the fluorescent lights in the room, but we're not entirely sure. And it was doing this both with our code and the TwoColorTrackingDemo code. I don't think the camera was at fault, as images grabbed from it looked just fine. We tried manually defining the color fields a couple times but that didn't help. Mind you we're using C/Windriver.

[jacobhurwitz]

We've spent a long time on our camera tracking code, and it finally works very well! (The night before our regional, too. Phew!) Our robot has a shooter, and we're using the camera to aim it at targets and then calculate how far it should fire. I'm pretty sure we'll post all our code on CD at the end of competition season, in case anybody's interested. We also have a pretty cool dashboard :)