Axis camera IP changes during the game

[ROULT]

We have configured the axis camera according to the instructions in WPILib 2016.

At the beginning of matches, the camera has effectively an IP corresponding to our team's number (10.44.3.5) but at the half of the game, it changes to something like 192.168...

Has anybody faced the same issue or knows how to solve it?

Thanks in advance for your help and time.

[TylerS]

Are you using DHCP to assign the axis camera IP or is it static? I recommend going static and retesting to see if that resolves the issue.

[kiettyyyy]

There's a setting in there that has it fall back to a 192.168 IP by default if it can't acquire or loses its DHCP assignment.

You can turn that off. Make it either DHCP only or Static IP only.

[mhaeberli]

When making it static only, should one specify a router (like 10.30.45.1, or 10.30.45.129)?
Thanks,
Martin Haeberli
(de-)mentor, FRC 3045 Gear Gremlins (formerly SWAT)

[kiettyyyy]

I've had good luck of setting it to 10.xx.yy.250 on actual fields at events I've CSA'd at.

Static IPs are the last resort. We're typically able to get them all fixed up while using mDNS and DNS.

[Mark McLeod]

The field DHCP serves addresses in the .20 to .199 range if I remember correctly.
So static addresses for cameras or other IP devices can use .10 to .19 safely.

[mhaeberli]

The Axis camera setup page:

http://wpilib.screenstepslive.com/s/4485/m/24194/l/144985-configuring-an-axis-camera

for the 2016 control system says you can use the range .3 to .19 safely for fixed IP addresses.

The field DHCP serves addresses in the .20 to .199 range if I remember correctly.
So static addresses for cameras or other IP devices can use .10 to .19 safely.

Martin Haeberli
(de-)mentor, FRC 3045 Gear Gremlins (formerly SWAT)

[Mark McLeod]

By FRC convention static IP addresses use .1 for the radio, .2 for the roboRIO, .4 for an AP to work with the robot radio as bridge, .5 for the DS laptop Ethernet port, .6 for a separate programming PC, .9 for at home DS wireless port, .11 for the first IP camera.

staying somewhat with the conventions makes it easier for others to help you debug, but that's all.

[BenjaminWard]

I want to point out that your Axis *should* always be available at axis-camera.local. It uses a similar mDNS setup as the robot, so anyone who has the driver station or any other mDNS software (Bonjour through ITunes, etc) will see the camera there.

[Poseidon5817]

I want to point out that your Axis *should* always be available at axis-camera.local. It uses a similar mDNS setup as the robot, so anyone who has the driver station or any other mDNS software (Bonjour through ITunes, etc) will see the camera there.

This is what worked for us. Prior to us figuring this out (but after our IP address that we used in the shop stopped working) we would scan the IP range before every match, find the camera, and enter it in the camera feed. This worked, although it was just another annoying thing on our already huge list of annoying things to do to set up for a match.

[hardcopi]

Ours didn't work the entire first day. The FTA's tried to get it working but it needed a static ip and we had to set up the windows host file to force axis-camera.local to 10.29.59.11 (our camera's static ip). Just wouldn't be seen on the dashboard until we forced windows to see it. Mdns just wasn't cutting it.

[Chris Hibner]

[minor rant]

It's very unfortunate that using static IPs is has become obfuscated. It pretty much cost us the first 3/4 of our first event as I stupidly believed that static IPs wouldn't work and/or were against the rules. It would be nice if the documentation was explicit, or at least it said somewhere that it is okay to do it if you follow these guidelines.

[/minor rant]


[important part]

After I read on chiefdelphi.com that people were using static IDs and it was indeed allowed, I then looked for what IDs we could use. That wasn't easy to find. When I finally found what I was looking for, it is stupidly simple. So here it goes:

1) Find the documentation for the FRC control system from 2014 (or earlier). 2) Set the IPs as described. 3) Profit

[sub minor rant]What bothered me is that they could have just said "you can continue to use the same static IP ranges from past years".[/sub minor rant]

For those without past years' documentation, here it is:

Set roboRIO to 10.xx.yy.2
Set driver station to 10.xx.yy.5
Set camera 1 to 10.xx.yy.11
Set camera 2 to 10.xx.yy.12

(where xx.yy is your team number, so 2112's roboRIO would be 10.21.12.2 and team 51's would be 10.00.51.2).

[RufflesRidge]

for the 2016 control system says you can use the range .3 to .19 safely for fixed IP addresses.


It's wrong (slightly). You should not use .4.

This is the address of something on the field (router, AP interface, etc.) that is set as the gateway for the roboRIO as part of the DHCP address served by the field (you can see this if you USB tether to the robot and pull up the web interface without turning the robot off after a match.

[Joe Ross]

[minor rant]

It's very unfortunate that using static IPs is has become obfuscated. It pretty much cost us the first 3/4 of our first event as I stupidly believed that static IPs wouldn't work and/or were against the rules. It would be nice if the documentation was explicit, or at least it said somewhere that it is okay to do it if you follow these guidelines.

[/minor rant]

It's documented in this years documentation. http://wpilib.screenstepslive.com/s/4485/m/24193/l/319135-ip-networking-at-the-event


For those without past years' documentation, here it is:

Set roboRIO to 10.xx.yy.2
Set driver station to 10.xx.yy.5
Set camera 1 to 10.xx.yy.11
Set camera 2 to 10.xx.yy.12

(where xx.yy is your team number, so 2112's roboRIO would be 10.21.12.2 and team 51's would be 10.00.51.2).

As documented at the link above, the driver station netmask must be 255.0.0.0 or else it won't connect to FMS.

[tr6scott]

Another observation from this, and also having major pain in the a$$ with mdns in our setup, still to be "working" but no root cause of why Aaron spent two hours in our pit on Thursday at Waterford.. I feel for you Chris.

Please note that once your radio is programmed at the event, the DHCP server is turn off on your robot radio. The field is the only DHCP server while at the event.

So when you are in your pit, and testing there is no DHCP server to hand out IP addresses, so everything kind of defaults back to the 169. address space. For others this seems to work... For us, not so much...

When we were in the pit at Waterford, I used an old dlink configured to our home settings, when I needed to test and program. (which was all the time)


Thanks for the info on the static IP's

[mwtidd]

It's documented in this years documentation. http://wpilib.screenstepslive.com/s/4485/m/24193/l/319135-ip-networking-at-the-event



As documented at the link above, the driver station netmask must be 255.0.0.0 or else it won't connect to FMS.

Another important thing to note is that if you specify a the default gateways as 10.TE.AM.1 it appears that all traffic goes to the fms. This caused for significant delays to be introduced only when we connected to the field as data was being passed from the Rio to the FMS, then from the FMS to the Kangaroo, then from the Kangaroo to the FMS, and finally from the FMS to the Rio. In reality it was probably also going through the Driver Station as the FMS does not connect directly to the robot, but short of doing a traceroute I couldn't tell you definitively.

In reality this traffic should have been able to stay local and should not have been subject to the bandwidth limitations the FMS imposes.

In windows you can leave that gateway empty and be all right. On the rio, it can be configured via the web dashboard and should probably be set to 0.0.0.0 as suggested by the images in the screensteps document you listed.

[Chris Hibner]

It's documented in this years documentation. http://wpilib.screenstepslive.com/s/4485/m/24193/l/319135-ip-networking-at-the-event

Thanks for the info, but this shows a flaw in this year's documentation. For some reason I was never able to find that. When I go to the control system page, the only link I get is http://wpilib.screenstepslive.com/s/4485/m/13503/l/242608-roborio-networking, which makes no mention of static IPs, nor does it provide a link to the page that you linked. The only options listed on this page is the mDNS option.

[mhaeberli]

Scott,

we had our own problems (added a second camera, but had trouble seeing it on the field).
But as to the Field radio configuration, our own ad-hoc solution was to have two new radios, one for "Field" configuration, one configured for use just as back home for "Pit / Build". We would just switch out the radio in the pit (and use the same test radio on the practice field).

Thanks,
Martin Haeberli
(de-)mentor, FRC 3045 Gear Gremlins (formerly SWAT).
----
Another observation from this, and also having major pain in the a$$ with mdns in our setup, still to be "working" but no root cause of why Aaron spent two hours in our pit on Thursday at Waterford.. I feel for you Chris.

Please note that once your radio is programmed at the event, the DHCP server is turn off on your robot radio. The field is the only DHCP server while at the event.

So when you are in your pit, and testing there is no DHCP server to hand out IP addresses, so everything kind of defaults back to the 169. address space. For others this seems to work... For us, not so much...

When we were in the pit at Waterford, I used an old dlink configured to our home settings, when I needed to test and program. (which was all the time)


Thanks for the info on the static IP's

[Mark McLeod]

Please don't use wireless on a second radio at an event.
It is against the rules and has the potential to cause quite a significant problem for the field staff.

There are field provided radios available for use on the practice field. Just ask the FTA.


T2 Wireless ROBOT control is only permitted on the FIELD or Practice Field. ROBOTS must be operated by tether when outside the FIELD or Practice Field.



T3 If operating wirelessly on the Practice Field, ROBOTS must use the provided Practice Field radio for communication.

[Fletch1373]

But as to the Field radio configuration, our own ad-hoc solution was to have two new radios, one for "Field" configuration, one configured for use just as back home for "Pit / Build". We would just switch out the radio in the pit (and use the same test radio on the practice field).


Parroting what Mark said. PLEASE don't do this. None of us (CSAs, FTA[A]s, Robot Inspectors, etc.) like having to track down rogue wireless access points at events, but we will if we see them. It's against the rules(Mark quoted them already) and has potential to disrupt the game in one form or another.

And no, simply refusing to broadcast the SSID does NOT mean we can't find it ;)

[ATannahill]

Thanks for the info, but this shows a flaw in this year's documentation. For some reason I was never able to find that. When I go to the control system page, the only link I get is http://wpilib.screenstepslive.com/s/4485/m/13503/l/242608-roborio-networking, which makes no mention of static IPs, nor does it provide a link to the page that you linked. The only options listed on this page is the mDNS option.
What did you search? I went to http://wpilib.screenstepslive.com/s/4485 and searched for "static IP" and the first result gave me the necessary information.

What would make this information easier for you to find?

[mhaeberli]

I'm sorry - I won't let it happen again.

That said, at our event (Madera / Central Valley Regional), there did not appear to be any WiFi access available for robot control on the practice field.

Thanks,

Martin Haeberli
(de-)mentor, FRC 3045 Gear Gremlins (formerly SWAT)
----
Parroting what Mark said. PLEASE don't do this. None of us (CSAs, FTA[A]s, Robot Inspectors, etc.) like having to track down rogue wireless access points at events, but we will if we see them. It's against the rules(Mark quoted them already) and has potential to disrupt the game in one form or another.

And no, simply refusing to broadcast the SSID does NOT mean we can't find it ;)

[Fletch1373]

I'm sorry - I won't let it happen again.

That said, at our event (Madera / Central Valley Regional), there did not appear to be any WiFi access available for robot control on the practice field.

Thanks,

Martin Haeberli
(de-)mentor, FRC 3045 Gear Gremlins (formerly SWAT)
----

That's not uncommon at events. The fields do ship with radios for the practice field, but many events don't pull them out/set them up. This is sometimes due to venue restrictions(i.e. no power available near the practice field). If you absolutely cannot test while tethered, you can ask the FTA about having the practice field radios set up, an he/she will either do so or explain why they can't. If you need a long ethernet cable to tether, you can try talking to other teams.

[Chris Hibner]

What did you search? I went to http://wpilib.screenstepslive.com/s/4485 and searched for "static IP" and the first result gave me the necessary information.

I didn't search. In my world of systems engineering words like "will" and "shall" are requirements. The document that I linked to has "will"s spread throughout it, and in my ingrained mind I viewed those as requirements on the system. Why would I search when the requirements were so clear?


What would make this information easier for you to find?

Was this sarcastic?

The answer is pretty simple. Put a link to it on the roboRIO networking page, along with some words along the lines of "Static IPs are also acceptable for more information see (insert link here)." I would think that all things roboRIO networking should be in or linked from the page named "roboRIO Networking". That's documentation 101.

[ATannahill]

Was this sarcastic?

Not at all. I will admit there is plenty of documentation in FRC that is hard to find and many people do not know about. I have met teams that did not know about screensteps. It is a big problem that I don't know how to solve. I have reviewed the screensteps each year and I have sent in suggestions about improvements in the past. If you have an idea of how to make the system better please post it or send it to FIRST. You can send your suggestion about the static IP documentation using the report error (I know error might be a bit of an exaggeration) at the bottom of the page.

[Chris Hibner]

I just saw the page update (http://wpilib.screenstepslive.com/s/4485/m/13503/l/242608-roborio-networking) - thanks for that - you guys rock!

The interesting thing about today's back-and-forth between Alex and I perhaps shows a bit of a generational difference (I hate to admit it, but I'm getting old). I have a related story here...

At my position at work I'm responsible for a large software package similar to the FRC control system*. I'm also responsible for all of the support that goes along with it. We recently decided to help improve our support position (actually improve our overall position by being able to spend more time developing software via reducing the amount of time we have to spend on support) by studying our support requests and upgrading our base documentation and creating an interactive help website.

When creating the new website I was all about the linking. One of the young guys in the group told me, "who cares, I just immediately go to the search feature." I initially wrote that off as two different styles of doing things.

After getting feedback on the site from many people, I finally noticed the trend that the old guys were all about having good links while the young guys were all about the search feature. I have some theories as to why that is, but I guess the important lesson was that different people approach things in different ways. This shouldn't have been a surprise to me - I recently wrote a long post on the important of diversity on a development team for this very reason. If you don't have people on your team to expose the different ways of thinking about problems, you're unlikely to uncover all of the use cases for your product (please don't read anything into that statement regarding the developers of the FRC docs - I just wanted to bring up a real-world example to support my earlier post in the other thread).

Anyway, thanks for listening. You guys have a great future ahead of you. Especially after putting up with an old crotchety guy like me.

* http://pi-innovo.com/product/