Sensor Models

Given that sensors are vital to feedback systems I’ve included a bunch of sensor models.  You can see the New Sensor Models by clicking the link.

I’ll be adding more in the future as i get the time.

What finally worked

I have a quad core machine at my desk so I run multiple MATLAB windows.  These multiple windows allowed me to test some distributed computing processes.  As a result I set up a script for allowing the multiple windows to run.  I was using Stateflow in the model which requires a compile before each run.  As a result the model had to be run from a temporary directory.

This temporary directory was the first sign that the function, when distributed, is working.  The second sign was when the output file is saved.

Long story short, the batch command worked.  The batch command works but only with the PathDependencies and FileDependencies properties set.  The function is something like this

jj = batch(’monte_sim_loop’, ‘matlabpool’, 0, ‘PathDependencies’, {…}, ‘FileDependencies’, {…});

The matlabpool set to 0 is important.  I tried to using a matlabpool of 3 for my initial runs.  It tied up 4 nodes but only run 1 instance of the sim.  Then I created a loop

for ii = 1:15

  jj = batch(…

end

The reason that a matlabpool of 3 tied up 4 nodes was that the matlabpool property is for how many additional nodes you want running.  It originally appeared to be an overhead function that was created.  A coworker discovered the matlabpool command already assumes 1 node and so anything higher than 0 ties up that many extra PCs for the 1 job task.  Since I just want my jobs distributed (not parallel) I set the property to 0.   When I ran the loop above, 15 computers were tied up and 15 nodes worth of results were produced.

If you know more, please share

I invite anyone and everyone who knows more about how to use the Parallel Computing Toolbox to share.  Use the comments to share.  Or if you like I welcome guest bloggers.

Thanks

Previous, related, posting

MATLAB’s Parallel Computing Toolbox First Impression

Monte Carlo Runs

For work I’ve been asked to run a Monte Carlo analysis.  The analysis is one where I vary a large set of parameters in a large Simulink simulation.  Any given simulation will take between 40 minutes and a few hours.  So obivously generating thousands of runs with a single computer would take months.

In the lead up to this analysis I asked a few questions.  First, I found a bank of parallel computing resources at work.  I asked them if it was possible and the answer was “Yes” with my take away being that it was doable and easy.  It may be doable, it is not easy.  Second, I went to Mathworks training (on modeling for aerospace system which had a session on parallel computing) and asked some questions about how to run parallel operations.  I also left this session thinking it would be easy.

The online help is worthless

When you are running a model of any complexity there are a lot of parameters to set.  If you are building models correctly you will be setting these parameters via variables not hard coding.  This means that the simulation workspace must have all those variables.

The Mathworks help with regard to the Parallel Toolbox and Simulink simulations is pretty meager.  One of the easiest means of distributing the simulation is through the use of the parfor keyword instead of the for keyword.  The meager help suggests that simulation must be run from within a function because parfor requires a static workspace and Simulink creates variables in whatever workspace it runs from.  So the help suggests using a dummy function as a wrapper for the sim command.

The help forgets to mention that running a simulation from a function’s workspace is simple - once you find that help but finding that help was a little buried.  (If you want to know how look up the simset function and the SrcWorkspace and DstWorkspace properties.)  I have run several simulations from within a function’s workspace on a single PC.  However, doing so from within a dummy function called from a parfor loop doesn’t work like it does from a single PC.  And the error messages are obtuse.

Obtuse Error Messages

I spent days attempting to get the simulations distributed to the various nodes.  The error messages provided at this stage were reasonably straight forward.  However, once the simulation was distributed to the nodes the error became far less useful.  The first couple of times there was no obvious error.  After digging through a long log file a cowroker found the errors and helped me fix them.  That said, I think they were listed as warnings in the log file not errors.

Next Post:  What finally appears to have worked

MEMS Gyro models

MEMS gyroscopes are becoming common in Aerospace systems.  They are small, low power sensors accurate in frequency ranges good for Aerospace applications.  Often, MEMS gyros are the only sensors commerically available that provides the necessary frequency response, mass, power and environmental.

I’ve found 2 types of MEMS gyro modeling.  Both of these modeling types are for the design of the MEMS gyro.  A MEMS gyro sensor requires design of some key parameters - resonant frequency, driving frequency, and quality factor.  These articles are not on the frequency response of the sensor.    The frequency response and noise are the primary items to model for control systems.  So these design articles are high fidelity models and information purposes.

Traditional modeling of MEMS Gyros

Traditional design modeling of MEMS gyros often starts with an FEM of the sensor.  However, the FEM is often too large for feasible modeling.  FEM modeling can be infeasible for memory reasons or simply the length of time it takes to produce results.

The next step in traditional design modeling is to create an equivalent electrical circuit for detailed analysis in various software packages.  Again producing results from these equivalent circuit models is time consuming.

Wiki article on Traditional MEMS Gyro modeling

Simplified lumped parameter model for MEMS Gyros

I found a journal article describing a lumped parameter model for MEMS gyroscope design suitable for running in Simulink.  The  benefit of the Simulink lumped parameter model technique allows for much faster MEMS gyro design results through simple gains and trnsfer function blocks.  The results present in the journal article looked encouraging.

Wiki article on Simplified lumped parameter model for MEMS Gyros

More articles coming…

Accurate sensor models are necessary for any good control loop design.  So I have a couple more sensor model/design articles coming.  After that I will start adding details of MEMS gyros as I find them on the web.

I’ve written an article on the wiki on what I call controller fusion.  I refer to it as controller fusion becuase, like Sensor Fusion, I use filters to blend non-ideal outputs from more than 1 transfer function into 1 output which is closer to the desired output.

For a work proposal on a reaction cancellation mechanism I used a proportional controller for fast response and a PI-Lead controller to drive the steady-state error to 0.  In simple sensor fusion the sensor outputs are filtered and then added together to form a better single output.  In this form of controller fusion I use filters on the error signal to adjust the gain of the controller in real-time.  As a result, PI-Lead output is almost turned off for a step command and the proportional controller output is almost turned off when the system is holding a steady-state value.

I have not had the time to bring this idea to full maturity but I thought it was an interesting enough idea to share.

Sensor Fusion

As discussed in the previous blog entry, sensor fusion is used to create one good sensor from at least 2 sensors that are not good enough to meet specifications.  This can be done simply but when real sensors are involved it can also become a bit of a black art requiring a lot of skill and experience.

Simple Sensor Fusion Example

The wiki has an example showing the details of simple sensor fusion.  The simple example has a low frequency sensor with a bandwidth of 20 Hz.  It also included a high frequency sensor with a lower bandwidth of 1 Hz and an upper of 1 kHz.  The sensors are blended using a second order low pass and high pass filter.  Both filters have a bandwidth of 15 Hz.

I hope to eventually create another example with better filters.  I also hope to create another sensor fusion example for sensors with non-ideal transfer functions.

Sensor Fusion or Sensor Blending

Sensors are what provides feedback to a closed loop system.  Sometime you can’t get the sensor characteristics you need.  This happens a lot in the aerospace industry.

When any one sensor cannot provide the necessary feedack then it is time for sensor fusion or sensor blending.  The simplest form of sensor fusion is a matter of two or more sensors which are filtered so that their strengths (good responsivity and low noise) are used while their weaknesses are filtered out.

Often times sensor fusion is nothing more than simple second order low pass or high pass filters with their outputs added together.  This simple fusion allows for two sensors to provide the desired output.

Simple Example of Sensor Fusion

The most simple sensor fusion that I’ve come across is the combination of two angular rate gyroscopes.  The low frequency gyro was good out to a frequency of approximately 20 Hz.  The high frequency gyro was good between 1 and 1000 Hz.  Unfortunately this system was sensitive to frequencies around 5 Hz.

Normally the blending frequency of the sensor fusion would have happened between 1 Hz and 20 Hz based on an analysis of each sensor’s noise and responsivity.  This example system was sensitive to frequencies around 5 Hz which meant that we needed to avoid frequencies between 0.5 Hz and 50 Hz.

The main weakness of the high frequency sensor was phase loss below 1 Hz.  So we designed a filter to extend the low end of the high frequency sensor down to 0.5 Hz.  More difficult to implement than to conceptualize but it takes some practice to do it correctly.

Ideal Sensor vs. Real Sensor

The ideal sensor is typically modeled with a second order system that has a natural frequency equal to the spec bandwidth and a damping of 0.707 or 1.  I default to 0.707.  This leads to a nice flat, unity response for the sensor below the bandwidth.  Real sensors are non-unity below the bandwidth - i.e. the magnitude has some ripple to it.  Sensor ripple around the blending frequency can be very problematic and must be assessed based on the system needs.

Introduction to Sensor Fusion on the Wiki

Here is an article on the wiki on Sensor Fusion.  It is currently a small, simple article that I hope to expand and encourage anyone interested in Sensor Fusion to help me expand.

Randomness and why the Banks are failing

This last New Years I was talking to a friend in the Banking industry - 2 am and drunk.  He was lamenting the fact that the financial institutes based all of their risk assessments of these fancy derivatives on models.  The models were traditional mathematics as well as neural network based artificial intelligence.  The point he kept coming back to was their reliance on these models and how the models didn’t make good predictions under certain circumstances.

My response was that models are as good as their inputs.  As I’ve stated in a previous post, models are designed, built, and validated to answer very specific questions under very specific circumstances.  When the question is outside the design parameters then the results are likely to be garbage and certainly untrustworthy.

An interesting article on the Edge…

On the Edge, Nassim Nicholas Taleb details the pitfalls of trusting models and an incomplete knowledge of statistics and randomness.  Taleb is the author of Black Swan and Fooled by Randomness.

The parts of the article I found most interesting were the ones about making decisions based on a rudimentary understanding of statistics.  His analysis is dead on.

On the International Space Station one of the Control Moment Gyroscopes (CMGs) failed.  After it failed NASA made the root cause analysis a high priority.  That said, engineers tried before me to explain why the CMG failed.  A bearing expert came in to tell us it could be this or it could be that or it could be something else…  The vendor responded similarly.

While I worked on figuring out the CMGs I was asked to determine what parameters in our telemetry stream could warn us of impending failure of another CMG.  Obviously we would prefer to shut it down before failure and bring it back to Earth for dissection and study.  I used every interpolation trick I knew, including Online Recursive Least Squares and Kalman filtering, to better predict what what was coming next.  No matter the technique or trick we applied to the data it didn’t work out.  “Good” techniques and models worked well on past days data but invariably they eventually fail to predict accurately some future event.

Randomness and Stochastic Control

Many real world systems are analyzed in stochastic manner.  In other words we assume that system noise and disturbances are random processes.  Frequently they are not random.  Frequently the processes are correlated.  Most of these systems can be approximated with these stochastic processes and analyses.

Systems engineering is often based on approximations of stats based models.  Obviously we have to be careful when we build models and especially careful letting Systems engineers (or ourselves) make decisions based on these models.

Source Links

Edge discussion on stats

Follow up discussion

MATLAB Pricing

MATLAB is a great tool.  I use it every day and have few complaints.  However, I’d like to use it for personal purposes.  The price of MATLAB makes its use for personal purposes cost prohibitive.  As of Sept. 14th, 2008 the prices are

• MATLAB: $1900
• Simulink: $3000
• Control System Toolbox: $1000
• Signal Processing Toolbox: $800

This is the basic MATLAB package I’ve always had as a professional.  Sometimes I have other toolboxes but I always have at least these.  Can most of us afford $6700 for personal use?

The MATLAB Monopoly

If MATLAB had any real competition, would the price still be $1900 for just MATLAB?  There are 2 competitors that I know of and neither is really a true competitor.  The first competitor is OCTAVE a free MATLAB like program.  In my brief examination of OCTAVE for use on my website I found it to be lacking most of the functionality of MATLAB.  The second competitor I come across is SimApp.  I’ve been in contact with a marketing person here in Colorado for SimApp and the price I was given was $500.  They have several licenses but I haven’t dug around the site to see what license you get for $500.  SimApp is a much smaller application with much less to it than MATLAB.

The purpose of SimApp is to offer only what we need most of the time and to do so at a reasonable price.  Mathworks offers items in toolboxes for the same purpose - at I assume that’s why.  However, their prices aren’t reasonable.

Is there justification for MATLAB’s price?

Like Microsoft, Mathworks is the only game in town and they set whatever price they want.  The price is high and I don’t like it but is it justified?

The Mathworks updates MATLAB about twice a year.  For the most part it is bug fixes and minor improvements.  Very rarely is there serious new functionality included in these updates.  For MATLAB 2008a the major upgrade is in Object Oriented programming.  The new interface is light years better than the old but the functionality isn’t new.

Most of the improvements I heard of over the last couple of years have involved improved plotting tools.  Some tools are new like a GUI interface to allow for interactive regression on the plot.  The other plotting improvements are bug fixes in my opinion (i.e. bugs like the aspect ratios not remaining fixed in certain uses of the saveas function).  After all these years, they still haven’t gotten the bode plot right in my opinion.

Conclusion

This latest round of installations for MATLAB 2008a really made me and a lot of my coworkers very angry.  There was a lot of extra work to get it installed.  And the only reason for our having the extra was that Mathworks didn’t do the work themselves.  In essence Mathworks let the users do beta testing of the MATLAB 2008a installation process on a full release version.  Kind of like every new Microsoft operating system, this program wasn’t ready for general release.

Since many of us who use and love MATLAB have long been cranky about the price for an individual license, there is some latent hostility and strong beliefs about knocking the chip off Mathworks’ shoulder.

MATLAB is a great program and every company has a right to set their own price to maximize profit.  That doesn’t mean users have to happy about it.  Companies with real competition worry more about irritating their customers.  That or they go out of business.

P.S.: 64 bit MATLAB

I have a 64 bit Quad core PC.  I installed 64 bit MATLAB on it.  However, anything in Simulink that requires a compiler doesn’t work.  Mathworks doesn’t ship a compatible compiler.  The only compiler compatible with Simulink on a 64 bit installation is a special installation of Microsoft’s Visual Studio 2005 Professional.  It seem kind of silly to install a $300 program just for the compiler.

Obviously, Mathworks should have included a compatible compiler.  The tech support was very helpful in this but only after I got nasty with them.  And the first level tech suggested more than one incorrect fix and this got to be time consuming.

Control System Modeling: Purpose

I’m going to use model and simulation as synonyms in this post.

The purpose of modeling in any discipline, including control systems, is to answer a question; often a very specific question is answered.  There are several reasons for why any given model only answers a small set of questions.  Budget and Schedule.

Modeling Complexity

Budget and schedule force engineers to model only those aspects deemed necessary to answer the question posed.

Modeling the universe in detail - even the very localized universe around a small object - takes a lot of work and time.  Budget and schedule concerns always force engineers to start with first principles and then model progressive deeper levels of details and fidelity.  The deeper layers are only modeled if the desired level of result accuracy requires this extra fidelity.

There are several reasons for keeping a model as simple as possible:

1. Initial time to development goes up with complexity
2. Time required for maintanence goes up with complexity
3. Odds of a mistake go up with complexity
4. Time between simulation start and delivery of results goes up with complexity

My observation is that items #1 through #3 increase roughly exponentially with complexity.  Turn around time (#4) increases but the amount of increase is highly dependent on the slowest part of the model as it exists prior to the increase in fidelity.

Control System Modeling: Pitfalls

Expanded Purpose

Engineers and other professionals who do not create or run simulations on a regular basis often forget about the narrow focus of a good model.  As a result these people often ask for results the model is not designed to produce.  Obviously the engineer being asked for the results needs to consider the request very carefully.  There may be an assumption built into the model which invalidates its use for this expanded purpose.

Juggling Programs

Each day that I work on a model I go through a process of “loading my RAM” or short term memory.  In order to work on the model and produce meaningful results a certain number of details and parameters must be loaded up into short term memory.  I find this process takes no more than 30 minutes and rarely takes more than 45 minutes.

The pitfall is in assuming you can juggle certain types of work.  Last summer I was asked to juggle modeling work and hardware maintanence work.  The hardware work needed me for 30 minutes at a time about 4 or 5 times a day.  As a result the hardware work repeatedly interrupted my efforts on the modeling work.  The interruptions came about every hour and a half.  So I used half of my time in between “loading my RAM”.

After about 2 or 3 weeks of trying to juggle the hardware and the modeling work I realized I was never gonig to get anything done on the model if I didn’t set some limits.  I asked the two programs how they wanted me to handle the problem.  The basic response was just deal with it.  So I decided to tell the hardware guys that 2 days a week they couldn’t bother me, except for emergencies.  No one was happy but it was the best I could do.