7 ms·

ODrive Project – Using inexpensive brushless motors in high performance robotics

234 points by madcowswe 9y ago

MichailP 9y ago
Can someone more familiar with embedded design explain a bit more on this? Can this really turn cheap motors into industrial level motors suitable for hobbyists?
- TFortunato 9y ago
  I'm on a cell phone, so I'll be brief, but can add more detail later. I've been doing motor drivers and embedded work (software and electronics) for robotics for a while, and did work on motor driver ICs before that, so this is kind of my wheelhouse! Briefly: I can tell you that the electronics and software are only a few parts of the overall equation here. Yes, this does look like (from the demo video results), a decent driver design, however quality of the motor DOES matter, and will eventually become a limiting factor if you are lookig for high precision or high power, as you start to run into things like torque digging, motor heating, etc. There are also little things in the driver design that can bite you if you aren't careful, but I'd need to look at the schematics to comment. I'm not trying to crap on the project or designer. There was clearly some thought and care put into this! I just don't want people to expect magic, or to think that the only difference between an industrial servo and a hobbyist motor is the electronics. That said, you can get VERY far with good electronics and control software! A hobbyist project will probably do just fine with something like this (or a motor driver reference design from the chip manufacturers), and by the time they run into limits of those designs and hobbyist motors, they'll probably have a pretty good idea of where they need to go as a next step! I'll take a closer look at this design later, and update if anyone is interested.
  - gvb 9y ago
    Please :-) Here are the documentation links to get you started: Hardware: https://github.com/madcowswe/ODriveHardware/ https://github.com/madcowswe/ODriveHardware/ v3.2 schematic: https://github.com/madcowswe/ODriveHardware/blob/master/v3/v3.2docs/schematic_v3.2.pdf https://github.com/madcowswe/ODriveHardware/blob/master/v3/v... Firmware: https://github.com/madcowswe/ODriveFirmware https://github.com/madcowswe/ODriveFirmware PC config and analysis support: https://github.com/madcowswe/ODrive https://github.com/madcowswe/ODrive FPGA: https://github.com/madcowswe/ODriveFPGA https://github.com/madcowswe/ODriveFPGA "... the FPGA logic and software that runs on the FPGA based ODrive. This is not currently in development, but may be resumed at some later date." ---- The hardware is based on a STM32F405RGT6[1] driving two TI DRV8301 brushless motor controller chips[2] and a bunch of MOSFETs to handle the power switching. I/O is a USB, CAN with driver chip, and SPI unbuffered on headers. [1] High-performance foundation line, ARM Cortex-M4 core with DSP and FPU, 1 Mbyte Flash, 168 MHz CPU, ART Accelerator http://www.st.com/en/microcontrollers/stm32f405rg.html http://www.st.com/en/microcontrollers/stm32f405rg.html [2] DRV8301 Three-Phase Gate Driver With Dual Current Shunt Amplifiers and Buck Regulator http://www.ti.com/lit/ds/symlink/drv8301.pdf http://www.ti.com/lit/ds/symlink/drv8301.pdf
    - carterehsmith 9y ago
      Sorry for being off-topic. I just want to say, "STM32F405RGT6" is possibly the most hardcore product/model name ever. Just beautiful.
      - revelation 9y ago
        There are usually a dozen variants of the same microcontroller design just with different peripherals, amount of memory, packaging.. You could just as well say STM32 or STM32F4 and that is pretty much 99.9% of the information you need to know :)
      - makomk 9y ago
        It packs a lot of information in. STM32F4 is ST Micro's range of high-performance ARM Cortex-M4 microcontrollers with FPU, STM32F405 is a particular family of devices in that range differing mainly in package and memory size, R specifies that it's the 64-pin variant, G indicates that it's the version with 1024KB of flash, T is the LQFP package, and 6 is for -40 to 85 °C temperature range. Most of this is shared across the entire STM32 range of devices.
- tyingq 9y ago
  I suspect there's no free lunch here. If they are designed for hobby r/c aircraft, they are designed for shorter runs with lots of free prop-driven fan cooling. Not for sustained runs without a prop cooling it. So, it would likely work, but have a shorter lifetime. The barrier to using them was having a low voltage / high current controller. This fills that gap. So, not a bad idea, but there's almost surely a durability tradeoff. And maybe that's fine for a hobbyist cnc application.
  - TaylorAlexander 9y ago
    Cooling can be an issue if you drive them near their rated power without adequate cooling. And absolutely they won't have the same quality of construction as true industrial devices. However they are sufficiently powerful to be useful and cost effective at continuous duty levels below their max rated power.
  - madcowswe 9y ago
    One thing to keep in mind is that for many robotics applications, the duty cycle for high torque (i.e. acceleration) is often quite low. So they may still run fairly cool.
- analog31 9y ago
  Historically, hobbyists have chosen stepping motors because they can be controlled with a fairly simplistic controller, and there are lots of solutions out there... check out some of the step motor drive boards at Pololu Electronics. But stepping motors have limitations, namely speed and torque per unit motor size. Note that as a hobbyist, I'm still living in the stepper motor world, so I'm interested in this project. Brushless servo motors offer the potential for much higher torque and speed in a small package, but require a different form of electronic control, and the gist of this project is that such controls haven't been available for hobbyists. So it's a matter of finding a gap in the existing project / product space, and filling it. Note that e-bikes use brushless servo motors, so somebody has done the math on what motor technology is most efficient. I also think these motors are in electric cars, and even appliances such as washing machines. I will be reading with interest. I'll also start keeping an eye out for what kinds of motors are available. As for "industrial level," I'd say that it's a matter of pushing machine speeds up to a level similar to what you might see in a factory. Often, with stepper motor driven gadgets, you accept the fact that your machine will take a long time to do anything, but who cares, it's a hobby. On the industrial side, you very quickly run into the situation where your motor is no longer the limiting factor affecting speed and precision, but the design and assembly of the mechanism is.
  - TFortunato 9y ago
    Yeah, brushless is definitely the way to go for efficiency, and good smooth motion. Stepper for an e-bike or washing machine (Not a BLDC either, but...) would be nuts, and in general steppers are really for cheap semi-decent control, not for anything where precision is really needed.
    - TaylorAlexander 9y ago
      My colleague had a motor from a newer washing machine out on his desk, and it did appear to be a BLDC. Alternating magnets with three phases of coils as you'd expect. Driven from rectified 120V AC!
      - TFortunato 9y ago
- bsder 9y ago
  Sure, the issue with brushless motors isn't the motor, it's the encoder. The encoder is what "closes the loop" and allows you to get the accuracy you need. If you have a way to relate the position of the thing being controlled to the motor position, then you can use any motor. So, it's a nice driver, but it doesn't make the encoder any cheaper.
  - TFortunato 9y ago
    That's a bit of an over simplification, but for a hobbyist application, sure. You are absolutely right that the encoder is a BIG part of your system design, but the motor quality will make a difference. If you are doing something like a robotic arm, or slow speed motor control, you don't just care about encoder ticks, you also start caring about things like torque ripple in the motor if you want decent motion quality, regardless of how good your encoder is!
  - _up 9y ago
    You can get cheap Magnetic Encoders. https://www.aliexpress.com/wholesale?catId=0&SearchText=magnetic+encoder https://www.aliexpress.com/wholesale?catId=0&SearchText=magn...
- pasta 9y ago
  Most industrial motors are also 'cheap', but controlling them is expensive. There are two things that matter: accuracy and repeatability. Most of the time accuracy is not a problem. But repeatability is. For example when you move something heavy a motor can loose a step. When you don't know this the rest of the accurate moves are out of control. That's why industrial controllers have good feedback systems. They know a step was performed. If not, you can act on it. So it's more about control than about motors. But cheap motors wear out faster.
  - TFortunato 9y ago
    "Losing a step" makes me think you are thinking about stepper motors, which can be a problem, but for brushless motors it's a bit more complicated than that, since we don't drive them in the same stepwise fashion.
    - pasta 9y ago
      Yes I simplified. But in a way servos are also step/pulse controlled. Edit: as other point out 'controlled' is not the best word here. Maybe 'positioned' would have been better.
      - jacquesm 9y ago
        No, they are not, servos simply do not step, and whatever pulse there is is PWM to control the torque without overheating the driver in an analogue domain. There is no reference based on a 'step' or a 'pulse', there is only the desired position and the actual position and the difference between the two can be quite large, much larger than with a stepper which can by definition be at most one step ahead or behind or it is game over. This gets very interesting once you start to combine servos on multiple axis and you want to limit your maximum error compared to some desired trajectory.
        pasta 9y ago
        I know servos don't step, but doesn't the decoder 'count' steps? But I totaly agree with you, they are completely different. Maybe in this case it was not very clever to oversimplify the problem. By the way: you point out what I think is great about this business. So much work has been done to control motors very accurate. It's amazing what CNC machines can do today. And also how software optimized motion paths (gcode). And now this hardware. Great stuff!
- TaylorAlexander 9y ago
  Yes. There are caveats related to long term durability, but you said "for hobbyists" who I think are less concerned with that aspect. As far as up front performance the answer is yes. Others have explained the details so I'm just adding to the "yes" camp. Brushless D.C. Motors are the way to go for robotics in many actuation situations for the near to medium term (next decade at least) and the lack of suitable low cost controllers (this is "low cost") has been a major issue, so this product is excellent. Source: am robotics engineer in Silicon Valley building my own brushless powered robot arm as a hobby and I'm an alpha contributor to the Odrive project. I've also designed my own brushless controllers [1] and built brushless linear motors. [1] https://youtu.be/vbrzxlRpC0k https://youtu.be/vbrzxlRpC0k
hla19 9y ago
Brushless motors are more expensive. There are open source drivers such as simonk and blheli and they are pretty popular in drone DIY world.
- moorage 9y ago
  Not more expensive than high power servo-motors! Hard to get low-RPM and position control from most drone motor controllers for robotics. I think it's mostly just different use-cases :)
- kawsper 9y ago
  When you mention BLHeli, don't forget BLHeli_S, and (soon) BLHeli_32 which is a re-implementation written in C (before it was assembler) built to run on 32-bit hardware (before it was 8-bit), but sadly the project is closed source :-(
chii 9y ago
i hate sites that autoplay video, especially if there's audio involved. How difficult is it to make it only play when the play button is pressed?
- yoodenvranx 9y ago
  Yes, somebody should scan all the links on YC for autoplaying videos and ads, rate the severity and provide the results via an API so that one can use a greasemobkeyscript/browser extension to highlight all the shitty links.
- moreati 9y ago
  I use https://chrome.google.com/webstore/detail/disable-html5-autoplay/efdhoaajjjgckpbkoglidkeendpkolai https://chrome.google.com/webstore/detail/disable-html5-auto... to address this
- Retr0spectrum 9y ago
  Personally, I got a completely blank page until I allowed a couple of domains to run scripts.
TaylorAlexander 9y ago
Glad to see you on HN! I'm an alpha contributor. I can't wait to put this thing in my brushless robot arm! I still gotta make that forum post. :-D
stevendhansen 9y ago
Very impressive! I love to see this kind of thing on HN. I scanned through your code a bit on mobile, and here are a few quick suggestions: 1) It looks like you are using field oriented control. This is used 99% of the time in industry, but if you really want high torque bandwidth you should check out alternate control techniques. My favorite is an up-and-coming algo developed at UW-Madison called Deadbeat Direct Torque and Flux Control (DB-DTFC when searching for papers). It uses an inverse motor model paired with rotor/stator flux estimators to produce a deadbeat (one timestep later) torque and flux response. I have heard apocryphal stories of people who implement DB-DTFC accidentally snapping motor shafts when they forget to limit the torque slew rate. It is a very high performance algorithm, and beats FOC and DTC hands down at the cost of a bit more complexity. 2) If you are sticking with FOC for now, you can make a few quick improvements that will help a lot. First add qd-axis decoupling on you current loop commands (may have missed them, but I didn't see them in your code). You will want reference frame speed ("omega") decoupling multiplied by current and the transient inductance of the machine, which undoes a lot of the cross coupling that causes issues at high speeds or fast changes in torque. Flux decoupling will help with integrator wind-up, and stator resistance decoupling also helps lessen integrator wind-up at low speeds. 3) Have you considered implementing a sensorless algorithm? It can be done with both FOC or DB-DTFC, although there are some constraints on changing your switching frequency on the fly. If you have a fixed switching frequency a common technique is to superimpose a high frequency carrier on top of your voltage commands and then demodulate the high frequency response in the currents. Since a BLDC has salient poles on the rotor, this technique lets you estimate speed even down to zero! Then you wouldn't need encoder/resolver feedback which would be especially nice for robotics projects. 4) If you really want to get all of the current out of those FETs check out discontinuous PWM strategies. This are especially helpful at low speeds when your applied voltage is low, and can lower your switching losses enough to give you an extra ~40% current rating. Great work overall. The hardware looks really clean and well designed, and it is easy to tell you put a lot of thought and effort into the site and this project.
- Animats 9y ago
  3) is interesting. Sensorless operation is common for running motors, but usually doesn't sense position when the motor is stopped, or being moved by external forces. So if you put a carrier on the power signals, you can potentially sense position, even at zero speed? No need for even Hall sensors? There's a paper from 2001 on that.[1] But it doesn't seem to be a mainstream technique. Are there problems with that approach? If it worked well, you'd expect to see it built into common motor control ICs by now. This paper [2] indicates some of the problems. Detecting the sensing signals in the presence of noise is reported to be hard, especially for small motors. It's a PhD thesis topic.[3] Looking for info about this, I'm finding academic papers, but not IC data sheets. It would sure be nice to have motors with full positional feedback and only 3 wires, instead of 16. [1] http://ieeexplore.ieee.org/document/955987/ http://ieeexplore.ieee.org/document/955987/ [2] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3231115/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3231115/ [3] http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1056&context=elecengtheses http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=10...
zkms 9y ago
The website mentions "supports power regeneration" but I couldn't find any reference to it inside the code. Can someone who knows about this explain how it works, both in the hardware and in the software? I'm super curious to be honest, I know some basic electronics but have never designed a circuit this complex before.
- madcowswe 9y ago
  So this product is still in development. Hence the hardware is ready for regeneration, but right now the firmware doesn't support it yet. In principle it works by just putting a high charge current capable battery on the DC bus, and simply dumping the regeneration current onto the bus, and the battery will eat it, as the bus voltage rises. The "Architecture" heading, a bit down on this page explains more: https://hackaday.io/project/11583-odrive-high-performance-motor-control https://hackaday.io/project/11583-odrive-high-performance-mo...
  - zkms 9y ago
    Ah ok -- thanks for the link! Do you know how this (dumping regenerative current on the supply bus) would work if there are multiple motor channels on the same bus that are simultaneously regenerating at the same time?
- stevendhansen 9y ago
  The power electronics are built using MOSFET half-bridges, which naturally support the ability to flow current in either direction. This allows current to flow from battery to motor or from motor to battery (regeneration). In regeneration the motor is actively slowing down the speed (creating negative torque) by pushing energy into the battery. This is achieved in software by regulating a "negative" current, which causes the inverter to produce a voltage that is lower on average than the back EMF generated by the motor. Because the motor is effectively at a higher voltage than the inverter in this condition, current will flow from high voltage to low voltage and therefore flows back through the MOSFETs (and MOSFET body diodes) into the battery. This is a bit of an over-simplification as brushless DC motors are actually excited by an AC waveform so the current is constantly reversing each half cycle, but the principle remains the same.
fest 9y ago
I have been following this project since it was published on hackaday.io. Congratulations to Oskar and the rest of the contributors for getting it to at least alpha production. Question: I could not find information on what kind of control modes are supported- position, velocity, current/force? Aside: I have previously used another similar product: VESC, which was born as a driver for electric skateboard motors (Odrive was not available yet). I used two of them in current control mode with feedback from magnetic encoders. Since motor current is proportional to torque, it's quite useful control scheme if the motion equations of the system can be expressed in terms of force/torque (which most of them are, if you think about it). One such example is car's accelerator pedal: it controls the torque exerted by motor, which exerts force against road, which makes mass to accelerate. The acceleration in turn increases velocity of the car, which in turn changes the car's position. While this looks obvious after one has thought about it, it actually means that the common linear control methods (e.g. PID) won't work optimally (if at all) if you try to control position by changing acceleration.
- madcowswe 9y ago
  Position, velocity and current/force are the currently supported modes, see: https://github.com/madcowswe/ODriveFirmware/blob/master/MotorControl/low_level.c#L168-L187 https://github.com/madcowswe/ODriveFirmware/blob/master/Moto... Coming soon will also be go-to commands which track 3-rd order polynomial position trajectories.

234 points by madcowswe 9y ago

Can someone more familiar with embedded design explain a bit more on this? Can this really turn cheap motors into industrial level motors suitable for hobbyists?

TFortunato 9y ago
I'm on a cell phone, so I'll be brief, but can add more detail later. I've been doing motor drivers and embedded work (software and electronics) for robotics for a while, and did work on motor driver ICs before that, so this is kind of my wheelhouse! Briefly: I can tell you that the electronics and software are only a few parts of the overall equation here. Yes, this does look like (from the demo video results), a decent driver design, however quality of the motor DOES matter, and will eventually become a limiting factor if you are lookig for high precision or high power, as you start to run into things like torque digging, motor heating, etc. There are also little things in the driver design that can bite you if you aren't careful, but I'd need to look at the schematics to comment. I'm not trying to crap on the project or designer. There was clearly some thought and care put into this! I just don't want people to expect magic, or to think that the only difference between an industrial servo and a hobbyist motor is the electronics. That said, you can get VERY far with good electronics and control software! A hobbyist project will probably do just fine with something like this (or a motor driver reference design from the chip manufacturers), and by the time they run into limits of those designs and hobbyist motors, they'll probably have a pretty good idea of where they need to go as a next step! I'll take a closer look at this design later, and update if anyone is interested.
- gvb 9y ago
  Please :-) Here are the documentation links to get you started: Hardware: https://github.com/madcowswe/ODriveHardware/ https://github.com/madcowswe/ODriveHardware/ v3.2 schematic: https://github.com/madcowswe/ODriveHardware/blob/master/v3/v3.2docs/schematic_v3.2.pdf https://github.com/madcowswe/ODriveHardware/blob/master/v3/v... Firmware: https://github.com/madcowswe/ODriveFirmware https://github.com/madcowswe/ODriveFirmware PC config and analysis support: https://github.com/madcowswe/ODrive https://github.com/madcowswe/ODrive FPGA: https://github.com/madcowswe/ODriveFPGA https://github.com/madcowswe/ODriveFPGA "... the FPGA logic and software that runs on the FPGA based ODrive. This is not currently in development, but may be resumed at some later date." ---- The hardware is based on a STM32F405RGT6[1] driving two TI DRV8301 brushless motor controller chips[2] and a bunch of MOSFETs to handle the power switching. I/O is a USB, CAN with driver chip, and SPI unbuffered on headers. [1] High-performance foundation line, ARM Cortex-M4 core with DSP and FPU, 1 Mbyte Flash, 168 MHz CPU, ART Accelerator http://www.st.com/en/microcontrollers/stm32f405rg.html http://www.st.com/en/microcontrollers/stm32f405rg.html [2] DRV8301 Three-Phase Gate Driver With Dual Current Shunt Amplifiers and Buck Regulator http://www.ti.com/lit/ds/symlink/drv8301.pdf http://www.ti.com/lit/ds/symlink/drv8301.pdf
  - carterehsmith 9y ago
    Sorry for being off-topic. I just want to say, "STM32F405RGT6" is possibly the most hardcore product/model name ever. Just beautiful.
    - revelation 9y ago
      There are usually a dozen variants of the same microcontroller design just with different peripherals, amount of memory, packaging.. You could just as well say STM32 or STM32F4 and that is pretty much 99.9% of the information you need to know :)
    - makomk 9y ago
      It packs a lot of information in. STM32F4 is ST Micro's range of high-performance ARM Cortex-M4 microcontrollers with FPU, STM32F405 is a particular family of devices in that range differing mainly in package and memory size, R specifies that it's the 64-pin variant, G indicates that it's the version with 1024KB of flash, T is the LQFP package, and 6 is for -40 to 85 °C temperature range. Most of this is shared across the entire STM32 range of devices.
tyingq 9y ago
I suspect there's no free lunch here. If they are designed for hobby r/c aircraft, they are designed for shorter runs with lots of free prop-driven fan cooling. Not for sustained runs without a prop cooling it. So, it would likely work, but have a shorter lifetime. The barrier to using them was having a low voltage / high current controller. This fills that gap. So, not a bad idea, but there's almost surely a durability tradeoff. And maybe that's fine for a hobbyist cnc application.
- TaylorAlexander 9y ago
  Cooling can be an issue if you drive them near their rated power without adequate cooling. And absolutely they won't have the same quality of construction as true industrial devices. However they are sufficiently powerful to be useful and cost effective at continuous duty levels below their max rated power.
- madcowswe 9y ago
  One thing to keep in mind is that for many robotics applications, the duty cycle for high torque (i.e. acceleration) is often quite low. So they may still run fairly cool.
analog31 9y ago
Historically, hobbyists have chosen stepping motors because they can be controlled with a fairly simplistic controller, and there are lots of solutions out there... check out some of the step motor drive boards at Pololu Electronics. But stepping motors have limitations, namely speed and torque per unit motor size. Note that as a hobbyist, I'm still living in the stepper motor world, so I'm interested in this project. Brushless servo motors offer the potential for much higher torque and speed in a small package, but require a different form of electronic control, and the gist of this project is that such controls haven't been available for hobbyists. So it's a matter of finding a gap in the existing project / product space, and filling it. Note that e-bikes use brushless servo motors, so somebody has done the math on what motor technology is most efficient. I also think these motors are in electric cars, and even appliances such as washing machines. I will be reading with interest. I'll also start keeping an eye out for what kinds of motors are available. As for "industrial level," I'd say that it's a matter of pushing machine speeds up to a level similar to what you might see in a factory. Often, with stepper motor driven gadgets, you accept the fact that your machine will take a long time to do anything, but who cares, it's a hobby. On the industrial side, you very quickly run into the situation where your motor is no longer the limiting factor affecting speed and precision, but the design and assembly of the mechanism is.
- TFortunato 9y ago
  Yeah, brushless is definitely the way to go for efficiency, and good smooth motion. Stepper for an e-bike or washing machine (Not a BLDC either, but...) would be nuts, and in general steppers are really for cheap semi-decent control, not for anything where precision is really needed.
  - TaylorAlexander 9y ago
    My colleague had a motor from a newer washing machine out on his desk, and it did appear to be a BLDC. Alternating magnets with three phases of coils as you'd expect. Driven from rectified 120V AC!
    - TFortunato 9y ago
bsder 9y ago
Sure, the issue with brushless motors isn't the motor, it's the encoder. The encoder is what "closes the loop" and allows you to get the accuracy you need. If you have a way to relate the position of the thing being controlled to the motor position, then you can use any motor. So, it's a nice driver, but it doesn't make the encoder any cheaper.
- TFortunato 9y ago
  That's a bit of an over simplification, but for a hobbyist application, sure. You are absolutely right that the encoder is a BIG part of your system design, but the motor quality will make a difference. If you are doing something like a robotic arm, or slow speed motor control, you don't just care about encoder ticks, you also start caring about things like torque ripple in the motor if you want decent motion quality, regardless of how good your encoder is!
- _up 9y ago
  You can get cheap Magnetic Encoders. https://www.aliexpress.com/wholesale?catId=0&SearchText=magnetic+encoder https://www.aliexpress.com/wholesale?catId=0&SearchText=magn...
pasta 9y ago
Most industrial motors are also 'cheap', but controlling them is expensive. There are two things that matter: accuracy and repeatability. Most of the time accuracy is not a problem. But repeatability is. For example when you move something heavy a motor can loose a step. When you don't know this the rest of the accurate moves are out of control. That's why industrial controllers have good feedback systems. They know a step was performed. If not, you can act on it. So it's more about control than about motors. But cheap motors wear out faster.
- TFortunato 9y ago
  "Losing a step" makes me think you are thinking about stepper motors, which can be a problem, but for brushless motors it's a bit more complicated than that, since we don't drive them in the same stepwise fashion.
  - pasta 9y ago
    Yes I simplified. But in a way servos are also step/pulse controlled. Edit: as other point out 'controlled' is not the best word here. Maybe 'positioned' would have been better.
    - jacquesm 9y ago
      No, they are not, servos simply do not step, and whatever pulse there is is PWM to control the torque without overheating the driver in an analogue domain. There is no reference based on a 'step' or a 'pulse', there is only the desired position and the actual position and the difference between the two can be quite large, much larger than with a stepper which can by definition be at most one step ahead or behind or it is game over. This gets very interesting once you start to combine servos on multiple axis and you want to limit your maximum error compared to some desired trajectory.
      - pasta 9y ago
        I know servos don't step, but doesn't the decoder 'count' steps? But I totaly agree with you, they are completely different. Maybe in this case it was not very clever to oversimplify the problem. By the way: you point out what I think is great about this business. So much work has been done to control motors very accurate. It's amazing what CNC machines can do today. And also how software optimized motion paths (gcode). And now this hardware. Great stuff!
TaylorAlexander 9y ago
Yes. There are caveats related to long term durability, but you said "for hobbyists" who I think are less concerned with that aspect. As far as up front performance the answer is yes. Others have explained the details so I'm just adding to the "yes" camp. Brushless D.C. Motors are the way to go for robotics in many actuation situations for the near to medium term (next decade at least) and the lack of suitable low cost controllers (this is "low cost") has been a major issue, so this product is excellent. Source: am robotics engineer in Silicon Valley building my own brushless powered robot arm as a hobby and I'm an alpha contributor to the Odrive project. I've also designed my own brushless controllers [1] and built brushless linear motors. [1] https://youtu.be/vbrzxlRpC0k https://youtu.be/vbrzxlRpC0k

hla19 9y ago

Brushless motors are more expensive. There are open source drivers such as simonk and blheli and they are pretty popular in drone DIY world.

moorage 9y ago
Not more expensive than high power servo-motors! Hard to get low-RPM and position control from most drone motor controllers for robotics. I think it's mostly just different use-cases :)
kawsper 9y ago
When you mention BLHeli, don't forget BLHeli_S, and (soon) BLHeli_32 which is a re-implementation written in C (before it was assembler) built to run on 32-bit hardware (before it was 8-bit), but sadly the project is closed source :-(

chii 9y ago

i hate sites that autoplay video, especially if there's audio involved. How difficult is it to make it only play when the play button is pressed?

yoodenvranx 9y ago
Yes, somebody should scan all the links on YC for autoplaying videos and ads, rate the severity and provide the results via an API so that one can use a greasemobkeyscript/browser extension to highlight all the shitty links.
moreati 9y ago
I use https://chrome.google.com/webstore/detail/disable-html5-autoplay/efdhoaajjjgckpbkoglidkeendpkolai https://chrome.google.com/webstore/detail/disable-html5-auto... to address this
Retr0spectrum 9y ago
Personally, I got a completely blank page until I allowed a couple of domains to run scripts.

TaylorAlexander 9y ago

Glad to see you on HN! I'm an alpha contributor. I can't wait to put this thing in my brushless robot arm! I still gotta make that forum post. :-D

stevendhansen 9y ago

Very impressive! I love to see this kind of thing on HN. I scanned through your code a bit on mobile, and here are a few quick suggestions: 1) It looks like you are using field oriented control. This is used 99% of the time in industry, but if you really want high torque bandwidth you should check out alternate control techniques. My favorite is an up-and-coming algo developed at UW-Madison called Deadbeat Direct Torque and Flux Control (DB-DTFC when searching for papers). It uses an inverse motor model paired with rotor/stator flux estimators to produce a deadbeat (one timestep later) torque and flux response. I have heard apocryphal stories of people who implement DB-DTFC accidentally snapping motor shafts when they forget to limit the torque slew rate. It is a very high performance algorithm, and beats FOC and DTC hands down at the cost of a bit more complexity. 2) If you are sticking with FOC for now, you can make a few quick improvements that will help a lot. First add qd-axis decoupling on you current loop commands (may have missed them, but I didn't see them in your code). You will want reference frame speed ("omega") decoupling multiplied by current and the transient inductance of the machine, which undoes a lot of the cross coupling that causes issues at high speeds or fast changes in torque. Flux decoupling will help with integrator wind-up, and stator resistance decoupling also helps lessen integrator wind-up at low speeds. 3) Have you considered implementing a sensorless algorithm? It can be done with both FOC or DB-DTFC, although there are some constraints on changing your switching frequency on the fly. If you have a fixed switching frequency a common technique is to superimpose a high frequency carrier on top of your voltage commands and then demodulate the high frequency response in the currents. Since a BLDC has salient poles on the rotor, this technique lets you estimate speed even down to zero! Then you wouldn't need encoder/resolver feedback which would be especially nice for robotics projects. 4) If you really want to get all of the current out of those FETs check out discontinuous PWM strategies. This are especially helpful at low speeds when your applied voltage is low, and can lower your switching losses enough to give you an extra ~40% current rating. Great work overall. The hardware looks really clean and well designed, and it is easy to tell you put a lot of thought and effort into the site and this project.

Animats 9y ago
3) is interesting. Sensorless operation is common for running motors, but usually doesn't sense position when the motor is stopped, or being moved by external forces. So if you put a carrier on the power signals, you can potentially sense position, even at zero speed? No need for even Hall sensors? There's a paper from 2001 on that.[1] But it doesn't seem to be a mainstream technique. Are there problems with that approach? If it worked well, you'd expect to see it built into common motor control ICs by now. This paper [2] indicates some of the problems. Detecting the sensing signals in the presence of noise is reported to be hard, especially for small motors. It's a PhD thesis topic.[3] Looking for info about this, I'm finding academic papers, but not IC data sheets. It would sure be nice to have motors with full positional feedback and only 3 wires, instead of 16. [1] http://ieeexplore.ieee.org/document/955987/ http://ieeexplore.ieee.org/document/955987/ [2] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3231115/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3231115/ [3] http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1056&context=elecengtheses http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=10...

zkms 9y ago

The website mentions "supports power regeneration" but I couldn't find any reference to it inside the code. Can someone who knows about this explain how it works, both in the hardware and in the software? I'm super curious to be honest, I know some basic electronics but have never designed a circuit this complex before.

madcowswe 9y ago
So this product is still in development. Hence the hardware is ready for regeneration, but right now the firmware doesn't support it yet. In principle it works by just putting a high charge current capable battery on the DC bus, and simply dumping the regeneration current onto the bus, and the battery will eat it, as the bus voltage rises. The "Architecture" heading, a bit down on this page explains more: https://hackaday.io/project/11583-odrive-high-performance-motor-control https://hackaday.io/project/11583-odrive-high-performance-mo...
- zkms 9y ago
  Ah ok -- thanks for the link! Do you know how this (dumping regenerative current on the supply bus) would work if there are multiple motor channels on the same bus that are simultaneously regenerating at the same time?
stevendhansen 9y ago
The power electronics are built using MOSFET half-bridges, which naturally support the ability to flow current in either direction. This allows current to flow from battery to motor or from motor to battery (regeneration). In regeneration the motor is actively slowing down the speed (creating negative torque) by pushing energy into the battery. This is achieved in software by regulating a "negative" current, which causes the inverter to produce a voltage that is lower on average than the back EMF generated by the motor. Because the motor is effectively at a higher voltage than the inverter in this condition, current will flow from high voltage to low voltage and therefore flows back through the MOSFETs (and MOSFET body diodes) into the battery. This is a bit of an over-simplification as brushless DC motors are actually excited by an AC waveform so the current is constantly reversing each half cycle, but the principle remains the same.

fest 9y ago

I have been following this project since it was published on hackaday.io. Congratulations to Oskar and the rest of the contributors for getting it to at least alpha production. Question: I could not find information on what kind of control modes are supported- position, velocity, current/force? Aside: I have previously used another similar product: VESC, which was born as a driver for electric skateboard motors (Odrive was not available yet). I used two of them in current control mode with feedback from magnetic encoders. Since motor current is proportional to torque, it's quite useful control scheme if the motion equations of the system can be expressed in terms of force/torque (which most of them are, if you think about it). One such example is car's accelerator pedal: it controls the torque exerted by motor, which exerts force against road, which makes mass to accelerate. The acceleration in turn increases velocity of the car, which in turn changes the car's position. While this looks obvious after one has thought about it, it actually means that the common linear control methods (e.g. PID) won't work optimally (if at all) if you try to control position by changing acceleration.

madcowswe 9y ago
Position, velocity and current/force are the currently supported modes, see: https://github.com/madcowswe/ODriveFirmware/blob/master/MotorControl/low_level.c#L168-L187 https://github.com/madcowswe/ODriveFirmware/blob/master/Moto... Coming soon will also be go-to commands which track 3-rd order polynomial position trajectories.