Easy Initial Config of PhotonVision

[scarmain]

Is your feature request related to a problem? Please describe.
PhotonVision is somewhat difficult to get started the first boot on a Pi/clone, trying to connect with mDNS that doesn't always work. Could there be a way to make this easier for teams?

Ideas:

• Have a file in /boot/photonvision.txt that teams could set the static IP and team number of PhotonVision for initial setup. Being in /boot/ means it's accessible on Windows for setup, as that is a FAT32 filesystem.
• When PhotonVision boots, if the IP is in the 10.TE.AM.xx format, could NetworkTables auto set the team number based on that IP.
• Use /boot/cmdline.txt to set the ip=xx for initial setup. See https://elinux.org/RPi_cmdline.txt

Describe the solution you'd like
See above

Describe alternatives you've considered
See above

Additional context
See above

[mcm001]

Mdns can be flakey but it's usually pretty solid for me if I've got a radio in my network and I don't just plug my pi straight into my computer. What situations did you have trouble with mdns in, out of curiosity?

[scarmain]

It's actually testing outside a robot that is harder. Like if I put a Pi on a table, plug the ethernet into a router, it's hard to find it on a network, especially if it's a 9-10th grader who barely knows how to program, much less network management in Linux...

[Alextopher]

I agree it should be easier to use PV without a robot.

I like the static IP suggestion by configuring something in /boot. It helps in situations where there isn't a DHCP server available or if mDNS isn't working on a network.

Should we pursue this? Are there any conflicting requirements that means we shouldn't implement this?

[mcm001]

Scope creep/additional complexity with how this would interact with the current configuration management system is my primary concern.

Maybe we could only pull this static IP when starting photon for the first time? Or we could investigate a static fallback IP for the Ethernet interface instead?

[mcm001]

Yeah I think we should instead configure a fallback static IP address that's common across all our images? That would require users configure their netmask and stuff appropriately still though....

[Alextopher]

I like that. @scarmain what do you think? Would connecting to the pi via ethernet & setting parameters in networking settings be easy enough?

[mcm001]

I still feel like asking users to configure a static ip or trusting link local fallback to actually work is a bit spooky, but it might be worth a shot?

[scarmain]

I guess, I don't exactly know what I'm asking for... These are the scenarios I see:

1. User plugs into robot. A static IP like 10.99.99.99 would work great for initial setup, but it's usually not super hard to find a Pi when the mDNS works right in the robot setup, as the Driver Station installs an mDNS client (I believe from NI).
2. User plugs into wired network with router. On a home network, the 10.x IP won't work for probably 90% of networks, as most home routers work on 192.168.x.x. On most school style networks, 10.x IPs probably work better, but I'm guessing some schools have network intrusion detection that might not get the benefits.
3. User plugs ethernet directly from Pi to PC, link local happens, and not sure that setting a static IP helps there. Not sure how big of an IP range you get in those networks.
4. (not practical) The Pi starts as a wi-fi hotspot, and you can do initial config that way. This is how some devices like ChromeCasts and their Home lineup work (And I think the XRP too). Then after you do initial setup, turn off the hotspot. I understand not bothering with this option, as FRC bans all wireless communications, and you don't want to deal with the hassle of turning it off.

And then we have to remind them to turn off the static IP configuration they used in initial configuration.

With all those use cases, I don't see a simple solution honestly. Maybe the current option is the best option.

[Alextopher]

So the biggest thing is setting a static IP is not enough for most networks. You need the static ip and the netmask. Also randomly guessing a 10.0.0.0/8 and hoping it's routable in a school is unlikely.

I've never had any issues finding PV on a robot network. My primary concerns are link-local and typical LANs.

I like whatever can give link-local support.