Camera Tracking Issues

[Gary Dillard]

Originally Posted by 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

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.

[Hadi379]

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?

[Greg McKaskle]

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

[Victor Tapia]

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?

[billbo911]

Originally Posted by Greg McKaskle

... 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

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?

[Greg McKaskle]

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

[billbo911]

Originally Posted by Greg McKaskle

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

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.

[Greg McKaskle]

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)

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