Hello,
Motor port B on my BrickPi is failing. Running the LEGO-Motor_Test.py program it does go forward, but stops when it should reverse. The motor on port A is working fine, alternately running forward and backward at the same speed.
I checked the cable and the motor. Running the program with ports A+C, A+D or C+D works fine with the same cables and motors.
What could it be?
Frans, has it reversed before? Is this sudden, or new?
Hi,
As far as I know it used to work fine. I’ve used both ports before with the test program and with a coupled speed control program that I wrote myself.
I think the problem started after I tested my python implementation for thread-safe operation of the BrickPi. There was a bug in it that resulted in BrickPiUpdateValues() being called again before the previous call ended. (Strangely this didn’t result in an error message straight away, but only after it happened a couple of times running the loop the error -1 was returned.) I now wonder if this may have somehow damaged the firmware, or worse the hardware of Atmel no1.
Interesting fact: I ran the test program LEGO-Motors_Test.py again with ports A+B, but set a lower speed: ±100 instead of ±200. Now when motors A and B are running forward, motor B clearly moves about twice as fast as motor A. Then when the motors should reverse, motor A does, but motor B stops. Switching back to forward puts motor B at twice the speed of A again.
This behavior didn’t show before, but that is probably because 200 is already so close to maximum power.
I measured the voltages on the pins of the Half-H driver connecting atmel1 to ports A and B. Pin11 (MBO0) is permanently on 9V supply voltage even when pin10 (MBPWM) is 0V. So, that driver chip is broken, or there is a short circuit somewhere.
I’m going to replace the driver chip and test again. Unfortunately, until I get that chip my BrickPi experiments are on hold 
Something I noticed during testing is that the H-driver chip gets quite hot when you run the motors back and forth for a while. The description of the chip shows that pins 4,5,12 and 13 are grounds, but can also be connected to heat sinks. Wouldn’t it be a good idea to add this heat sink to the BrickPi design?
It does sound like the motor controller chip has indeed been fried. Let us know how the replacement operation works. If it doesn’t, could you contact us through our contact page?
Hello,
Thank you for the reply. From a functional perspective the replacement operation has been a success: my BrickPi works again. However, it doesn’t look as pretty as it used to 
Replacing the IC on this small PCB proved to be considerably more difficult than I (naively) thought it would be. Nevertheless, the new driver now sits nicely in a dip socket and I managed to keep the damage to a minimum: only the MBO1 trace needed to be replaced with a wire.
Fingers crossed that all other connections prove to be reliable over time.
I also have a direction based motor problem. Even though I’ve had the BrickPi for months I only just got a 8x battery box and the power connector for it yesterday so I tried the motors for the first time. LEGO-Motors_Test.py. My failure was more serious. It went forward for 3 seconds, did something different then the motors stopped and the PI froze up. My network link (wifi) went down and the PI rebooted itself. I was able to log in again. It looks like at least one of the ports has this problem. If I change the power setting from ±200 to ±100 I don’t see the failure although subjectively the motors seem to turn more slowly than they should. The electronics is buried pretty deeply in the robot. When I get more time I need to take it apart to do better testing. I guess it is time to look at the schematic.
We have 3 robots very similar to simplebots and our motorports (and one sensorport that used a dIMU sensor) seem to burn out one by one.
Hello Mickmack,
In my case one of the motor driver IC was broken. That IC, however, doesn’t handle the sensor ports. Those are connected to the Atmel directly. Do you have a multi-meter or scope to measure the outputs on the motor driver IC and the Atmel?
Out of curiosity, do the motors on your simplebots have to work hard?
I have a multimeter but our robots are “on tour” with my colleague of mine so i can’t measure the outputs right now. The motors aren’t hard pressed at all. We’ve only tried the robots for short periods of time and never given full power signal to them (only about 160 out of 255) and they’re only powered by eight (rechargeable) AA batteries which wouldn’t yield more than 10V effective Voltage even when fully charged.
At least some of them initially worked but all of a sudden stopped working and emitted an smell of burnt electronics.
The sensor port stopped working at the same time as the motor port next to it so I suspected it burned out at the same time but if they don’t share the same driver chip i need to test it more when the robot comes back.
Yesterday, while doing some tests with the balancing task for a segway-robot, motor port D failed in exactly the same way as port B from my previous posts. A motor on port D now can only run forward at full speed and doesn’t reverse.
I haven’t taken measurements yet, but I’m quite sure that it is a broken driver-IC again with Pin11 (MDO0) permanently on 9V.
What could cause this? Does my BrickPi just have a bad batch of driver-ICs or is my program overheating them somehow?
Given the trouble of replacing the AB-driver, I can say that I’m not looking forward to replacing the CD-driver.
Zencuke, Mickmack, did you find what went wrong with your brickpis and what caused it?
Frans,
I haven’t gotten back to it. Haven’t even turned it on since. I’m sort of afraid to touch it because I don’t want to smoke the Raspberry PI. More annoying is I sent email to Dexter and got no response. Plus they seem to be ignoring this entire thread including MickMack’s posts above of a week ago.
-steve
Hey Steve,
As I mentioned in a previous post, I’m sorry if we missed or ignored one of your previous e-mails. I try to be responsive, and ignoring you wasn’t my intention. If your hardware isn’t working, we’ll replace promptly at our own cost. Please contact me and I’ll arrange for a replacement.
John
Hi John,
Replacing broken hardware for free is a generous offer. However, as you said in Zencuke’s omniwheel-robot topic, it is probably best to get more information about the problem first. At least 3 people have similar problems (probably 4, because I think Ivar’s problem of a rebooting RPi when running the motor example is related). It might therefore not just be a case of bad SN754410 driver ICs. The topic about the ultrasonic sensor returning wrong distance values showed that there probably are different versions of that sensor around. This made me wonder if that could also be the case for the NXT motors.
Searching for information about NXT motors I found this very nice webpage:
http://www.philohome.com/nxtmotor/nxtmotor.htm
It provides lots of information about the performance of the motor, but also about its internals.
A nice schematic can be found at:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1846577
Note that these two sources disagree on the type of PTC resettable fuse that is used in the NXT motor.
If the PTC is indeed the RXE065 or MF-R065, as the first link suggests, then at room temperature the fuse would trip at a sustained current of 1.3A (see spec.sheet at: http://www.philohome.com/motors/RXE065.pdf). This is well above the max. allowable sustained current of 1.1A of the SN754410NE (spec.sheet at: http://www.ti.com/lit/ds/symlink/sn754410.pdf). Moreover, at room temperature it takes this PTC 5.3seconds of 3.25A surge current to trip. Again this is well above the allowable 5milli-second 2A surge current of the SN754410.
If the PTC is the MF-R030, as the schematic of the second link suggests, things look a bit better. The maximum sustained current at room temperature then is 0.3A and it trips at 0.6A, all within SN754410 specs. However, also this PTC needs 3 seconds to trip when handling a surge of 1.5A at room temperature.
The question now is if such large current surges can happen. I think they can and that the condition of rapidly changing rotation direction at full power is one of them.
If the above supposition is true, then for the case the NXT motors have the MF-R030 PTC, the solution could be to stack two SN754410 ICs, like shown on this webpage: http://letsmakerobots.com/node/10509
If the NXT motor has a MF-R065, well then I guess another way to limit the surge current needs to be considered.
In the mean time it may be wise to limit the number of AA batteries in the pack to 6. I noticed that a fully charged 8 pack has a static voltage of 11.5V. This will drop when loaded of course, but with 10V it is still above NXT specs.
Hey Frans,
I’ve been trying to do a little reading on this, I’m not sure if I have any answers yet. You bring up a lot of good points.
Just to throw another thought out there, the LEGO Mindstorms NXT uses this as the motor controller I believe:
(It actually uses a LB1930M and a LB1836M).
I wonder if this offers more protection?
Also another question Frans, do you think that back-emf could be causing the problem?
ALso, two more thoughts:
There is more detailed information on motor performance here: http://www.philohome.com/motors/motorcomp.htm
And another thought: since the Motors perform up to 12V, I think that’s safe with AA batteries. However, as the supply voltage drops, the amperage will increase, no? And possibly bring the motor driver chips up to a dangerous level. Could that be happening?
Hello John,
Yes, my first thought was going to back-emf. The idea is that when the motor runs forward, the permanent magnets cause back-emf voltage that counters the voltage of the driver, thereby keeping the current low. Now, when the driver switches direction of the driving voltage it would add up to the back-emf voltage that may lag a little behind because of mechanical inertia. This could result in a high current peak for a short while.
However, you have a good point in that the original NXT is using a driver that appears to have lower specifications than the SN774411. If back-emf is causing dangerous current spikes, then you would expect these to burn the LB1836M as well, unless it has additional protection for this, but that doesn’t become clear to me from the specs.
Another possibility could be ‘crow-bar’ current in the driver IC. This is the condition that both ‘switches’ on one side of the H-driver are conducting, effectively resulting in a short-circuit. This is a very bad thing for a H-driver, and I cannot believe the SN774410 doesn’t somehow prevent this condition from happening, unless it is driven out of specification by the controller (atmega in our case).
Anyway, I presented this problem to my colleagues (who are far more knowledgeable about electromechanics than I am) and they said that it is very difficult to find the root of this problem without taking measurements with an oscilloscope. They also warned me that using a more powerful driver may remove the symptoms, but not necessarily the cause.
Unfortunately, I don’t have an oscilloscope available, but I think that I can provide a sure-way-to-disaster test to fry the driver: simply connect motors to ports A and B, put lego NXT wheels on them and run them forward and backward at full power, switching direction every 0.01s.
With something like this I have managed to fry three driver IC already. Two with 8 batteries and one with 6 batteries. One time I checked the temperature of the driver IC with my finger. It was hot enough to hurt a lot.
It might be nice to replace the SN774410 with the LB1836M and run the same test. It is not a drop-in replacement, but it might show if these drivers behave differently.
I hope this is somewhat helpful.
Cheers,
Frans
I’ve been experiencing the same issues. I’ve already spoken to John at Dexter via email and arranged to have my BrickPi replaced (much appreciated John).
Reason for posting is I’ve just come up with the “half speed backwards” problem on port A too - this used to work fine so it does appear I’ve overloaded the controller. Is there anything we can do as users to prevent this? My application is relatively high-load, but I used much the same base robot with the NXT controllers for several months before porting over to the Brickpi without breaking anything and added some extra gearing to reduce the strain somewhat after reading about the issues here.
Is restricting the maximum power that I call from the BrickPi likely to help, or will stall conditions still push the current over the safe limits? Would it be possible to piggy-back an extra motor controller on top in parallel if that’s what’s failing as I’ve seen done elsewhere? (Apologies if that’s a silly question and would either not work or just cause something else to break; electronics isn’t my strong suit).
Or for that matter, could I put a faster/lower current tripping fuse in-line in my cables?
Hey Frans, I’ll try to run a test with an Oscope. I will try to put the results up here for discussion. I really appreciate you workign with us on the topic.