ODrive: High performance servomotor controller

[Oskar Weigl]

Hey,

I thought you guys might be interested in my project called Odrive. It is an open source 2-axis brushless servomotor controller, meant to be used with cheap hobby motors. I think it definitely would be useful for building high speed pick and place machines.

Let me know if you are interested in development, or want to get your hands on some early hardware.
Cheers!

[Jason von Nieda]

*Picks jaw up off floor*

Wow! That is an impressive demo!!

Can you tell me a little about the software stack seen in the demo gif? Is all the motion being generated by your Odrive board? Sending Gcode to it?

I'm pretty amazed that the machine doesn't throw itself off the table and run across the floor with those accelerations. 

Nice work Oskar!

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3b288331-1935-4837-8d82-4f212951338e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Graeme Bridge]

Thats insane, how accurate and how repeatable is the positioning?

[Oskar Weigl]

Thanks!

I have been focusing on doing the control and motion profiles, so I haven't done any interfacing yet. The demo is using a hard-coded array of target locations to reach; at the moment the software stack supports straight line movements from point to point.

It currently does not do much interfacing, but the v3 board has both USB Serial and CAN on it for interfacing. The idea with USB Serial is to be able to accept G-Code, however this is not implemented yet. If someone here is interested in porting some G-Code parsing to this board, I'll happily send them a board to test on.

I should probably mention that the youtube-to-gif converter doesn't really get the framerate correct, so the gif is a bit fast. You should check the youtube video and all the specs on the project page. Nevertheless, the drive should be able to handle the speeds implied by the gif, as it can handle more than 10x the power used in that demo.

Cheers,

Oskar

[Oskar Weigl]

The accuracy and repeatability of the motor positioning itself is only limited by the encoder feedback. So if you have a decent encoder well coupled to the motor, and say it is 2500 counts per rev, you can get 0.05 degrees accuracy.

I would say that in most designs that are not a precision manufactured professional machine, the mechanics would be the limiting factor by far.

That said, you could, if you really wanted, use the v2 of the board that has much more inputs, and hook up a high precision linear encoder. Then the mechanical stiffness is less important, and you can get very extreme absolute accuracy.

Cheers!

[matt]

Hi Oskar

Can you send a link to the motors you are using? Also as it stands, is
it using an encoder for positioning - can you get good repeatability out
of it? Say 0.05mm precision?

Matt

On 2016-05-11 21:35, Oskar Weigl wrote:
> Thanks!
>
> I have been focusing on doing the control and motion profiles, so I
> haven't done any interfacing yet. The demo is using a hard-coded array
> of target locations to reach; at the moment the software stack
> supports straight line movements from point to point.
>
> It currently does not do much interfacing, but the v3 board has both
> USB Serial and CAN on it for interfacing. The idea with USB Serial is
> to be able to accept G-Code, however this is not implemented yet. If
> someone here is interested in porting some G-Code parsing to this
> board, I'll happily send them a board to test on.
>
> I should probably mention that the youtube-to-gif converter doesn't
> really get the framerate correct, so the gif is a bit fast. You should

> check the youtube video and all the specs on the project page [1].

> Nevertheless, the drive should be able to handle the speeds implied by
> the gif, as it can handle more than 10x the power used in that demo.
>
> Cheers,
> Oskar
>
> On Wednesday, May 11, 2016 at 9:26:34 PM UTC+2, Jason von Nieda wrote:
>
>> *Picks jaw up off floor*
>>
>> Wow! That is an impressive demo!!
>>
>> Can you tell me a little about the software stack seen in the demo
>> gif? Is all the motion being generated by your Odrive board? Sending
>> Gcode to it?
>>
>> I'm pretty amazed that the machine doesn't throw itself off the
>> table and run across the floor with those accelerations.
>>
>> Nice work Oskar!
>>
>> Jason
>>
>> On Wed, May 11, 2016 at 12:05 PM Oskar Weigl <madc...@gmail.com>
>> wrote:
>>
>>> Hey,
>>>
>>> I thought you guys might be interested in my project called Odrive

>>> [1]. It is an open source 2-axis brushless servomotor controller,

>>> meant to be used with cheap hobby motors. I think it definitely
>>> would be useful for building high speed pick and place

>>> machines.Let me know if you are interested in development, or want

>>> to get your hands on some early hardware.
>>> Cheers!
>>>

>>> [2]

>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "OpenPnP" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to openpnp+u...@googlegroups.com.
>>> To post to this group, send email to ope...@googlegroups.com.
>>> To view this discussion on the web visit
>>>
>>
> https://groups.google.com/d/msgid/openpnp/3b288331-1935-4837-8d82-4f212951338e%40googlegroups.com

>>> [3].
>>> For more options, visit https://groups.google.com/d/optout [4].

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/c6607b96-4a4e-4933-b125-77575818daf1%40googlegroups.com
> [5].
> For more options, visit https://groups.google.com/d/optout [4].
>
>
> Links:
> ------
> [1]
> https://hackaday.io/project/11583-odrive-high-performance-motor-control
> [2]
> https://camo.githubusercontent.com/beebe492cced4ada2046e786a958af7caaec998a/68747470733a2f2f6a2e676966732e636f6d2f6c5978376b362e676966
> [3]
> https://groups.google.com/d/msgid/openpnp/3b288331-1935-4837-8d82-4f212951338e%40googlegroups.com?utm_medium=email&amp;utm_source=footer
> [4] https://groups.google.com/d/optout
> [5]
> https://groups.google.com/d/msgid/openpnp/c6607b96-4a4e-4933-b125-77575818daf1%40googlegroups.com?utm_medium=email&utm_source=footer

[Oskar Weigl]

Hey Matt,

You can read about the motors on my post about it here.

Yes all machines and demo rigs I have used with this project have had encoders. But I do have some sensor-less code that I have used for some other projects. For a robotics application I would always use encoders though.

The machine you see on the demo has a 600CPR encoder, and a 20mm diameter pulley. So the theoretical positioning accuracy should be 0.03mm. However, the mechanical design in that demo rig was super sloppy, so the final accuracy at the head would've been much worse. However, with a much better and stiffer mechanical design, it should be able to reach this kind of accuracy.

Cheers!

[Glen English]

This is excellent reading for people contemplating such a project

deals specifically with GT 2mm and 3mm pitch belts.

https://www.gates.com/~/media/files/gates/industrial/power-transmission/manuals/light-power-and-precision-manual.pdf

[Glen English]

Oh hang on - that's a lead screw drive.

What lead screw pitch ? and lead screw diameter ?

[Oskar Weigl]

Hey Glen,

The v2 demo uses spectra line, and the v1 demo uses a belt. None of them use a lead screw.

Cheers.

[Mark Harris]

We had a discussion about your project at the office earlier this week :) Leadshine make 3 phase stepper drivers which can drive hobby brushless motors, and likewise their 3 phase steppers can be driven by hobby brushless ESCs. I'd be keen to see your ODrive board driving a leadshine 3 phase stepper.

The real issue I have with rc motors is they have very very large step sizes, and do not hold steps (especially microsteps) very well. Even with encoders I'd be skeptical about how much jitter you get.

Trotec use brushless DC motors in their lasers, with an encoder, 3 stage reduction drive - amazing acceleration and precision. The motors they use have much higher pole count though which helps a lot.

I've done quite a bit of work with 3 phase DC drive electronics and layout for 200+A/70+v applications if you want sch/pcb review :)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9d6e62a6-25fd-4f7c-8565-0cee4ac822af%40googlegroups.com.

[Lisandro B]

Please, take this pile of cash and send me lots of this :D.

Joke aside, I can't wait to get a couple of boards, I'll following this project very closely. Great job!

[Paul Jones]

Yeah!! I’ve been waiting for this sort of thing for a while!! I thought about developing one myself, but that level of performance was too far out of my level of skillset vs time ratio.

Great Job!

 

Paul.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jzPOqn%3Dd1yLW83D%2B%3DU5vub-gtSzy1xzwug4%3DK2rpHz_gA%40mail.gmail.com.

[Glen English]

Hi Oskar.

Hmmm then I am looking at the wrong Youtube URLs (lead screw) 

The belt performance is expected. (speed/ accuracy, especially on 2mm GT that is very good belt), 

but I like your use of the hobby model motors is very interesting. I see there are a few projects online using these motors at slow speed and fast.

It seems there are a very large quantity of motor variations. turns, torque rpm per volt so a random choice probably would not satisfy.

How did you make your encoder?

On your belt- what was the peak force on the belt (Newtons) and what sort of belt ? 

regards

[Paul Kelly]

I’ll add my applause. And a commitment to purchase a heap too.

Do you need help manufacturing? We have some spare capacity at the moment I’d be happy to donate...

PK

 

Paul Kelly | Design Engineer
CASWA Pty Ltd
2/33 Horus Bend, Bibra Lake  WA  6163
M 0402 177280 | P +61 8 9277 0900 | F +61 8 9467 0550 | E te...@caswa.com

Check out our new explainer video for AccessPack..

 

From: ope...@googlegroups.com [mailto:ope...@googlegroups.com] On Behalf Of Oskar Weigl
Sent: Thursday, 12 May 2016 4:35 AM
To: OpenPnP
Subject: Re: [OpenPnP] ODrive: High performance servomotor controller

 

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c6607b96-4a4e-4933-b125-77575818daf1%40googlegroups.com.

[Oskar Weigl]

Hey Mark,

Its cool to know that my project has been the coffee-break discussion somewhere ;D

ODrive will happily drive 3-phase steppers. The only major difference, as you pointed out, between hobby brushless motors and 3-phase steppers are the pole counts. Hobby motors will typically have around 7 pole pairs (though some have up to 14), and the leadshine 3-phase steppers have 50 pole pairs. This means that if you use a hobby motor and drive it like a 3-phase stepper (lock-in style), you get very poor resolution, like you mentioned. 

However, driving a 3-phase machine (50 pole pair or 7 pole pair) lock-in style is very inefficient. I use instead something called Field Oriented Control (FOC). This has no lock-in torque at all, and relies entirely on the encoder's precision. So you could say that you move away entirely from "steps", and control the torque electronically instead of electro-mechanically. This also means that the pole count is no longer relevant (:

This has mostly advantages such as a huge improvement in efficiency and better dynamic response. But, as you pointed out, it does mean that we rely on a good encoder to have enough resolution to avoid jitter, or we have to dial back the feedback gain until friction is able to damp the jitter. Fortunately, good dynamic response can be achieved even with mild feedback gain if you have a good system model and use feed-forward.

Ok cool! When it's time for another board revision, I'll let you know!

Cheers,
Oskar.

[Oskar Weigl]

Thanks!
I will announce when the project is in alpha testing stage, and when it is in beta testing stage. I will try to facilitate getting boards out to people by some method at those times.
Cheers!

[Oskar Weigl]

Thanks!

Actually, when its time to make the first round of some alpha testing boards, that would be beyond incredibly helpful. I was wondering how I would go about doing a small batch, and getting some help with that would be amazing!

I will let you know when we have done the very basic testing of the first prototypes to make sure the very basics are working. When that's all figured out, I would very very much appreciate your help ;D

Cheers!

Oskar

[Oskar Weigl]

Thanks! ;D

[Oskar Weigl]

Hey Glen,

One one project I used this encoder, and on the other I used something like this one.

The belt design I have should not be used as a reference, it was not engineered at all, just something thrown together for a demo.

Cheers

[Graeme Bridge]

definitely seems an interesting controller, I'm currently designing my machine so I'm thinking going with nema 23's would let me swap out to 3 phase motors and this board.

One question would be how we control the Z axis as this board only controls X and Y

[Oskar Weigl]

Hey Graeme,

Quite a few people have asked me this. There are a few options.

1. Use Odrive for the main axes, and use a stepper for the Z axis.
2. Use 2 Odrives. Gives you a 4th auxiliary axis for whatever you want to do with it.
3. We redesign Odrive v4 to have 3 axes.

I think I will compile the expected cost of a 3 axis Odrive and do a survey, and see what people prefer. I think I will do this at some point during the beta phase.

Cheers

[Rich Obermeyer]

It would seem to me that the encoder would be best attached to the other end of the belt, (idler) not the motor.  Then any error related to the belt would be ignored.

You really only care about how far the belt is moving and how fast.  The motor moving is not the same thing as the belt moving although they are related.

@Oskar does that make sense to you?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d936cef7-a568-4f65-90fe-639d9b37d60f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich

[Lisandro B]

Maybe you can evaluate the possibility of Daisy chain the boards, so one USB can control many of them

[Mark Harris]

When doing brushless motor controllers myself for uav applications we've used FoC too, using STM32 M3 series controllers - but we going for constant velocity not trying to hold steps, I had not thought of using them for that.

Personally I think i'd prefer to have one mcu per motor, especially when using high count encoders.  With a high pole count working off back emf only (ie: unsensored) we were approaching the limits of the mcus processor time. If you have quadrature encoder hardware, obviously this is then done in the PHY rather than reading analogue channels so takes a lot less cpu.. but still.

It could be an idea to put an RS485 or CAN bus on the board, and the unit which gets USB plugged in becomes the master?

On 12 May 2016 at 13:26, 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

Maybe you can evaluate the possibility of Daisy chain the boards, so one USB can control many of them

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9a450102-47f2-4bd5-8f5c-f0937b799e20%40googlegroups.com.

[Oskar Weigl]

Yes that makes sense. There are two things I would be careful about:

1. The transfer from the motor to the encoder still has to be somewhat stiff. The torque production efficiency would decrease like cos(delta_theta/pp), where pp are the number of pole pairs in the motor. To not drop below 90% efficiency, on a 7 pole pair motor you would have to ensure that during full torque, the mechanical error is no more than about 4 degrees.
   
2. There are now extra mechanical springlike dynamics in the feedback path, which may change the stability of the controller. I think this can be adequately modeled though.

Cheers!

[Oskar Weigl]

Yes this should be possible. You would set up one as the master which would talk USB, and the others would be connected on a CAN bus and listen for low level commands that way.

[Oskar Weigl]

Hey Mark,

The micro-controller I am using has 2 hardware quadrature encoder interfaces, so the encoder counting is done in hardware. If I remember correctly they can work up to 20 or so MHz, so that shouldn't be a big issue. I know of an STM chip that has 3 of all the required peripherals in case we wanted to do a 3 axis board.

In my v2 prototype I was using a much less efficient cpu, clocked at 1/4 the speed, and that had a really crappy floating point unit (5-14 times less efficient than the current chip). And there I was running 2 axes at 16kHz, and it had loads of CPU time left. I am fairly confident that CPU time should not be an issue, even at 32KHz. But we will see when I get v3 booted up.

Yep, there is already a CAN transceiver on the v3.0 board. Yeah that's a good idea of automatically arbitrating: the board with the USB plugged in is automatically the master.

Cheers!

[FredG]

Hello Oskar,

have you thought about sharing your pcb designs on oshpark.com ?

They offer two and four layer boards at a very good price and free international shipping from USA...

[Oskar Weigl]

Hey Fred,
I have considered that and I'm happy to share them in this way. I want to make sure that the board works with the very basics first.
Cheers!

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1d605be0-0bc0-4f99-9eec-feb63c837365%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[code shell]

Incredible speed, believes the Forum will be a lot of people want to continue to seethe open source 2-axis servo motor brushless controller, please keep updating ... A toast.

在 2016年5月12日星期四 UTC+8上午3:05:17，Oskar Weigl写道：

[Oskar Weigl]

Thanks! Yeah I will keep this thread and the hackaday.io page up to date as soon as I have something to report. I will be doing basic board tests this week.
Cheers!

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8b82d190-56e4-4d11-aadf-b476889ca50f%40googlegroups.com.

[Oskar Weigl]

Hey everyone,

There is now an update about board availability and the roadmap for the ODrive features on the project page.

If you are interested in getting an ODrive board, you should check it out.

Cheers!

[Oskar Weigl]

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. They have not been all allocated yet, you can signup here.

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.

[Anthony Webb]

How many motors will the controller handle (looks like maybe 2)?  Are there motors that you recommend that will pair nicely with this setup?  I'd generally be interested in knowing a little more where the project is at today, what the roadmap looks like, and maybe an overview of how to interface (ie do you just use standard step/dir signals?)

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3f36efa1-54d4-4119-97ce-033db3309d30%40googlegroups.com.

[Oskar Weigl]

Hey Anthony,

The version currently going to a small batch production is v3.1, which will indeed handle 2 motors. The plan for v4 is to do 3 motors, but it will take us a while to get to v4.

The motors I recommend are generally low kv motors, for higher torque and lower speed. But it really depends on your application. I made some recommendations in this post. I will prepare a google sheets template for motor selection calculations, it's on the todo list (;

Speaking of, the roadmap/tasklist is currently located here. You can see that the first supported interface will indeed be step/dir. But many people have requested various kinds of more advanced interfaces, including a protocol with feedback over the USB Serial, and ultimately something like CiA402 over CAN.

Cheers,

Oskar

On Fri, Dec 16, 2016 at 3:51 AM Anthony Webb <anthon...@gmail.com> wrote:

How many motors will the controller handle (looks like maybe 2)?  Are there motors that you recommend that will pair nicely with this setup?  I'd generally be interested in knowing a little more where the project is at today, what the roadmap looks like, and maybe an overview of how to interface (ie do you just use standard step/dir signals?)

On Thu, Dec 15, 2016 at 10:17 AM, Oskar Weigl <madc...@gmail.com> wrote:

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. They have not been all allocated yet, you can signup here.

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.

On Sunday, July 3, 2016 at 8:55:44 AM UTC+9, Oskar Weigl wrote:

Hey everyone,

There is now an update about board availability and the roadmap for the ODrive features on the project page.

If you are interested in getting an ODrive board, you should check it out.

Cheers!

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3f36efa1-54d4-4119-97ce-033db3309d30%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CALsNZy0yczaDBTaHt_xY2XsnG2G94_OOvm0DrDhJNQ8QAMtA4Q%40mail.gmail.com.

[Lamont Cranston]

On Dec 15, 2016, at 11:26 AM, Oskar Weigl <oskar...@gmail.com> wrote:
> The motors I recommend are generally low kv motors, for higher torque and lower speed. But it really depends on your application.

Since this is the OpenPNP mailing list I'd guess that pick-and-place would be the application.

I'm interested in the answer to this question too. Since you posted to the OpenPNP list you must think there's a motor out there that, along with ODrive, would be useful for pick-and-place applications. Can you please give an example?

I heard about ODrive a while back, but you wrote this:

"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"

https://hackaday.io/project/11583-odrive-high-performance-motor-control

I guess I must have misunderstood.

Generally for pick-and-place you don't want gearing if you can avoid it. More gearing means more slack ("backlash") and positional accuracy trumps all other concerns for PnP.

Although "don't care about speed" isn't true for PnP, it doesn't need the sort of velocities you see in RC/drone drivetrains. And the sort of crazy (impressive!) velocities+accelerations shown in your demo videos probably aren't useful for pick and place machines except at the very high end -- most of us don't have vacuum pickup systems that can reliably maintain part position on the nozzle at those velocities+accelerations.

I'd be happy to be wrong about all this.

PS, high-current DC power supplies (like 200A @ 12V) are actually pretty cheap, check out what the bitcoin miners are doing with surplus server PSUs...

[Oskar Weigl]

Hi Lamont,

So the main benefit of brushless servomotors over steppers is power. However, there are also some other benefits, like closed-loop positioning, and silent operation. Of course, you can do closed-loop positioning with steppers too, like with the Mechaduino. And utility of silence can be questioned, but for some people, sitting next to their 3D printer is the only option, and having it be silent would be very nice.

So, back to the main topic, power:

When dimensioning an actuated system, lets say a PnP system, the main performance metrics will be acceleration/force and top speed. This can be decomposed to the gearing ratio and power. I.e. the gearing will trade force for top speed, and the power will determine how much you get of both. To be clear, by gearing I don't mean a gearbox, which indeed can give backlash, friction, and other problems, but I simply mean the diameter of the pulley, or the pitch of the lead screw, etc.

So lets say we have a belt and pulley actuated PnP system, with a hobby motor and the ODrive powering it. Lets say we take a motor on the "slow and torquey" end of the kv's, so about 400, and suppose we take a very small pulley, say 10 mm diameter. So we have kind of gone "max force, min speed". Now the top speed of this system at a bus voltage of 24V is 5m/s (calculation). Suppose this motor is rated for 50A, then we have a force output of 240N (calculation). This should get a 3kg load up to the top speed in about 60ms, over a distance of 144mm (calculation, calculation).

I plan to make a spreadsheet to facilitate the above calculations at some point.

So this gearing is good if your average displacement is about 300mm. But if your load is lighter, or your distance is further, you could gear it faster. However, I would still keep the motor at the "minimum possible" kv, and simple scale up the pulley diameter, simply to have more teeth engaged, and a smaller pulley curvature.

If you are using leadscrews it may not be the case, I haven't done much calculations on those.

I don't know much about PnP vacuum systems, I kind of assumed that the weight of a small surface mount component is very small compared to the suction force, even at high accelerations. Maybe there is room for innovating on low cost, but higher performing vacuum systems?

So in conclusion, what brushless servomotors improve over steppers (apart from silence and closed-loop control) is mainly power. And if you want a fast machine, this is good. Of course you might want something that is faster than steppers, but you don't really want to pull 10g, then its still valid to use the ODrive, just that your motors will run cooler, which is also a good thing.

Oh and thanks about the heads up about high power PSUs. The idea with the lipo battery as high power energy supply has some potential drawbacks, such as battery life (which I have yet to test), so running the system off of a powerful PSU and using a brake resistor instead may be more reliable.

Cheers,

Oskar

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/A820C5BF-1C3A-4D87-85D9-1FD1A81A4680%40gmail.com.

[Lamont Cranston]

On Dec 18, 2016, at 5:56 AM, Oskar Weigl <oskar...@gmail.com> wrote:
> So the main benefit of brushless servomotors over steppers is power. However, there are also some other benefits, like closed-loop positioning, and silent operation. Of course, you can do closed-loop positioning with steppers too, like with the Mechaduino.

Yes, I've switched my PnP over to mechaduinos and am active on that forum :)

But "real" BLDCs (as opposed to steppers, which are technically also BLDCs) have only a few poles (as few as three) whereas commodity steppers have at least 200 poles. So in order to get nice smooth sinusoidal commutation on a stepper your motor driver's PWM chopper and the DAC that maps out the current waveform both need to run 60x faster.

So I would say that power is not the only benefit of BLDCs over steppers.

Having completely rewritten the mechaduino code at this point I can say that this concern is not purely theoretical, although a different choice of components than the mechaduino made might help. But being able to use motors with fewer poles seems to me the easier route.

Assuming the firmware were adequately developed, can you comment on any disadvantages of an ODrive-driven BLDC drivetrain compared to a Smart Stepper (Trampas' helpful term for the class of closed-loop steppers that encompasses Mechaduino, Nano Zero Stepper, and others) for PnP applications? Clearly the advantages are more power and slower switching -- what are the disadvantages?

> but I simply mean the diameter of the pulley, or the pitch of the lead screw, etc.

Yes, although PnPs tend to use belts not leadscrews, and without a gearbox there is only so much gearing you can get from a single on-axis pulley. GT2 gears with a 5mm bore (to fit commodity stepper shafts) only go down to 12 teeth (I've heard that a 10-tooth version exists), so that pretty much establishes the limit of the gearing ratio you can get without an actual gearbox, and it's not much.

> I don't know much about PnP vacuum systems, I kind of assumed that the weight of a small surface mount component is very small compared to the suction force,

Perhaps for 0402/0603s. Even then there is "wind" force against the component as the head velocity rises. I'm sure this would be a significant issue if a PnP ran as fast as the (impressive) videos on the ODrive webpage. Also the pickup tips for those tiny components have pretty tiny apertures.

> Maybe there is room for innovating on low cost, but higher performing vacuum systems?

Others here have more experience than me on this, but simply jacking up the vaccuum pressure may not always be the easiest path. At a certain point the extreme vacuum force deforms the solder-tinned surface on 0402s/0603s leads and the component ends up stuck to the pickup tip! I've seen this while pick-and-placing solder spheres in order to reball BGAs, it is a huge huge headache. And the solenoids we use to cut off the vacuum pressure rely on a spring to reset the piston when the current is cut off, so at a certain vacuum pressure you can no longer shut off the vacuum (I've seen this too by cascading vacuum pumps) and you would need a dual-electromagnet solenoid. But if you're willing to spend enough upgrading the vacuum path it must be possible -- high-end commercial PnP machines do move at the speeds shown in the ODrive videos so it must be possible at some price point.

> Oh and thanks about the heads up about high power PSUs.

No problem, I have lots of experience with them and they are both amazingly cheap and amazingly high quality. And amazingly scary when you wire electrolytic capacitors to them backwards! But don't be afraid of them. Finding the obscure PWRBLADE connectors can be a hassle but after that it's smooth sailing. Only downside is that you only get 12V out of them (without stacking, of course).

[Red Davies]

So, I've been working on a 'glue-on' magnetic linear encoder for the
MGN12-style of rail. I guess one could use that as feedback instead
of the rotational encoder with some firmware tweaks?

> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

> To post to this group, send email to ope...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/94C9F1A1-EE1F-45E2-9AFA-4F3316DDC728%40gmail.com.

[oliver jackson]

Hi red, you have piqued my interest. How do you plan to modify mgn12 rails so they have linear encoders? I was considering leaving space for adding glass scale linear encoders when I build my pnp, so any alternatives would interest me

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAFGw4%3DB0hoZNVrZzehPYnZuB6sM6-uH8JREM57kMj8oBt%2BLgWA%40mail.gmail.com.

[Lisandro B]

I have an unused 5um glass linear scale lying around, I will gladly do some beta testing on my cnc when that code gets implemented

[Oskar Weigl]

Hi Lamont,

That's a very good point about the pole count. The rule of thumb I have come to use is that the update-rate of the voltage needs to be at least 10x per electrical revolution. This means that a 50 pole stepper (200 quadrature states per rev) would be limited to 2400rpm at a 20kHz switching/control frequency. Any faster would start to sacrifice the shape of the current waveform.

I would say that one of the main disadvantages is the availability of motors. The hobby motors meant for RC aircraft and the like do not have dust shielding and may require a different kind of mounting than the standard NEMA mounts. However, I am confident that the community can innovate around this.

Cheers,

Oskar

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/94C9F1A1-EE1F-45E2-9AFA-4F3316DDC728%40gmail.com.

[Oskar Weigl]

Yeah that should be possible. The only limitation is that any error between the motor angle and the displacement of the actuator needs to be limited to around +/- 10 electrical degrees. So for a 7 pole pair motor, this is about +/- 1.5 degrees. I can imagine that under high forces, a belt may stretch by this amount, unless you make sure that it is very stiff.

Of course you could do both: Use an encoder on the motor shaft for commutation and use an encoder on the rail for accurate positioning. This is not supported on the current hardware due to lack of IO, but ODrive v4 should have significantly more IO, so this may be a possibility.

Cheers,

Oskar

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAFGw4%3DB0hoZNVrZzehPYnZuB6sM6-uH8JREM57kMj8oBt%2BLgWA%40mail.gmail.com.

[Michael Anton]

My understanding is that you still need the rotational encoder for handling motor commutation, and dynamic movement.  The linear encoder is just used for final positioning.  So, to use a linear encoder, you still actually need two encoders.

Mike

[Juha Kuusama]

Hi,

The speed is indeed very, very impressive. For a pick and place, accuracy is also important. In principle, how accurate positioning ODrive can achieve, if we assume no error from the encoder? Also, we can get position data from rotation encoder by counting revolutions, right? 

[Oskar Weigl]

Hi Juha,

In principle, the precision is the encoder resolution. That is, suppose you have a very cheap encoder, like a 600 CPR (4*600 quadrature counts/rev), the resolution is 2400 per revolution. Suppose you have a 16 tooth GT2 pulley, then in principle the resolution is 13 microns. Of course, you can get better encoders, and then the resolution is even better than this. I think the limit is going to be mechanical slop in the rest of the system and/or dynamic disturbance forces (if any).

Yes, position data is maintained by continuously counting the encoder over multiple revolutions. This is how I track the position in my demo video.

Cheers,

Oskar

On Tue, Dec 20, 2016 at 7:42 PM Juha Kuusama <ju...@kuusama.com> wrote:

Hi,

The speed is indeed very, very impressive. For a pick and place, accuracy is also important. In principle, how accurate positioning ODrive can achieve, if we assume no error from the encoder? Also, we can get position data from rotation encoder by counting revolutions, right? 

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/755575b9-c41d-4071-9a13-41ac8dec62e9%40googlegroups.com.

[Trampas Stern]

The Nano Zero Stepper is like the Mechaduino and uses a 14bit rotational encoder.  With averaging (which is done using Iterm of the PID) the accuracy is +/-1/2 bit. While a single sample accuracy appears to be within a couple of bits. 14 bits is 16384 counts per revolution.  Note however the accuracy due to calibration and other errors are such that you can not position motor to the accuracy of the encoder. 

You can see a demo of the unit connected to one of Peter' heads:

https://www.youtube.com/watch?v=GPzezjQHAuE

Running at high RPMs you can see the accuracy of the system:

https://www.youtube.com/watch?v=9EQ9Z9q5NG8

[Lisandro B]

On my CNC I have linear rails and c7 ball screws, just tell me which motor can replace my currently 3nm stepper and let's start testing :)

[Lamont Cranston]

On Dec 19, 2016, at 7:14 AM, Red Davies <noid...@gmail.com> wrote:
> So, I've been working on a 'glue-on' magnetic linear encoder for the
> MGN12-style of rail.

Sounds interesting, can you say more about this? Curious how/where you mount the strip.

I've been playing with the AMS magnetic linear encoders but they say you should not stick them to ferrous metals and many of the linear rails use ferrous stainless steel.

[Oskar Weigl]

You can check the table on the bottom of this post (Link) for some appropriate motors. Maybe this one (Link) is appropriate?

Do keep in mind that these kinds of brushless motors are usually a bit faster and less torquey than steppers, so it may be oversized unless you actually need 3Nm peak torque.

Make sure you are signed up to the board manufacture signup (Link) and you will get a board as soon as they are ready.

Thanks for helping out with testing ;D

Cheers,

Oskar

On Thu, Dec 22, 2016 at 2:08 PM 'Lisandro B' via OpenPnP <ope...@googlegroups.com> wrote:

On my CNC  I have linear rails and c7 ball screws,  just tell me which motor can replace my currently 3nm stepper and let's start testing :)

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/105351f6-e5dc-4848-bd86-200b59621bd1%40googlegroups.com.

[Oskar Weigl]

When I got the batch manufactured, 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

Video link!

Cheers,

Oskar

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3f36efa1-54d4-4119-97ce-033db3309d30%40googlegroups.com.

[Oz-Ron]

Oskar,

I am impressed! This manufacturing technique is very clever.

Using the SR-71 principle, if the parts move fast enough, the leads can then reflow the solder paste directly upon placement thereby alleviating the need to run the PCB through an oven!  Pick, place & solder all in one……. J   

 

Happy new year to all, and special thanks to Jason for his incredible dedication & swift responses.

OpenPnP will live long and prosper!

 

Cheers,

Ron

 

[Oskar Weigl]

Haha in this context, at first I thought SR-71 was some sort of infrared lamp soldering standard. But as soon as I tried to Google it, I see that you are a funny guy xD. 

I think the main problem of this technique is the noise of going through the sound barrier so frequently (;

Cheers, 

Oskar 

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f7e7ad42-b288-4a90-b299-ac9f30a52f1f%40googlegroups.com.

[Mark Harris]

Its not a very large frontal area so the bang wont be too bad... the noise from your new plasma bearings though... :)

On Dec 26, 2016 06:43, "Oskar Weigl" <oskar...@gmail.com> wrote:

Haha in this context, at first I thought SR-71 was some sort of infrared lamp soldering standard. But as soon as I tried to Google it, I see that you are a funny guy xD. 

I think the main problem of this technique is the noise of going through the sound barrier so frequently (;

Cheers, 

Oskar 

On Mon, 26 Dec 2016, 03:35 Oz-Ron, <ronedw...@gmail.com> wrote:

Oskar,

I am impressed! This manufacturing technique is very clever.

Using the SR-71 principle, if the parts move fast enough, the leads can then reflow the solder paste directly upon placement thereby alleviating the need to run the PCB through an oven!  Pick, place & solder all in one……. J   

 

Happy new year to all, and special thanks to Jason for his incredible dedication & swift responses.

OpenPnP will live long and prosper!

 

Cheers,

Ron

 

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/L44yY_LGNls/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f7e7ad42-b288-4a90-b299-ac9f30a52f1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2Brx3hLk730tnU5xhL6T%3DUYsPMOmtypX4TW-wgxyaR2uAp%3DGvA%40mail.gmail.com.

[Oskar Weigl]

Hi,

Just wanted to let you guys know that there is an ODrive community getting started over at https://discourse.odriverobotics.com, with some discussion that you might find interesting.

Cheers!