Camera Tracking Issues

[Hadi379]

During the Buckeye Regional, and prior to, we had vision tracking working with our robot. Everything worked when we were at home, on the practice field, tethered, and tethered during calibration time on the actual competition field Thursday.

Although, as soon as we went wireless on the competition field, our robot would just keep tracking, spinning in circles.

Our setup:

Axis 206 IP camera via ethernet to switch/radio
Switch/radio via ethernet to roborio

Camera Settings:
Image size 240x360
15 FPS
(currently, I believe compression is set to 0)
This should mean our data rate is approx 4.2 Mbps

Something tells me it has to do with the accessible ports on the competition field.


Any info would be greatly appreciated

[TylerS]

Would it be correct to assume the vision processing is done on the laptop?

If that's the case are you using networktables to communicate?

Are you receiving a camera image back to the DS?

If you can answer those questions it'll make diagnosing the issues a lot easier.

[Hadi379]

I believe the vision processing is done on the roborio.

Not using network tables.

And yes, we are getting the live feed on the DS.

[Josh Tatum]

We also had vision tracking issues at buckeye. Everything worksd fine in our shop, however, buckeye was much brighter than our shop. We fixed our issues by adding another led ring around our camera and using a combination of a Pepsi cup and the inside of a Tostitos bag to help reflect the light at the goal.

[AWoL]

How are you connected to your camera? If it's an IP camera or a USB camera connected to a coprocessor that you're connecting to with IP, make sure that everything (RIO, camera, coprocessor, heck, even driver station) has a static IP address. We had a similar problem during early matches last weekend but realized it was NetworkTables not working because of mDNS, and fixed it by setting everything to static IPs.

[Alan Anderson]

Originally Posted by Hadi379

I believe the vision processing is done on the roborio.

Not using network tables.

Nothing about the field's network port restrictions would interfere with that setup.

The only thing I can think of immediately is the way you're addressing the camera. The mDNS name of an Axis 206 includes its serial number by default; you would have to change it to just "axis-camera" in order for it to work properly both on the field and in the pit after your radio was reprogrammed for the competition. The other option is to set everything to static IP addresses -- roboRIO, camera, and Driver Station computer -- but that makes the field connection slightly less "friendly" to the rest of the system.

[Hadi379]

I believe we set everything to static at buckeye with the help of the CSA and FTA, but that didn't seem to work. I'll have to check the camera name, what if we changed to an axis 1013? Would that make any difference?

We are using labview, which I forgot to mention earlier.

In regards to the network ports, do you need to reference which ports you intend on using in the vision code?

[Alan Anderson]

Originally Posted by Hadi379

I'll have to check the camera name, what if we changed to an axis 1013? Would that make any difference?

The Axis 10xx cameras have the name "axis-camera" by default. That's what the vision code will be looking for, assuming you haven't changed it to an explicit static 10.TE.AM.11 address.

In regards to the network ports, do you need to reference which ports you intend on using in the vision code?

No, the IP camera support uses http: and always the same port.

[Hadi379]

In the attached image, should the camera open VI have the "axis-camera.local" or should it have the static IP of "10.3.79.11" as its constant?

The host name for the camera is just "axis-camera" in the camera settings.

[Hadi379]

And this is in our dashboard code:

[Hadi379]

bump, I'm desperate for ideas

[Gary Dillard]

We had issues on the competition field as well this weekend but nowhere else, but ours was the opposite problem. We were unable to recognize the cameras and couldn't track at all. We have 2 cameras and 2 pcduinos, all static ip addresses (10.team.......). Ran fine at home and tethered.

Still my biggest complaint about competitions - there is nowhere to test and debug your entire system except on the field while running a match. The radio is a HUGE part of the system. All the components work fine.

[Owen Busler]

Team 303 had a similar issue at buckeye. Our green led ring was not strong enough for the camera to distinguish between the green reflected light and the very very bright stadium lights. Our camera worked fine at our workshop because its much darker there. You can see how we fixed this here:

https://www.instagram.com/p/BDMOOHal...-by=frcteam303

We added a second ring and attempted to direct the green light and shield the camera from the ambient stadium lights with the reflective cup. You guys could try something like this but you really couldn't test it until your next event.

[Greg McKaskle]

Hadi. I don't have my computer with me, but it looks like you have both an ip/dashboard loop and a duplicate mjpeg background loop. I would have to make a similar edit to test what happens with competing access loops like this. You may want to try commenting the bg loop out.

It looks like you also made a db edit to use the constant name instead of the one from the DS. I don't think this would do any harm, but it is a difference

Honestly, I would want to look at the camera settings since I that is usually where the issue lies

Greg McKaskle

[Greg McKaskle]

Gary. How was communication routed? Specifically, starting from the cameras, where did images and info flow. To what devices on what ports? The biggest difference is that the field only has a few ports open for teams to use, and the timing of bootstrapping can be very different.

Greg McKaskle