Camera Tracking Issues
 

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

Re: Camera Tracking Issues
 

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.

Re: Camera Tracking Issues
 

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.

Re: Camera Tracking Issues
 

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.

Re: Camera Tracking Issues
 

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.

Re: Camera Tracking Issues
 

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.

Re: Camera Tracking Issues
 

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?

Re: Camera Tracking Issues
 

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.

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

Re: Camera Tracking Issues
 

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.

Re: Camera Tracking Issues
 

And this is in our dashboard code:

Re: Camera Tracking Issues
 

bump, I'm desperate for ideas

Re: Camera Tracking Issues
 

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.

Re: Camera Tracking Issues
 

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.

Re: Camera Tracking Issues
 

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

Re: Camera Tracking Issues
 

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

Re: Camera Tracking Issues
 

Thanks Greg, let me get more details from my software and controls guys - I'm the mechanical guy, just listening to what they were telling me.

Re: Camera Tracking Issues
 

Greg,

Would those items you pointed out still allow tracking to work tethered, on the practice field, and at home?

Those images are recent changes, I apologize, but the only changes weve made were the db constant and when we were at buckeye, the camera open was labeled with the ip "10.3.79.11" instead of "axis-camera.local" the entire competition. Could that have been the problem?

Re: Camera Tracking Issues
 

Now that I'm back at my computer, the MJPEG Loop VI is redundant, but it is not related to sending images to the dashboard. It was once used to keep up with a camera that was streaming MJPGs at a rate faster than your roboRIO was reading them. Without this loop, the images would buffer and there would be lag in the camera processing. The MJPEG Loop is no longer in the palette because its functionality is now built into the other IP and Dash VI. So it is unnecessary, but it sounds like the affect it causes was what was causing you issues.

So the issue you were having was probably caused by the IP address. The next thing I'd look at is the camera settings. If the camera is getting its IP via DHCP, then hard coding the IP in the code is gonna work sometimes, but it is very brittle. It is trying to predict the number given out by your DHCP server and would break as soon as the devices get IPs in a different order or the DHCP server changes.

Greg McKaskle

Re: Camera Tracking Issues
 

Greg. I work with Gary. We use 2 USB cameras each connected to a pcDuino as the image processing server. The pcDuino's IP addresses are static (10.29.73.50 & 51) and are connected to the radio via an Ethernet hub. I noticed during last weeks regional that we would get communication in our pit by setting the DS's subnet mask to 255.255.255.0 but not with the recommended 255.0.0.0. With either subnet mask we did not get communication on the field while using the FMS's network. One thing that we didn't try is setting the client viewers IP addresses to a static IP (10.29.73.xx), but in order to do so we will have to give up one of the cameras. It is currently set to read all incoming headers (10.29.73.275). The servers are sending compressed buffers via UDP. Also the processing algorithms are set to automatically run on boot-up, but it does delay 20-30 seconds.

I read today that the limit for static IP's are "Other devices - Static 10.TE.AM.6-.10 or .12-.19 (.11 if camera not present) subnet 255.255.255.0."

Could this be part of the issue?

Re: Camera Tracking Issues
 

Greg,
I believe I know the answer to this question, but I just want to be 100% on it.

If a team is using off board processor on the robot, say an RPi, can it send it's tracking data to the RoboRio via UDP on almost any port? Let say we use 2073 for the sake of argument. The data never leaves the robot nor crosses the WiFi connection or passes through the field network. Would this be an problem?

Re: Camera Tracking Issues
 

Bilbo. The UDP data is going through the switch of the Open Mesh, correct? So as long as nothing is filtered or modified by port, it should work fine. I don't have details on how the radio is configured, but I assume all port filters are at the wifi AP and not in the bridge/switch. I'll look into it and let you know if my assumptions are wrong.

Greg McKaskle

Re: Camera Tracking Issues
 

In our configuration, there is a switch on board the robot, so the data never passes through the radio.
My understanding is that the QOS takes place on the radio, but I have no clue if that is for WiFi traffic only,or both WiFi and LAN.
So, I'm looking forward to hear what you find out.

Re: Camera Tracking Issues
 

I'm still trying to understand the way traffic is intended to flow. You have a USB camera connected to a pcDUINO at a fixed IP. I agree that your IPs are within the range of what the DHCP server is handing out and should be moved, but unless you have lots of other somthingDuinos, you probably didn't have a collision. Then the traffic is sent using UDP -- on what port to what devices?

If you could document the rest of the IP addresses and port/types used, it may explain the problem.

Also, when you say it delays 20-30 seconds, is that a fixed delay, or a period where it loops and retries? I'm not sure exactly what you mean. What happens if the field takes longer that 30 to allow a connection?

Greg McKaskle