this is one of those ideas that keeps popping up (mostly in the context of robotics use-cases).
I am mostly interested on opinions, or if such a thing could be technically / economically feasible.
ADD: well, they basically exist, but are generally crazy expensive, so it is more a question of if they could be made more cost-competitive with conventional "dumb" motors.
typically, when building something using motors, there are several types of issues:
needing to power the motor;
needing to control the motor.
for very small motors, it is easy enough to drive the motor over light-gauge wire (say, pairs of 24AWG stranded wire). however, much past a few amps, and progressively heavier wire is needed.
ideally, you would run power to the motors separate from the controls, where if a project uses multiple motors close together, all of these can share the same power connections (say, by daisy-chaining off the same wires).
or, you can use motor-drivers (such as Talon or Jaguar modules), but these are fairly limited and expensive (you give them PWM to control the motor, and there is generally no feedback about motor status, and for smaller motors they may cost significantly more than the motor). if you want feedback on a DC motor, generally an encoder is needed, which in turn means more wires and more IO pins (and cost).
I am not rolling in money, so have generally ended up building my own driver boards.
I have ended up using synchronous wye motors some (such as HDD spindle motors, or a converted car alternator), which do a few nifty things:
they can either be run fast (like DC motors), at a controlled speed and number of turns (like a stepper), or fast and for a controlled number of turns (say, you can quickly ramp the motor up to full speed, then ramp down and brake to get the motor to the desired position).
likewise, there is no need for an external encoder (back-EMF is used).
typically 4 IO wires are needed, basically 3 PWM signals (for the phases), and a pin to feed back commutation pulses (from some logic which "listens" to the EMF).
however, the boards for this tend to be a little bulky.
but, I have also seen computer fans, where you have a small motor which basically just spins a fan, and a data wire is used both to listen to the fan, and also to indicate to it what the desired speed is. the controller is basically built into the fan (the coils are typically mounted directly to the controller).
so, the basic idea here is:
what if there were something like a computer fan, just with a somewhat more powerful motor (say, 50 or 100 watt);
ideally at a sane cost (say, $25 per motor, for this size, more for bigger or less for smaller);
and with a more capable control protocol (and dynamic load-sensitive performance tuning);
also preferably not significantly larger than a raw motor.
something similar has been done already with larger industrial motors (they mount a VFD directly onto the motor), and control them over Ethernet or similar.
so, possible idea for the this could be to stick an MCU (say an ATmega or similar) and driver electronics onto the motor (probably behind the coil and rotors), probably with the H-bridge transistors and similar encased in a ceramic package and heat-sink or similar.
likely, the MCU could use a high-level control protocol (vaguely more like that of a VFD) as opposed to PWM signals. I am half-imagining something similar to Ethernet, except done with RS-232 fed through a balun (RX and TX would use a shared wire, and the device could detect packet collisions by noting if its sent message comes back mangled).
possibly a single twisted pair could be used, with the motors connected together via a hub (likely using punch-down connectors or spring-loaded vampire-connectors or similar). when powered on, the motors could try to establish communication parameters with the hub or host controller (such as identifying the transmission speed, by default could assume 57600 or 115200).
the reason for using a twisted pair and a balun (for differential signaling) is to try to reduce the effects of noise on the wires (motors are very noisy), and RS-232 because MCUs tend to support it built-in.
each motor could have a MAC address or similar (unique per motor), but would dynamically configure a smaller (say, 5/12-bit) address to identify itself with (vaguely similar to ARP and DHCP), which would be used for primary communication (bus may be slow, so it is preferable to use small messages).
commands sent to the motor would be things like movement commands or setting parameters, and the motors could give status feedback (responses to commands, or indicating when a motor has reached its target, ...).
possibly, it could also be applied to things like solenoid coils, steppers, ...
most messages would be host-to-motor or motor-to-host, so we could save a few bytes by using a compact message format, say:
000a-aaaa 0sss-ssss [tag, data, ...] (host-to-motor, 5-bit addr)
010a-aaaa 0sss-ssss [tag, data, ...] (motor-to-host, 5-bit addr)
100/110 reserved
0010-aaaa aaaa-aaaa 0sss-ssss [tag, data, ...] (host-to-motor, 13-bit)
0110-aaaa aaaa-aaaa 0sss-ssss [tag, data, ...] (motor-to-host, 13-bit)
1010-aaaa aaaa-aaaa 0000-bbbb bbbb-bbbb 0sss-ssss [tag, data, ...] (motor-to-motor)
111t-tttt 0sss-ssss [MACa [MACb] ...] (intended mostly for motor configuration).
probably a simplistic TLV format would be used for message data.
if built by hand, I don't think it would really be practical for particularly small motors (due to limits of how small I can build things with perfboard and through-hole construction), but if made commercially, possibly specialized PCBs with surface-mount parts could be made for smaller motors (similar to computer fans).
thoughts?...
I am mostly interested on opinions, or if such a thing could be technically / economically feasible.
ADD: well, they basically exist, but are generally crazy expensive, so it is more a question of if they could be made more cost-competitive with conventional "dumb" motors.
typically, when building something using motors, there are several types of issues:
needing to power the motor;
needing to control the motor.
for very small motors, it is easy enough to drive the motor over light-gauge wire (say, pairs of 24AWG stranded wire). however, much past a few amps, and progressively heavier wire is needed.
ideally, you would run power to the motors separate from the controls, where if a project uses multiple motors close together, all of these can share the same power connections (say, by daisy-chaining off the same wires).
or, you can use motor-drivers (such as Talon or Jaguar modules), but these are fairly limited and expensive (you give them PWM to control the motor, and there is generally no feedback about motor status, and for smaller motors they may cost significantly more than the motor). if you want feedback on a DC motor, generally an encoder is needed, which in turn means more wires and more IO pins (and cost).
I am not rolling in money, so have generally ended up building my own driver boards.
I have ended up using synchronous wye motors some (such as HDD spindle motors, or a converted car alternator), which do a few nifty things:
they can either be run fast (like DC motors), at a controlled speed and number of turns (like a stepper), or fast and for a controlled number of turns (say, you can quickly ramp the motor up to full speed, then ramp down and brake to get the motor to the desired position).
likewise, there is no need for an external encoder (back-EMF is used).
typically 4 IO wires are needed, basically 3 PWM signals (for the phases), and a pin to feed back commutation pulses (from some logic which "listens" to the EMF).
however, the boards for this tend to be a little bulky.
but, I have also seen computer fans, where you have a small motor which basically just spins a fan, and a data wire is used both to listen to the fan, and also to indicate to it what the desired speed is. the controller is basically built into the fan (the coils are typically mounted directly to the controller).
so, the basic idea here is:
what if there were something like a computer fan, just with a somewhat more powerful motor (say, 50 or 100 watt);
ideally at a sane cost (say, $25 per motor, for this size, more for bigger or less for smaller);
and with a more capable control protocol (and dynamic load-sensitive performance tuning);
also preferably not significantly larger than a raw motor.
something similar has been done already with larger industrial motors (they mount a VFD directly onto the motor), and control them over Ethernet or similar.
so, possible idea for the this could be to stick an MCU (say an ATmega or similar) and driver electronics onto the motor (probably behind the coil and rotors), probably with the H-bridge transistors and similar encased in a ceramic package and heat-sink or similar.
likely, the MCU could use a high-level control protocol (vaguely more like that of a VFD) as opposed to PWM signals. I am half-imagining something similar to Ethernet, except done with RS-232 fed through a balun (RX and TX would use a shared wire, and the device could detect packet collisions by noting if its sent message comes back mangled).
possibly a single twisted pair could be used, with the motors connected together via a hub (likely using punch-down connectors or spring-loaded vampire-connectors or similar). when powered on, the motors could try to establish communication parameters with the hub or host controller (such as identifying the transmission speed, by default could assume 57600 or 115200).
the reason for using a twisted pair and a balun (for differential signaling) is to try to reduce the effects of noise on the wires (motors are very noisy), and RS-232 because MCUs tend to support it built-in.
each motor could have a MAC address or similar (unique per motor), but would dynamically configure a smaller (say, 5/12-bit) address to identify itself with (vaguely similar to ARP and DHCP), which would be used for primary communication (bus may be slow, so it is preferable to use small messages).
commands sent to the motor would be things like movement commands or setting parameters, and the motors could give status feedback (responses to commands, or indicating when a motor has reached its target, ...).
possibly, it could also be applied to things like solenoid coils, steppers, ...
most messages would be host-to-motor or motor-to-host, so we could save a few bytes by using a compact message format, say:
000a-aaaa 0sss-ssss [tag, data, ...] (host-to-motor, 5-bit addr)
010a-aaaa 0sss-ssss [tag, data, ...] (motor-to-host, 5-bit addr)
100/110 reserved
0010-aaaa aaaa-aaaa 0sss-ssss [tag, data, ...] (host-to-motor, 13-bit)
0110-aaaa aaaa-aaaa 0sss-ssss [tag, data, ...] (motor-to-host, 13-bit)
1010-aaaa aaaa-aaaa 0000-bbbb bbbb-bbbb 0sss-ssss [tag, data, ...] (motor-to-motor)
111t-tttt 0sss-ssss [MACa [MACb] ...] (intended mostly for motor configuration).
probably a simplistic TLV format would be used for message data.
if built by hand, I don't think it would really be practical for particularly small motors (due to limits of how small I can build things with perfboard and through-hole construction), but if made commercially, possibly specialized PCBs with surface-mount parts could be made for smaller motors (similar to computer fans).
thoughts?...
Last edited: