When modeling real-world systems for control it is often necessary to deal with a realistic approximation of the noise and disturbances the system is likely to experience.  For satellites with pointing systems this often means that a disturbance PSD is created or measured.  This disturbance is modeled as a random process whose energy is described by the PSD.  The PSD is applied to a State-Space model which represents the structural characteristics of the system – specifcally the characteristics of the transmission this disturbance energy to various portions of your system.

All of this starts with a PSD so we define a PSD class

classdef psdData

....

end

From here we define our properties, methods and events.  Since this will be a stand-alone class for holding and manipulating data, there are no events.  So what properties do we need?

• Bare Essentials
  • Name: Name the PSD data
  • Freq: Vector of Frequencies at which Magnitude data is captured
  • Mag: Vector of Magnitudes measured
  • RootPSD: Is this a a root PSD – in other words the units are something like rad/rt(Hz) instead of rad^2/Hz?
• Plotting Essentials
  • UnitBaseMag: Base unit for magnitude measurements
  • UnitBaseFreq: Base unit for frequencies at which magnitude measurements are captured
  • PlotFreqUnit: Frequency Units desired on PSD Plot
  • TimeUnit: The UnitBaseMag just holds a value like radians or degrees or m or ft.  If the measured magnitude is a rate – rad/sec or m/sec then this holds that the TimeUnit is 1/sec

The reason the units are broken up into base and time portion is because we will be including methods to integrate and differentiate the PSD.  In my industry rate PSDs are often the easiest to measure.  As a result we often get rate PSDs (in rad/sec) but need an angular (position) disturbance PSD so we end up integrating the measured rate PSD.  So it only makes sense to incorporate integration and differentiation into our class.  I’ll deal with the methods in a later posting

Now that we have a list of properties we need to decide access priviledges.  See a full list of Class Property Attributes here.

I hardly used MATLAB 2008a and never installed 2008b because of the shear amount of time it required to solve all of the stupid little issues with Mathworks new installation procedure.  I hate it and they should get rid of it.  However, in MATLAB 2008a Mathworks introduced a huge change to their classes.

In some of my work creating classes makes a lot of sense.  However, in previous versions building a class was an excrutiatingly slow and painful process requiring the developer to create a multitude of m-files for setting and getting properties, for displaying the data, and other basic infrastructure.  In 2008a MATLAB came out with a new way of programming classes which – at least for small, simple classes – greatly reduces development time.

In MATLAB 2008a, many of the infrastructure m-files you used to have to build for classes disappeared.  The entire class can be held in a single file if desired.  This one file can contain properties, events and methods.  For my purposes I usually end up with a few m-files containing helper functions for certain pieces of codes that are required in several places.

Over the course of the next several blog posts I’ll be going through an example of a class I built in about a day.  I’ve also found that making tweaks is very easy since there are far fewer files to deal with and many changes made to methods take effect immediate without the need to destroy and recreate the instance of class you are testing.

The example class will be a class for holding and plotting PSD Data.  Something very useful for Stochastic controls.

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