ODrive - High performance motor control

Hobby brushless motors are incredibly cheap and powerful. However we need a way to make robots out of them. ODrive is that way.

Similar projects worth following
Stepper motors are ubiquitous in hobby robotics projects: If you make a robotics or automation project today, it is very likely you will use them. Almost all DIY projects from 3D printers and CNC mills, to air hockey and juggling robots use them. However in industrial automation, brushless servomotors have taken over, and it's clear why: They don't lose steps, are much more powerful, efficient, and silent.

However, brushless motors are not unique to expensive industrial automation equipment. In fact, you can get some very powerful and cheap motors at hobby shops. The electronics to drive these motors are also dirt cheap. So how come virtually no non-industrial automation systems use them?

To be honest, I have no idea. Seriously, a driver that allows this should clearly exist.
But since it didn't, I decided to make one.

And you are invited!
This project is open source, both in hardware and software, and I warmly welcome anyone who wants to join.

Alpha boards now available!

Get one here, and read more about the release here.

Key specs:

  • 2 motor channels, designed for >100A peak current.
  • 1 DC-DC converter channel
    • For powering the system with an arbitrary voltage power supply, or
    • Use of a brake resistor
  • 24V bus voltage
  • USB, CAN, SPI, and step/dir interface (read more below)
  • Encoder feedback for arbitrarily precise movements
  • Supports power regeneration
  • Use of a high power density Li-Po battery means you can achieve >1kW peak power output with only a modest power supply.
  • It will feature various optimal control strategies and motion profiles.
  • Permissive licence on both hardware and software: You use this project in anything you like, even commercial products (as long as you attribute this project's contributors).


The design is based on two earlier prototypes.

Here are some very simple demos with v2. The peak power output in these tests were only about 60W. The new version (v3) will be able to deliver much more power.

Below is a demo with v1. The mass being moved is 3kg, and the peak power was about 200W. The noise is not from the motor, but from my poor mechanical design which means that the belt teeth rubs against the idler pulley edge.

Stay up to date


  • USB Serial port
    • G-code parser for interfacing with existing automation tools
  • CAN interface
    • Protocol TBD. One possibility is to support a subset of CiA 402.
    • Many types of command modes:
      • Motion profiled position commands
      • Velocity command
      • Torque command
  • Step/direction input
  • Some general purpose digital and analouge pins


The drive is designed to be able to deliver incredibly high peak power, more than 1kW per motor channel. However, power supplies that can deliver this kind of power are expensive. Also, when the actuator is being decelerated, there is energy absorbed. Most power supplies do not like having energy dumped back into them.

The solution: Put high-power energy-storage on the DC bus. A battery like this one can deliver around 3kW. These types of batteries also have a fairly high charge rating, and if the regeneration is only over a couple of 100 milliseconds, they can probably handle a fair bit more than specified. Thus, they should be able to handle the full range of regeneration power in most robotics applications.

This means we have a variable voltage DC bus, that fluctuates with the battery's state of charge. So the way we power the system is via a DC-DC converter. There is another upside to this as well: we can use any voltage power supply and just convert it to the bus voltage. I expect most people will use an inexpensive ATX power supply (specifically the 12V rails). In many robotics applications the motion consists of several discrete movements, only some of which are high power. In this case, we can have access to a very high peak power, but only require a very modest power supply.

Another thing that's nice about using a battery for stabilising the DC bus, is that if multiple of these drives reside on the same bus, there is no fighting over the regulation of the bus voltage: a single board can have the DC-DC connected to a PSU, and the rest of the boards in the system can just use the bus. If fact, you can even skip populating the DC-DC on the slave boards.


So this project is good for some things, but not everything.

You should use this drive in your project if:

  • You need high power: >1kW peak power per channel!
  • You need high precision: Encoder feedback control means that the precision is as high as your encoder's precision, which can be very very high.
  • You need reliability: Encoder feedback ensures that the drive recovers from positioning errors: no more missed steps.

You should not use this drive in your project if:

  • You need high torque, but don't care about speed, and you don't want to use any gearing. If this is the case, steppers are probably better for your project
  • If you are interested in very tiny motors...
Read more »

  • Alpha Preorders Finished

    Oskar Weigl4 days ago 0 comments

    The preorder period of ODrive v3.2 and the corresponding getting started kits has now concluded. To those who joined the project, thank you for your support, and welcome to the alpha stage team! The batch of v3.2's have now gone to manufacture and we are slightly ahead of schedule for shipping things out by the 15th of May.

    I anticipate that there are some people who will want to join mid-way through the alpha stage, so I made sure to order some extra stock. At the time of writing there are 8 kits left and 17 ODrives. They will continue to be available on the ODrive Shop page until stock runs out.

    Again thank you for your support!

  • ODrive v3.2 and Alpha Release

    Oskar Weigl03/27/2017 at 20:31 2 comments

    I am excited to let you know that the time has finally come for the alpha stage of the ODrive project. This consists of two components, the alpha software release and the manufacturing run for ODrive v3.2.

    TL;DR: Get your v3.2 alpha board Here.

    ODrive v3.2

    The new design is ready, and can be reviewed here. The design will go to production on Monday the 17th of April. As a one man team, I would greatly appreciate any and all feedback in from your review. Feel free to leave comments on this post, or write a private message.

    Changes from v3.1

    • Fix current sensor filter capacitor values
    • Break out the SPI port
    • Consolidate all 0.1" headers into two long rows
    • Remove the confusing EV (Encoder Voltage) rail.
    • Add test-points for most interesting analogue signals
    • Add precision LDO for AVCC (analog VCC)
    • Change MOSFETs to a slightly better Rdson version (30% better)
    • Adjust heatsink holes
    • Add fiducials
    • Improve labling

    ODrive v3.2 production run

    You can buy a board in this run on the shop: The expected shipping date is expected to be the 15th of May, and the pre-orders will close on Monday the 17th of April, though some extra stock may be left after that. This is the board revision designed to be delivered simultaneous to the alpha firmware release.

    Firmware alpha release

    You can check which features will be included in the release here. The alpha release will include all the core features of the board, and allow go-to commands sent over USB, as well as step/direction interfacing.

    Proper documentation, setup and tuning instructions will be ready for you by the time that the board ships.

    ODrive is for real

    As I mentioned in the previous post, I finish my day job on Friday, and I will be taking up developing ODrive full time.

    ODrive is a serious product and deserves a website, so I bought the domain, and set up a Squarespace website. As of the time of writing, I have only added the shop page: the reason for putting up that first is to be able to take the payments for this v3.2 pre-order. I've been focusing on getting the v3.2 board ready, and I haven't had time to put the rest up just yet. It will be up soon :)

    The reason I'm sharing this with you now, is because some people astutely pointed out that a website with no content, and only a shop page, looks very suspicious. Rest assured that the site at is mine, and communication from is legitimate. Any payments should go to ODrive SWE, and the address of the business is in Stockholm, Sweden. The VAT number of the business is SE901114035801.

    ODrive forums

    I am deeply impressed with the projects, ideas, skills and contributions that all of you have conveyed to me through various channels. I am really excited to talk to you about your application, how we can build the ODrive community and advance the project. In the next couple of weeks, I will set up an online forum for ODrive, and I hope you will join the community there!

    This will be the place for all kinds of discussions, comments, ideas, feature requests and queries. It will also serve as the main place to get help with your ODrive; where I, and others who will be gaining experience with the board, can all help you and each other. We'd also love to hear about your project: what you wish to do when kilowatts and micrometers meet in an affordable package.

  • Someone please build a parallel cable robot

    Oskar Weigl03/23/2017 at 11:44 7 comments

    I think the ODrive could provide plenty of power to make some really cool high dynamics.

    I was inspired by the Hangprinter discussions over on the RepRap forums.

  • Progress Update

    Oskar Weigl03/10/2017 at 01:48 6 comments

    It's time for an update.

    There has been some significant progress on the software including two major new features. The v3.1 hardware that I wrote about in the previous post has been further tested, this time not only by myself, but by several early developers. We managed to find only one serious hardware bug so far, which is fixed by replacing four capacitors. With the fixes to those bugs, the alpha testing stage is around the corner.

    New Features

    Two new major features are ready: USB Serial and brake resistor control.

    USB CDC - The main way for the ODrive to communicate with a PC or embedded computer (such as the RaspberryPI) is via USB Serial (aka USB CDC). This interface will be used both for sending configuration and commissioning commands, and interfacing with existing tools that have G-Code style output. With further extension, it can also support binary, and various application specific, protocols. Yay for open source.
    With significant help and contribution from @nickaknudson we now have a working USB CDC interface, which runs in a task parallel to the motor control tasks. The current implementation is very basic, it parses the commands and relays position commands directly to the motor control task. Going forward we will add trajectory generation to support coherent movement between multiple axes. Then we can handle the basic G0 and G1 G-Code "go-to" commands.

    Brake resistor - Software support for a brake resistor is now in place. This means that we can safely dissipate the energy absorbed when decelerating. This is important since many power supplies cannot handle reverse energy flow. The implementation has the two motor controllers estimate their power draw, and then calculates the net power draw from the power rail. If it is negative in total, the pulse width of the brake resistor control is set to exactly dissipate and hence cancel this power.

    Demo - In the above video you can see a demo of both features.

    Hardware bug found

    Everyone knows that voltage amplifiers have high input impedance, and low output impedance. Right? Well, apparently not.

    Above is a figure from the DRV8301 datasheet. 100 ohm output impedance doesn't qualify as low output impedance in my book... So this extra output impedance is causing a way too large "R" in the RC filter that filters the current sensor output. Hence the current sensing is way too slow, and barely usable.

    The fix involves replacing the capacitors highlighted in green painted labels with 2.2nF capacitors.

    Replacing 0603 capacitors on lots of boards gets quite tedious. Nevertheless, I don't want to ship out any of the remaining ODrive 3.1 boards with known errors on them. As you can see, I have 8 left, and they should all work now. If you are interested in claiming one of them, sign up for an Initial Development board on this form.

    Crowdsourced Testing

    I'm incredibly grateful for the people who were brave enough to pay for a board that was completely untested and with missing core features, and generous to spend their time helping to test those features as the were being brought up. You know who you are: Thank you!

    Below are some videos of some ODrives out there ;D

    ODrive v3.2 and Alpha Testing

    Already almost 200 of you have signed up for a board and at the same time shared with me the amazingly diverse projects that you want to use ODrive for. There were many projects that I expected like 3D printers, CNC mills, and Pick and Place machines. However there were so many cool and diverse projects I didn't expect. Here are some examples that was mentioned by more than one person each:

    • polargraphs
    • robot arms
    • walking robots
    • exosuits
    • motion simulation platform
    • heavy duty camera gimbals
    • camera dolly/slide
    • under water robots
    • mobile ground robots
    • various art projects

    I aim to have a quote ready for the manufacture of ODrive v3.2 at the beginning of April, and with that, I will open pre-orders for the Alpha release. I will send an email to everyone signed up on the google...

    Read more »

  • The Boards Have Arrived!

    Oskar Weigl01/20/2017 at 17:39 4 comments

    Check this out, a box full of goodies:

    Inside each of the 5 packets, are 6 ODrive v3.1. And they are in lovely black and gold. The manufacturing quality of CircuitHub is really top notch ;D

    Here is a picture of the new boards on the testbed. Actually I never used the test bed in the end, since the manufacturing quality was so good. I don't expect any defects, and with such a small batch I don't mind replacing a board if it was indeed a DoA.

    ODrive v3.0 next to v3.1. Black looks great ;D

    Preparing some kits to go out with the first round of pre-alpha board orders.

    With the help of the early developers who will be helping, hopefully Alpha release will occur soon. If you want to get notified when that happens, make sure to sign up for the board manufacturing run: Link.

  • Sexy machine assembly

    Oskar Weigl12/24/2016 at 04:13 1 comment

    In my previous post I mentioned that the first batch of ODrive v3 is being assembled. I asked CircuitHub to take a video. And holy shit, industrial pick and place machines are so sexy! Hopefully ODrive will enable inexpensive machines that go this fast ;D

  • Two motor operation

    Oskar Weigl12/14/2016 at 18:37 0 comments

    Two motor operation is finally done. For those of you who are interested, here is the interrupt-dance that makes it all work: Link.


  • Prototype manufacturing run!

    Oskar Weigl12/03/2016 at 09:51 9 comments

    The time has finally come for the manufacturing run of ODrive v3.1. They are now on the way, and should arrive early to mid January.

    At this stage, around 20 board kits are going out the people who signed up to the "Inital development" phase.

    Since the boars are going out to just a small group of early developers, I will have the time to personally get you up to speed with the codebase and help to get going with the hardware. Then, together, we can prepare some stuff that is a bit more stable and a bit more documented for when the alpha testing begins.

    The cost for me to get this small batch of boards manufactured was $96 per board, so that is the amount I need to ask for a kit, plus shipping.

    The kit involves basically everything seen in the above picture, and consists of:

    • ODrive v3.1
    • USB Programmer
    • A set of the optional large gauge wire screw terminals
    • A set of pin headers
    • Some nylon standoffs

    I hope that ODrive will be able to help you make an awesome robotics project, thank you so much for your contribution to helping people have access to open robotics hardware and software.

  • Testing: Progress update

    Oskar Weigl11/26/2016 at 15:28 1 comment

    I mentioned in a Previous post that before we can start manufacture, we need to have some basic functionality tests to preform QA testing. For a couple of months I was unable to work on this project, but now I am back to being able to spend most of my weekends again. So I have been able to make some progress.

    Currently the following is ready:

    • Testing rig with a motor and encoder
    • Testing PCB with pogo pins to make quick connections during testing
    • Low level code to trigger current sensing and motor control from the 3-phase PWM pheriperal
    • Online current sensor calibration
    • Lock-in, open-loop voltage vector motor spinning
    • Automatic motor resistance measurement

    The following is still left to be done before manufacturing can commence:

    • Test that the bed-of-nails board makes good electrical contact
    • Check that the transient response of the current sensing is good
    • Low level code to allow hand-over of the ADCs between the two motor channels
    • Write the encoder drivers
    • Finish up the test routines to be able to detect faults

    Pictures and video!

    Below is a motor-encoder pair doing lock-in, open-loop voltage vector motor spinning.

    New motor test cradle. The design is openly available, Link.

    Some pictures of the bed-of-nails. The design is openly available, Link.

  • Production testing: Hardware

    Oskar Weigl08/20/2016 at 05:52 0 comments

    In order to finish manufacturing of the first batch of v3 boards, we need a simple way to test if the boards work as they come off the automated assembly. Since I want to get the boards out to people as soon as possible, I will only test the very basic functionality. More features can be added to the tests later.

    The basic functionality I want to test is:

    • Does the logic supply power up?
    • Does the firmware boot up?
    • Execute some simple test voltage vectors to test the current sensors.
    • Spin a motor open loop (no encoder feedback)
    • Does the encoder work?
    • Spin the motor closed loop.
    • Same tests on the 2nd motor channel.

    This requires two main components: the test hardware and the test software. In this post I will only focus on the test hardware.

    Test board

    To quickly test the board, one of the best ways is to make a bed-of-nails that can make connection to all the required places on the board for testing all in one go. The idea is to use spring-loaded pins like these pogo pins that sit on a separate PCB underneath that can break out the connections to the test equipment. @Thomas Branch made one on Circuit Maker here. At the time of writing the design is not completely finished reviewing yet, but should be done soon.

    Here are some picutres:

    Encoder - motor rig

    To do the aforementioned motor tests, we need a motor and an encoder for each channel. The setup is designed to be as simple as possible, so it is just a motor directly coupled to an encoder, nothing else. I picked this gimbal motor since I just happened to have it lying around. But I picked a gimbal motor in particular since its high phase resistance means that if there are any bugs that cause the voltage to be switched on much higher than intended, it means that it doesn't just blow up immediatly, just melts slowly (;

    I picked this encoder. You can find the design on onshape. Below are some pictures:

View all 13 project logs

Enjoy this project?



Toon wrote 5 days ago point

Is the v3.2 send to production?
Starting to build my own controller, to learn more about it and understand the difficulties of controlling BLDC's.
Using a teensy, 8,5 bit magnetic encoder, and a 3phase bridge.
I'm currently implemented sinusoidal commutated control. No current feedback yet.
Can you recommend some good articles, studies, you use during development of the firmware?
How do you deal with cogging? The motor likes drop into a certain position. I have a turingy aerodrive 3542 800?


  Are you sure? yes | no

Oskar Weigl wrote 4 days ago point

Hey, yeah the v3.2 was just sent to production today, but I ordered some extra so there is still some up for grabs.

Cool! Best of luck. Here are some resources in the order of most basic to most in depth:

The simple solution to the cogging is to just use encoder feedback to force the motor with high gain to the location you need, and just reject the cogging through the feedback. Otherwise I think it could be characterised, like so:

but I haven't looked into that myself yet.

  Are you sure? yes | no

Toon wrote 4 days ago point

I already ordered a V3.2 board :-).
The JamesMevey2009.pdf is going to be an interesting read.
Thanks for the resources.
I think I have to re-evaluate my code to compensate for the cogging. I created a methode that scales the gain in order to move the motor in position without pushing to much current through the motor. I'll make it a bit more aggressive and add some current sensing feedback. I scared that I might burn out my motor.

  Are you sure? yes | no

Oskar Weigl wrote 4 days ago point

@Toon Cool, welcome to the alpha team!

Okay, best of luck!

FYI, cogging torque compensation is a planned feature for ODrive, though not the highest priority yet:

  Are you sure? yes | no

Christopher McCloskey wrote 04/14/2017 at 19:10 point

What is the maximum encoder count/RPM that can be handled by the 2 axis system?

  Are you sure? yes | no

Oskar Weigl wrote 04/14/2017 at 19:13 point

Max encoder count is 2 billion, maximum encoder rate is around 10MHz, max rpm depends on the number of pole pairs of the motor. For a 7 pole pair motor, its around 18k rpm. 

  Are you sure? yes | no

eduardo calegari wrote 04/12/2017 at 02:26 point

Does your code identify the position of the motor rotor through the back emf and save this information through the encoder?
In which part of the code does this happen?
Is it automatic or does it have to be calibrated?
Which cnc software do you use?

Sorry so many questions, friend, it's the will to learn.

  Are you sure? yes | no

Oskar Weigl wrote 04/12/2017 at 02:32 point

The encoder is calibrated against the rotor by driving a very strong current, and telling the user they may put no load on the motor. Then the rotor magnets will align to the magnetic field, and that is how you find where the rotor is in the first place. After that you just track the encoder.

I currently don't use any CNC software, but I will start trying some soon.

  Are you sure? yes | no

eduardo calegari wrote 04/11/2017 at 10:31 point

Congratulations on your cnc, the best project I've ever seen,

My names is eduardo calegari, I live in Brazil,
I've always been fond of cnc bldc its hardware and pid positioning codes,
If you could give me information on books and studies on pid and position codes bldc stm32f.
   I will be very grateful if you guide me in this learning because I am a little lay on this subject.

  Are you sure? yes | no

Oskar Weigl wrote 04/11/2017 at 17:03 point

Thank you!

Sure, I would recommend reading something like this:

  Are you sure? yes | no

Christopher McCloskey wrote 04/04/2017 at 19:39 point

Is the motion still precise/smooth at low/slow rpm? I am guessing commutation is done by back EMF, but I was under the impression that for precision at low speeds hall effect sensor commutation is generally necessary. Have you found a way around this? 

  Are you sure? yes | no

Oskar Weigl wrote 04/11/2017 at 04:46 point

Yes the motion is precise and smooth at low speed. The commutation is done by encoder feedback, so even more precise than hall effect sensors.


  Are you sure? yes | no

Christopher McCloskey wrote 04/11/2017 at 13:45 point

Wow, that's amazing. The only other encoder commutation system I've seen  costs $40 per cable, not including the actual encoders or drivers. Is there currently a feature to output one pulse per encoder revolution on one of the I/O? Equivalent to spindle indexing, which would allow tapping/threading operations with CNC via Mach3 or LInuxcnc. 

  Are you sure? yes | no

Oskar Weigl wrote 04/11/2017 at 17:00 point

@Christopher McCloskey
It should be straightforward to set up one of the GPIO pins to send a pulse every revolution.

  Are you sure? yes | no

Alexander Osika wrote 03/21/2017 at 09:08 point

Hi Oskar! Really cool project; cheap brushless motors with position control will be great for robotics :) I was wondering however if you have considered going in the direction of having a motor controller with integrated encoder, mounted at the motor itself, and connected on a bus? As reference I have been looking at the T-STorM32 project ( and the commercial motors from SimplexMotion.
Greetings from Chalmers Robotics!

  Are you sure? yes | no

Oskar Weigl wrote 04/11/2017 at 04:45 point

Hey! Thanks!

Yes I have thought about making an all-in-one package with motor/controller/encoder. The main limitation is cost. I will take it up seriously once the baseline controller is out and stable.


  Are you sure? yes | no

EngineerAllen wrote 03/12/2017 at 10:30 point

looks complicated!

how many hours did it take? 1000?

  Are you sure? yes | no

davedarko wrote 03/12/2017 at 13:48 point

It's over 9000!!

  Are you sure? yes | no

EngineerAllen wrote 03/12/2017 at 15:36 point

not you again

  Are you sure? yes | no

Oskar Weigl wrote 03/12/2017 at 19:31 point

Yeah I's say around 1000 is about right. I haven't counted, but I know I've played 1000 hours of Dota 2, and I've worked on this project about the same ammount ^^

  Are you sure? yes | no

EngineerAllen wrote 03/12/2017 at 20:24 point

haha thats a good balance =D

  Are you sure? yes | no

Oskar Weigl wrote 03/12/2017 at 20:25 point

  Are you sure? yes | no

Alain de Lamirande wrote 01/09/2017 at 14:51 point

Guten Tag Oskar ! Wie gehst ? Mein Name ist Alain. Ich bin von Kanada. Ich interessiere mich wirklich für Ihr Projekt. 

Do you have some boards, ready made to sell that I could test ? I know that this is open source, but I need a quick solution to test before I can make my own !

Danke für alles !

  Are you sure? yes | no

Oskar Weigl wrote 03/07/2017 at 17:20 point

Sure, just sign up for a board here:

  Are you sure? yes | no

Toon wrote 11/25/2016 at 13:04 point

I just saw this :
also on hackaday.io
Price is a bit to much at $169 + shipping and I don't think they will reach the $75K goal.
I think ODrive can be cheaper with the same performance. 
Also they use a 14bit magnetic rotary position sensor from Austria Microsystems claiming accuracy of +/- 0.2°. I know we had a conversation before about this but I still think it could be a nice option compared to the "600P/R Incremental Rotary Encoders" which is bulkier and a bit more expensive.

Looking forward for news on the new test-PCB's. 

  Are you sure? yes | no

Oskar Weigl wrote 11/26/2016 at 10:12 point

Thanks for sharing!

It looks like it is stepper motor based. In fact, it looks very similar to a Mechaduino, but with a web interfaced strapped on.

When it comes to performance, it depends on what you mean. But for sure in terms of power output, ODrive will be much higher.

Yeah I think the magnetic encoders are a good idea to support, and I intend to support it on ODrive v4.

I have some progress to share, I will do a writeup to share hopefully this weekend.


  Are you sure? yes | no

Toon wrote 11/26/2016 at 17:08 point

The HDrive is a brushless direct drive based on a two phase hybrid stepper motor. They show a little movie where they spin it to 10.000 RPM. Impossible with a conventional stepper motor. Will be something between a BLDC and a stepper.

Mechaduino uses stepper motors. 

I like the idea of an webInterface and having a udp socket as an interface. 

  Are you sure? yes | no

Maciej wrote 10/30/2016 at 19:08 point

Is it usable now? I'm thinking about testing it in big 3D printer, just want to know if step/dir input works? Than maybe I'll be able to help you guys developing it further ;)

  Are you sure? yes | no

Oskar Weigl wrote 10/31/2016 at 10:38 point

Hey, sounds cool! Unfortunately the project is quite delayed, but it will get back on track in the next week, which is exciting!

If you want to be informed when you can buy a board at alpha testing stage, which is what it sounds like to me, please sign up here:

  Are you sure? yes | no

volatile666 wrote 11/09/2016 at 17:54 point

So, how's the status now? ;)

  Are you sure? yes | no

Oskar Weigl wrote 11/10/2016 at 08:14 point

@volatile666 Last weekend I ordered some test-PCBs (bed of nails). So stuff is moving along again. Once the test-routines all work, we can start manufacture.

  Are you sure? yes | no

volatile666 wrote 09/14/2016 at 15:10 point

Any news? :) No news is good news?

  Are you sure? yes | no

Oskar Weigl wrote 09/15/2016 at 15:01 point

Currently the project is a bit stalled unfortunately. It should pick back up in full force around November (:

  Are you sure? yes | no

PointyOintment wrote 09/01/2016 at 02:39 point

Could you do a writeup on how you arrived at your current design (i.e. what parts and configurations you're using and why)?

  Are you sure? yes | no

Oskar Weigl wrote 09/01/2016 at 07:38 point

Yes I can do. Currently my priority is to the get the manufacturing and base functionality done. After that I can do a writeup.

  Are you sure? yes | no

Toon wrote 08/23/2016 at 11:55 point

How well does this system work with a free spinning motor? 

I had lost of trouble controlling them if they are not loaded. Oscillating to much, and can't get the PID parameters right. Adding a load to the axle of the motor made it easier.  

  Are you sure? yes | no

Oskar Weigl wrote 08/24/2016 at 05:33 point

You can calculate them analytically, or you can do a structured set of tests. I'll write you a PM.

  Are you sure? yes | no

mariano porta wrote 08/15/2016 at 08:13 point

Hi! I'm not sure if I'm in the correct place... I'm from Argentina and looking for motor alternatives to make linear actuators for a flight motion simulator, this motors are great because they are available in my country and relatively cheap compared with big DC motors. Anyway, I use Simtools ( ) to transform telemetry in motion, and send from the PC to an Arduino Uno r3 and then to a Motomonster driver o similar. Is there a way that your controller  will be used to replace dc motors and drivers and connect to arduino or direct to the PC and Simtools?  Sorry to bother with this, but we have a big community and a lot of people will be interested. Thanks anyway and sorry for my English!

  Are you sure? yes | no

Oskar Weigl wrote 08/15/2016 at 13:24 point

There is a USB Serial port that should be able to receive commands (position, velocity, and/or force). You may need to make a simple protocol to interface with your PC software, but that should be quite easy.

  Are you sure? yes | no

mariano porta wrote 08/15/2016 at 14:44 point

Thanks for your reply! When do you think you would have some boards to test?

I made a thread at that forum so more knowledgeable guys than me could see your development 

  Are you sure? yes | no

Oskar Weigl wrote 08/16/2016 at 03:13 point

@mariano porta: Unfortunately the board production is taking longer than I want. You can sign up to get notified as soon as they are ready at the link in this post:

Cool, I made a silly post on there so I can get notified by email to follow the discussion.


  Are you sure? yes | no

Michael Bushey wrote 08/11/2016 at 06:52 point

Please don't use CircuitMaker, us Linux people are excluded. :( This project is amazing! 

  Are you sure? yes | no

Oskar Weigl wrote 08/11/2016 at 09:56 point

Feel free to port the project to some other CAD package. Personally I am so used to AD and CM that I will put up with rebooting into windows when I need to do some PCB work.

  Are you sure? yes | no

Michael Bushey wrote 08/15/2016 at 21:59 point

I would like to create the board on KiCAD. Where can I find the schematic and the BOM? The links are dead.

  Are you sure? yes | no

Oskar Weigl wrote 08/16/2016 at 03:10 point

@Michael Bushey: Please let me know which links are dead, I will try to fix them. You can find the relevant files in the ODriveHardware github link in the sidebar (then go to the v3 folder).

  Are you sure? yes | no

Michael Bushey wrote 08/17/2016 at 19:48 point

The sidebar link is good. :)

The first three links under Boards and Development -> Boards! are dead:

You can review the original Altium Designer files in the v3.1rc branch on the GitHub.
You can review the schematic and the BOM.

  Are you sure? yes | no

Oskar Weigl wrote 08/18/2016 at 04:56 point

@Michael Bushey: Okay I fixed the links you mentioned, thx for pointing them out.

  Are you sure? yes | no

Joshua Elsdon wrote 08/18/2016 at 13:40 point

I feel your pain, though CircuitMaker is really good, worth the effort of rebooting into Windows, even if it is the only thing you run there. There are some shortcomings, though essentially it is all the bits of their full package (Altium Designer) that are needed, without all the mega fancy stuff cluttering the menus.  Not sure if CM will run in WINE. 

  Are you sure? yes | no

alexisdal wrote 07/23/2016 at 06:32 point

can't wait to try it out. Excellent market analysis.

  Are you sure? yes | no

Oskar Weigl wrote 07/23/2016 at 07:52 point

Sign up for a board, and you can try it soon!

  Are you sure? yes | no

lukejs3 wrote 07/14/2016 at 11:54 point

How suitable would something like this be for a CNC knee mill servo? It looks like the applications shown are all fairly high speed, low torque. I guess a belt drive reduction would help. Any thoughts?

  Are you sure? yes | no

Oskar Weigl wrote 07/14/2016 at 23:22 point

Yeah, the only difference is the gearing. I haven't gotten around to doing a high torque/force demo because I don't have a strong enough frame for that. But many CNC people have shown interest, and that is definetly one of the intended applications.

  Are you sure? yes | no

Kearney Lackas wrote 07/13/2016 at 15:46 point

Looks like have nets for hall effect sensors (M0_AH, M0_BH, etc). Is this right? Are these implemented in firmware yet?

  Are you sure? yes | no

Oskar Weigl wrote 07/14/2016 at 10:44 point

No, the M0_AH stands for Motor 0 phase switching for the A phase, on the High side mosfet. There are corresponding M0_AL for the low side mosfet.

  Are you sure? yes | no

Toon wrote 07/11/2016 at 09:38 point

Which encoder do you use at the moment? 

Incremental quadrature A B (Z) aren't that cheap.  

Have may have found another option: or magnetic Position sensors with ABI or UVW output. 

  Are you sure? yes | no

Oskar Weigl wrote 07/11/2016 at 12:22 point

On my last rig I used something like this one, which is a tad over $10:

I have considered using these magnetic rotary encoders, but the issues with them are latency and precision. For example, the ones you found only have 360 ticks per revolution (whereas the one I linked has 2400). If someone has an application where such a precision is not required, they can indeed be used.

  Are you sure? yes | no

lukejs3 wrote 07/14/2016 at 14:37 point

Oskar, the AS5047 (and I guess probably many/all of those AMS sensors) have an incremental output too - if you use that would you still have a latency issue?

  Are you sure? yes | no

Oskar Weigl wrote 07/14/2016 at 23:19 point

@lukejs3: Ah yeah, that might work then actually! Thanks for that!

  Are you sure? yes | no

Toon wrote 07/26/2016 at 09:07 point

I got an AS5040 adapterboard with incremental output. Works nice with my Turnigy Aerodrive SK3 - 3542-800kv which fit perfectly on a nema17 stepper mount. I made a 3D printed support for the sensor and fixture for the magnet. 

Next thing is to wait for the ODrive test board or make my own ESC.
I tried a car ESC from Hobbyking but they're not optimized for slow speed and have a lot of lag in response. Didn't really think I could get this to work, but one could always try.

  Are you sure? yes | no

Oskar Weigl wrote 07/27/2016 at 12:13 point

@Toon: Sounds awesome! I think it will work if the AMS is up to snuff ;D.

  Are you sure? yes | no

nathan wrote 07/05/2016 at 04:38 point

Fantastic project. You mentioned the alpha boards will be released in a few weeks, any updates? The description mentions 150A max motor current, is this true for the v3.1 boards? At what voltage will ODrive be able to power the motors? Thanks!

  Are you sure? yes | no

Oskar Weigl wrote 07/05/2016 at 08:49 point


Yeah you can find the latest update about the boards here:

The 150A is the expected peak current rating, yeah for v3.1. The bus voltage is designed to go up to 24V.


  Are you sure? yes | no

nathan wrote 07/05/2016 at 09:26 point

Thanks Oskar! Signed up to get a board

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates