-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finding Dexters IP address #71
Comments
Given an audio output #72 , and a TTS engine as described there, it should be possible to speak Dexters ip address when it changes via e.g. This seems simple: However, that doesn't seem to actually work. E.g. when you connect or disconnect the WiFi, the script is not fired. |
WARNING: Be very careful about adding any attempt to speak or play any sound to a script that needs to run on startup. If you don't have a sound card plugged in, that will generate an error, and the error may make the script file. E.g. adding those commands to speak the IP address to RunDexRun then unplugging the adapter will cause the robot to fail to start the DexRun firmware, etc... This issue can be avoided by using a bash script called that checks to verify the audio device is connected.
You might call that file 'say' and don't forget to |
#83 Bonjour may be a useful tool in Windows 10 and MACs. |
I don't know your ubuntu version but you could add a service to start AFTER:network https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6 |
Dexters ship with a pair of fixed IP addresses: 192.168.0.142 and 192.168.1.142. DHCP is disabled, on the CAT 5 adapter. This is probably best for direct connection to a PC, because then you can setup the PC CAT5 for one of those subnets, and always find Dexter. However, if you need multiple Dexters on a network, or want it accessible from multiple machines, then the network setup will have to be changed to move to DHCP.
If a WiFI adapter is plugged into the USB connector under the CAT5 (well... it will melt, but if you plug in a USB A to A extension, and THEN plug in a WiFi adapter) and configure your routers SSID and password, it will be assigned an IP via DHCP.
Once the IP has been assigned via DHCP, the address of Dexter is effectively unknown. So how can we find Dexters IP address(es)?
Display. If Dexter had a screen, it could show the IP address. New tool interface / end effectors #24 documents work on a new end effector that would include a "tinyscreen". USB Interface? #44 documents the possible use of the console, microUSB connector on the MicroZed board with a PC or tablet (or even cell phone) to provide a powerful local user interface (
hostname -I
shows IP addresses). An actual display adapter would be even nicer.Boot dance. The robot currently attempts to "dance" out it's IP address on startup via moving joint 4/5. This is hard to catch and only shows one IP.
MAC address / ARP. Address Resolution Protocol maps MAC addresses to IP address. Since Dexters CAT5 adapter is implemented in the FGPA, it does NOT have a "unique" assigned MAC address like most ethernet devices. This causes problems when multiple Dexters are on the same net, so the latest RunDexRun file looks for a robot serial number in the Defaults.make_ins file and updates the hwaddress line in the /etc/network/interfaces file with that value. After a restart, the MAC address will have been generated via the serial number and is far more likely to be unique. It uses the Xilinx mfgr code at the start of the MAC to avoid possible collisions with other mfgrs devices, as is recommended by Xilinx. As a result, any device with Xilinx mfg code on the net is likely to be a Dexter.
In windows, at the command prompt, this will show you matching entries in the list of devices known to that PC:
arp -a | find "00-5d-03"
This assumes the Dexter has communicated once to the PC, and may not be present until after that communication has happened, which probably makes it less than totally useful except when directly connected: At that point, the PC is sure to see Dexters first connection and call for an IP address.
Of these the first seems best. A display / local user interface is useful on it's own.
The text was updated successfully, but these errors were encountered: