Field Oriented Control using dsPic33

What type of probes do you guys use when scoping controller waveforms? Is it safe to use the ones that typically comes with the scope for ~100V ?
 
pelle242 said:
What type of probes do you guys use when scoping controller waveforms? Is it safe to use the ones that typically comes with the scope for ~100V ?
I think most scopes can handle 50v so when you need to scope higher voltages you MUST switch the switch on the probe to 10x. All the probes I have switch between 1x or 10x so if your scope can handle 50v on 1x (read data sheet) then 500v on 10x is likely the max. Be careful scoping these voltages I have made the ends of a few multimeter's disappear because of a small slip and if a couple fingers are involved you can be in trouble.
 
Burtie said:
Very nice. But is sine any good on RC/BLDC motors with non-sine BEMF? I guess it's only good for induction motors. On BLDC/PMDC/PMAC motors, DTC/FOC should be used...


BTW, sorry for intruding, but some of you guys might be interested in my Rigol scope that I no longer need:
http://endless-sphere.com/forums/viewtopic.php?f=9&t=42889&p=626782#p626782
A huge advantage over ATTEN is it's built-in 16-channel logic analyzer.
P.S. Rigol is a subsidiary of Agilent.
 
Lebowski said:
...Also, it's very easy to implement very smooth torque control and braking (regen) control.


Ok it turned out to be so easy, I had to change nothing in the software, It just works :)

So here is a short demo, showing the variable strength regenerative braking in action ( caution: this video has v high nerdiness rating :eek: )

http://www.youtube.com/watch?v=-fiGinj8c7Q&feature=youtu.be
[youtube]-fiGinj8c7Q[/youtube]


I will infact have to modify the software slightly to disable this feature when electric braking is not required.

Burtie
 
Burtie can I ask which compiler you are using, and at which level of optimization?
 
bigmoose said:
Burtie can I ask which compiler you are using, and at which level of optimization?

Hi Dave,
The C compiler I am using is MPLAB C30 v3.31 Optmisation level 0

I believe the free version of this compiler will give this capability :)

Burtie
 
Burtie said:
Got the demo board running well enough to try a low lower dyno run,
-comparing the efficiency of the FO algorithm against the standard trapezoidal one.

Using Identical hardware to run both algorithms, and motor hall sensors with neutral timing,
This is what I found....

Slightly disappointing not to see any efficiency increase using the FOC yet.

Burtie

Wow that is cool, especially the dynamometer. I thought FOC controllers would be available in the RC world similar to this trapezoidal ESC from hobby King http://www.hobbyking.com/hobbyking/store/uh_viewitem.asp?idproduct=10331 . I was thinking the noise reduction alone would be enough justify their use but all I can find is your project. The 67% efficiency seems very low. Is that because the motors are running slow?

The graph on pg 97 in the PhD thesis at http://webfiles.portal.chalmers.se/et/PhD/JohanAstrom.pdf shows marginal improvement (about 3% max) with an optimal control scheme over standard BLDC motor control for a 375W motor. He uses Direct Current Control arguing it is simpler to implement than FOC and more efficient because of less switching, stating on pg 86 "As a result, it will be possible to reduce the number of switching transitions, mainly due to active choice of the zero space vectors, SV0 and SV7. Only the currents and the position of the motor needs to be known which simplifies the control compared to FOC."

Teh Stork said "4. Field weakening can substantially increase speed of motor, and you need FOC to realize this." I think you can also get field weakening with timing advance using a six step trapezoidal BLDC controller to get higher speed at the cost of decreased efficiency due to increased copper losses caused by the extra current.
 
Hi Ken,

Thanks for the link to the thesis, I will give it a read.

I agree the 67% efficiency figure seems low.
I would expect it to improve when I can run the motor at higher power levels.
At only one or two hundred watts, I guess the friction in the motor bearings, particularly the big skirt bearing, are affecting the results significantly.


Currently working on some custom hardware for this FOC algorithm which will allow me to run a lot more power in the next few weeks, so we will find out :)
 
Hello Burtie.

Is this technology private for you sell?

I am looking for a microcontroller and I am looking to PICs but I am more familiar with ARMs. Can you suggest a microcontroller part number?

I am also developing a controller but I am in a lower stage, on the 6 steps :) See here my project page for the controller: http://smartebike.likesyou.org/

Thank you.
 
Burtie said:
I agree the 67% efficiency figure seems low.
I would expect it to improve when I can run the motor at higher power levels.

At only one or two hundred watts, I guess the friction in the motor bearings, particularly the big skirt bearing, are affecting the results significantly.

You could measure the friction losses. The torque due to friction losses is a constant and the no load current would be zero without friction. Therefore Torque friction = no load current x Kt. There is an example in "Graph 2: hub motor torque / speed" at http://avdweb.nl/solar-bike/hub-motor/cute-q-85sx-motor-test.html#h0-1-4-measuring-motor-parameters


Burtie said:
Currently working on some custom hardware for this FOC algorithm which will allow me to run a lot more power in the next few weeks, so we will find out :)

Sounds great. I came across another example of sinusoidal commutation on this forum at http://www.endless-sphere.com/forums/viewtopic.php?f=3&t=22919&hilit=android&start=600#p655443 . Speedict links to this PDF that explains how it is done http://www.endless-sphere.com/forums/download/file.php?id=94710 . Based on this document (pg 3) FOC and sinusoidal commutation may produce the same sinusoidal controller output for your motor which you mentioned you have seen. This document also recommends reverting to trapezoidal control at low speed due to poor position estimation but you seemed to have the motor running very slow in your video.
 
casainho said:
Hello Burtie.

Is this technology private for you sell?

Very early days, If ever I get anything to work well enough, I will probably post the design and offer some PCBs for sale to DIY minded folk :)




Ken Taylor said:
You could measure the friction losses.

I guess so, but would involve dismantling the dyno to remove the belt to the gen, and I kind of got distracted by some shiny electronic stuff :wink:

If you are interested in field oriented control and haven't found it already, you might want to check out the fine work done by Lebowski on this forum, there are a few great threads, documenting his work.

Burtie
 
Burtie said:
casainho said:
Is this technology private for you sell?
Very early days, If ever I get anything to work well enough, I will probably post the design and offer some PCBs for sale to DIY minded folk :)
Ok, good to know. If you need help to put a wiki working or git, just ask, I did just that recently to my project, so I can document it in a more structured way.

Maybe someday I will be able to use your work here, for now I am with 6 steps. Later I plan to change for a powerful ARM Cortex M4 (STM32F405xx) running at 168MHz; DSP instructions; 7 timers; ADC 12-bit, 2.4 MSPS A/D, 7.2 MSPS in triple interleaved; synchronize A/D conversion by the timers. With all this resources I hope to implement FOC and don't need hall sensors. I will keep subscribed to this message. Thanks.
 
Hi there and congratulations for the running FOC. It is not simple to get it work properly and there are a lot of things that can go wrong as i can say from my experiences. I am also working on a BLDC controller with custom PCB and FOC on the basis of an AVR32UC3C from ATMEL. I am using 3 Hall sensors for position monitoring and 2 Allegro current sensors as imputs for the control loop. Furthermore i have implemented space vector modulation like shown in the attachement from TI . The current status is that i can spin the motor in "open loop" which means that i am increasing the commutation angel to force rotation. The plan is to switch to "closed loop" after a certain amount of hall signals after which i can start rotorposition interpolation based on rotor speed. In "closed loop" the current feedback is used to regulate Iq and Id. The problem is that the regulation doesn´t work properly and the rotor gets stuck immediately. I am not sure what is the problem yet. What kind of startup sequenze do you guys use and what values (PI) for the regulation loops are suitable? I know that it depends on the motor characteristics to optimize but i need basic adjustements to start with. I would be very interrested in any working code with hallsensor setup. I searched a lot in the last days and most projects with FOC are sensoreless.

MAny thanks, Peter
 
Hi Peter,

The PI Coefficients I am using are listed at the top of page 3 of this thread, they might be a good place to start.

You can find an example of hall sensor interpollation in Microchip AN1017 (the sinusoidal control app note), I lifted the code from here, adapted it, and applied it to the FOC app.

If you have hall sensors, you can tell where the rotor is, to within +or- 60 edegrees even when the motor is stopped. This is close enough to enable your closed-loop FOC to start the motor from a stand-still, without the need for any open-loop trickery :)
Once you have the motor moving, you can apply the interpollation, which enables you to get a more accurate estimate of the rotor angle.

Keep us posted on your good work!

Burtie
 
Lebowski said:
Burtie said:
Lebowski said:
The bandwidth is not determined solely by the sample rate (20 kHz), but by samplerate and loop coefficients... pity I can't see the code here

Code:
//******** D Control Loop Coefficients *******
#define     DKP        Q15(0.05)
#define     DKI        Q15(0.01)
#define     DKC        Q15(0.99999)
#define     DOUTMAX    Q15(0.99999)

//******** Q Control Loop Coefficients *******
#define     QKP        Q15(0.01)
#define     QKI        Q15(0.005)
#define     QKC        Q15(0.99999)
#define     QOUTMAX    Q15(0.99999)

Thx Burtie, I have seen your coefficients. Am i right that if you write Q15(0.05), that the value 0.05 will be taken and transformed into a fixed point number?! I will try the coefficients and new startup and keep you informed about the progress.
 
Just spent the better part of my morning reading through and following links from your thread Burtie. Thanks for documenting it all and making the cool vids! I like your approach to simplifying the AN1078 startup by splicing in sensored feedback, the need to have a controller that doesn't require calibration is very important. It makes me wonder if the AN1160 code could be spliced in for low speed startup, with transition to VOC at a specific frequency. I'm just getting my feet wet with coding, so the implications and processing needs of such a task is beyond me.
 
PowerPedro said:
I would be very interrested in any working code with hallsensor setup. I searched a lot in the last days and most projects with FOC are sensoreless.
Hi Pedro / Olá Pedro.

Is your project OpenSource?
 
Alan B said:
You guys are having way too much fun.

I think I'll order the Stellaris TI kit.

Am looking for a cheap hubmotor for testing, something will hall sensors but perhaps damaged in some way that doesn't affect test stand use but makes it unsuitable for ebike use.
For the same purpose, I bought a cheap and new Q85 motor from BMSBattery.com. In fact I have two, one already on a testing bicycle :)
 
Back
Top