JamesNewton
commented
6 years ago A partial (hack) solution is to set a fixed IP which is always up, in addition to the DHCP address. After SSHing into Dexter:
nano /etc/dhcp/dhclient.conf
and comment IN the alias section, then edit it to pick a static address that won't cause issues on your network. e.g. the fixed ip for the robot. I used one on my 192.168.0 network, but you should be able to use any local network address that isn't the same as your PC or anything else on your network (because it will also be active when connected to your local router). If you pick an address that is in the DHCP range, or otherwise could be assigned to another device on the network, you won't be able to talk to either device reliably. This is the major limitation of this solution.
alias { interface "eth0"; fixed-address 192.168.0.138; option subnet-mask 255.255.255.255; }
I also set a faster timeout and retry, but that shouldn't be necessary.
timeout 5; retry 60;
And now, that will NOT work... because there is a service that messes it up: https://linux.die.net/man/8/avahi-autoipd by overriding DHCP when it fails and assigning it's own "adhoc" ip address in the 169.254.1. net. Mine always came up on .141 but I don't know if that is consistent (couldn't find a way to control it) then you have to reconfigure your PC and even then I couldn't get it to actually communicate on that address.
So you want to disable the avahi daemon for this to work... but you can't. I tried everything to "neatly" turn it off and it would come back on no matter what. So... I went a bit nuclear on it:
apt-get remove avahi-daemon
now, that also removes:
Removing avahi-utils ...
Removing telepathy-salut ...
Removing libnss-mdns ...I don't think we will be doing anything with telephony services (which is what telepathy-salut provides) and the libnss-mdns service is the one that lets you find the device on the .local network. shrug I've never used that.
Now when you start the bot, it takes a minute or two, and then then fixed address will come up and start working. Yeah!
AndrewSmart
When Dexters had a fixed ip address, you could just connect a CAT5 cable between the PC and Dexter and it would work. And yes, that is perfectly valid electrically... Ethernet signaling is specifically setup to work in that configuration, so that when only two devices need to be interconnected, no hub or router or anything else is really needed.
Now, there were problems if you enabled your WiFi and it went up on a different subnet, but that was fixable by changing Dexters IP. E.g. if your WiFi local addresses were 192.168.0 and Dexter was set to 192.168.1.142 then it would not work. But you could disconnect from WiFi, set your PC to a fixed 192.168.1.141 address, SSH into Dexter and change it's IP address to 192.168.0.142, then release your PC's static IP and sign back into WiFi. Your PC to the internet via WiFi, Dexter to your PC via CAT5.
When Dexter's firmware was changed to use DHCP, it was MUCH better for use on a real network, but that requires that we have a router with DHCP for Dexter and the PC to connect into. Carrying the extra router is a pain when doing demos, and it is often the case that users don't have CAT5 connections available to their local routers, relying instead of WiFi for all connections; which Dexter can't support at this time, and isn't really desirable anyway for a security on a robot.
It would be nice to have Dexter start in DHCP, and then if that isn't found, fall back to a static IP.