rhitee05
10 kW
I normally stay on the hardware side of things, but I'm making an ill-advised foray into the software side of controller design. I figured I might as well document my misadventures for others to look at. If there's interest, I'd love to have a discussion here about designs, techniques, etc. As long as it's mostly related to the software side of controllers, I won't consider it OT. 
Background
As a grad student, I'm currently taking a class on FPGA Design, which is mostly project-based. I've talked my professor into letting me work on implementing a BLDC controller as my project for the class. Now, that comes with a few caveats. As any engineering student will tell you, class projects are usually somewhat contrived for educational purposes! In this case, there are a few specific types of functionality I have to include to keep my professor happy (happy professor = happy student!). However, I don't think that will sidetrack the project too much from where I'd like it to be. The second caveat is that the hardware I will be using for class would not be workable for a useful controller. However, I don't think that will be a major obstacle either. The end result should be portable to a more appropriate platform. It'll be easier to get a handle on the hardware requirements once I actually start writing code.
Concept
I've started by brainstorming roughly what the "ideal" controller would be capable of as an end-goal. Here's a quick bullet-point list:
- Sensored and sensorless operation, automatic detection of Halls, possibly "hybrid" mode using sensored for low-speed and sensorless for high-speed
- Field-oriented control using a design heavily based on Shane Colton's (write up here: http://web.mit.edu/scolton/www/MSCR_Rev1.pdf)
- Closed-loop control with current-based (torque) throttle and outer speed loop for "true" cruise control
- Capability for high electrical RPMs and high PWM frequencies (maybe on-the-fly adjustable PWM frequency?)
- Data logging with serial interface for download to PC, possibly "dev mode" allowing PC control via serial port
- "Intelligent" capabilities: still brainstorming here, but some ideas are:
- Automatic sensing of phase and hall connections to determine correct wiring pattern
- Self-tuning mode runs a calibration routine to adjust control loop parameters for optimal response in a given system configuration
- Self-diagnostic functionality, error detection/logging, etc.
I know this sounds ambitious, and it is. I'll be the first to admit that! The design process here it to start with a lofty goal and then work toward it in a series of small, incremental steps.
Methodology
I've thought for some time now that an FPGA-based controller could be superior to a traditional MCU-based one. The main reason is that FPGAs are inherently parallel. The control task can be broken into many smaller parts - rotor position sensing, commutation, PWM generation, throttle control, etc. A MCU must do each of these in sequence, so the speed of any given task is limited by the total of all tasks. This limitation does not exist in a parallel architecture. The PWM generator can operate independently of the throttle and thus be made almost arbitrarily fast, accepting a new throttle signal whenever the throttle module is done generating one. Each module operates independently and communicates asynchronously with the other modules. Adding more functionality to one area will require fewer trade-offs in other areas.
This makes incremental development possible. I can start by building a simple controller which uses Hall sensors only and does basic 6-step commutation. More functionality can be built around that, and each of those simple modules can be gradually replaced by more advanced versions. There are many intermediate steps along the way where I can pause to test and debug the design before making the next leap. Jumping directly into an advanced design like this would be nearly impossible, but by taking an incremental approach the brick wall becomes a set of manageable steps.
Development Plan
I'm feeling this out as I go, but here's what I have so far. Our class projects are divided into three sections, so my development schedule will be based around this structure.
The first segment of the project will make use of the FPGA's embedded processing capabilities. For this I'll be constructing the data logging, serial UI, and a sort of "system supervisor." The supervisor probably won't do very much for now, but eventually this is where the "intelligent" functionality will be implemented. I may implement the "simple" 6-step commutation controller at this stage, or I might just create a dummy testbench to generate fake data to feed the other modules for testing.
The second segment will make use of signal processing. This is when I'll implement the math necessary for field-oriented control. I might also get into the sensorless algorithm here.
The 3rd segment will likely work to fill in the gaps left after the first 2. There will be a few PI/PID controllers used in the system as well as some other miscellaneous functionality. If I don't get to sensorless in stage 2 it will be done here.
It's not clear yet if I'll be able to test this on an actual motor during the class. It would be very nice to do so, but it's not strictly necessary for my course. I might buy a tiny little outrunner and throw together a very bare-bones FET bridge to serve as a test mule.
After I finish my class-related obligations, I'll take stock of where I'm at and what is left to be done. Assuming that most of the functionality is complete, the main task here will be to take a close look at the hardware requirements. For our class we're using a development board which should have plenty of capability. However, this board uses a part that is obsolete (several tech generations old) and from the high-performance (high-cost) Virtex line. For this to be practical, it will have to be ported to a more affordable part. I think this should work out fine, but we'll have to cross that bridge when we get to it.
Technical
I'll say a few words about the languages and techniques I'll be using to do this. As I mentioned before, for our class we're developing for the Xilinx Virtex II Pro platform. Most of the development will be done in a language called VHDL. I won't say anything more here other than it's a hardware description language, rather than a traditional software language. Some parts of the design will be done using C, specifically the embedded tasks - the "supervisor", data-logging, and serial UI. Both parts should end up being fairly portable to a different platform once my class is complete.
Community Input
I'll let all of the above sink in before I start putting up lots of design details. But, I wanted to throw the doors open and invite any feature suggestions. I reserve the right to reject any or all suggestions, but I'd be willing to bet people have a lot of good ideas I didn't think of. Let's hear them!
Background
As a grad student, I'm currently taking a class on FPGA Design, which is mostly project-based. I've talked my professor into letting me work on implementing a BLDC controller as my project for the class. Now, that comes with a few caveats. As any engineering student will tell you, class projects are usually somewhat contrived for educational purposes! In this case, there are a few specific types of functionality I have to include to keep my professor happy (happy professor = happy student!). However, I don't think that will sidetrack the project too much from where I'd like it to be. The second caveat is that the hardware I will be using for class would not be workable for a useful controller. However, I don't think that will be a major obstacle either. The end result should be portable to a more appropriate platform. It'll be easier to get a handle on the hardware requirements once I actually start writing code.
Concept
I've started by brainstorming roughly what the "ideal" controller would be capable of as an end-goal. Here's a quick bullet-point list:
- Sensored and sensorless operation, automatic detection of Halls, possibly "hybrid" mode using sensored for low-speed and sensorless for high-speed
- Field-oriented control using a design heavily based on Shane Colton's (write up here: http://web.mit.edu/scolton/www/MSCR_Rev1.pdf)
- Closed-loop control with current-based (torque) throttle and outer speed loop for "true" cruise control
- Capability for high electrical RPMs and high PWM frequencies (maybe on-the-fly adjustable PWM frequency?)
- Data logging with serial interface for download to PC, possibly "dev mode" allowing PC control via serial port
- "Intelligent" capabilities: still brainstorming here, but some ideas are:
- Automatic sensing of phase and hall connections to determine correct wiring pattern
- Self-tuning mode runs a calibration routine to adjust control loop parameters for optimal response in a given system configuration
- Self-diagnostic functionality, error detection/logging, etc.
I know this sounds ambitious, and it is. I'll be the first to admit that! The design process here it to start with a lofty goal and then work toward it in a series of small, incremental steps.
Methodology
I've thought for some time now that an FPGA-based controller could be superior to a traditional MCU-based one. The main reason is that FPGAs are inherently parallel. The control task can be broken into many smaller parts - rotor position sensing, commutation, PWM generation, throttle control, etc. A MCU must do each of these in sequence, so the speed of any given task is limited by the total of all tasks. This limitation does not exist in a parallel architecture. The PWM generator can operate independently of the throttle and thus be made almost arbitrarily fast, accepting a new throttle signal whenever the throttle module is done generating one. Each module operates independently and communicates asynchronously with the other modules. Adding more functionality to one area will require fewer trade-offs in other areas.
This makes incremental development possible. I can start by building a simple controller which uses Hall sensors only and does basic 6-step commutation. More functionality can be built around that, and each of those simple modules can be gradually replaced by more advanced versions. There are many intermediate steps along the way where I can pause to test and debug the design before making the next leap. Jumping directly into an advanced design like this would be nearly impossible, but by taking an incremental approach the brick wall becomes a set of manageable steps.
Development Plan
I'm feeling this out as I go, but here's what I have so far. Our class projects are divided into three sections, so my development schedule will be based around this structure.
The first segment of the project will make use of the FPGA's embedded processing capabilities. For this I'll be constructing the data logging, serial UI, and a sort of "system supervisor." The supervisor probably won't do very much for now, but eventually this is where the "intelligent" functionality will be implemented. I may implement the "simple" 6-step commutation controller at this stage, or I might just create a dummy testbench to generate fake data to feed the other modules for testing.
The second segment will make use of signal processing. This is when I'll implement the math necessary for field-oriented control. I might also get into the sensorless algorithm here.
The 3rd segment will likely work to fill in the gaps left after the first 2. There will be a few PI/PID controllers used in the system as well as some other miscellaneous functionality. If I don't get to sensorless in stage 2 it will be done here.
It's not clear yet if I'll be able to test this on an actual motor during the class. It would be very nice to do so, but it's not strictly necessary for my course. I might buy a tiny little outrunner and throw together a very bare-bones FET bridge to serve as a test mule.
After I finish my class-related obligations, I'll take stock of where I'm at and what is left to be done. Assuming that most of the functionality is complete, the main task here will be to take a close look at the hardware requirements. For our class we're using a development board which should have plenty of capability. However, this board uses a part that is obsolete (several tech generations old) and from the high-performance (high-cost) Virtex line. For this to be practical, it will have to be ported to a more affordable part. I think this should work out fine, but we'll have to cross that bridge when we get to it.
Technical
I'll say a few words about the languages and techniques I'll be using to do this. As I mentioned before, for our class we're developing for the Xilinx Virtex II Pro platform. Most of the development will be done in a language called VHDL. I won't say anything more here other than it's a hardware description language, rather than a traditional software language. Some parts of the design will be done using C, specifically the embedded tasks - the "supervisor", data-logging, and serial UI. Both parts should end up being fairly portable to a different platform once my class is complete.
Community Input
I'll let all of the above sink in before I start putting up lots of design details. But, I wanted to throw the doors open and invite any feature suggestions. I reserve the right to reject any or all suggestions, but I'd be willing to bet people have a lot of good ideas I didn't think of. Let's hear them!
