Motor port B fails to run backwards

Frans, silly question: could adding some software delays in the motor operations help with this problem? You mentioned a possible problem when the direction is changed really rapidly, we could be crow-barring or worse, we could be applying power across both bridges and causing a short. If we changed the motors in a controlled manner, maybe adding a state in python code that didn’t allow changes of the pwm by more than 10% every 5 ms, that might reduce the load on the h-bridge. What do you think?

Hey Shao, it’s not a silly question. That’s a really clever hack actually, but I don’t know if we can do that in production. You might be able to put a trip fuse in the cable, but I don’t know if that will actually help the problem. As Frans pointed out there should be fuses in the motors themselves.

I do have a friend who’s a dab hand with a soldering iron so I might look at getting that done (replacement received today, thanks) and see how it goes, as long as I’m not running the risk of just burning something else on the BrickPi out. I did take one of my NXT motors apart, and the fuse I have is the same as Philo’s one which looks very much like the RXE065, ie 3.25A for 5.3s to guarantee it tripping, so nothing like conservative enough to protect the controller, I was thinking of putting a much lower trip current one in there. I might look at doing both, as Frans’ comments suggest that even with 2 controllers stacked the standard fuse on the motor still wouldn’t trip soon enough to save them - presumably the NXT iteself does something else either in firmware or hardware to stop the lower-spec ICs that they’re using from burning out - I’ve had some pretty high-load appications and prolonged stalling with Lego’s hardware and never had the motor fuses trip out or the controller die. I’ll put the soldering job forward for my mate’s consideration and feed back with the results.

I ran an oscope on the motors today, running the simple back and forth. I’m not entirely sure what to make of the results. It did seem like the switching was happening really violently, which again, might be a software-solvable problem.

I was using an 8XAA battery pack on these.

The first image is with the power at 200. This shows each time division at 500ms.

This is at 255. You’ll notice the voltage isn’t showing any PWM. That can be a problem with other motor controllers I’ve worked with: if you’re not alternating, it can overheat.

The time div here is 20 ms. You see the shop drop of the yellow line, and the sharp spike here of the purple line, and then the purple line collapses a bit. Maybe that’s causing one of the problems that Frans mentions?

This is a real closeup. This is the motor running at 200 (so you can see the pwm’s rising and falling) and you can see the switchover. Each division here is 500 uS. So the switch between the two happens in 500 uS.

Thank you for the scope images.
Some remarks: The time division in the first image is 50ms and in the third image it is 10ms.
The second image shows the voltages of the 3s forward-reverse test with full power. That test doesn’t really heat up the driver chip very much. It gets more interesting if you change direction every 0.1s (100ms), like:

from BrickPi import *   #import BrickPi.py file to use BrickPi operations

BrickPiSetup()  # setup the serial port for communication

BrickPi.MotorEnable[PORT_A] = 1 #Enable the Motor A
BrickPi.MotorEnable[PORT_B] = 1 #Enable the Motor B

BrickPiSetupSensors()   #Send the properties of sensors to BrickPi

while True:
    print "Running Forward"
    BrickPi.MotorSpeed[PORT_A] = 255  #Set the speed of MotorA (-255 to 255)
    BrickPi.MotorSpeed[PORT_B] = 255  #Set the speed of MotorB (-255 to 255)
    ot = time.time()
    while(time.time() - ot < 0.1):    #running while loop for 0.1 seconds
        BrickPiUpdateValues()       # Ask BrickPi to update values for sensors/motors
        time.sleep(.02)              # sleep for 20 ms
    print "Running Reverse"
    BrickPi.MotorSpeed[PORT_A] = -255  #Set the speed of MotorA (-255 to 255)
    BrickPi.MotorSpeed[PORT_B] = -255  #Set the speed of MotorB (-255 to 255)
    ot = time.time()
    while(time.time() - ot < 0.1):    #running while loop for 0.1 seconds
        BrickPiUpdateValues()       # Ask BrickPi to update values for sensors/motors
        time.sleep(.02)              # sleep for 20 ms

If you run this and keep your finger on the driver IC you will be very eager to press Ctrl-C after about 10s (it gets that hot). It would be nice to see the voltage changes of this test. Also, if possible, can you make a record of the currents involved?

The 4th image with the close up shows that at a direction change the voltage on the ‘B’ terminal drops approx. -1.5V below ground and stays below it for about 0.5ms. Also, when switched high for the first time, the ‘A’ terminal overshoots the supply voltage with approx. 1.5V (but for a shorter duration). Shouldn’t the IC’s protection diodes on the output terminals prevent this?

could adding some software delays in the motor operations help with this problem?

Yes, I think that could work. However, the software should not be set too conservative, otherwise it will affect control, e.g. balancing of a segway-type robot.
A good test would be to see what the highest direction switching frequency is on a NXT and implement that on brickpi.

Hey Frans, a few more updates. I’m going to try out a few changes to the code before proceeding. I see the heating your talking about. In fact, I got the motor chip to overheat (the motor after about 10 minutes of back and forth at 100ms, suddenly slowed down); it however reset and worked again after letting it cool down. The second time I ran it, I wasn’t able to get it to overheat. I was’t able to replicate the problem you’re seeing where the chip gets destroyed.

It happened a lot faster (less than a minute of operation) at 100 ms intervals, with fresh AA batteries, at 12V power total.

This reset makes some sense: the SN chip not only has the protection diodes built in, but thermal shutdown. I think what I see after about 10 minutes is the motor chip overheating and going into thermal shutdown.

I also tested the NXT at 100ms changes as well. It seemed to be about as brutal (it switches back and forth pretty strong), except that it has a little more oscillation around the changes. These oscillations don’t look like they’re full PWM changes, just some sort of softer landing for the motors.

Another thing occurred to me: some motor drivers need a constant alternating PWM. I worked with another TI Chip once and it needed to be cycled once every 10 microseconds, or it would overheat. To run the motor at a max of 99 or 98% PWM cycle might be beneficial to the motor chip. This is a simple change I thin in the software that could help preserve the life of the motor chip. It would not affect power functions I think.

Also, when I limited the function to 0.5 second cycle time, there was not an overheating problem.

Here are some scope shots of what was going on, with the NXT and BrickPi.

NXT Motor at 50% - 100 ms switching.
NXT Motor at 50% - 100 ms switching.

NXT Motor at 100% - 10 ms switching.
NXT Motor at 100% - 10 ms switching.

NXT Motor at 100% - 10 ms switching.
NXT Motor at 100% - 10 ms switching.

BrickPi Motor at 100% - 100 ms switching.
BrickPi Motor at 100% - 100 ms switching.

BrickPi Motor at 100% - 10 ms switching.
BrickPi Motor at 100% - 10 ms switching.

BrickPi Motor at 100% - 100 ms switching. After thermal shutdown.
BrickPi Motor at 100% - 100 ms switching.  After thermal shutdown.

Hello John,
Thanks again for the scope images. Interesting results.

This reset makes some sense: the SN chip not only has the protection diodes built in, but thermal shutdown. I think what I see after about 10 minutes is the motor chip overheating and going into thermal shutdown.
That could be it, but it could also be that the fuse in the motor tripped. Actually when looking at the last scope image, that makes more sense to me. When the fuse in the motor trips the circuit resistance goes up and the current comes down, so when the driver switches direction it can supply the low current without the voltage droop.
I was’t able to replicate the problem you’re seeing where the chip gets destroyed.
Yes, I'm also not 100% sure that it is the heat that destroyed the ICs, but it is the only thing I can detect at the moment. Moreover I do think that the rate at which the IC heats up with this test is too high. When thermal safeties kick in less than 1 minute with full batteries, I think something is not right.
To run the motor at a max of 99 or 98% PWM cycle might be beneficial to the motor chip. This is a simple change I thin in the software that could help preserve the life of the motor chip. It would not affect power functions I think.
That wouldn't affect the power, but I'm fairly sure that this will not affect heating of the IC much. I did the 100ms switching test also with lower power settings. With power setting 200 the heating rate is still very high, but the PWM is cycling every 2ms (look at scope image 1 of your previous post).

In scope image 1 of your last post (NXT Motor at 50% – 100 ms switching) I don’t see the switching. The trigger line is at 100ms where the driver switches direction but it never switches back again and afaics the time division is 100ms.
That image does show a couple of interesting things though:

  1. The NXT uses full power for more than 300ms after the direction change and then starts to pull down the driving voltage for increasing times until the high-low time is about 50-50 (50% power setting). This can only mean that the NXT was using a form of speed control during this test.
  2. Unlike the BrickPi the NXT doesn’t use 10 waves of 2ms for the PWM (compare this image with the first image of your previous post).
  3. The NXT uses PWM on the high voltage line, so if the direction switches the PWM signal goes from line ‘A’ to line ‘B’. BrickPi always uses PWM on the same line and switches the other line between 0 and 9V to change direction. Note that this probably is not the cause of overheating. I ran the 100ms test program with alternating: 100% forward - full stop, and it would still heat up the IC.

The scope image “BrickPi Motor at 100% – 10 ms switching” clearly shows that BrickPi isn’t capable of that switching frequency. It can roughly do a period of 25ms, but with considerable jitter. The NXT handles the 10ms quite well, most likely because the program is running on the NXT micro controller directly, whereas the BrickPi has some overhead from RPi to BrickPi communication.

Anyway, I don’t see any direct clues in these images why the driver IC should be overheating or failing. If possible try to measure the current as well.

Hi, it seems I’ve faced the same issue: yesterday I’ve implemented a remotely controlled 3-motor car with BrickPi. This part was really fun :slight_smile: Unfortunately it stopped after about 2 minutes of operation, and never recovered after. The smell was like something has burned out there, although there are no visible damages. Currently BrickPi constantly spins one of these motors when connected, and can spin another one only in one direction; in any other sense it seems it works fine.

I don’t think I did something wrong - the brick was connected to 8xAA battery source, and all the tests were working fine until I started to run the car. I suspect only one possible reason: the car has pretty big wheels, so probably two of its motors very power-consuming.

So a few questions:

  • Should I order a new BrickPi, or it’s the case when it must be replaced by Dexter Industries?
  • Am I correct it’s safer to use 6xAA power box instead of 8xAA with BrickPi?
  • Are there any instructions helping to avoid similar issues in future? I’m anyway going to implement a programmatic protection for this by slowing down the motors when they’re slowed down by an external force, but I’m curious if there are better ways to manage this.

Hey Alexyakunin,
If all motors were operating properly and now don’t, the chip might have been damaged. Can you contact us through our website about this?

To answer a few of your questions though:

  • It’s safer to use the 6XAA battery power box. This doesn’t work terribly well with the Model B, but works better with the B+ (which has a much more forgiving power setup).
  • In our latest firmware (which is beta) we’ve eliminated the ability to change motor directions within a few ms. We’ve been back to this problem a few times and the best we can find is that there’s some damage to the chips when direction is changed too quickly (the breaking action seems to damage the chips). It also can cause the Pi to reset because of a heavy voltage draw. We’ve tried to address this in the latest firmware.

Quick update: Dexter Industries sent me the replacement unit the same day, and the case was handled extremely well on their side.

As far as I understand, my issues is related to a combination of factors: I used Raspberry Pi B+ (which normally requires less power) with 8xAA battery pack, + likely the vehicle I assembled required more power to apply to motors due to larger wheels.

Hello, I am having what seems to be the exact same issues discribed here. I have been happy with my BrickPi for about two months now, running it mostly via the BrickPi C API and 8xAA battery pack that came in the kit on top of the pi B. Up untill yesterday, I have only been using the BrickPiUpdateValues() function after adjusting my motor values to move the robot.

However, the first time that I used the function
motorRotateDegree(power, degree, ports, 0, 0);
(as suggested in a previous post) in the Python API

one of my motors now refuses to turn forward, and will only go backwards. In fact, even after I shut down the system there remains a voltage on one motor port (I assume from some cap) which resists motion in the forward direction on any motor I try.

Now, I have been having motor issues for a few weeks where one motor would spin many more degrees than the rest; I tried to resolve the issue with this function and an updated python API I found on Dexter Industries Github.

It seems like all my motors are failing now, and we have a school competition comming up soon that depends on the BrickPi.

This seems like a hardware defect, and I am not sure what to do. Any help would be very appreciated!

Thank you!

azriel, can you please try running the example python program “LEGO-Motor_Test.py”. If you don’t have the latest version, please update it using the git commands.

Do the motors run?

Hello, thanks for your quick responce.

I just ran LEGO-Motor_Test.py from the latest repo; the motors all run forward, though the defective port is not running it’s motor backwards when all the other ports are doing so. There is also a delay in when each motor stops, that is very noticable and prohibits the robot from going on a straight path.

thanks again for your help.

At this point I guess there is nothing I can do but buy another one for $80 because I can’t afford to have the rest of the motors failing like this in our competition.

I am actually afraid to use the motorRotateDegree function and try to get fast encoder readings, if my next BrickPi will have the same failing feature, I will have wasted $160 on this project. All I really wanted was motor sync of some sort.

I hope there is someone from Dexter Industries who can help me with my hardware failure. My team is very disapointed that the project is idle. So far I have not gotten any responce.

Azriel, can you please contact us through our website, we’ll try to handle this and make it right.

http://www.dexterindustries.com/site/?page_id=65