Well, I have two thoughts...
If you can safely assume that there is some device that you should be able to reach (for example, your control PC), then this becomes a bit easier: you can implement a loop that tries to ping the control computer a few times, if it succeeds then great, if not then it's time to try a new network. You could do this with a script that:
- Using the
-c flag on the ping command, which will allow you to set a 'count' (so it doesn't ping infinitely). Point ping at something you should be able to reach. - Observing the exit value of the ping command: ping will exit with an error value if the device can't be reached.
- If you get an error value, try a new network. You can use something like
nmtui for this, and you may already have it installed on Ubuntu. - GOTO 1.
Then you wrap that functionality into a bash script, and write a systemctl service to launch that script when your system starts.
So that would work, but I personally don't love the idea of my robot being super dynamic when it comes to how I connect to it, and I don't love the fact that this is really a hardware problem that we're trying to work around with a software solution. The hardware problem here is that it's not possible to interface with the robot once it's sealed up for waterproofing.
To address this, you should consider adding a waterproof data port. You could do this by purchasing a waterproof cable assembly, and cutting a USB cable in half. You then solder that USB cable to either side of the waterproof connection, so you now have one side of a USB cable that can live inside your enclosure to plug into your on-board PC, and another side that can plug into a USB-to-ethernet adapter on your control PC. I would recommend using USB over ethernet only for ease-of-soldering purposes. This approach provides you with a port that you can always SSH over, even if the robot is not otherwise connected, which is always valuable.
