Close
0%
0%

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.

Boards are available

ODrive v3.5 boards are available at the ODrive Shop.

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, UART, PWM, 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).

Demos

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.


Join the discussion!

Check out the ODrive Community.

Stay up to date


Motors

Check out the ODrive motor guide. You can also read this post about outrunner motors.

Interfaces

  • USB Serial port -- PC, BeagleBone, RaspberryPi, etc.
  • CAN -- CANOpen and CiA 402 is a possibility
  • UART -- Arduino, mBed, etc.
  • PWM -- RC Recievers, Arduino, etc.
  • Step/direction -- Existing motion controllers
  • Some general purpose digital and analogue pins

Protocols

  • G-code parser for interfacing with existing automation tools
  • Many types of command modes
    • Goto (position control with trajectory planning)
    • Position commands
    • Velocity command
    • Torque command

Architecture


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.

The system is also capable of using a brake resistor to dump the regenerated energy instead of a battery to absorb it. This is a simpler and possibly safer setup, and is also what the project will use in the first instance, until the battery storage feature is ready.

Applications

So this project is good for some things,...

Read more »

  • 2018 in Review and New EU Webshop Open

    Oskar Weigl12/30/2018 at 06:11 3 comments

    Many of our European customers will be happy to know that the EU webshop is now officially open. Most of our products are now stocked and available from a warehouse in the UK. The shipping times to Europe should be drastically improved when ordering from there.


    Now that we have reached the end of the year, I want to take the opportunity to summarise some of the highlights of the past year, and to thank each and everyone of you for the incredible support we've received.

    In the beginning of 2018 we released ODrive v3.5, and with that we reached a stable hardware version. With that we were able to focus our efforts on improving the firmware, supporting software and the overall user experience.

    We saw over 100 new features, improvements and fixes (full details in the Changelog). Just to lift out some highlights, we have implemented:

    • Trapezoidal trajectory planner
    • Switching frequency increased to 24kHz for silent operation
    • Storing of configuration parameters to Non Volatile Memory
    • Many encoder related improvements, including index pulse encoders and Hall sensor feedback
    • RC PWM input

    On top of this there are currently many excellent features waiting in Pull Requests which will be our priority to merge as soon as possible.

    We love seeing so many fantastic projects come to life with the help of ODrive. Check out the Projects category on our forum to see all the ones people have chosen to share. I want to highlight two projects that I found to be particularly excellent.

    The first one is a modular, heavy duty Swiss mill-turn machining center for cutting metal called SwissMak, which uses ODrive to precisely control the two spindles, and will also use ODrive for the movement axes in a future version. They successfully completed a kickstarter, and the first set of machines are being manufactured at this very moment.

    front iso view 2 jan 17

    The other project I want to feature is the Stanford Doggo, a quadruped robot made by a group of students at Stanford University. Check out more photos, and watch it walk, dance and jump extremely high in their excellent video presentation here.

    Stanford Doggo

    To all businesses and hobbyists alike that have chosen to use ODrive; a huge thanks to everyone that have helped to make this possible.

    On top of that we want to specially thank all the direct contributors to the project. For your code contributions, test data, documentation improvements and for providing help to other users on our forum and Discord. Thank you so much, your contributions are invaluable.

    In 2018 ODrive went from a promising project to a successful product and business. We hope to continue on this trend and make ODrive even better.

  • Jan 2018

    Oskar Weigl01/15/2018 at 09:49 0 comments

    Robot Arm and More

    The ODrive project has been very fortunate to attract such a strong community of enthusiasts. Today we want to feature the excellent work done by Richard Parsons, who's been very active on the ODrive Community. In the video below he demonstrates his direct-drive robot arm, how he built and wired up the servo axes, his step/dir tests and finally his high speed pen plotter.

    ODrive v3.4

    Since the last newsletter update, ODrive v3.4 has become available. From a user-perspective, not much of the design has changed from v3.3. However, we now have a 48V version available. It has the same current handling capacity as the 24V version, hence it has twice the power. We are talking around 3kW peak power per axis.

    We can't wait until the videos of projects with this kind of power show up!

    New Encoder

    We now stock the CUI AMT102 encoder in the ODrive Shop. This is a compact 8192 counts/rev encoder with index pulse. It comes with a custom 2m shielded cable that matches the pin-out for the ODrive.

    The increased resolution will help with smoother motion and less "hunting" vibration when holding position. Also, in a couple of weeks, when we expect have the index pulse feature finished, it should enable the ODrive to restore the encoder calibration. This means that the encoder calibration only has to run once to commision the drive, and then skipped every run from then on.

    Above is a design by [Wetmelon] on the ODrive Community. It uses the 1.6kW N5065 motor and the aforementioned AMT102 encoder, to make a NEMA23 compliant compact and high performance servomotor. The above prototype is printed in PET-G filament, that has a glass transition temperature of 88C, so despite using a 3D printed part it should be ok for applications that don't run the motors too hot. If you are interested, he also made a design that uses a 10:1 gearbox, check it out.

    Your Project

    If you also have a project that you are working on that uses the ODrive, or even one that could make good use of an ODrive, we'd love if you shared some pictures with us.

  • ODrive v3.4 Ready Soon

    Oskar Weigl11/24/2017 at 01:09 0 comments

    We have managed to sell out of ODrive v3.3, thank you everyone who has shown such support! The batch of ODrive v3.4 are due to arrive in about a week from now, and we hope to have them tested and available to ship in the beginning of December.

    As you might be aware, we used to have a restriction asking you to not order more than two drives at a time. Now we are able to order much bigger batches, so this restriction is lifted: order as many ODrives as you would like. With this batch and going forward, I think we should be able to keep ODrive from going out of stock.

    On that note: If you are an OEM or Distributor, please get in touch, as we now have the capacity to take large orders.

    Thanks to everyone who has helped to make this possible,

    Cheers, 

    Oskar.

  • Announcing 48V ODrive Board

    Oskar Weigl11/06/2017 at 23:05 2 comments

    Many of you have requested that there should be available a 48V version of ODrive. I'm happy to announce that this is expected to become available in the beginning of 2018. To be notified when it will be possible to order, please sign up here: https://goo.gl/forms/EUJP726GsLaBf5YN2.

    Some things to note:

    • The price is expected to be $149.
    • The current handling capacity will not decrease, hence the power handling capacity will in principle be double that of the 24V version.
    • We will keep offering the 24V version at the same price as before: $119

  • Cogging Torque Compensation

    Oskar Weigl11/06/2017 at 22:55 0 comments

    Inexpensive hobby brushless motors are powerful, but they are not built for precision applications. One of the undesirable characteristics of less expensive motors is cogging torque. This is the torque generated by the permanent magnets in the rotor being attracted to the iron in the stator in an unbalanced way.

    In more expensive motors this is avoided by skewing the rotor magnets, as shown below. This balances the reluctance torque across the skew angle, which eliminates most cogging torque.

    Straight and skewed rotor magnets.

    Interestingly, the cogging torque exhibited by the motor is a constant function of the rotor angle. That means that if we can figure out what it is, we can improve the performance by simply compensating for it.

    And that is exactly what we did. Thanks to the implementation of a calibration and compensation algorithm by @Wetmelon on the ODrive forums, we can estimate and cancel the cogging torque.

    Cogging torque map: Current as a function of encoder count. Measured values in blue, fitted values in orange.

    Without and with anticogging, showing rotor position at 25 RPM commanded velocity. Note that the feedback gains were not very stiff for this test.

    Note that the above is just an excerpt of the full writeup, please see that for more detail, and full resolution plots.

    This algorithm is already merged to the devel branch of the ODrive firmware, and after sufficient testing will be available in the next release.

  • UART and Arduino Library

    Oskar Weigl10/18/2017 at 01:43 0 comments

    The UART feature is now ready for testing.

    Many of you have been waiting for the ability to control the ODrive from another microcontroller, and so this feature complements the USB and let's you do exactly that.

    I have also made a first revision of an Arduino library that lets those of you who wish to use Arduino get started quickly. If you don't use Arduino, you can still have a look at the library to see how the communication is implemented, and copy that to your platform.

    The UART feature is currently in a pull request, which means that the documentation on the master branch hasn't updated yet. Please check the documentation on the uart branch instead. Here are some of the important things that are new for UART:

    If you have any problems, or if everything worked perfectly, or anything in-between: please help us with feedback. Once this feature has been confirmed to work for enough people, we will merge it to the devel and hence master branch in the next release.

  • Three Demos

    Oskar Weigl10/02/2017 at 04:09 0 comments

    It's so awesome to see what kind of cool stuff people are doing with the ODrive. Here are 3 demos of fairly different nature. I think they are awesome, I hope you do too!


    Willam Osman put ODrive on a PowerWheels. This video is actually a few months old now, and I probably should have posted it earlier. Anyway, watch that thing do doughnuts:

    The Arduino library and UART communication is under way, a usable release should be ready in a couple of weeks. Check out the first demo:

    Bauerslab posted his awesome Skittle Sorter on the ODrive forum. It's really awesome to see the diverter teleporting around. If you wanna skip to the action, it starts at 6:15.

  • Which voltage in your application?

    Oskar Weigl08/25/2017 at 03:40 0 comments

    It’s good to know what voltage range people want to use ODrive for in their application. Right now the voltage rating is for 24V, but it’s fairly easy to change. There is a current handling penalty to increase it though, so it might be useful to offer two versions. To help us decide between the different options, please answer the poll about what supply voltage would be the most ideal in your application. You may check multiple options if they apply to you.

    Thanks!

    Link to poll

  • Electrical issue discovered

    Oskar Weigl08/13/2017 at 07:57 0 comments

    Thanks to the help from the community, recently we uncovered a hardware bug that affects all ODrives manufactured to date (v3.3 and earlier).

    This bug is described in more detail here, and the fix is described in detail here.

    In short, the bug means that the GND on the GPIO pins and the M1 motor gate driver has significant spikes of electrical noise. This causes glitches on the control signals on the GPIO pins, and motor control glitches on M1.

    If you plan on using M1, it is strongly advised that you apply this fix. You can follow the instructions as linked above. If you do not feel comfortable applying the fix, you can also send the board to me (San Jose, CA, USA), and I will apply the fix for you, free of charge (you pay shipping to me, I pay shipping back to you). If you need help to apply the fix to your board, please email info@odriverobotics.com, and we can arrange it.

    We have already started applying the fix to all the ODrive v3.3's:

    The fix applied to an ODrive v3.3.

    Applying the fix to all the ODrive v3.3.

  • Sensorless Mode

    Oskar Weigl08/04/2017 at 23:50 0 comments

    Quite a few of you have requested sensor-less operation: running the motor without an encoder. This is now a reality:

    Video shows open-loop startup speed-ramp followed by switching to closed loop FOC velocity control.

    The main limitation of this mode is that it's not able to provide precise control at very low speeds (it can however spin up to speed using not-so-precise control). Therefore, this mode is great for applications where the primary operational regime is at speed. So not great for CNC machines or polargraphs, but great for electric skateboards and conveyor belts.

    If you are interested in the technical details, or have an ODrive and want to try this out, please see the Sensorless mode post on the forum for more detail.

View all 32 project logs

Enjoy this project?

Share

Discussions

Johannes wrote 04/26/2017 at 12:16 point

Nice, thx for clearing things up. Waiting keen for the the board to arrive. So I will now order 21pcs Sony VTC4 cells (best economical/quality/longlife cell for the purpose) and a 240W powersupply that can be tuned to 25.2 V or 3.6V per cell (7cells in series/3parallel with oz890 smartBMS as balancer/ I2C-bus-monitor w/o FETs) to run two SK3-6364 motors

  Are you sure? yes | no

Johannes wrote 04/23/2017 at 13:34 point

shipping date is Mai 15 if i rember right.

I dont get why there is a 12V input? Makes no sense to me. I want to use a 24V 10A powersupply from ebay, about $20 and no noisy fan sounds good to me, now that i payed over $100 for the V3.2 board. Using a PC powersupply is much too complicated and expensive for my purposes. 

Please throw out that 12V input and replace it by a simple 24V input, thanks!!

http://www.ebay.com/itm/DC-24V-10A-240W-Converter-Adapter-Power-Supply-for-LED-Light-CCTV-AC110V-220V-/291899181907?hash=item43f68c0b53:g:CnkAAOSwpLNX9DiH

  Are you sure? yes | no

Oskar Weigl wrote 04/23/2017 at 19:37 point

Yes, expected shipping date is the 15th of May.

I assume you are looking at the architecture diagram. That shows just one way to wire it up, where there is a battery on the DC bus, and an arbitrary voltage power supply (8 to 22V) on the AUX port.

The currently supported way to hook it up is to plug in a power supply (like your 24V supply) directly on the DC bus, and a brake resistor on the AUX port.

Cheers

  Are you sure? yes | no

Toon wrote 04/18/2017 at 07:24 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 04/19/2017 at 06:33 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:

http://scolton.blogspot.co.uk/2009/11/everything-you-ever-wanted-to-know.html

http://www.drivetechinc.com/articles/IM97PM_Rev1forPDF.pdf

https://github.com/muffinator/fall-2011/raw/master/URGE/JamesMevey2009.pdf

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: http://hackaday.com/2016/02/23/anti-cogging-algorithm-brings-out-the-best-in-your-hobby-brushless-motors/

but I haven't looked into that myself yet.

  Are you sure? yes | no

Toon wrote 04/19/2017 at 08:52 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 04/19/2017 at 21:10 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: https://github.com/madcowswe/ODriveFirmware/projects/1#card-2046258

  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.
Hehe

  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: http://manuals.chudov.com/Servo-Tuning/PID-without-a-PhD.pdf

  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.

Cheers!

  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 (http://www.olliw.eu/storm32bgc-wiki/What_is_T-STorM32_about?) 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.

Cheers!

  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: http://goo.gl/forms/Y9aHMVqWyjW9WjHG2

  Are you sure? yes | no

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

I just saw this : https://www.kickstarter.com/projects/919717340/the-user-friendly-servomotor-you-always-hoped-exis/comments
also on hackaday.iohttps://hackaday.io/project/6912-the-user-friendly-servomotor-you-hoped-existed
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.

Cheers!

  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: http://goo.gl/forms/Y9aHMVqWyjW9WjHG2

  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 (https://www.xsimulator.net/ ) 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: https://hackaday.io/project/11583-odrive-high-performance-motor-control/log/40702-boards-and-development

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

Cheers!

  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!
Thanks!

  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

Similar Projects

Does this project spark your interest?

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