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 1 comment

    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

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

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:

http://ams.com/eng/Products/Magnetic-Position-Sensors/Angle-Position-On-Axis/AS5132 or http://ams.com/eng/Products/Magnetic-Position-Sensors/Angle-Position-On-Axis/AS5134 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: http://www.ebay.com/itm/600P-R-Incremental-Rotary-Encoder-DC5-24V-Wide-Voltage-Power-Supply-6mm-Shaft-/282047672496?hash=item41ab59f0b0:g:AyoAAOSwZ8ZW8P1d

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

Hey,

Yeah you can find the latest update about the boards here: https://hackaday.io/project/11583-odrive-high-performance-motor-control/log/40702-boards-and-development

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

Cheers!

  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

mitja.kumin wrote 06/08/2016 at 18:17 point

In interfaces list is mentioned the possibility of step/dir input. If I look at schematics there is no such input provided. So the question is: Is there only CAN interface and no direct step/dir input? In this way there is no way to hook the drive to mach / linuxCNC / usbCNC etc... Which PC software can be used to interface to this drive?

Can we expect step/dir input in the near future? This would be awesome feature and the drive could be used with any well known CNC software for hobbyists.

  Are you sure? yes | no

Oskar Weigl wrote 06/08/2016 at 18:26 point

It should be possible to use the GPIO port and interrupts to do software counting of the step pulses. This will have some performance limit, I'm not sure what it would be, but maybe it is sufficient.

In the next revision we can think hard about how to do it in hardware.

Cheers!

  Are you sure? yes | no

mitja.kumin wrote 06/08/2016 at 19:09 point

I believe it would be a really big step forward if you can provide some hardware solution so it is possible to connect to the drive the same way as with stepper drive. I really don't have a clue about writing the code for the MCU. I can tell only what I wish for a servo drive in the hobby range. This would be setting the parameters trough some PC interface (length traveled at one full rotation of motor, PID parameters, encoder parameters, etc...)and simply hooking the drive to step/dir/enable for each motor separately. 

So let's say you have 10mm of movement at one full revolution of the motor, and the encoder gives 400 pulses per revolution. This means you have to put 400 pulses in step input to move axis for 10mm. With one pulse you would move it for 0.025mm. With encoder that has higher pulses per revolution you are getting better linear resolution. Speed is controlled with step pulse frequency- the higher, the faster the motor.

Drive should get the command where(dir) and how far(number of step pulses) to go, and drive should take care of the rest. Enable could be used as a motor brake function. But I'm quite certain the motor would need a cooling fan so it won't overheat if there is no turning of the motor (or slowly turning). Here I'm thinking about putting motor and encoder in some neat housing in make some hookup terminals or connectors. I can do machine hardware solutions really gut but I lack knowledge at programming. 

Cheers!

  Are you sure? yes | no

Oskar Weigl wrote 06/09/2016 at 08:37 point

@mitja.kumin
Yes, what you describe is what I also mean. When I say to use the GPIO ports and do the counting in software, i still mean it should be directly possible to connect the ODrive to step/dir signals. The software part is just exactly how the counting is done by the ODrive, as a user this is not visible.

The flow you describe, with the configuration with the PC, etc, is exactly how I plan to do it. I think it also makes sense to have a configurable rotation angle per step pulse.

I also think that for high performance applications it will be necessary to put the motor and encoder in a housing, that has an intake filter and an exhaust fan, for forced air cooling. Feel free to contribute with a design! ;D

Cheers!

  Are you sure? yes | no

Douglas Plumley wrote 06/07/2016 at 02:04 point

Hey Oskar, very cool project!  I'm very new to electronics, trying to expand my horizons with a project with some friends.  Your controller looks like a great alternative to the super expensive industrial controllers we've looked at, any chance you'll be partnering with a company to sell pre-assembled/soldered boards?

Keep up the great work!

  Are you sure? yes | no

Oskar Weigl wrote 06/07/2016 at 07:25 point

Hey, thanks! Yes, I plan to do a small production run soon with some alpha boards, and then a larger run when the drive is ready for beta. I intend for the drive, once mature, to be available to just buy the assembled hardware.

  Are you sure? yes | no

Consultant wrote 06/03/2016 at 19:33 point

The idea is fantastic however getting it into either my CNC or 3D printer looks to be a problem.

Without typical stepper motor dir/step inputs, there is no path available currently.

There is no CAN on any typical controllers I am aware of (for cheap).

Whats the strategy to make this get into mainstream?

  Are you sure? yes | no

Oskar Weigl wrote 06/03/2016 at 19:50 point

I think I will try to cater for hardware step/dir input for a future version. Many people have been asking for a 3 axis version, so maybe when the time comes to do that, we can use a larger package and hence map timer/counters to do the step/dir counting. I still have to check if there are enough compatible timers/counters, but I think so.

Until then, it should be possible to use the GPIO port and interrupts to do software counting of the step pulses. This will have some performance limit, I'm not sure what it would be, but maybe it is sufficient.

  Are you sure? yes | no

Consultant wrote 06/03/2016 at 20:08 point

So you would be writing the software converter from pulses to position or someone else would take on that task?

  Are you sure? yes | no

Oskar Weigl wrote 06/03/2016 at 21:23 point

Whoever does it first wins a high five!

  Are you sure? yes | no

volatile666 wrote 05/29/2016 at 15:04 point

How did you measure the motors torque? Do you maybe even have torque/speed curves?

  Are you sure? yes | no

Oskar Weigl wrote 05/29/2016 at 15:31 point

I do have this plot of theoretical torque and power for the Turnigy Aerodrive SK3 - 4250-350kv motor at 60A. I haven't done any dynamometer tests. I did do an analysis on the achieved trajectory of the v2 rig (that you see in the first video), and it suggests that the real torque is close to the theoretical one.


  Are you sure? yes | no

volatile666 wrote 05/29/2016 at 18:13 point

Thank you! You dont happen to have a speed/torque curve for the motor when short-circuited and driven externally?
Im thinking about using this motor as a brake, but for this to work I need to know if the motor produces enough current (and thus torque) when short circuited for a specific speed range.
Using an electronic load I could then preset a current (and thus torque) to achieve a specific braking torque.

  Are you sure? yes | no

Oskar Weigl wrote 05/29/2016 at 18:27 point

@volatile666: I'll PM you.

  Are you sure? yes | no

Thorsten Eggert wrote 05/29/2016 at 12:59 point

Funny, I started to build and code a very similar thing, a stepper replacement board for use with brushed motors. I had no idea how to use brush less ones... I started with a AVR and switched to a STM407. You wrote the version 3 of the hardware is untested at the moment, when do you think it is tested good enouth so that interested people can start building ?

  Are you sure? yes | no

Oskar Weigl wrote 05/29/2016 at 13:15 point

I'm not really sure, I can only really work on this project on the weekends and sometimes in the evenings. But I'm trying my best to get the major components tested. I have already found 2 (minor) problems with the circuit.

We should be talking weeks, not tens of weeks.

This is me today: https://drive.google.com/file/d/0B5Zwiu1SQzGMdEFqWWRNR3llQ2M/view 

Cheers!

  Are you sure? yes | no

Thorsten Eggert wrote 05/29/2016 at 13:28 point

Sure, I think we all work on our fun projects mostly at the weekends, to less time and to less money. I did not expect a more precise estimation (-:. Thanks for the quick reply

  Are you sure? yes | no

HecatronsWorkshop wrote 05/28/2016 at 22:16 point

For the swd connector to program the Arm, might I recommend one of the small 10 pin standard connectors

https://makersify.com/products/dfrobot-gadgeteer-socket-smt-10pcs or

http://www.digikey.com/product-search/en?x=-1289&y=-73&lang=en&site=us&KeyWords=3220-10-0100-00 

When using the jtag segger (adafruit do a cheap educational version) this seems to be a standard connector for swd. I've also seen it used on LPC Xpresso / Netduino boards. It's footprint is also a lot smaller for the pcb

  Are you sure? yes | no

Oskar Weigl wrote 05/29/2016 at 01:23 point

Hm, you think $70 is cheap? The programmer I'm using costs less than $5, including shipping. Just search e-bay for "ST-Link v2".

  Are you sure? yes | no

HecatronsWorkshop wrote 05/29/2016 at 05:12 point

The type of programmer doesn't matter so much, I just meant you could get away with a smaller footprint for the swd connector which might also make it easier to connect to.

I think the ST-Link v2 uses the standard 20 pin IDC connector. If you used the below adapter board and cable for example this is what's commonly used to connect to boards like the arduino due

https://www.adafruit.com/product/2094
https://www.adafruit.com/products/1675


  Are you sure? yes | no

volatile666 wrote 05/28/2016 at 15:40 point

Great project, exactly what I need!
How do you plan on balancing the individual LiPo cells?

  Are you sure? yes | no

Oskar Weigl wrote 05/28/2016 at 16:15 point

Thanks!
I don't xP. At least not for now. The plan is to use a LiPo at about 50% state of charge, so there will be a huge margin of charge error before it would become an issue. So either you could just periodically check that the cells are somewhat even, or we could add cell balancing in the future.
You could also just get a standalone balancer. I'm not sure if they are able to run while the battery is in use, but you could then at least run it when the machine is not in use.

  Are you sure? yes | no

v.T wrote 05/26/2016 at 21:17 point

great work. I have been wondering why dc-dc motors have not been replacing steppers for quite some time. For professional control they are the standard. I own a precision CNC with Sinumeric 810M control. This will need to get replaced at some time. It reads the machine position via Haidenhain Glass Rulers (1µm), servo motors are attached via harmonic drives. I would definitively not need the power of the board, but I am highly interested in the control loop and g code abilities. A work fellow is working on a g code creator. If you are interested to see, if this could be an integrated ad-on, let me know. For CNC I consider 4 position axis as must, a 5th as option if you need a synchonized spindle (for most applications a speed control would be sufficient). You should also consider some IO ports (probe input, coolant on/of, etc...).

Is there any link where I can find out more on the G code interpreter? From where does it get the code, what are the realtime requirements of a potential G code server, etc.... By offering a CNC control replacement bundle with machine CTRL, I think you are entering an interesting and lucrative field. BTW, I am located in Stuttgart area.  

Greetings Georg

  Are you sure? yes | no

Oskar Weigl wrote 05/27/2016 at 13:51 point

Thanks!

Due to micro-controller peripheral limitations, the options are basically 1, 2 or 3 axes. But it is possible to daisy chain multiple ODrives over CAN to get more axes. I think it would be useful to do a cost estimation for each kind (1, 2, or 3 axes), and do some sort of survey to see what most people prefer.

It currently does not have a G-Code interpreter yet. But it would get the G-Code from a PC, raspberry pi, or something like that over USB serial.

Cheers!

  Are you sure? yes | no

v.T wrote 05/27/2016 at 18:12 point

Hello Oskar,

I would not put an interpreter on the boards, a parser should be enough. The question would be, if the parser should be G-code based... ( in G-code comments might be omitted if they do not remove material, especially if you are working with a miller offset to consider the miller diameter. Whole sequences might not be passed on to the motion control. I would put the interpreter on a PC, converting the G-code into axis movement directives. The master board would have a stack to have access to the next moves and pass it on to the daisy chained slave boards. 

If I had to choose I would opt for 3 channel boards. You can still omit one channel when soldering parts to save money, but I would not know why. This would give you a 5 axis control + spindle speed with just 2 boards.

The C code interpreter on the PC would chop the g-code into axis moves. Each axis controller would have to make sure to keep the axis within the channel specified by the tolerances (closed loop control). If this fails an error stops the controller. The axis controls could be the tool center position, all offsets, etc. could be handled by the interpreter on the PC.

I am only into μPC programming (Xmega, ATtiny), not Visual C or alike. So I can't help you with the PC part. The board side you are sure much more advanced in than I am. Still, my offer stand to make contact to a friend you could help you on the PC side and to contribute to the architecture. This would be easier to discuss in German (I assume your native tongue?), you can contact me at mail(at)tardy(dot)de.

Greetings

Georg

  Are you sure? yes | no

Niko Kivel wrote 05/27/2016 at 18:34 point

As Georg mentioned, an interpreter on the board doesn't make too much sense. Linuxcnc is a great tool which could do the interpretation and send it out via CAN-bus, afaik.

  Are you sure? yes | no

Oskar Weigl wrote 05/27/2016 at 18:50 point

@v.T: I see your point, G-Code specifies much more than just the motion sub-system. I suppose with v2 of the board, with much more GPIO, or with a new revision of the v3 board with more GPIO, it could be possible to control the entire application system with the ODrive. In this case it may make sense to have G-Code parsing.

But as it stands, yes, the current ODrive is limited to just the motion control of 2 (possible 3 with another board revision) axes. I think, as you, and @Dani Epstein, suggested, it would make sense to leave the main system control to a smoothie-board, a PC, or something else.

There are basically two options: Either the central controller does all the motion calculations in real-time, and just passes the current position, velocity and acceleration demand to the controllers. This might be possible on an embedded central controller like the smoothie-board.

Alternatively we come up with some high level motion primitives, such as cubic splines, and the host passes this into a queue on the master ODrive. The main issue with this would be synchronization, but I suppose that CAN time synchronization protocols do exist.

I'm sorry but my German is barely good enough to order Pizza. I am from Stockholm, studied in London, live in Zurich, and about to move to Tokyo.

Cheers.

  Are you sure? yes | no

Dani Epstein wrote 05/26/2016 at 10:38 point

I'm very interested in putting this into a 3D printer. The smoothieboard is what I have my eye on since it has all the other features a 3D printer needs (heater controls bla bla yada). Will this be able to interface somehow with a smoothieboard to replace the on board drivers? That would be well wikkid.

  Are you sure? yes | no

Oskar Weigl wrote 05/27/2016 at 13:47 point

So I had a look at the smoothie board. It should be possible to re-purpose pins p0.4 and p0.5 from motor M1, OR pins p0.21 and p0.22 from motor M4, to be connected to a CAN transceiver, and talk to the ODrive over CAN.

  Are you sure? yes | no

Dani Epstein wrote 05/27/2016 at 14:24 point

Sounds great. For a 3D printer one would need at least four motors, all of them capable of working in both directions. One of the reasons I'm designing my own printer is that I want multi-head capability, and therefore each extra head would add another motor to the mix. 

Seems like you will have to come up with a solution to easily swap out stepper motor drivers for ODrives for an existing board that can do everything already including motor control, such as the smoothieboard, and make the ODdrive do nothing other than DC motor control. In this way one would be able to easily connect two or more ODrives to drive one's existing solution with very little overhead in terms of design, programming and assembly. I have no idea if this is feasible, but think that this is the simplest solution rather than trying to provide everything else as well. 

On the other hand, printer board firmwares do a lot of acceleration calculations which might actually hamper the ODrive from performing at its max; I don't really know what I'm talking about really, just sort of thinking out loud. No doubt you will correct me one way or another!

  Are you sure? yes | no

Oskar Weigl wrote 05/27/2016 at 16:10 point

@Dani Epstein: Yeah I also think this is the best way to get up and running quickly. Of course, in the long term, people could copy the design and integrate it in a monolithic controller.

Yeah it should be possible to do some edits in the smoothie-board firmware to export over CAN the position, velocity, and acceleration of axes to be driven by ODrive. And you are absolutely correct, in a coordinated motion control system, it only makes sense to have a single centralized trajectory planner. So there would be three options: use the existing trajectory planner in smoothieboard (I assume optimised for steppers) and get sub par performance; port the fancy motion control algorithms developed for ODrive to smoothieboard (this is probably the best option); or to let ODrive be the master.

Cheers! ;D

  Are you sure? yes | no

Dani Epstein wrote 05/27/2016 at 16:42 point

Option 2 looks the the most probable, but then only you would really know. If you get this to work then the good folks at the smoothieboard would probably be only delighted to add this to their board. It is such an overwhelmingly better solution than steppers technically and financially. 

Since 3D printing is really coming along at such a pace, it gives you a great opportunity to really get the ODrive out there and tested in real-world situations. Smoothieboard already covers just about everything there is i that realm, so I think that working with them is a win-win situation.

  Are you sure? yes | no

HecatronsWorkshop wrote 05/26/2016 at 08:13 point

Could this be used to turn a Brushed DC Motor into a Servo?

  Are you sure? yes | no

Oskar Weigl wrote 05/27/2016 at 12:33 point

Yes. You can drive 3 brushed motors in both directions, or 6 motors in only 1 direction with this board (v3). With the v2 you can drive 4 motors in both directions, or 9 motors in 1 direction.

Or a fancy mix of the above.

  Are you sure? yes | no

HecatronsWorkshop wrote 05/28/2016 at 21:26 point

Thats very cool, I wasn't expecting bushed motor support

  Are you sure? yes | no

Thorsten Eggert wrote 06/03/2016 at 09:09 point

It's possible to us 3 brushed motors with step /dir pins when a encoder is attached?  Would be ´nice since you can get many cheap, powerful motors from the automotive area.

  Are you sure? yes | no

Oskar Weigl wrote 06/03/2016 at 12:50 point

So I'm still not sure about step/dir support yet, not that many GIPO pins are broken out.

  Are you sure? yes | no

Thorsten Eggert wrote 06/03/2016 at 18:22 point

Thats sad, I think step/dir is the most common way in diy cnc and 3d printers. With a step/dir interface it could be used as drop in replacement in many projects.

  Are you sure? yes | no

Oskar Weigl wrote 06/03/2016 at 20:01 point

I think 2ch step/dir should be possible to do in software with interrupts. Not sure about performance, but it should work.

  Are you sure? yes | no

Niko Kivel wrote 05/26/2016 at 06:17 point

Hi there,

I love the project!

I'm into CNC and want to replace my steppers. I don't need 1 kW though. But I'm happy to be a tester, and I'm quite close I guess (Aargau/CH) :)

Just my 2 cents about the encoders. It would be great to have RS422 (differential) support. In CNC one is typically using high line count encoders (2000 lines or better) and due to the harsh environment (vibration, RF stray fields from HF-Spindles, ...) RS422 is superior to single ended.

If you think about RS422, why not use a RJ45 jack for the connection? It comes with the benefit that cheap patch cables can be used.

cheers Niko

  Are you sure? yes | no

Oskar Weigl wrote 05/27/2016 at 12:33 point

Hey, Thanks!

I think it could be possible to add RS422 trancievers, it depends on how many need it. If it is fairly requested, I could make it an option, so that people that don't need it just don't populate the tranciever.

  Are you sure? yes | no

Niko Kivel wrote 05/27/2016 at 18:22 point

To my knowledge the differential channels can simply be used for single ended signals by disabling the termination resistor. That's how Mesa does it on their 7i47(S) card.

  Are you sure? yes | no

stehlik.michal wrote 05/25/2016 at 16:28 point

Any recommendation or suggestions for feedback mechanism? Btw, I really like this idea :

  Are you sure? yes | no

sjd.aliyan wrote 05/25/2016 at 18:27 point

As you see in the picture there is a incremental encoder used for feedback.

  Are you sure? yes | no

jmhtau wrote 05/25/2016 at 11:51 point

This is begging for a good connection to the PCB something like Han-Fast Lock connectors. No PCB component, 8 awg/60A.  No doing something naughty like bolting a big ring terminal to the PCB with a washer on each side. (works short term, never holds up to vibration, the PCB will deform and lose contact pressure) 

  Are you sure? yes | no

Alex365 wrote 05/25/2016 at 06:48 point

Great! Thank you for creating this project. I'm really looking forward to build one controller myself. Have you looked into the cooling of the brushless motors? I'm afraid pumping 1kW into these motors, designed for forced air cooling inside an aircraft might destroy the magnets, have you some experience with his?

  Are you sure? yes | no

Oskar Weigl wrote 05/25/2016 at 14:23 point

Yes I did think about this, and I think to really get the most out of the motors you probably need to use a fan and a shroud to force cool the motors. Of course the controller can be in control of the fans, so that you can get silent operation on low power programs, and high performance (but noisy) on high power programs.

  Are you sure? yes | no

f4grx wrote 05/24/2016 at 20:41 point

What are the options for the CAN protocol? This part is relevant to my interests.

I found on the SimplexMotion website that the standard is:

"CANopen standard for motor control systems (CiA-301/402)"

Here:

http://www.can-cia.de/can-knowledge/canopen/cia402/

CIA301 is downloadable, but 402 is "members only" :(

Here is a draft: http://overpof.free.fr/schneider/CAN%20&%20CANopen/CANopen/%A9CiA%20CANCANopen%20CD%20V5.1/standard/dsp402.pdf

I think this project has great potential for CNC control. Steppers are very slow and lack torque and precision, even the NEMA 23 models.

Excellent job!

  Are you sure? yes | no

Oskar Weigl wrote 05/25/2016 at 14:21 point

Hey, yeah a few years ago I was working with an ABB MicroFlex e150, using the CiA 402 protocol. I think it would be cool to support it, but I think there are quite a few features that are higher priority. Of course, if you implement it, I would be very happy to merge it in (:

The inital CAN protocol would probably just feature some very simple process data items only, such as desired torque, speed, and position, and with some mode value (torque only, velocity only, position with velocity and torque feed-forward, etc). Initially there probably will not be any support for configuration over CAN, this would be done over the USB serial.

Again, I'm open to supporting whatever makes sense, if you are willing to write it (:

  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