ros2_ouster_drivers: Don't use IP addresses in params file

I also go through very approachable instructions for setting up DHCP on IPs so I think that’s also very user friendly. I think this is a case that you prefer to work with the aliases, but I think new users via Ouster’s own instructions, my additional thread on them, and 2 production users’ experience makes a compelling argument not to change this. I’m making the judgement call not to change this unless Tom disagrees, but it sounds like we’re in agreement. I agree from your comments here that it should be explicitly documented, but documentation is not changing default behavior.

I added the set_udp_dest_auto firmware update feature in this ticket: https://github.com/SteveMacenski/ros2_ouster_drivers/issues/16. But just to set expectations, if this is something you value, I’d recommend implementing it. This is unlikely something that I will do. This will likely only be implemented in my next driver-updates-binge which given the status of my backlog is easily months away.

I think we can close this then - but follow up on the PR for the specifics in documentation we’re already doing over there. Ping if you want it reopened.

To give the appearance of a static IP address, what we do is hard wire the LiDAR(s) to the computer (i.e., no switches or anything in between the computer and the LiDAR … this is also for performance). Then for each physical ethernet interface on the computer, we bind a static IP address and make sure that each one is on a separate subnet – this also has the benefit of making the kernel routing table very easy to read and debug. Then for each subnetwork (i.e., a “dedicated channel” to a LiDAR) we allocate exactly one address in a DHCP pool (obviously, that address is different from the static IP bound to the interface on the host also participating on that subnet). Since the LiDAR is the only device (beside the computer) on the given subnet, it always gets the same address. This insulates us from any device specific configuration and scales nicely as now you map subnetworks to things like “top LiDAR”, “rear LiDAR”, etc. As stated earlier, the approach is also performant both from a network congestion standpoint and routing.