First boot was successful but board failed to light wifi indicator (at top of robot’s head); regardless, SSID was broadcast and I connected to it successfully.
Issue is now that second boot attempt fails:
Note that I’ve tested multiple sets of batteries and confirmed voltage with a multimeter. See video of issue here
Hello @ethanschoonover
Let’s see if we can get the robot out of its coma. For that, I would need a couple of tests and answers from you. Btw, thanks for the video, it couldn’t be better to describe the issue.
Cleo
Hi Cleo, thanks for following up.
I’ve recorded another video of both the boot, positive results including green systemd output and boot to login, SSID coming up and full access to the web UI.
As a next step, I’ve ran some of the hardware tests in the python notebook. Failure on the Motors & Encoders test, FWIW (see video linked below).
I did power off then and was able reboot the board successfully using the GoPiGo3 power button.
I figured the next troubleshooting step would be to re-image the system image and so went ahead and did that.
Subsequent boots have been normal and the web UI comes up and seems fully functional.
Just out of curiosity (and because I’m planning on ordering a fair number of these for our coding & robotics curriculum and will be responsible for maintenance) what do you think the issue was here? I had the feeling that the GoPiGo3 board was stuck in a state that prevented it from cycling the power correctly.
Hi @ethanschoonover,
That’s a really odd behavior, huh. First time seeing it behave this way.
There could have been 2 things:
The firmware on the GoPiGo3 was corrupted or not present.
A corrupted/not present firmware on the GoPiGo3 and a partially corrupted image.
I would incline to say it was the GoPiGo3 that wasn’t responsive and less the probability of having a corrupted image.
To better describe this behavior to you, imagine that the GoPiGo3 had this bad firmware that didn’t trigger the Raspberry Pi to boot. Since it couldn’t do this, there was nothing you could do on the RPi.
But the moment you helped it out to successfully boot up with a micro USB cable, the OS had the time to see that the GoPiGo3 was unresponsive and start flashing it. Subsequent boots would have given you a functional GoPiGo3/DexterOS.
Interesting as this behavior is a bit similar to how the GoPiGo3 behaves when some specific diode (close to the power button) on it goes bad. Fortunately in your case, this was a software issue.
Let us know if you’ve got any other questions about anything.
Thank you!
Hello @ethanschoonover
A lot of things are happening on the first boot. The system is making sure the robot has the proper firmware for example. For some still unknown reason, it didn’t go according to plan for your little robot. However, it was able to recover after a couple of boot-ups.
I’m hard at work perfecting this process, so others are not stuck.
Thanks so much for the debugging you offered us.
Cleo
Thank you both for the follow up. Your description definitely matches my experience and it seems that the automatic firmware write at boot solved the problem. That’s a nice solution on your part, btw. I don’t do embedded systems work, but I’m impressed with the fact that you have to factor in a lot of disparate end user configurations, hardware variations, etc.
Anyhow, I appreciate the help and am always a willing test subject if you ever want to beta test something. I’m planning on deploying a small fleet of these in our classes and am comfortable testing and bug reporting 
Cheers,
Ethan Schoonover
I did notice that one of the students was rotating one of the wheels in reverse to watch one of the power LEDs come on after I first assembled. I politely suggested we NOT run current through the circuit in that direction and they ceased , but this was before first boot and so when we did boot successfully (despite the lack of WiFi indicator, etc.) I assumed it had no relation to second failure to boot. Your mention of a diode failure causing a similar issue makes me wonder, though, if that couldn’t have contributed to the symptom and issue noted.
I’m no EE, so just guessing and this may indeed have no relation to the issue at all
-Ethan
Hi @ethanschoonover,
That’s an interesting hypothesis. Even this way, I don’t think this could have had anything to do with the GoPiGo3 failure you encountered. That’s because it was a firmware failure.
Still, we can’t be 100 percent sure about this, as with anything in this world, and hence your hypothesis can’t be discarded, so we’ll think about what you said and see if it’s possible to brick the GoPiGo3 by rotating the wheels manually - @Matt.
Thank you!
Unless rotating fast enough to cause an over-voltage, I don’t think rotating the motors would cause electrical damage. However, it could lead to corrupted FW. It would take some testing to have a better idea of what happens. Basically it would just power the GPG3 in a brown-out state, with very inconsistent power.
This topic was automatically closed after 3 days. New replies are no longer allowed.