Search This Blog

Thursday, November 6, 2014

Mechatronics Project 4

Project 4 moved away from microcontrollers. For this project, we had to do System Identification of a brushed DC motor using Matlab, Simulink, and an XPC target. This was very similar to a project I had to do in Instrumentation and Measurement Systems last semester, but instead of Labview doing the motor control and data collection, simulink and the XPC target were. The basic idea is to feed the motor pseudorandom binary noise (PRBS) and collect voltage, current, position, and velocity data. The voltage is used as an input, and the current, position, and velocity are used as output, to a grey box motor model. The Matlab SystemID toolbox PEM function was used to find the model parameters, which were first estimated from knowledge of brushed motors (ex: rotor inertia, winding resistance, etc). After the model is obtained, it's checked against the data that was used to make it, i.e. the same input that was used to build it was input into the model, and the outputs of the model were checked against the actual data outputs. This was the verification step. A second set of PRBS data, a set of square wave data, and a set of triangle wave data, were then run through the model, and the model outputs were compared to the real data ouputs (in the time domain). This was the validation step. Finally, the frequency response of the model was compared to the frequency response of the validation PRBS data. That was all repeated for a two parameter/output model, where the current was not used.

Here is a link to my project 4 report: public google drive

Below is my simulink model that was built and loaded onto the XPC target. Going from top -> down, the first set of blocks generate various PWM waveforms that feed into the motor driver. The next set of blocks handle analog data acquisition of motor current and voltage. The next set is a digital output for direction control. The last set of blocks reads the motor's encoder channels, converts the rising/falling edges into up counts and down counts via a state model, and outputs angular position and velocity.

Simulink Model

The physical setup is shown in the next picture.

Messy wires
The XPC target had a NI 6070e DAQ card and was connected to my laptop via ethernet. The current sensor and motor driver are on the breadboard. The motor is lower center. The DAQ accessory breakout board is the green thing center. The XPC target is in upper left. An oscilloscope (upper right) was used for debugging.

I made 3 Matlab scripts. One read the XPC host scope data and saved it in .mat files. One post-processed the data. This included filtering, unit conversions, and creating iddata objects. The third script handles the model building, model estimation, and time and frequency domain data comparisons to the model. Again, I can't post my scripts because the class is still on-going.

The following are the resulting comparisons between model 1 (3 parameter model) and the data. Blue is the model, and grey is the data. You'll have to blow all these up to see them well...sorry about that.

PRBS verification

PRBS validation

2Hz Square wave

3Hz Triangle wave
The model and the data matched very well. I believe current sensor noise and velocity noise (and the resulting heavy filtering) caused most of the discrepancies. Cleaning up the wiring and using a better velocity calculation technique (some sort of moving average) would probably have helped. The average correlation was about 85%. Position and velocity did better than current in most cases.

The following is the frequency response comparison for model 1.

Model 1 Frequency Response
The model and data agree well out to about 60 rad/s (~10Hz). The goal was to get a model that was good out to about 5Hz.

Model 2's plots looked very similar except for the absence of current.

Over all, it was a success. Two good, usable models of the motor were obtained. I now know how to use Simulink and XPC targets, and I got a refresher on SystemID. The XPC target was far superior to Labview for this project because it is a realtime system, while Labview is not. When I did this with Labivew, I was unable to sample the encoder fast enough to prevent aliasing above a certain (low-ish) RPM; I was also running into the software loop execution rate limit (~0.001s). Note: I made it sound a lot easier than it was. The Labview project took ~100 hours. This time around it took about 50 hours. SystemID is hard to get right.

Again, I can't post the codes for this project until the class changes this project.

Useful documents/links:
-Matlab/simulink documentation and tutorials are excellent
-http://www.ni.com/white-paper/7109/en/
-http://www.edn.com/design/integrated-circuit-design/4363949/Decode-a-quadrature-encoder-in-software
-motor, motor driver, current sensor data sheets
-NI DAQ card data sheet