13
$\begingroup$

I have a robot that uses brushed motors in its servo system. These are Maxon 3W motors, with 131:1 planetary gearboxes. The motors are controlled by a PIC microcontroller, running a 1kHz PID controller. The servos are for a low speed high torque application. There is significant backlash between the sensor and the motor.

Maxon offer 12W brushless motors which are the same size. These are better in many ways: double the torque, better heat dissipation, higher efficiency.

The problem, obviously, is that they require more complex drive electronics. Also, I have heard a couple of people mention that brushed motors are better for servo applications, though they never explained why.

  • Has anyone else implemented this kind of system?
  • Are there any gotchas when using brushed motors for servos?
  • Is it possible to servo it at low speeds if I only have the 3 integral digital Hall sensors, and no encoder? (I would prefer not to add an encoder because of the money and space cost)
  • It torque ripple likely to be a problem?
$\endgroup$

2 Answers 2

6
$\begingroup$

Brushed motors are easier for servo systems, but are not better. Many high end servo systems are brushless/AC.

It is possible to control the motors at low speeds with only 3 hall sensors. You really don't want trapezoidal commutation, especially at low speeds so could add an encoder or estimate the rotor position if necessary.

It is possible to estimate the rotor position with only hall/current sensors but if there are a lot of external disturbances it won't work very well.

Torque ripple is unlikely to be a problem, of course it depends on your application. More advanced commutation methods (sinusoidal or flux vector) essentially eliminate torque ripple.

You say that your application is low speed, but you are also using a 131:1 gearbox. What RPM does the motor normally see? Its not really a low speed application if the motor is running at 30%+ of its rated RPM. Even hall sensors are very high resolution after going through that much reduction so you might not really need low speed performance at the motor itself.

IMHO Given that your current system has significant backlash between the sensor and the motors, I can't imagine a brushless system doing any worse even with halls/trapezoidal commutation.

$\endgroup$
1
  • $\begingroup$ Thanks for the answer. The velocity of the motor ranges from full speed, right down to zero. Sometimes the motor will need to make large rapid movements, and sometimes it will need to make tiny or very slow movements. $\endgroup$ Commented Nov 2, 2012 at 9:16
4
$\begingroup$

In industry, there is a strong preference for low maintenance brush-less motors over relatively high maintenance brushed motors. While the former may me more expensive in terms of the motor itself and the drive electronics, the reduction in the term long cost of maintenance usually out weighs the extra capital cost.

As user65 suggests, you may need sinusoidal commutation to avoid torque ripple at low speeds, depending on precisely how you design your system and how fine you need your velocity control to be.

The paper A Comparison Study of the Commutation Methods for ... has some interesting information commutation methods, which might be of use.

Ultimately though, I think that avoiding using encoders is a false economy.

Unlike halls, they have the distinct advantage that they aren't tied to the motor rotation - i.e. they don't have to go on the motor shaft. You could place them on the load side of the gearbox, which will allow you to quantify the precise effects of the backlash in your gearbox.

This would allow you to to perform backlash compensation in software, run dual servo loops (one for position tracking with backlash compensation and another for more immediate velocity control) and generally take much more precise control of your system both at high and low speeds.

$\endgroup$
5
  • $\begingroup$ Regarding encoders: annoyingly, our system suffers from a high level of very variable backlash. It can vary between 0% and 60% of the load's travel! There's not much we can do about it without making fundamental changes to the nature of our robot. $\endgroup$ Commented Feb 3, 2013 at 23:11
  • $\begingroup$ @Rocketmagnet - Presumably most of your movements are from one end of travel to the other then? If you are making moves of less than 60% of travel I can't see how you can ever know where you are. At least if you add an encoder you would know where you are, even if you don't know how much you have to turn the motor to get somewhere else. Have you published anything anywhere about your robot yet? I would be interested to read more about it. $\endgroup$
    – Mark Booth
    Commented Feb 4, 2013 at 1:35
  • $\begingroup$ On our robot we have analogue position sensors at the load (after the backlash), so I can do reasonable position control. And we have torque sensors at the motor output (before the backlash) so I can at least drive the motor quickly until it feels the backlash being taken up. Still, I'd really prefer not to have any backlash. $\endgroup$ Commented Feb 5, 2013 at 11:50
  • $\begingroup$ @Rocketmagnet - Wouldn't we all. *8') It's why I like working with direct drive linear motors, there your only real problem is cogging and that can be tuned out. Incidentally, do you have a single motor per axis, and have you considered doubling up and having a pair of these high backlash actuators working in opposition? I presume that's how your air muscles are used in the dextrous hand. $\endgroup$
    – Mark Booth
    Commented Feb 5, 2013 at 13:10
  • $\begingroup$ My dream is to use direct drive motors. Sadly other constraints rule these out at the moment. We have a single motor per axis. One motor per tendon would remove the backlash, but massively increase the weight, cost and size. $\endgroup$ Commented Feb 5, 2013 at 16:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.