Electro-Optical Sensors

Electro-Optical (EO) sensors are used in a wide variety of satellite applications.  EO sensors take light energy and turn it into electrical energy.  There are a variety of sensors that do this.  Some image while other provide the centroid of a spot of light.

Scientific imaging is largely done with CCDs.  FPAs can fill the same role as CCDs with many advantages (such as less noise and therefore sensitivity to lower signal levels).  However, fewer people have experience with FPAs the engineering community than CCDs.  Also (I believe) FPAs are more expensive.

LECs and Quad Cells are typically used as position sensors.  LECs use a single photodiode with 4 electrical pickoffs to return the centroid of a spot.  Quad cells use 4 photodiodes each with 1 electical pickoff for centering applications and centroiding applications.  Each sensor returns 4 voltages/currents which are used to calculate the centroid.

Note that for a Quad cell to provide fine resolution centroid information the light spot must be “large” compared to the sensor itself.  A tight light beam (like a laser) creates a small spot and the only information returned is the quadrant where the light is.  A broad light beam where the spot occupies 50% of the sensor face, for example, will create signals from all 4 quadrants for a centroid calculation.

For more information see the Electro-Optical Sensors article on the wiki.

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.

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.