Trex failures - multiple units

Did something change recently with the manufacture of T-Rexes? (Say within the last 6 months or so?) I’ve used dozens of these things for the same purpose, same motors, same batteries same everything without any problems.

This week I had two customers in different parts of the country using pretty close to identical setups report what sounds like heat caused speed controller failures.

Case 1) - T-Rex driving twin motors, cooled with fan and unblocked vent to outside air. Controlled by a spectrum AR7000 receiver driving channels 1 and 2 with mixing. Default software settings with no serial based programming done. Receiver power supplied by linear regulator rather than the regulator on the speed controller (we have had issues caused by conflicting 5v power sources when power is drawn from the Trex).

This failure was particularly disturbing as the unit failed ‘on’ and drove the robot around in circles with no control. Controller reset when powered down left for a moment and powered back up. Problem is apparently repeatable, but requires the system heat up.

Case 2) - Same setup and system components. TRex is not powering rearward movement of one motor. The other motor and other direction seem to work, but there is a possibility the power to that one failing motor is out in both directions and that the customer was unable to describe the unit’s behavior. The problem is unlikely to actually be in that motor as we’ve had a zero failure rate on these motors and have used more than twice as many of them as we have of T-Rexes. The behavior sounds a lot like a half-bridge or full-bridge failure of half the unit, but as I understand it they have thermal sensors, overcurrent cutouts and a number of other protections. Is that not true? Is it even possible to burn out half the controller given a 12v input, stable/proven wiring and no meddling with the controller itself?

Customer tampering is not a realistic probability. Both units were tested before they were sent out and worked properly. It is theoretically possible that in case 1 the linear regulator supplying power to the receiver is cutting out and leaving the Trex without a signal. If the Trex loses signal does it continue operations according to the last received command or stop movement?

If the solution is replacement of the controllers it will be expensive and require flying out to at least one customer site. It would be a disaster to replace them with more controllers that eventually fail because of a bad manufacturing run, a change in the design which we did not understand or a bugged software update. Any thoughts about what might be causing this?

Hello.

I’m sorry to hear about the problems you’re having. I don’t think we’ve had any recent changes in the basic design or manufacturing process, but we’ll look into it. What kind of current do your motors typically draw? The TReX controllers use integrated motor drivers that have the over-current and over-temperature protection built-in. Loss of the RC signal should not cause the motors to run. In general, we haven’t heard of these kinds of problems; please let us know if you find out anything more that could narrow down the cause of the problems.

- Jan

I went back and double checked the motors. They pull 7A each while under fairly heavy load for our vehicle and max out at 20A when stalled. I’ve never blown a fuse on one of the controllers, but we don’t stall the motors often or for long. The numbers would be for each motor. I’m cooling with a low power fan directed at the underside of the controller. The two units that failed are the only two out of quite a few identical vehicles we’ve built over several years and run under some very stressful conditions (kudos to the T-rexes on those). I’ve personally loaded up a vehicle with trade show equipment plus heavy spare batteries and had it pull a trade show booth. It did it outside in the sun up inclines with no overheating (this is not that unit by the way. That one is still working fine).

Is there a test procedure I can use on the units to find out what is fried when I get them back?

Hello.

We don’t have a specific test procedure we can recommend. I suggest you look for unusually high current draw that might be indicative of a short, and you should visually inspect the board for any scorched areas or melted parts. If you have a USB-to-serial adapter, you can connect the units to your PC and control them using the TReX Configurator program, which is linked from the resources tab of the product page. The configurator has a “Serial Params & Status” tab under the “Parameter Configuration” tab that will let you see if you are experiencing any motor driver faults. The configurator will also tell you what firmware version your controllers have. We released version 1.2 last September, but the changes are minor and should only affect serial control of the device. Still, it would be nice to know if these boards are version 1.2 or the original version 1.0. If you want us to take a look at the boards, please contact me directly at ben at pololu dot com and I’ll give you an RMA number.

When the RC signal cuts out or becomes too noisy, that channel stops affecting the motors. If that channel is designated as a “required channel”, the TReX stops driving the motors and reverts to safe-startup mode. By default, only channel one is designated as a “required channel”. If you are using mixing mode and channel 2 becomes unreliable or cuts out while channel 1 stays active, you will only have control of throttle or steering using channel 1 (depending on how you have your motors connected); channel 2 will have no effect, and you will not lose control of the bot (your control will just be limited to turning in place or driving in a straight line).

- Ben