I am trying to use my robots in class again this year. This did not work so well last year, but we have a new IT staff and I am more optimistic that we might solve this.
I have five GoPiGo 2s. My students are trying to connect to them with Surface Pro 4 computers running Windows 10 EDU. Last year our network was set to actively scramble the signal from rogue WiFis which shut me down. This has been resolved.
Currently our student computers can connect to a robot’s WiFi, however, they cannot acquire an IP address from the robot as is evidenced by seeing a 169 IP address when doing ipconfig from the command line. My personal MacBook Pro and work Surface Book (also Win 10 EDU) do not have this problem and get an address like 10.10.10.xx.
Have you seen this before? If so, how do we fix it?
Also, I noticed that there’s a new version of the Dexter OS. I downloaded it and tried to run it on one of my GPG2s but the unit won’t boot. What is the latest version of the OS these units can run? Can I download that somewhere to get this one guy back up and running?
I think APIPA may be interfering with the IP address you should be getting instead. That’s the automatic private IP addressing. I would disable it and see if the problem still persists.
Here’s a quote from Microsoft’s support page:
Click Start, click Run, type “cmd” (without the quotation marks), and then click OK to open a MS-DOS command line window. Type “ipconfig /all” (without the quotation marks), and then hit the ENTER key. If the ‘Autoconfiguration Enabled’ line says “Yes”, and the ‘Autoconfiguration IP Address’ is 169.254.x.y (where x.y is the client’s unique identifier), then the computer is using APIPA. If the ‘Autoconfiguration Enabled’ line says “No”, then the computer is not currently using APIPA.
Thank you for getting back with me. I forwarded your email to a colleague of mine here who is going to test turning off APIPA. I’ve been teaching since I saw your email and haven’t had a chance to hear if this worked. Will let you know.
DexterOS 2.3.0 does support the GoPiGo2. I wonder what went wrong there?
On the other hand, if APIPA is the guilty party, moving to the latest version won’t help you.
Downloaded a fresh copy of 2.3 and tried again. Robot boots up and stays up, but light on top letting you know the robot is ready to go does not come on and it never shows up in the list of WiFi networks.
Coming back around to this thread. Trying to sort through several issues.
Looking at APIPA first, we have turned it off on a Surface we are testing with. Still can’t log into the robot.
Have some iPads as backup units to connect with the robots. iPads cannot reach mygopigo.com with connected with a robot either. They, too, have a 169 IP address.
This makes me wonder if there is a firewall setting we are overlooking or if something is not working right on the robot.
Getting to DexterOS 2.3, I cannot get a robot to boot to that version. Tried several robots. Tried several SD cards. Have downloaded the software three times. When I go back to Dexter OS 1.3.1 all is good.
We’re aware of an issue (and totally puzzled by it) where 2.3.0 doesn’t like the GoPiGo2 although there’s no reason for it. We’re still looking into this one.
Instead of attempting to reach mygopigo.com, can you reach 10.10.10.10 instead? It bypasses potential issues with name resolvers.
Tested this today when I had time. IF going to mygopigo.com does not trying 10.10.10.10 does not work either. Tested this with a couple or Surfaces, a couple of iPads, and one old Gateway running Win 7.
My personal MacBook Pro works flawlessly with the robots.
My school assigned Surface Book wunning Windows 10 EDU works flawlessly with the robots. APIPA is on but it can connect, ping, etc.
My Surface Pro 3 that I use to run a 3D printer has APIPA off. It will connect but not communicate. Pinging does not work.
Its hot or miss, but those student Surface Pro 4s that will not communicate with a robot behave like the SP3 above. A minority of others will work. Haven’t figured out the pattern as to why yet.
This might be an idea, but do you think you can set the IP address manually for one Surface Book that’s acting bad and see if this fixes it?
Generally speaking, if the client is not getting a valid private IP address, then it could be something with the WiFi drivers on the Raspberry Pi - specifically, if during the boot procedure, hostapd starts too early, then it could lead to this problem.
But because your own MackBook Pro and school-assigned Surface Book work flawlessly, then it can’t be robot and instead, it must be the Surface Books. I’m bewildered as to what it could be the reason.
Another idea I can think of, is running Linux on one these bad-acting Surface Books and see if you can connect to DexterOS and reach the robot’s homepage. You don’t necessarily have to install Linux (i.e. Ubuntu) on it, you can just run it without installing it.
Another thing to try would be to assign an IP address to each Surface. Something like 10.10.10.x where x is 11 and up, with each tablet being assigned a unique number.
Haven’t had time to test with an Ubuntu flash drive. I did set an IP address manually for a Surface that was not connecting automatically. This did work, but the browser loaded the robot’s site very slowly. I was in a rush when I did this so I guessed at a subnet and did not put anything for DNS. If you have recommendations for these please pass along. I used 10.10.10.14 for the Surface and 10.10.10.10 for the gateway.