Axis Camera Issues
 

Last year, our team used the Axis Camera M1013 and it worked for us just fine. We're trying to get it working again to put on our robot at competition. I tried using the 2014 FRC Axis Camera Tool to configure our camera, but to no avail.

I realize that procedures may have changed for this year's competition, and since I'm not that familiar with how cameras work, could anyone point me to a guide on how to get an axis camera up and running for the 2015 competition?

Re: Axis Camera Issues
 

If you are using a static IP on the camera (2014 configuration) The camera will be on the wrong subnet in the pit.

Go to WPI screens steps IP networking at the event.

I would suggest the static IP for everything as the easiest work around.

Re: Axis Camera Issues
 

These are the instructions for using the camera at an event, and though we are planning to use the camera there, is there anything different I need to do to get the camera working at home? I'm trying to get it going at our facility to make sure our camera is still working before competition.

Re: Axis Camera Issues
 

The roboRIO, by default, uses mDNS to come up with fake DNS names that work without knowing any IP addresses. This is not compatible with Axis camera.

So, you have to use the static workaround listed in the link. This is the way things were setup last year.

Once the DriverStation and camera are on the same 10.TE.AM.x network, then they will communicate.

You can have the radio serve DHCP addresses out of the 10.TE.AM.x pool, so that you don't have to manually set the IP address on the DriverStation.

Re: Axis Camera Issues
 

The Axis cameras should work in both scenarios if you set it to DHCP in the basic TCP settings, and in the advanced TCP settings set the host name to axis-camera. It seems that you typically have to power cycle the camera after making this change.

We considered using the service name and mDNS to find the camera independent of its host name, but we ran out of time getting the mDNS libs on the roboRIO and decided to go for a fixed host name. You can, of course choose static IPs if you wish, but it is not what I'd recommend.

Greg McKaskle

Re: Axis Camera Issues
 

Does that mean that the DriverStation will display the feed from "axis-camera" without any additional fiddling?

(I don't have LabVIEW with me at the moment to look.)

Brad

Re: Axis Camera Issues
 

The dashboard will. The driver station app is the small one on the bottom. This will occur when the driver station gives the dashboard the address of the camera as specified in the Vision code on the robot. If you don't want it to be specified that way, modify the dashboard to use a fixed camera address.

Greg McKaskle

Re: Axis Camera Issues
 

Static ip for everything is the simplest way, on the field its still a static ip, tether to it...still a static ip. My team have used this at the competition and we are pretty successful with that atleast.

Re: Axis Camera Issues
 

I stand by the recommendations in the documentation. DHCP and mDNS simplify things considerably, in everyday life and in FRC. We made sure that all static would still work as a fallback.

Greg McKaskle

Re: Axis Camera Issues
 

Yes they do, however if you want to write your own vision program, or desktop program, its a lot harder to interface with a dchp then it is with a static ip.

Re: Axis Camera Issues
 

We've been using the static IP for everything approach and have had no troubles with it at all, after having performed the initial setup to get the roborio, axis camera, bridge, router, and driver station on static IP addresses.

My personal feeling is that although the static IP addresses take a little more effort to get set up initially, they will continue to "just work" after the initial setup.

Re: Axis Camera Issues
 

DHCP manages a menial task of assigning and tracking a numeric IP address that are routable. DNS and mDNS let you name the IP and reference it using the name.

If you are writing code using IP addresses, then DHCP complicates matters. If you write code where the addresses are meaningful address names, then the code is more readable, more portable, less brittle, and DHCP really doesn't help or hurt. Used together, and you have a more modern, in my opinion, a more convenient and flexible system.

I also expect things to further improve. Not everything was able to get done in one year. The Axis camera didn't get renamed by the imaging tool this year, which added a manual step, complicating matters a bit. We also didn't have mDNS service lookup to find all Axis cameras. Once either one of these is in place, IP cameras will be smoother.

You may use static IPs, but I do not miss having to dig into the Windows control panel to modify my IP several times a day in order to get on the internet or connect to the robot/camera. Scripts for connecting to the networks are slightly better, but still nowhere as convenient as using Bonjour or mDNS, and letting my computer do the menial tasks.

The problems I'm generally seeing is when teams have a mix of static and dynamic IPs. I've seen many instances where instead of setting the host name, a well-intentioned team sets the Axis camera to a static IP. This doesn't fix the problem, and in fact, complicates it further.

Greg McKaskle

Re: Axis Camera Issues
 

The issue is, at competition, there is no DHCP when you are not connected to the field. IE tethered. You are relying on the fallback IPs to all be in the same subnet. If you use a mix of static & DHCps, chances are you will be missing something when the DHCP is not there or the DHCP is assigning addresses in a different subnet that the static IPs

Other than that, largely what Greg said.

Re: Axis Camera Issues
 

Our team did indeed run into troubles using the AxisCamera class (and the smartdashboard) via C++ and using static IP for the camera 10.xx.yy.11

We did not have any troubles in our lab and testing until we were at competition.

We researched it, and one of my programmers (Gillian) was kind enough to post our experience and our 'how to' on setting up the camera, testing it, and the exact naming that's necessary (in some cases appending .local and in others not appending it) to make things work in a mDNS environment.

FYI - we did NOT modify anything about our RoboRIO in order to get mDNS working just fine. No extra libs etc.

Here's the thread - http://www.chiefdelphi.com/forums/sh...d.php?t=136170