OpenServo.com Forum Index OpenServo.com
Discussion of the OpenServo project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Brushless DC Servo
Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenServo.com Forum Index -> Hardware
View previous topic :: View next topic  
Author Message
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Thu Nov 19, 2009 10:33 am    Post subject: Brushless DC Servo Reply with quote

In a different thread, FireBALL asked if it were possible to create an OpenServo using a BLDC motor. I mentioned that it was possible and I volunteered to investigate further.

Here are my initial schematics, based on the OpenServo v3 design and Atmel app note 444:



Let's discuss.
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Thu Nov 19, 2009 10:50 am    Post subject: Reply with quote

To begin the discussion, I have two main questions:

I've never truly understood the purpose and use of the AREF pin on AVRs. Have I drawn the right signal to the AREF pin? The app note suggests using this pin compared to the BEMF from the motor to determine timing for commutation, but maybe I've implemented it wrong.

Also, can someone double-check that the voltage dividers/low-pass filters (VD/LPF) are using sane values? I tried to scale the outputs for a 7.2v - 24v battery supply. (Maybe I should narrow that range so we can get better use of the ADC?)

Thanks. Talk to you soon.

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 361
Location: Maine USA

PostPosted: Thu Nov 19, 2009 10:55 am    Post subject: Reply with quote

This MOSFFET might be of interest here.

http://octopart.com/parts/search?q=VNB28N04&js=on

The OV protected devices have some nice benefits relative to those inductive spikes.

ST has similar chips for high side, or low side drive.
Back to top
View user's profile Send private message Visit poster's website
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 361
Location: Maine USA

PostPosted: Thu Nov 19, 2009 11:14 am    Post subject: Reply with quote

I see a typical 1 amp load would use a .1 ohm Rsense. That's nearly 1/8 watt to dissipate. Not exactly a huge amount. It increases if you increase your motor current as well.

I'm mostly concerned that LR circuits are often known as tank circuits. If you lower your Rsense, you lower the chances of resonance issues that can cause voltage to spike way high. Perhaps one of the hall current sensing devices would help reduce that. They are typically in the .0xx ohms range.

http://www.allegromicro.com/en/Products/Categories/Sensors/currentsensor.asp

Also about position, have you see the thread about OpenEncoder yet?

http://www.openservo.com/Forums/viewtopic.php?t=940

If you can plan for an extra line that can be used as a software I2C, you might get full rotation and positional feed back. OE requires +5, GND, SCL and SCA lines. SCL and SCA are done via software, not dedicated hardware. Or at least that's my plan with the OSV3. More about my OE progress can be found here.

http://www.openservo.com/ConstructionTutorial_MG995_open-encoder?highlight=%28mg995%29

[edit]
Just noticed you called for a 1k Rsense. Perhaps hall isn't right for this app.
[/edit]
Back to top
View user's profile Send private message Visit poster's website
kbb



Joined: 01 Jun 2007
Posts: 180

PostPosted: Thu Nov 19, 2009 11:02 pm    Post subject: Re: Brushless DC Servo Reply with quote

There's also AVR related (talks about the ATmega32M1) information on driving a brushless CD motor here

http://www.atmel.com/dyn/resources/prod_documents/doc8138.pdf
Back to top
View user's profile Send private message
kbb



Joined: 01 Jun 2007
Posts: 180

PostPosted: Thu Nov 19, 2009 11:30 pm    Post subject: Reply with quote

robotjay wrote:
I've never truly understood the purpose and use of the AREF pin on AVRs. Have I drawn the right signal to the AREF pin?


AREF is the reference voltage for the ADC: it determines the voltage range that the 10-bit ADC can measure. If the pin is not connected to anything then you get to choose AVCC or an internal 1.1V reference. If you connect AREF to a voltage source, then that is the only reference voltage you can use (see Note 1). For example: if you connect a precision 3V reference source to it, the ADC will measure between 0 and 3V across its 10-bit range (ADC == 1023 == 3V).

Edit: [Note 1] For some AVR, including the ATmega48/88/168. But not all, for example: the ATmega16/32/64M1 allows you to select any of the references.


Last edited by kbb on Sat Nov 21, 2009 4:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Fri Nov 20, 2009 9:20 am    Post subject: Reply with quote

jharvey,

Quote:
This MOSFFET might be of interest here.

http://octopart.com/parts/search?q=VNB28N04&js=on


Nice find. This seems like a no-brainer. Eliminates the need to software monitor current and temp. I'll grab a few samples and see if they're worth using.

Quote:
Just noticed you called for a 1k Rsense. Perhaps hall isn't right for this app.


When you say "just called for" do you mean by the voltage requirements I listed? Is this voltage spike something we should be concerned about? Is there a way to clamp the spike without having to use expensive current measurement chips?

Quote:
OE requires +5, GND, SCL and SCA lines. SCL and SCA are done via software, not dedicated hardware.


Awesome work with the OE! I've really been out-of-the-loop too long, and I'm excited to see where this goes. Why use bit-banged I2C? The hardware is already there and ready to go, and I2C can hold up to 128 devices no problem. Regardless, I'll be sure to add support in software for this.



Kevin,

Quote:
If you connect AREF to a voltage source, then that is the only reference voltage you can use.


So if we try to use a potentiometer for feedback, we'll get inconsistent results because the AREF voltage will bounce around, right? The app note suggests using the AREF in this way, but the app note doesn't anticipate us trying to close the motion loop. Maybe I should go to a fixed ADC reference, and monitor the zero-crossings in software, rather than by using hardware interrupts. Or maybe I should scrap analog position reference, and use nothing but encoders or digital potentiometers. Comments welcome. Talk to you soon.

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 361
Location: Maine USA

PostPosted: Fri Nov 20, 2009 10:16 am    Post subject: Reply with quote

Quote:
When you say "just called for" do you mean by the voltage requirements I listed?

What I mean was that I had just noticed you called for a 1k resistor, while the data sheet I was looking at used a .1 ohm resistor. This change in value changes the circuit greatly, and I'll have to stew it over a bit more before I can decide if I should encourage a hall based, or resistor based current sensor circuit.

The ACS712 and ACS714 are $3 ea. That is kind of expensive, but not really that bad. I see it's insertion resistance is 1.2 milli ohm. I also think they have some that aren't advertised. I seem to call some that you didn't have insert in series, just put them over the trace and it picks up the field that way.

Quote:
Why use bit-banged I2C?


That data is typically not needed by the rest of the devices on the master bus. It's bandwidth would increase jitter and decrease the number of devices you can have on that bus. Also I don't believe the packet formation of the OSV3 protocol is compatible with the OE protocol.

So I'm planning for the local bus, and if OE data is desired, it can be obtained on request.
Back to top
View user's profile Send private message Visit poster's website
kbb



Joined: 01 Jun 2007
Posts: 180

PostPosted: Sat Nov 21, 2009 1:16 am    Post subject: Reply with quote

robotjay wrote:
So if we try to use a potentiometer for feedback, we'll get inconsistent results because the AREF voltage will bounce around, right?


My understanding from the manual on the ATmega48/88/168 is that if you supply a voltage to AREF, then you cannot use the “internal references” (23.5.2 ADC Voltage Reference, and elsewhere).

An ATmega48/88/168 manual.

My quick skim thru the application note you linked to indicates that their solution is to connect VCC (known and fixed value) to one of the ADC inputs and sample it, then use that reading to scale other ADC readings (where needed) appropriately: probably only the “current” reading needs to be scaled in the example application. VMOTOR is presumably required to be greater than, or equal to VCC.

In such a solution (assuming the pot is connected between ground and VCC as in OpenServo), two readings would need to be taken to get a position pot reading: one immediately after the other. One for VCC and one for the pot. The VCC reading would then be used to scale the pot reading to the correct value.

The only problem with this is that you lose resolution in the pot readings (which might already be considered moderately low res), the higher the V of the motor supply (VMOTOR), the more you lose.

Therefore, if one wanted to retain the current pot resolution I imagine one would leave AREF unconnected (using VMOTOR for the pot would almost certainly contain too much noise, or maybe a filter would help with that) and connect VMOTOR to one of the ADC ports through a potential divider (just as OpenServo does for VBATT). However, the same would need to be done for U, V, W and speed-ref.

The potential divider may introduce an accuracy issue (depending on what accuracy is needed and the tolerance of the chosen resistors). Therefore, if more accuracy for the readings from the motor (U, V and so forth) is needed, some simple “calibration” may be needed.

You’re dropping the “speed reference” in your schematic, in favour of position? That means there will be just enough ADC ports: U, V, W, current, VMOTOR (or VCC) and position (SCL and SDA are on ADC5/ADC4 when using the I2C interface). Total 8 (given the correct package form).

Caveat: I am dumping my brain, I probably haven’t thought though all the possible angles on this. For example: are there any issues with AREF not tracking VMOTOR? Of course there are other solutions (external ADC for the pot, two MCUs, different AVR, and so on).


Last edited by kbb on Sat Nov 21, 2009 4:52 pm; edited 1 time in total
Back to top
View user's profile Send private message
FireBALL



Joined: 24 Jul 2009
Posts: 28

PostPosted: Sat Nov 21, 2009 4:58 am    Post subject: Re: Brushless DC Servo Reply with quote

robotjay wrote:
In a different thread, FireBALL asked if it were possible to create an OpenServo using a BLDC motor. I mentioned that it was possible and I volunteered to investigate further.

Let's discuss.


Way to go Robot JAy. Let me know once the schematic is ready and I'll have the pcbs fabed
Back to top
View user's profile Send private message
kbb



Joined: 01 Jun 2007
Posts: 180

PostPosted: Sat Nov 21, 2009 4:53 pm    Post subject: Re: Brushless DC Servo Reply with quote

FireBALL wrote:
Let me know once the schematic is ready and I'll have the pcbs fabed


I'd recommend prototyping it first, it will save a load of pain.
Back to top
View user's profile Send private message
FireBALL



Joined: 24 Jul 2009
Posts: 28

PostPosted: Sat Nov 21, 2009 5:27 pm    Post subject: Re: Brushless DC Servo Reply with quote

kbb wrote:

I'd recommend prototyping it first, it will save a load of pain.


of course KBB, the schematic is very logical, hence easy to work with the actual pcb rather than the breadboard. And not to mention I'm always in hurry Smile
Back to top
View user's profile Send private message
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Mon Nov 23, 2009 6:49 am    Post subject: Reply with quote

Jared,

jharvey wrote:
What I mean was that I had just noticed you called for a 1k resistor, while the data sheet I was looking at used a .1 ohm resistor. This change in value changes the circuit greatly, and I'll have to stew it over a bit more before I can decide if I should encourage a hall based, or resistor based current sensor circuit.


You should take the values in my schematic with a grain of salt. I literally copy and pasted the current monitoring circuit from the OSv3 schematic. I do not know enough about the Zetex current monitoring IC to say what value resistors should be used in this application. I personally like your idea to use a hall sensor instead, considering we don't have the same space restrictions we have on the OSv3. I'll shoot an email over to the ST application engineers and let them recommend an appropriate sensor for us.

Kevin,

paraphrased by RobotJay, kbb wrote:
In such a solution, two readings would need to be taken to get a position pot reading.


After doing some math and assuming we leave the ADC inputs scaled as I've drawn them, at best (6.2v battery) we'll get 90.0% of the total ADC range. At worst (30v battery) we get 18.6%. Good news: The resolution increases slightly as the battery drains... Unfortunately though, at 10-bit resolution, worst case gives us only 190 (less than 8-bit) ticks of resolution. This is unacceptable and we have to find another solution.

paraphrased by RobotJay, kbb wrote:
Therefore, if one wanted to retain the current pot resolution one would leave AREF unconnected and connect VMOTOR to one of the ADC ports through a potential divider


Please correct me if I'm wrong, but this still leaves us with resolution issues dependent on the VMOTOR value. Instead of having low resolution on the position, we've now shifted it to U,V,W, and the battery voltage itself. The lower resolution will affect the timing of the motor, and I don't know what sort of effect (if any) this would have.

kbb wrote:
Of course there are other solutions (external ADC for the pot, two MCUs, different AVR, and so on).


I've weighed a lot of ways to do this, but IMHO, the easiest work around is to use a second AVR with a DAC. The second AVR simply outputs a scaled potentiometer value through its DAC to the first AVR. Considering I've got about a hundred ATMega168s lying around, I'll draw an extra one of these into the schematic to serve as second AVR, although we could easily save money and board space by using a smaller/slower microcontroller. Let me know if you have any objections to this, as I may be overlooking important details.

ALSO, there might be some sort of off-the-shelf solution for this already, without using another AVR. If there is, I'm unaware of it, and Google has yielded very little for me. Talk to you soon.

-Jay

EDIT 11/23/2009: Of course, all of the analog scaling problems disappear if we use a digital encoder, like Jared's OpenEncoder. I'd still like to retain analog positioning for posterity's sake.
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Mon Nov 23, 2009 7:40 pm    Post subject: Reply with quote

Nice.

I would go with hall or encoders as this is easiest to do.
If you do then you can drop the back EMF support, as it serves no useful purpose. Kevin has probably noted that Back EMF is tricky somewhere in the board, and I would agree. It is much less linear, hard to get right for timings, and has a negative effect on the torque.

Otherwise I am impressed. I would love to make a mini controller to control BLDC for a quadcopter I am playing with.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
kbb



Joined: 01 Jun 2007
Posts: 180

PostPosted: Mon Nov 23, 2009 11:07 pm    Post subject: Reply with quote

robotjay wrote:
paraphrased by RobotJay, kbb wrote:
Therefore, if one wanted to retain the current pot resolution one would leave AREF unconnected and connect VMOTOR to one of the ADC ports through a potential divider


Please correct me if I'm wrong, but this still leaves us with resolution issues dependent on the VMOTOR value. Instead of having low resolution on the position, we've now shifted it to U,V,W, and the battery voltage itself. The lower resolution will affect the timing of the motor, and I don't know what sort of effect (if any) this would have.

You are correct! I don’t know what the effect would be either, but possibly preferable to collapsing the resolution of the position if there was a desire to cram it all into one AVR. Which I am now thinking is probably not a good way to go.

robotjay wrote:
kbb wrote:
Of course there are other solutions (external ADC for the pot, two MCUs, different AVR, and so on).


I've weighed a lot of ways to do this, but IMHO, the easiest work around is to use a second AVR with a DAC. The second AVR simply outputs a scaled potentiometer value through its DAC to the first AVR. Considering I've got about a hundred ATMega168s lying around, I'll draw an extra one of these into the schematic to serve as second AVR, although we could easily save money and board space by using a smaller/slower microcontroller. Let me know if you have any objections to this, as I may be overlooking important details.

Sounds like a good way to go to me.

My thoughts along the dual AVR route was slightly different: that one AVR would implement the BLDC drive, basically much as in the app note. The second (master) would measure position, current for over current cut off, implement the I2C “command and control” interface and so on. The two controllers might communicate with each other over the UART interface, the master would tell the BLDC what the current position is and needs to be (or whatever), whether to stop, and so forth. Seems like a very simple protocol would suffice. Essentially an OpenServoV3 which controls the BLDC AVR rather than driving a H-bridge.

robotjay wrote:
ALSO, there might be some sort of off-the-shelf solution for this already, without using another AVR. If there is, I'm unaware of it, and Google has yielded very little for me. Talk to you soon.


Anything like these of use?:

http://www.farnell.com/datasheets/391874.pdf
http://www.farnell.com/datasheets/389114.pdf

They’re low-cost, but an unknown quantity to me without doing a lot of reading. At least with the two AVR route one knows where one stands. In any event, it is something that could be worked out by bread-boarding designs to test them.

robotjay wrote:

EDIT 11/23/2009: Of course, all of the analog scaling problems disappear if we use a digital encoder, like Jared's OpenEncoder. I'd still like to retain analog positioning for posterity's sake.


I came across the ME120 and ME210 here the other day. Sadly, the resolution seems a bit low and the price a bit high.

http://www.nubotics.com/products/index.html
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenServo.com Forum Index -> Hardware All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group