Boards and Development

A project log for 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.

Oskar WeiglOskar Weigl 06/26/2016 at 22:0113 Comments


The number one thing people have asked me is: "When are the boards available?". It took a while to get ready, but I am now happy to announce that the release candidate of board version 3.1 is ready! You can review this release candidate in any of the following ways:

I am not sure if the continued development will be with the AD files in GitHub, or on CM, it depends on the input I receive from the community.

After identifying and working around some bugs present in v3.0, I was able to verify that the basics of the board design does indeed work as expected. In v3.1, I have fixed the bugs that were present in v3.0, and made some minor modifications. I have refrained from any major modifications or improvements to make sure that the changes that were applied should only fix the issues, and not introduce any new ones. Therefore, I am fairly confident that once this version is released, that it should be fine to distribute the first batch of development prototypes.

Board production runs

So while the design is open source, and anyone is free to go and make boards, I realise that the majority of us would prefer to just buy an assembled board. So I will facilitate some board manufacture production runs. I realise that some people want to get their hands on a board at the early alpha stage, while some want to reduce the risk and want to join in when the project is ready for beta release.

To that end, I have prepared this survey:


Roadmap of features

To help decide when you would want to join the project, or what ODrive can do for you at what time, it makes sense to have a roadmap of features. You can see the first draft of the roadmap of features we want to get into the first usable release of ODrive. The milestones to look out for in particular are First usable release, and Alpha testing production run. When these are done is basically when the alpha production will happen.

This roadmap is intended to be dynamic, and will change with feedback from the community, and new ideas come about. Your input to this roadmap is very welcome!

How you can contribute

Have a look at the roadmap. If you feel that have the skills to implement any of the features we want to include in ODrive, then please join the development effort and help make them become a reality! If you have an idea, or made a feature on your own, just get in touch, and we can get it in the roadmap, or get the feature merged.


buglyo.balazs wrote 03/27/2017 at 14:48 point

Hi Guys!

LEt me allow to  congrat for this cool controller.

Right now i have some question. 
In the 3.1V is there any "big" bug ? 
How can i control the controller.?
I tried to find the controller but i was not able to find it. 


  Are you sure? yes | no

Dave wrote 08/26/2016 at 21:59 point

Not sure if this helps or not, but maybe until boards are ready, I can work on designing an OpenBuilds-based linear axis that can accept the Turnigy motor from your previous post and mate it with a belt-driven stage?  Would people want something like this?  Basically, I'm thinking of C-Beam ( and 3D-printed end caps, one for mounting the motor and encoder, and the other with a pulley.  The stage could possibly have the belt tensioner integrated.

  Are you sure? yes | no

Oskar Weigl wrote 08/27/2016 at 09:39 point

I think this would be really cool!!

  Are you sure? yes | no

Dave wrote 08/27/2016 at 13:27 point

Can you recommend a kv spec for an outrunner?  I'm thinking about ordering the 28 and 35mm SK3 sizes from HobbyKing.  Maybe even a larger one as well.

  Are you sure? yes | no

Oskar Weigl wrote 08/28/2016 at 03:55 point

@Dave: My calculations for typical moving masses and lengths of linear axes show that for direct drive with a pulley and belt, you basically just want as low kv number as you can.

  Are you sure? yes | no

Anne wrote 07/12/2016 at 12:49 point

This looks very interesting! I'm interested in cable-driven robots, where in each actuator a motor turns a cable spool and the encoder is attached to a separate pulley to measure the cable movement. This allows interaction, where the user can manipulate the effector and the robot can respond, but also permits huge working volumes just by having big spools of cable.

  Are you sure? yes | no

Oskar Weigl wrote 07/12/2016 at 15:58 point

I have discussed making a super fast, large area, polargraph robot for a large art installation with some friends. I think this drive would do very well for that.

I am not sure what you mean by having the encoder separate from the motored spool?


  Are you sure? yes | no

Anne wrote 07/12/2016 at 16:44 point

Well, the idea is to wind the cable onto a spool. (For the prototypes at least I am thinking extremely small and light - for "cable" read "stainless steel thread". and for "spool" read "sewing machine bobbin".) Of course as you fill a spool the radius grows, so the relationship between angle and cable length is complicated and depends on the winding history. So putting an encoder on the motor shaft doesn't really measure the thing you want to know. Instead I planned on guiding the cable out from the spool, around the shaft of an encoder, and out into the work volume. This way as long as tension is maintained and the cable doesn't slip on the encoder shaft you get a clean measurement of cable extension. 

If it helps, the natural numbers of actuators for such a robot are one (up/down spider), two (hanging graffittibot), three (hanging three-axis robot), four (tensioned three-axis robot), six (tensioned six-axis robot) or eight (tensioned six-axis robot; this is what people mostly seem to use). Of course for large robots they aren't naturally collocated, so I had pictured modular single-motor actuators communicating over CAN.

  Are you sure? yes | no

Oskar Weigl wrote 07/12/2016 at 18:41 point

@Anne: Awesome, you can probably get some sick speeds with ODrive powering something that lightweight. Ah I see about the encoder, that makes sense. So ODrive requires an encoder on the motor shaft anyway, to keep track of the rotor angle to drive the correct currents. So you would have to connect an extra encoder for this. ODrive v3 is a bit limited in terms of extra IO, but I think you should be able to connect the PWM output of one of these: Although I'm not sure about the max speed you can use with such an encoder, depends on the pulley you pull the thread over obviously.

Otherwise, you could connect whatever encoder you want to some other devboard and hook it up over CAN. Also, ODrive v4 will have lots of more extra IO, but it will probably be a while before v4 is ready xP.

By the way, from an inductance point of view, it is actually better to wire up the motors with long wires, than it is to have long DC bus cabling. Of course long distance to the motors is bad for the encoder signals, so it's a tradeoff I guess.


  Are you sure? yes | no

Alice Blake wrote 07/04/2016 at 08:36 point

yay an update :D also if people want a batch ran in the uk i'm willing try :)

  Are you sure? yes | no

Oskar Weigl wrote 07/04/2016 at 12:25 point

yay indeed xD
I think jumping on the centralized bandwagon to get the quantity up will end up being cheaper than doing a local production run :)

  Are you sure? yes | no

Alice Blake wrote 07/04/2016 at 13:01 point

internalshippingiis expensive though D: although if it's a letter for the PCB it might be OK :/

  Are you sure? yes | no

Oskar Weigl wrote 07/04/2016 at 16:22 point

@Alice Blake: some of my friends in the UK will be ordering some, so maybe it should be possible to split the international shipping between you.

  Are you sure? yes | no