I was examining your board with a bit of magnification and I noticed something potentially interesting that looks like a solder-splash across two power traces near the upper right of your picture.
Does that exist on both boards? Is this board still working? If so, would you flick it off and see if that eliminates the problem?
For comparison, here’s a magnification of the original board pictures you showed me. You will notice a much better, and cleaner, soldering job done to that pin.
Item number 2 should be 200k, not what looks like 30 ohms. (“300” in resistor notation should read as 30x100, in other words, 30 ohms. The other, reading “222” should read as 22x102, in other words 2200 or 2.2k - the last digit being the “multiplier”, or the number of zeros to append to the two numbers that represent the value.)
Note also that my PCB, which is an older version GoPiGo-3 board has the same 30 ohm resistor there.
For comparison, look at the 820 ohm current limiting resistor leading to pin-4 of the Atmel controller chip, (5v Vref). It is labeled “821” which equates to “820” ohms.
My schematic, which is marked as the GoPiGo 3.2.0 version, shows completely different values for a lot of the components in the power supply and power management sections.
Note that, aside from the resistor in place of the diode, your boards components look just like mine, except for the placement of CP14, the very large silver electrolytic capacitor, which on your PCB was moved to the edge of the board.
When I check it with my fingers, it’s one of the two next to the 3R3, would say the little one (in the green box). And a few seconds it’s normal and then it heats up very quickly. If I know what could happen I would let it run… i have no idea about it and i’m a bit scared.
Hold the can upside down and spray the cold liquid on the board all over that area. Do it a couple of times. Get it nice and frozen. (Be careful of the IC’s)
Then turn it on with both supplies and see what warms up first.
I have no can of compressed air and the picture I’ve send is from the dead board. I would like not to lose my warranty at the moment (for both boards). The other board works (with batteries only) and I hope I don’t lose that too because I have to go forward with my semester thesis - no experiments on the board that runs actually until I have an alternative. But if I have an alternative/solution, I would be very happy to give you the informations and do further investigations.
I have contact with the support (@mitch.kremm) and hope they can help me out somehow.
I thought I could order a new one from a shop here in Switzerland, but if they send me the exact same version (v3.3.0) again, I don’t know if I would have the same problems.
That green part is a soft (self-resetting) fuse. There are two on the board. One there that feeds the battery power to the PI if nothing else is connected, and another one closer to the Atmel processor for the servos.
It should NOT get hot.
Please make the following tests on the working board.
Test:
Hook things up so that the component gets hot.
Remove the power adapter from the Raspberry Pi itself.
Examine: Does the green component start to cool off?
Can you check the voltage on each side of the green component when it gets hot?
Jim, Woody told you he needs to protect that working board, like critical to his course. I suggest that he not mess with it, period. Every handling of these boards is an opportunity for “bad juju.”
A long time ago, in a far away land (New Mexico State University 1976), I decided to do a one-semester research project to complete my Mechanical Engineering degree with a “never got less than an A in his life” study buddy.
We submitted a plan, requesting funding from the department for the material, and got approval by our graduation review adviser. It turned out the advisor was in a lawsuit with the university, and the university would not approve the funding. We submitted a change from physical analysis to software simulation analysis, which the review advisor would not approve, and would not release us to a different advisor.
Being the final semester before graduation there really was not time for anything to go wrong. I had invested six years of course work, and I really wanted to stop paying for life and start earning a living.
The university agreed to switching advisors, allowing the software simulation analysis, and we managed to graduate as planned.
I’m here all the time the next coming weeks because of covid-19, you can come here immediately - but think it would not be easy to travel over borders (…covid-19 ).
Thank you very much for your help! Really cool to have such a community here! But now I have to prioritize my things a little and the highest one is to go forward with my work. I asked the support for warranty exchange, but they are in the US and it’s not so easy to do that in a fast way. Depending on there response I will try to get some replacements from the shop I bought the two GoPiGo3s here in Switzerland.>
If I get the chance to do more research on this problem after my semester thesis progress is a bit further than now, and I wouldn’t break my warranty claim with experiments and I have a backup in place, then I would love to do further investigations.
My kid brother has to periodically remind me that “other people aren’t as good at this as you are”, and I totally agree. I would have no problems experimenting with the last bottle of oxygen while waiting for rescue. Others, maybe not.
Of course Woody has to prioritize and make sure his studies are successful and I am sorry for not paying attention.
I think I would express that “slightly” differently, as in:
(…covid-19 )
Absolutely true.
You are totally correct and I apologize for my thoughtlessness.
Using an external power adapter, (at least with an earlier revision GoPiGo controller board), is a normal use-case.
If you can do that and it doesn’t get hot, that’s fine. If you are concerned that it might damage the robot, then (of course) continue using the batteries. Hopefully you have lots of spares.
Since I am also doing a LOT of development work with Charlie, involving minimal or no independent movement, I also attached a 12v 2+ amp power adapter similar to the one you showed earlier.
Re: The high-frequency tone.
That might be coming from the adapter. If you are confident that it’s coming from the robot itself, I’d either use a different adapter or continue using batteries.
Re: Development on the robot itself. Especially if you are using batteries to power the 'bot exclusively, I would recommend doing development externally, and then moving the files to the 'bot for testing, which is what I am doing with my remote camera robot project.
What I do:
I have a PC running Windows 10, and I’ve downloaded Visual Studio Code to my system. I also set up a GitHub repo to store my work off-line. Visual Studio Code handles all the “Git” stuff for me so all I have to do is push and commit.
Once I have something I think worthy, I use FileZilla to move the file(s) to the 'bot for testing.
If I’m going to be spending a lot of time coding, or if I am working on just the browser side of my project - and I can simulate that entirely on my PC - I don’'t even turn the 'bot on.
Of course, you have to do things the way that works best for you.
For your information: I found an old gopigo (v1.6.0) in my cellar (didn’t know that I still have it).
I’m now working with them until my other (newer) boards are back (hopefully soon).
I can work as expected with v1.6.0, using the same battery pack and the same usb power adapter as with v3.3.0 -> I can switch between battery and usb power adapter as I want and use both at the same time and it works perfectly.
When I get the new v3.3.0 boards back, I will try the rpi2B board with the v3.3.0 board and check whether the problem also exists there. But I hope that with the new boards the problem is completely gone.
The differences I have to the configuration with the heat / 19V problem are:
pi@dex:~ $ sudo sh ~/Dexter/GoPiGo3/Troubleshooting/all_tests.sh
===============================
GoPiGo3 Troubleshooting Script
===============================
Checking for hardware, and checking hardware and firmware version.
==================================================================
Manufacturer : Dexter Industries
Board : GoPiGo3
Serial Number : 6EE2126A514E4C47324B2020FF041911
Hardware version: 3.x.x
Firmware version: 1.0.0
**Battery voltage : 10.768**
5v voltage : 5.049
Attach now a usb power supply to the raspberry pi.
The power led on the gopigo3 should be green
Execute sh ~/Dexter/GoPiGo3/Troubleshooting/all_tests.sh
Result:
pi@dex:~ $ sudo sh ~/Dexter/GoPiGo3/Troubleshooting/all_tests.sh
===============================
GoPiGo3 Troubleshooting Script
===============================
Checking for hardware, and checking hardware and firmware version.
==================================================================
Manufacturer : Dexter Industries
Board : GoPiGo3
Serial Number : 6EE2126A514E4C47324B2020FF041911
Hardware version: 3.x.x
Firmware version: 1.0.0
**Battery voltage : 19.026**
5v voltage : 5.081
Log has been saved to Desktop. Please copy it and send it by email or upload it on the forums
Remove the battery pack
The power led on the gopigo3 is still green! (Should be red! Motors should be blocked if no battery pack is attached, but led is still green and motors could be moved… on the v1.6.0 board, the motors are blocked like expected)
Execute sh ~/Dexter/GoPiGo3/Troubleshooting/all_tests.sh
Result:
pi@dex:~ $ sudo sh ~/Dexter/GoPiGo3/Troubleshooting/all_tests.sh
===============================
GoPiGo3 Troubleshooting Script
===============================
Checking for hardware, and checking hardware and firmware version.
==================================================================
Manufacturer : Dexter Industries
Board : GoPiGo3
Serial Number : 6EE2126A514E4C47324B2020FF041911
Hardware version: 3.x.x
Firmware version: 1.0.0
**Battery voltage : 19.103**
5v voltage : 5.085
Log has been saved to Desktop. Please copy it and send it by email or upload it on the forums
Reattach the battery pack
Remove the usb power supply from the rasbperry pi.
Execute sh ~/Dexter/GoPiGo3/Troubleshooting/all_tests.sh
Result:
===============================
GoPiGo3 Troubleshooting Script
===============================
Checking for hardware, and checking hardware and firmware version.
==================================================================
Manufacturer : Dexter Industries
Board : GoPiGo3
Serial Number : 6EE2126A514E4C47324B2020FF041911
Hardware version: 3.x.x
Firmware version: 1.0.0
**Battery voltage : 10.819**
5v voltage : 5.045
The engineers in US (thanks @mitch.kremm ) could not reproduce the problem. He asked me to test with other USB power supplies, here are my results:
These Adapters/Cables shows the result above with the 19V:
I’ve been working with these adapters for a long time with different Raspberry Pis in combination with different boards and had never such a problem with one of them. I can not believe that so much adapters should have a problem. With the GoPiGo v1.6.0 the adapters are all working without showing me such high voltage!
Nobody out there in Europe (maybe 50Hz) has the same problem with a GoPiGo3 v3.3.0 board???
I have the older v3.2 “red” board, and can confirm that when:
The board is powered by both +12v and +5v at the same time. —and—
The power supply LED is lit green. —and—
The +12 supply is subsequently removed.
THEN
The green power LED remains lit.
The wheels attempt to turn when commanded despite the absence of the +12 volt supply.
I don’t remember exactly about the power supply reading, (mine maxed at about 14.4 volts), but I think it remained high.
I remember mentioning this in earlier postings of mine discussing the operation of the robot from about a year or so ago.
The +5v supplies are all “Element-14” or other officially-branded Raspberry Pi power supplies purchased from Micro Center, a reputable and official retailer. (With US power pins. I use an adapter to connect to the two-pin European power pins shown in Woody’s illustrations.)
Also note that I have several of each kind - both micro-USB and USB-C connector supplies, all official supplies, for both the Pi-3 and earlier and the Pi-4
All of the micro-USB +5v supplies I use for my Pi-3 (or earlier boards), are “official” Pi-3 rated supplies.
The +12 supplies I use are either:
A bank of eight NiMH cells in the provided holder.
A 12v 3A supply originally intended to be used with a high-current-draw device like a NAS box or an external hard drive. Measured ripple, (using the “AC” scale of my multi-meter across the open end of the 12v barrel connector), is in the magnitude of micro-volts.
Hardware:
These tests were done using either a Pi-3B or a Pi-4B-4 gig, using stock “Dexter” Raspbian for Robots or DexterOS releases as of those individual points in time.
I am using an “as shipped” 3.2.2, (early version with C14 in the middle of the board), GoPiGo-3 board using the stock 1.0.0 firmware.
I only use known, and verifiably good, SD cards. (i.e. SanDisk Extreme Pro, application grade A1 or A2, or equivalent Micro Center SD cards)
Modifications:
I have recently updated many of the Pi boards dedicated for GoPiGo use, (or other uses), with Adafruit Real Time Clock modules, and have made the appropriate modifications to the config.txt and hwclock.cfg configurations to enable them.
However, these findings predate these updates, but persist through them.
I would like to help you get to the bottom of this too.
Would you please be kind enough to publish the specifications of the system you are trying to duplicate this with?
What version of GPG board? Are you using the as-shipped stock 1.0.0 firmware, or something special being used internally?
What version of Raspberry Pi are you using, and if it’s a Pi-4, what firmware revision are you loading?
This can be significant. Ask Nicole about the headaches we’ve been having flashing firmware with the Pi-4!
What operating system, version, and any special modifications/installations, (for development work, etc.), are you using?
What is the kernel version reported by “uname-a”?
My system returns Linux Charlie 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
where the “armv7l” indicates the stock 32-bit low-latency kernel)
Can you reproduce this on an absolutely stock, as-shipped, system with as-shipped hardware, etc.?
I can honestly say that in the, (literally), decades and decades and decades of hardware and software testing I have done, places where the developers say “I can’t reproduce it.” or “It works perfectly for me!”, invariably turn on something that either the user, or developer, did differently.
I’m not trying to bust chops, but once we know what the differing factor(s) is/(are), we can figure out what’s really going on.
@woody123, if I might offer a way for you to proceed on your project without getting derailed by the issue you have discovered.
One way that users develop for the GoPiGo3 is to only use battery power, and put the robot “up on blocks”, on the desk on a block of foam to allow the wheels to turn without the robot walking off.
While it is good for users to take a break periodically, (like while recharging the battery pack), some keep a spare battery pack always recharging so there is no real “down time”.
Perhaps you don’t need to solve the dual-power-gets-hot issue?
If I don’t need my 'bot to be moving while I am working on it, I use a +12v adapter and plug it into the battery connector. (99% of the time this is what I do while working on programming projects.)
If I need to test something that involves the 'bot moving around, I plug in the batteries. I also have several extra sets charged up and ready to go if I need them.
If I’m programming, and need a “quick” motion test while on the +12v adapter, I either pick Charlie up and watch the wheels or use a piece of wood to lift him up off the table for the couple of minutes I need to see what’s going on.
This avoids all the “dual power” issues for the time being.
Later on, after you have totally dominated your class project and gotten top marks, (and I can dig up a newer version of the GoPiGo controller board), we can revisit this issue.
For now, get your project going. We’ll pick up the rest later.
I attempted to reproduce this again yesterday.
I used our official LiOn battery and the official Raspberry Pi charger on a Pi3+ / GPG 3.3.0 board.
I’m in Canada, so 60hz, 110V although the charger should take care of removing those differences.
I couldn’t reproduce the issue.
We also did the same right in China (50Hz, 220V) and he couldn’t reproduce either.
Is that the “new” new board or the “old” new board?
Totally agree. And the “magic sauce” usually ends up being something so insanely trivial that it escapes notice. Or something any sane person would consider totally unrelated.
Case in point:
Remember the gentleman with a Pi-2 who couldn’t get his 'bot to run properly on WiFi?
He just received a Pi-3, installed it, and tried to use Etcher on the Mac to burn it. It fails miserably with an apparent blown flash. Consistent and repeatable.
He was eventually able to execute a “raw” dd on his Mac to get the SD card working.
I have seen the exact same thing using Etcher on Linux Mint 19.3.
Any attempts to flash a Dexter/Modular Robotics image file containing a truncated file system image using Etcher within Linux Mint also fail, producing a SD card with an unusable system.
“normal” un-truncated images usually work well.
I think part of the fact is that Etcher, (when run on anything else but Windows), is less comprehensively tested and/or supported, and the non-windows Etcher versions appear to trash file images that have a truncated or damaged filesystem image. (At least this is true for M.R. images.)
Why this should be true is beyond my understanding.
“In theory” Etcher is simply a manifestly civilized “dd”.
Then again, “theoretically” it is impossible for bees and wasps to fly.
N.B. Actually no longer true.
I just had several ideas that might be the reason why, and they may have absolutely nothing to do with either Etcher or the Modular Robotics images. More research is needed.
I am planning to continue researching this when I get out.
I might try to get myself an inexpensive Mac system to test with. However that’s as much of an oxymoron as an “inexpensive Ferrari to teach Driver’s Education”
Note:
I am updating this topic with the latest findings so that anyone who finds it while searching will get the best and latest information.
Ref: My post at:
The actual issue appears to be the fact that the original poster was feeding the GoPiGo through both the GoPiGo’s 12v connector AND the Raspberry Pi’s 5v input.
This can cause a condition where the Raspberry Pi is “overdriving” the GoPiGo controller board by providing a higher +5 voltage than the board was programmed to provide.
When you do that, the IC that generates the +5v from the +12v works “backwards” and sucks current instead of providing it.
This can cause components on the GoPiGo board to overheat and/or cause the 12 voltage to rise dramatically.
I discuss the solution to this problem over at the thread referenced above.
)
).
