f ta - atst.nso.edu

D R A F T

Project Documentation Document SPEC-0176

Draft A

Wavefront Correction

Active Optics Engine Critical Design Definition

Luke Johnson, Keith Cummings, Mark Drobilek,

Erik Johansson, Kit Richards, Friedrich Wöger

WFC Group

June 2016

D R A F T

aO Engine CDD

SPEC-0176, Draft A Page i

REVISION SUMMARY:

Date: June 2016 Revision: Draft A Changes: Initial document

D R A F T

aO Engine CDD

SPEC-0176, Draft A Page ii

Table of Contents

1 OVERVIEW ........................................................................................................... 1

1.1 SCOPE OF THE DOCUMENT ...................................................................................... 1

1.2 RELATED DOCUMENTS ............................................................................................ 1

1.2.1 Related DKIST Project Documents.............................................................................. 1

1.2.2 Interface Control Documents and Drawings .............................................................. 2

1.2.3 Other Documents ......................................................................................................... 2

1.3 DEFINITIONS AND TERMINOLOGY ............................................................................. 2

1.4 COMMON SERVICES FRAMEWORK GLOSSARY ........................................................... 3

2 ACTIVE OPTICS OVERVIEW ............................................................................... 5

2.1 QUASI-STATIC WAVEFRONT CORRECTION FOR DKIST ............................................... 6

2.1.1 TCS ................................................................................................................................ 7

As mentioned above, the aO Engine is a subsystem of the WFC. The top-level controller of the WFC is the Wavefront Correction Control System controller, the WCCS 7

2.1.2 TEOA ............................................................................................................................. 7

2.1.3 M1 Assembly ................................................................................................................ 7

2.1.4 Feed Optics ................................................................................................................... 8

2.1.5 High-Order Adaptive Optics ........................................................................................ 8

2.1.6 Low-Order Wavefront Sensor ...................................................................................... 8

2.1.7 Context Viewer ............................................................................................................. 8

3 QUASI-STATIC WAVEFRONT AND ALIGNMENT CONTROL ........................... 9

3.1 JUSTIFICATION OF ACTIVE CONTROL STRATEGY ....................................................... 10

3.2 DEMONSTRATION OF AO ENGINE ALGORITHMS ....................................................... 12

3.3 ACTIVE OPTICS PERFORMANCE ESTIMATION AND ERROR BUDGET ............................. 12

3.3.1 Quasi-static wavefront error performance.................................................................13

3.3.2 Pupil alignment performance .....................................................................................14

3.4 MODAL BASES USED IN ACTIVE OPTICS .................................................................. 20

3.4.1 Zernike Basis ...............................................................................................................20

3.4.2 M1 natural modes ........................................................................................................20

3.5 INPUTS ................................................................................................................. 20

3.5.1 Wavefront error input ..................................................................................................21

3.5.2 Boresight error input ...................................................................................................22

3.6 WAVEFRONT CORRECTION OUTPUTS ..................................................................... 22

D R A F T

aO Engine CDD

SPEC-0176, Draft A Page iii

3.6.1 M1 axial actuator error ................................................................................................22

3.6.2 M2 hexapod position error ..........................................................................................23

3.6.3 M3 tilt error...................................................................................................................23

3.6.4 M6 tilt error...................................................................................................................23

3.6.5 Clear Active Optics offsets: aoZero ...........................................................................23

3.7 CORRECTION MONITORING ..................................................................................... 23

3.8 LOGGING .............................................................................................................. 23

3.9 DATA TRENDING ................................................................................................... 24

3.10 SET POINT ALGORITHMS ........................................................................................ 24

3.10.1 Notation ........................................................................................................................24

3.10.2 Generalized algorithm .................................................................................................26

3.10.3 Passive Correction ......................................................................................................26

3.10.4 Active Correction.........................................................................................................27

4 IMPLEMENTATION ............................................................................................ 29

4.1 PASSIVE CORRECTION .......................................................................................... 29

4.2 ACTIVE CORRECTION ............................................................................................ 29

4.2.1 M1 active correction ....................................................................................................30

4.2.2 M2 active correction ....................................................................................................31

4.2.3 M3 and M6 active correction .......................................................................................31

5 AO ENGINE ALGORITHMS ............................................................................... 33

5.1 ACTIVE OPTICS COORDINATE TRANSFORMATIONS ................................................... 33

5.2 WAVEFRONT CORRECTION .................................................................................... 34

5.2.1 Input Derotation ...........................................................................................................34

5.2.2 Wavefront Error Processing .......................................................................................35

5.2.3 Wavefront Reconstruction ..........................................................................................36

5.2.4 Output Gain Control ....................................................................................................37

5.2.5 Correction monitoring .................................................................................................37

5.3 BORESIGHT CORRECTION ...................................................................................... 37

5.3.1 Pupil error calculation and derotation .......................................................................37

5.3.2 Boresight reconstruction ............................................................................................38

5.3.3 M3 coordinate rotation ................................................................................................39

5.4 CALIBRATION ....................................................................................................... 39

5.4.1 Boresight reconstruction matrix ................................................................................40

5.4.2 Wavefront sensitivity matrix .......................................................................................41

D R A F T

aO Engine CDD

SPEC-0176, Draft A Page iv

5.4.3 Wavefront reconstruction matrices............................................................................43

5.4.4 Pupil position ...............................................................................................................44

6 SOFTWARE DESIGN ......................................................................................... 46

6.1 OVERVIEW ............................................................................................................ 46

6.2 USE CASES .......................................................................................................... 47

6.2.1 Startup ..........................................................................................................................49

6.2.2 Diffraction Limited Observations ...............................................................................50

6.2.3 Seeing Limited On-Disk Observations .......................................................................50

6.2.4 Calibrations..................................................................................................................50

6.2.5 Shutdown .....................................................................................................................52

6.2.6 Change in Modal Basis ...............................................................................................52

6.3 DETAILED DESIGN................................................................................................. 53

6.3.1 aO Engine Controller ...................................................................................................53

6.3.2 Events Published by the aO Engine ...........................................................................66

6.3.3 Events Subscribed to by the aO Engine ....................................................................67

6.3.4 Headers ........................................................................................................................68

6.3.5 Interlocks .....................................................................................................................68

6.3.6 Logging ........................................................................................................................68

6.3.7 Health and Alarms .......................................................................................................69

6.3.8 GUI Screens .................................................................................................................70

6.4 USE CASE DETAILS .............................................................................................. 70

6.4.1 Diffraction limited and seeing limited observing ......................................................70

6.4.2 Boresight Alignment Calibration ................................................................................74

6.5 HARDWARE REQUIREMENTS .................................................................................. 76

D R A F T

aO Engine CDD

SPEC-0176, Draft A Page 1 of 76

1 OVERVIEW

1.1 SCOPE OF THE DOCUMENT

This document describes the design of the Active Optics (aO) Engine, a subsystem of the Wavefront

Correction System (WFC). The aO Engine is the component of DKIST’s Active Optics system

responsible for computing position errors of the active mirrors resulting from constant or slowly-varying

sources of wavefront error.

This document also contains a description of the overall Active Optics system. The Active Optics system

is responsible for correcting wavefront aberrations caused by optical misalignments, optical surface

defects, and other constant or slowly-varying sources of wavefront error so that, upon exiting WFC-BS1,

quasi-static wavefront quality meets requirements laid out in SPEC-0001, SPEC-0009, and SPEC-0058.

The design presented in this document provides a comprehensive definition of the quasi-static wavefront

control strategy for DKIST and its implementation in all related DKIST subsystems. Requirements for

this operation, contained in (SPEC-0175, the aO Engine DRD), flow from SPEC-0058 and SPEC-0129.

1.2 RELATED DOCUMENTS

1.2.1 Related DKIST Project Documents

SPEC-0001 DKIST Science Requirements Document

SPEC-0005 Software and Controls Requirements

SPEC-0008 Top End Optical Assembly Specification

SPEC-0009 DKIST System Error Budgets

SPEC-0012 Glossary and Acronym List

SPEC-0013 Software Operation Concepts Definitions

SPEC-0014 Software Design Description

SPEC-0021 TCS Software Design Description

SPEC-0022 Common Services Framework: Users’ Manual

SPEC-0058 Wavefront Correction System Specifications Document

SPEC-0063 DKIST Interconnects & Services Specification

SPEC-0092 M1 Cell Assembly Specification

SPEC-0129 Wavefront Correction Operational Concepts Document

SPEC-0131 Transfer Optics Assembly Specification

SPEC-0132 Feed Optics Control System Design Requirements

SPEC-0142 LOWFS Critical Design Document

SPEC-0175 Wavefront Correction aO Engine Design Requirements Document

TN-0058 Reference Design Studies and Analyses for the Wavefront Correction – coudé

TN-0088 CSF Base Software

TN-0241 Wavefront Correction System Implementation of DKIST Optical System

Lookup Tables

TD-0017 M1CA Zernike and Document Update

AMOS document 2106/01/28, AO Sensitivity Matrices

ATST-ANA-22100-01-05, Telescope Mount Assembly – Performance Analysis Mount, Feb

2013

D R A F T

aO Engine CDD


ATST – M1 Mirror Cell Assembly Software Design Document, Doc #OSL/2106/30/27, June

2014

Software Design Document for the ATST Top End Optical Assembly, Doc #SDD-32506, Oct

2012

1.2.2 Interface Control Documents and Drawings

ICD 1.2-2.3 M1 Assembly to WCCS

ICD 1.3-2.3 TEOA to WCCS

ICD 1.5-2.3 Feed Optics to WCCS

ICD 2.3-4.4 WCCS to TCS

1.2.3 Other Documents

[1] Johnson, L. C., Upton, R., Rimmele, T., Barden, S. "Quasi-static wavefront control for the

Advanced Technology Solar Telescope." Proc SPIE 8444, 84443O-8 (2012).

[2] CODE V® Version 10.4 Reference Manual, Synopsys, Inc. (2012)

[3] Pierard, M. and Gabriel, E., “M1 Mirror Cell Assembly Control System Design Description”,

AMOS doc #2106/30/13 issue 3 (2013)

[4] L3 Brashear, “Software Design Document for the ATST Top End Optical Assembly”, L3

doc# SDD-32506 (2012)

[5] Wararit Panichkitkosolkul, “Confidence Intervals for the Coefficient of Variation in a Normal

Distribution with a Known Population Mean,” Journal of Probability and Statistics, vol. 2013,

Article ID 324940, 11 pages, 2013. doi:10.1155/2013/324940

1.3 DEFINITIONS AND TERMINOLOGY

Acronym or

Abbreviation Meaning

aO CDD CSF CV DKIST

Active Optics Critical Design Document Common Services Framework Context Viewer Daniel K. Inouye Solar Telescope

DM DRD

FCLS

FOCS

Deformable Mirror Design Requirements Document

Force Constrained Least-Square (aO algorithm)

Feed Optics Control System FOV FWHM

HOAO HOWFS LOWFS LT LUT M1CS

Field-of-view Full Width Half Maximum

High-Order Adaptive Optics High-Order Wavefront Sensor Low Order Wavefront Sensor Limb Tracker Lookup Table M1 Control System

http://atst.nso.edu/library/icds/ICD%201.2-2.3%20M1%20Assy%20to%20WCCS.pdf

http://atst.nso.edu/library/icds/ICD%201.5-2.3%20Feed%20Optics%20Assy%20to%20WCCS.pdf

D R A F T

aO Engine CDD


NCP

NPF

Non-Common Path

Neutral Pointing with Focus (aO algorithm) OCD Operational Concepts Definition OCS QSA RTC SRD TCS TEOACS TMA WBS

WCCS WFC

Observatory Control System Quasi-Static Alignment Real-Time Controller Science Requirements Document Telescope Control System Top End Optical Assembly Control System Telescope Mount Assembly Work Breakdown Structure

Wavefront Correction Control System Wavefront Correction System

1.4 COMMON SERVICES FRAMEWORK GLOSSARY

This section provides brief definitions for various DKIST Common Services Framework (CSF) concepts,

structures and patterns. While these definitions give additional context to the discussions in this

document, the reader should refer to the CSF reference documents for more detailed information,

particularly SPEC-0022, CSF User Manual and TN-0088, Base Software for Control Systems.

Attribute: An Attribute is the fundamental data structure used by CSF for the storage of

parameter data. Attributes store data in string form.

Attribute Table: An Attribute Table is a data structure containing multiple attributes. It is the

fundamental data type used to send information between CSF components.

Configuration: A Configuration is an Attribute Table along with a unique ID that can be used to

trace data flow throughout a CSF control system. Configurations are used to send commands and

parameters to objects in a CSF control system.

Controller: A Controller is the fundamental object used to implement control structures in CSF.

Service: A feature of CSF used to implement various kinds of support facilities. For example, the

Connection Service, Event Service, Property Service, Health Service, etc.

Connection Service: The CSF Connection Service connects various CSF component objects

together, regardless of location, so they can communicate with each other using the CSF control

system paradigms. Connections use a peer-to-peer messaging pattern.

Event: An Event is a data structure used to publish data over the CSF control network. Any

number of CSF components may subscribe to an event (including zero). Publishing and

subscribing of/to events is accomplished using the CSF Event Service.

Event Service: The CSF Event Service provides the communications infrastructure to transmit

and receive Events on the CSF control network. Events use a publish-subscribe messaging

pattern.

Data Handling System: The DHS is the on-site storage facility at the DKIST summit where

science data is stored. The DHS receives data through the BDT.

Bulk Data Service: A CSF Service used to store and retrieve binary data in a database called the

Bulk Data Store. The WFC system uses the Bulk Data Store to store and retrieve various

parameter arrays and matrices as well as dark and flat field images.

D R A F T

aO Engine CDD


Bulk Data Store: The Bulk Data Store is the database used by the Bulk Data Store to store data.

The database may be used for exclusive local access by the WFC or may be used throughout the

observatory control systems.

Property Service: A CSF service used to store/recall constants and parameters used to configure

a control system.

Archive Service: A CSF service used to store data for engineering purposes. Data is stored using

CSF Attributes along with component and timestamp meta-data. Archive Service data is stored in

a database that can be queried and recalled for later analysis.

Logging Service: A CSF service used to log textual messages such as details about errors or

warnings or debug information. The data stored in the log database may be recalled for later use,

but it is not easily searchable and not suitable for storage of engineering data.

Health Service: The CSF Health Service is used to monitor the health of a control system and

easily trace problems using a tree-like display at the operator’s console.

D R A F T

aO Engine CDD


2 ACTIVE OPTICS OVERVIEW

The DKIST Active Optics system is responsible for control of quasi-static wavefront and alignment errors

throughout the telescope. The Active Optics system is not a discrete subsystem of DKIST, rather it is a

collection of telescope subsystems that work together to either passively or actively control these quasi-

static optical errors.

The Active Optics system is comprised of active mirrors: M1, M2, M3, and M6, their control systems:

M1 Control System (M1CS), Top-End Optical Assembly Control System (TEOACS), and Feed Optics

Control System (FOCS), and Wavefront Correction (WFC) subsystems: Active Optics Engine (aO

Engine), Wavefront Correction Control System (WCCS), High-Order Adaptive Optics (HOAO), and Low

Order Wavefront Sensor (LOWFS). All telescope subsystems involved in the Active Optics system are

managed by the Telescope Control System (TCS).

Operation of the Active Optics subsystems is governed by setting the modes of the active mirror

controllers and the WFC system:

The WFC system operates in seven different modes, off, idle, calibrate, diffraction limited on-disk, seeing

limited on-disk, seeing limited coronal, and limb tracking with image stabilization. More detail on the

WFC operational modes can be found in SPEC-0129.

Active mirror controllers operate in three modes: off, passive, and active. When the active mirror

controllers are operating in passive mode, quasi-static wavefront and alignment are controlled by lookup

tables (LUTs) within each active mirror controller. This distributed control method places requirements

on the four active mirrors, M1, M2, M3, and M6, and their controllers, M1CS, TEOACS, and FOCS,

such that they are able to adjust the positions of the mirrors to counteract repeatable gravitational and

thermal flexure within the telescope structure as external temperatures fluctuate and the TMA articulates

through its full range of motion. The aO Engine is not responsible for direct LUT control of the four

active mirrors. However, data logged by the aO Engine will be used to evaluate LUT performance and

calculate updates to the active mirror LUTs. The design of the aO Engine will also permit the replication

of the LUT control functionality of these mirror control systems, which can be used in the event of a

malfunction within one or more of the active mirror controllers.

When the active mirror controllers are in active mode, and the WFC system is in either diffraction limited

on-disk or seeing limited on-disk mode, the aO Engine is responsible for processing wavefront

measurements from the WFC wavefront sensors to estimate the current residual quasi-static wavefront

and alignment errors after LUT correction. Whenever the aO Engine detects a significant optical error, it

will compute position offsets for the four active mirrors and send commands to their control systems to

remove the measured wavefront and alignment error.

The aO Engine relies on the DKIST active mirror systems to correct the measured quasi-static wavefront

and alignment errors, so in order to meet its requirements, the aO Engine also sets positioning

requirements on all DKIST active mirror systems that flow down from top-level requirements in SPEC-

0058. Positioning requirements set on the four active telescope mirrors appear in their respective DRDs.

Additionally, successful passive control of Active Optics requires maintenance of the distributed LUTs

within each active mirror control system. To this end, the aO Engine will include software that logs all

relevant data for LUT refinement such as wavefront measurements, active mirror positions, telescope

positions, temperatures, and system configurations. Moreover, the WFC group will deliver software and a

user interface that allows the WFC specialist to mine the logged data, analyze trends, and update the

active mirror LUTs (this software is not part of the aO Engine or its control system).

D R A F T

aO Engine CDD


2.1 QUASI-STATIC WAVEFRONT CORRECTION FOR DKIST

Figure 1: Active Optics signal flow diagram

Quasi-static wavefront control of the entire DKIST optical system requires multiple telescope systems

working together, many of which fall outside the direct control of WFC. These external systems include

the Telescope Control System (TCS), the Top End Optical Assembly (TEOA), the M1 Assembly, and the

Feed Optics Control System (FOCS). The aO Engine, which is a WFC sub-system, works together with

these systems to implement the quasi-static wavefront control; of the Active Optics.

Each of these systems supports Active Optics operation in some capacity. The following subsections

contain brief descriptions of their roles with regard to Active Optics.

D R A F T

aO Engine CDD


2.1.1 TCS

The TCS serves as the parent controller for WFC and the other telescope sub-systems. With regards to

WFC activities, it primarily functions as a management controller, passing configurations from the OCS

through to the WCCS. For Active Optics operation, the M1CS, TEOACS, and FOCS must be set to active

mode when the WFC system is in a configuration that requires the aO Engine to send position updates to

the active mirrors. The WFC is not able to directly configure the active mirror subsystems and relies on

the TCS to sense the WFC operating mode and automatically configure the active mirror controllers

according to the WFC mode. A table showing the mapping between WFC modes and active mirror

controller configurations appears in ICD 2.3-4.4 WCCS to TCS.

2.1.2 WCCS

As mentioned above, the aO Engine is a subsystem of the WFC. The top-level controller of the WFC is

the Wavefront Correction Control System controller, the WCCS. The WCCS is responsible for

configuring the aO Engine, which it does using Common Services Framework (CSF) configurations. The

WCCS generates configurations for the aO Engine based on configurations it receives through the WCCS

engineering GUI and the TCS/WCCS interface. All functionality of the aO Engine is available through

the WCCS engineering GUI and a subset of that functionality is available through the TCS/WCCS

interface. The functionality available through the TCS/WCCS interface addresses the requirements in the

aO Engine Design Requirements Document (DRD).

2.1.3 TEOA

The TEOA houses M2 and the M2 control system. For Active Optics control, the TEOACS is able to

control the M2 hexapod to move M2 in six degrees of freedom: translation along the x, y, and z axes and

rotation about the x, y, and z axes. Using its own internal control scheme, the TEOACS is able to hold

M2, to within positioning requirements, at any specified set point within its actuation range.

During normal telescope operation, the TEOACS will adjust the M2 set point to correct slowly-varying

telescope aberrations. When the TEOACS is in passive correction mode, the M2 set point is controlled by

predetermined internal lookup tables. These lookup tables determine the absolute M2 set point as a

function of telescope altitude, azimuth, and temperature.

When the TEOACS is in active correction mode, it also adjusts M2 position set points using internal

LUTs. Additionally, the TEOACS will accept position error signals generated by the aO Engine, which

are calculated from measured quasi-static wavefront error. The TEOACS will treat the position errors

from the aO Engine as offsets to its internal lookup tables and adjust the M2 set points accordingly.

Internal LUTs for the TEOACS can be updated manually as needed, using correction offsets generated

through offline analysis of recorded aO Engine data.

2.1.4 M1 Assembly

The M1 Assembly contains M1 and the M1 control system (M1CS). The M1 Assembly works with the

Active Optics system in a similar way to the TEOA. The M1 Assembly also corrects for slowly-varying

telescope aberrations except it contains more degrees of freedom than the 6 M2 rigid-body modes. Using

its own internal control scheme, the M1CS is able to hold the 118 M1 axial actuators, within positioning

requirements, at any specified set point within their actuation range, allowing it to accurately control the

bending modes of the mirror.

Similar to M2, M1 will be driven by an internal lookup table containing predetermined actuator set points

that compensate for flexure due to changing gravitational forces and thermal gradients. These LUTs can

be updated manually when needed, using correction offsets generated through offline analysis of recorded

aO Engine data. When M1CS is in passive correction mode, M1 actuator set points will be determined by

D R A F T

aO Engine CDD


these lookup tables. When M1CS is in active correction mode, it accepts actuator set point offsets to the

M1 LUT, generated by the aO Engine. These offsets are expressed in either the Zernike basis or the basis

of natural M1 mirror modes. The M1CS converts these figure errors to forces to be applied to the axial

actuators. Although modal bases are the primary format in which correction offsets are communicated

from the aO Engine to the M1CS, the M1CS also allows the aO Engine to send a full force vector of 118

elements representing the force to be applied to each actuator in Newtons. Finally, the M1CS also

maintains LUTs for inoperable actuators.

2.1.5 Feed Optics

The Feed Optics Control System consists of M3, M4, M6 and their associated controllers. M3 and M6,

which are part of the Active Optics system, are flat mirrors mounted on stages that rotate about their x and

y axes and are used to steer the optical beam of the telescope. The FOCS is able to hold M3 and M6 to

within requirements at any specified set point within their actuation range. The FOCS also operates in

both active and passive mode. When the FOCS is in passive mode, both M3 and M6 set points are

determined by lookup tables and in active mode the FOCS will accept position offsets to M3 and M6

from the aO Engine. Internal LUTs for the FOCS can be updated manually as needed, using correction

offsets generated through offline analysis of recorded aO Engine data.

2.1.6 High-Order Adaptive Optics

HOAO is a subsystem of WFC. It is one of the sources of wavefront error measurements used as inputs to

the aO Engine. HOAO is able to measure slowly-varying wavefront error modal coefficients and pupil

position errors and send them to the aO Engine for offloading to the Active Optics mirror controllers.

2.1.7 Low-Order Wavefront Sensor

The LOWFS is also a WFC subsystem. As with the HOWFS, the LOWFS is able to send slowly-varying

wavefront modal coefficients to the aO Engine for offloading to the Active Optics mirror controllers (note

that pupil position measurements are only provided by the HOWFS).

2.1.8 Context Viewer

The CV is only used by the aO Engine during boresight calibration. Boresight calibration is a special

procedure that uses the CV to measure image position error while aligning the boresight. When

performing a boresight calibration, the aO Engine will receive pupil position errors from the HOAO and

image position errors from the CV. It will then calculate position offsets for M3 and M6, which will be

sent to the FOCS. This process is described in more detail in the calibration section.

D R A F T

aO Engine CDD


3 QUASI-STATIC WAVEFRONT AND ALIGNMENT CONTROL

Control of quasi-static errors within DKIST is divided into two sub-categories, quasi-static wavefront

control and boresight stabilization. Quasi-static wavefront control refers to control of slowly-varying

wavefront errors excluding piston, tip, and tilt. Boresight stabilization refers to steering the light beam

such that the pupil at the HOWFS and the image position at the CV are kept in stable positions as the

coudé room rotates.

The telescope systems used to control quasi-static wavefront errors are the M1 actuators and M2 hexapod.

There are 118 M1 axial actuators which can be used to control the bending modes of the primary mirror.

The M2 hexapod is able to move the secondary mirror in six rigid-body degrees of freedom (x, y, and z

translation plus tilt about x, y, and z axes).

M3 and M6, part of the Feed Optics, control the boresight alignment. They are flat mirrors that can tilt

about their x and y axes. M3 is placed near a focal plane and M6 is placed near a pupil plane. During

Integration, Test and Commissioning (IT&C), the telescope boresight will be aligned and the relationship

between maintaining boresight alignment and controlling the HOWFS pupil and CV image positions will

be determined. The telescope boresight refers to the beam of light between M6 and M7 that sends light

down to the coudé room. When properly aligned, this light beam will run along the coudé rotational axis

so that it remains stable while the coudé room rotates. It is intended that active beam control with M3 and

M6 during telescope operation will maintain the boresight alignment.

The Active Optics system uses two methods for correcting quasi-static errors, active correction and

passive correction. In passive correction, no wavefront sensing is done and positioning of the corrective

elements is driven by LUTs internally kept within each mirror’s control systems. In active correction, the

corrective elements are driven by both internal lookup tables and offsets to these lookup tables sent from

the aO Engine.

The offsets sent from the aO Engine are position errors relative to the mirror’s current position. The aO

Engine calculates these offsets based on wavefront measurements sent from either the HOAO or LOWFS.

Which wavefront measurements the aO Engine uses to calculate offsets is generally automatically

determined by the WCCS, based on the WFC operating mode, but can also be manually set from the

WCCS engineering screen.

Whether the Active Optics system is operating using active or passive correction is determined by the

WFC mode. When the WFC mode is set to either diffraction-limited mode or seeing-limited on-disk

mode then the Active Optics system will operate using active correction. In all other WFC modes, the

Active Optics system will operate using passive correction. The TCS is responsible for coordinating all

subsystems involved in the DKIST Active Optics and will configure the active mirror controllers based

on the WFC mode.

Quasi-static wavefront errors are actively sensed by averaging exit-pupil wavefront measurements over a

period of time so that mean wavefront variance due to high temporal frequency atmospheric turbulence is

reduced below the value for Active Optics system error apportioned in the SPEC-0009 case 2 error budget

for seeing-limited delivered image quality. This averaging time will change based on seeing conditions

and is expected to vary between one and three-hundred seconds. Wavefront information is sent to the aO

Engine as modal coefficients using either the Zernike basis or natural M1 mirror basis. Boresight

alignment errors are sensed by the HOWFS, which measures pupil motion and sends pupil position errors

to the aO Engine. Image motion is not actively sensed by the aO Engine during observations. Instead,

image motion is estimated and corrected for by the HOAO using an active fast tip-tilt loop controlling

M5.

The aO Engine uses the input modal wavefront coefficients to calculate position errors of M1 and M2 and

sends the position errors to the M1CS and M2CS using the CSF event network. The aO Engine is capable

D R A F T

aO Engine CDD


of using multiple control algorithms for M1 and M2 correction that allow for different tradeoffs between

minimizing M1 actuator forces and limiting pointing error induced by moving M2. In a separate

calculation, the aO Engine uses pupil position errors from the HOWFS to calculate position errors of the

active Feed Optics mirrors, M3 and M6. Position errors of M3 and M6 are sent to the Feed Optics Control

System (FOCS) using the CSF event network.

This section defines the inputs to the aO Engine, the outputs it sends to its associated systems, and the

algorithms it uses to compute the outputs from the inputs.

3.1 JUSTIFICATION OF ACTIVE CONTROL STRATEGY

The Active Optics wavefront control strategy uses a priori information about telescope flexure and

temperature to control the motions of motorized mirrors within DKIST such that the deterministic aspects

of the telescope’s quasi-static wavefront error are corrected. A priori knowledge of flexure and

temperature effects on telescope performance is incorporated through lookup tables that establish set

points for each motorized mirror based on measured telescope position and temperatures. FEA modeling

done as part of the TMA contract has identified gravitational flexure and thermal effects as the primary

drivers of quasi-static wavefront error. Lookup tables are stored locally within the control systems of the

mirrors that they affect.

During passive wavefront correction, the motorized mirrors are positioned according to their internal

lookup tables. The mirror controllers are designed such that their positioning accuracy and repeatability

meets or exceeds the wavefront error allocated in the Case 3 error budget for seeing-limited coronal

observations. During active wavefront correction, lookup tables are also used in the same way as in

passive wavefront correction but WFC actively measures the residual quasi-static wavefront error and

sends offsets to mirror positions that reduce wavefront errors not corrected by lookup tables.

The update rates of the lookup table set point corrections and the active updates from WFC are not

synchronized and it is likely that the lookup table update rate may be much higher than the WFC update

rate. As a result, the position of an active mirror may change significantly between the time when WFC

begins measuring quasi-static wavefront error, and the time when the active mirror receives a set point

update from WFC. WFC wavefront measurement does not reset when a LUT update is performed so there

was some concern that this could result in a scenario where the lookup table updates cause degradation in

the wavefront performance of DKIST and that lookup tables should be disabled during active wavefront

control, or their influence should be subtracted from the WFC set point updates.

A study was undertaken to determine the best wavefront control strategy, resulting in a determination that

it is best to leave the lookup tables in operation during active wavefront correction. This study showed

that, regardless of the difference in update rate between the lookup table and WFC offsets, the

LUT+WFC method performed better than the LUT only or WFC only methods. The only scenario in

which the LUT+WFC method did not perform better than the other two methods is when the LUT

trajectory was anti-correlated to the desired mirror trajectory. While the possibility of the LUT being anti-

correlated to the desired trajectory exists, it is unlikely and, therefore, we decided to use the LUT+WFC

method. Additionally, when performing active wavefront correction, the aO Engine will monitor the

telescope performance and attempt to detect if the LUT becomes anti-correlated to the optimal trajectory.

If the aO Engine does detect this scenario, it will raise an alarm so that the offending LUT can be

manually disabled.

Figure 2 shows characteristic results from this study using a single-actuator aO model with the LUT

updating every second and the WFC offset updating every 15 seconds. In this example, time is

compressed so that the telescope goes from horizon pointing through zenith and back to horizon in 12

minutes. This time compression is done to emphasize the effect of lag time in the Active Optics

correction. As can be seen from this simulation, if the LUT is even weakly correlated to the desired

actuator trajectory, it will partially compensate for the lag in the Active Optics loop and lead to better

D R A F T

aO Engine CDD


overall correction. Of course the opposite is true if the LUT is anti-correlated to the desired trajectory,

which is why the aO Engine will attempt to detect if this situation is occurring and send a notification that

performance can be improved by switching off the LUTs.

Figure 2: Results of aO active method study using a single-actuator system. White line = optimal trajectory, red line =

LUT trajectory, green line = aO only trajectory, blue line = aO + LUT trajectory. Top: LUT is strongly correlated to

D R A F T

aO Engine CDD


optimal trajectory. Mid: LUT is weakly correlated to optimal trajectory. Bottom: LUT is anti-correlated to optimal

trajectory.

Another concern with our active optics implementation was that degeneracy between M1 and M2 could

cause them to “fight” with each other. For example, if M1 and M2 apply equal and opposite wavefront

corrections the net effect on the wavefront is zero but the system is clearly in an undesirable

configuration.

The two methods we use to correct quasi-static wavefront aberrations deal with this problem in slightly

different ways. The Force-Constrained Least Squares (FCLS) method minimizes the total force applied to

the M1 actuators so it will preferentially apply any wavefront errors in the shared M1-M2 subspace to

M2. This will prevent mode buildup on M1 as the only correction terms applied to M1 will be those that

cannot be corrected by M2. The Neutral Pointing plus Focus (NPF) method eliminates the degeneracy

between M1 and M2 by correcting focus and astigmatism only with M2 and all other wavefront error

modes only with M1, forcing M1 and M2 into orthogonal subspaces.

A significant mismatch between the modeled sensitivity matrices and actual sensitivity matrices still has

the possibility to subvert our attempts at breaking degeneracy, which is why we have developed methods

for measuring the telescope sensitivity matrices in situ. Careful calibration of the active optics sensitivity

matrices will be necessary for successful quasi-static alignment of the DKIST.

3.2 DEMONSTRATION OF AO ENGINE ALGORITHMS

The algorithms used by the aO Engine to correct quasi-static wavefront errors have been shown, in

simulation, to meet top-level science requirements. The most recent results, published in 2012[2]

,

demonstrate that the aO Engine control algorithms are able to control wavefront errors to an accuracy that

is limited only by the wavefront sensor noise. Of the 100 initial cases simulated, convergence to the noise

level took a maximum of 6 iterations. Initial configurations contained randomized wavefronts with

approximately 2 micron RMS wavefront error.

As calculated in SPEC-0142, one iteration of the correction algorithm in median seeing will require

approximately 30 seconds. We can assume that from the time Active Optics is switched on, it should

provide an optimized correction within 3 minutes provided that all optical misalignments are within the

capture range of the wavefront sensor.

Given the degeneracy within the optical system, the aO Engine is capable of correcting the wavefront to

the same level of accuracy using different sets of commands to M1 and M2. As stated above, the two

reconstruction algorithms within the aO Engine are capable of selecting which M1 and M2 commands to

use in order to optimize different criteria. One reconstruction algorithm minimizes force applied to the

M1 actuators (FCLS) and the other algorithm minimizes image motion induced by moving M2 (NPF).

Both algorithms are derived in the publication mentioned earlier and their implementation and calibration

are presented in sections 5.2.3 and 5.4.3.

3.3 ACTIVE OPTICS PERFORMANCE ESTIMATION AND ERROR BUDGET

The DKIST Active Optics system will be evaluated based on two performance metrics, quasi-static

wavefront error and HOWFS pupil position control. The two following subsections address these

performance metrics and discuss expected performance of DKIST Active Optics.

Performance analysis discussed in this document focuses on wavefront error due to sensing and control

algorithms that fall within direct control of the WFC team. Wavefront errors due to operation of the active

mirrors, such as repeatability, accuracy, resolution, range, etc. of their controllers, are dealt with in the

SPEC-0009 error budgets separately.

D R A F T

aO Engine CDD


WFC representatives were directly involved in requirements definitions, design reviews, and acceptance

testing for the M1, TEOA, and feed optics hardware and software. All performance requirements were

driven by Active Optics modeling to ensure that the SPEC-0009 error budget allocations would be met by

each subsystem.

3.3.1 Quasi-static wavefront error performance

Quasi-static wavefront error performance requirements are defined in SPEC-0058. The Active Optics

system is responsible for reducing DKIST wavefront error from the coronal error budget (SPEC-0009

Case III) to the seeing-limited on-disk error budget (SPEC-0009 Case II).

Two aspects of the Active Optics are discussed here, the total amount of correctible quasi-static wavefront

error and the residual quasi-static wavefront error after the Active Optics correction is applied.

For total correctible quasi-static wavefront error, the relevant terms in the Case II and Case III error

budgets are the “M1 static error”, “M2 static error”, and “quasi-static optical alignment error”. The M1

and M2 static error terms refer to the 50% encircled energy (EE50) contributions from uncorrected

wavefront aberrations caused by M1 and M2 while the “quasi-static optical alignment error” term refers

to all other optical misalignment errors as well as those inherent in the Active Optics alignment

algorithms. In the Case III error budget, active mirrors are driven only by lookup tables so the Case III

error terms include lookup table accuracy as well as surface figure deformations and other sources of

misalignment. The Case II error budget assumes active sensing and positioning of M1, M2, M3, and M6

by the Active Optics system, using the WFC LOWFS, so the error terms include only errors that the

Active Optics is unable to correct.

The differences between the Case II and Case III error budget allocations are shown in Table 1.

Simulations of the correction algorithms used in the aO Engine[1]

demonstrate that the limiting factor for

the correctible quasi-static wavefront error is the capture range of the wavefront sensor. The LOWFS

capture range is discussed in SPEC-0142 section 3.6 and shown to be more than adequate for the levels of

wavefront error shown in Table 1.

Budget allocation Case III

(arcsec, EE50)

Case II

(arcsec, EE50)

Difference

(arcsec, EE50)

Difference

(µm rms)

M1 static error 0.264 0.020 0.244 1.220

M2 static error 0.207 0.030 0.177 0.885

Quasi-static alignment 0.200 0.017 0.183 0.915

Table 1: Case III and Case II error allocations for active optics

To examine the residual wavefront error performance of the Active Optics, we turn to the “Active Optics

System” term in the Case II error budget. This error budget item combines errors due to sensing and

actuation in the Active Optics system and figure errors of M1 due to hysteresis or mismodeling. The total

allocation for the “Active Optics System” term is 0.035 arcseconds. Of the total, 0.022 arcseconds have

been allocated to M1 aO errors, leaving 0.029 arcseconds for errors due to WFC aO.

Conversion between 50% EE and nanometers wavefront error is discussed in TN-0148 Appendix A. A

factor of 2.0 x 10-4

arcsec per nm is reported from experience at the Gemini observatory and a factor of

4.1 x 10-4

arcsec per nm is reported from a simulation studying the effects of correcting low-order Zernike

modes for typical polishing error cases. Additionally, a third method to estimate the conversion factor

applied wavefront errors to the system in simulation and calculated a factor of 2.83 x 10-4

arcsec per nm.

Converting 0.029 arcseconds EE50 to nanometers leaves us with a WFC aO allocation of 145 nm, 71 nm,

or 102 nm rms depending on which factor is used. Following the logic used in TN-0148, we expect the

D R A F T

aO Engine CDD


flexure and thermal-induced wavefront errors to have a relatively larger low-spatial-frequency content

than typical mirror polishing errors, so we use the 2.83 x 10-4

factor to determine the WFC aO error

budget, setting the total allocation at 102 nm rms.

The aO Engine uses null-seeking algorithms to calculate the Active Optics corrections so it is expected

that there will be very little error associated with the algorithms themselves. Indeed, simulations of the aO

Engine algorithms[1]

show that the Active Optics corrections converge to the noise floor set by the

wavefront sensor within approximately 6 iterations, even for large initial wavefront errors. As a result, the

102 nm rms wavefront error allocated to the WFC aO performance is dedicated entirely to the

performance of the LOWFS. Further detail on the breakdown of the LOWFS error budget is presented in

SPEC-0142 section 4.1.

3.3.2 Pupil alignment performance

The primary purpose of closed-loop boresight alignment is to stabilize the telescope pupil on the

HOWFS.

In diffraction-limited and seeing-limited observations where the aO Engine is sending offsets to the active

mirrors, the HOAO fast tip-tilt (FTT) loop will be locked to correct image jitter. Image jitter requirements

on the HOAO FTT are orders of magnitude tighter than the telescope pointing requirements and will

compensate for any pointing drift. As a result, the only error budget that incorporates telescope pointing

drift is the SPEC-0009 Case III error budget, which does not put any requirements on the aO Engine.

M6 will still be updated with LUT positioning but during observations, there is no method available to

sense M6 misalignments so no closed-loop correction is possible. For the above reasons, a pointing error

budget does not appear in this document.

However, the aO Engine is responsible for actively controlling the pupil position on the HOWFS lenslet

array. The pupil position is sensed using four subapertures of the HOWFS that are at the edge of the

telescope pupil. The HOWFS selects one image from each of these subapertures, sums all the pixels

within each subaperture, and records the total illumination values for each of the four subapertures at a

nominal rate of 10 Hz. The HOWFS keeps a running average of the subaperture illumination levels and

sends it to the aO Engine at a user-defined update rate (default 1 Hz), resetting the running average every

time it sends a new measurement. When the aO Engine receives an event from the HOWFS containing

the four subaperture illumination values, it performs a quad-cell centroid computation to determine the

pupil position, as described in section 5.3.1. The gains and offsets used in the quad-cell computation are

determined by the calibrations described in section 5.4.4.

The performance requirements for maintaining pupil position on the HOWFS lenslet array derive from

SPEC-0058 requirement 2.1.1-0115 which specifies that the alignment of the telescope pupil with respect

to the HOWFS must be actively controlled to within 5% of a subaperture.

The pupil error budget, presented in Table 2, has been developed to account for all known sources of

active pupil alignment error. Pupil error is given in units of percentage of a HOWFS subaperture. The

current design of the HOWFS calls for a 21.5 mm pupil size with 43 subapertures across so the

conversion factor from percentage of a subaperture to mm is 21.5/4300 mm per subap%. The pupil

alignment requirement in SPEC-0058 is given in terms of a maximum allowable value so line items in the

pupil error budget are added to estimate the total error.

Allocation 5.00

Budget total 5.00

Measurement noise 0.20

D R A F T

aO Engine CDD


Calibration offset bias 2.50

Gain calibration error 0.30

Pupil eccentricity 1.00

Pupil edge variation 0.25

Pupil drift 0.20

M3 repeatability 0.20

Reserve 0.35

Table 2: Pupil alignment error budget, units are in % of a HOWFS subaperture

Most of the values in the pupil alignment error budget have been derived through simulations that

reproduce the pupil sensing algorithm described in this document. Our simulator for the pupil alignment

algorithm generates a high-resolution elliptical pupil with adjustable center position and eccentricity,

down samples it to determine the relative illumination of each HOWFS subaperture, applies photon noise

and read noise based on expected illumination levels (80% full pixel wells at maximum illumination) and

measured HOWFS camera read noise (30 e- RMS). It then computes the illumination levels of the four

subapertures selected to be pupil position monitors, shown in Figure 3, and applies the quad-cell formula

to determine the estimated pupil position. The simulator also allows for calibration of the quad-cell gains

and offsets using the calibration procedure described in section 5.4.4.

Errors such as misalignment during calibration, pupil eccentricity and rotation, photon noise, read noise,

and pupil blurring can be injected into the simulation to observe their effects on pupil estimation

accuracy. The following subsections describe the line items in the error budget and their budget

allocations in more detail.

D R A F T

aO Engine CDD


Figure 3: Locations of subapertures chosen for pupil position estimation shown in red. The squares are subaperture

lenslets, while the the x-es represent actuator locations on the deformable mirror projected onto the lenslet array.

3.3.2.1 Measurement noise

Our model assumes that all pixels within each subaperture receive the same illumination. This is a

simplification but a justifiable one, given that solar granulation features are low-contrast. This assumption

may not hold true when viewing a large active region so the estimated pupil error has been padded with a

safety factor of 4 to include cases where the average pixel illumination is low.

In general, measurement noise has a small effect on pupil estimation accuracy because the total number of

sensed electrons in each subaperture is very high. Each subaperture has 400 pixels, each with well depth

~30 ke-, so at 80% illumination, the SNR per pixel is approximately 150, making the total subaperture

SNR over 3,000. Figure 4 shows a plot of 200 iterations, demonstrating that pupil position estimate

variations due to measurement noise are barely noticeable. The RMS deviation due to noise observed in

1000 iterations was 0.05% of a subaperture, which has been multiplied by a safety factor of 4 to get the

error budget estimate of 0.20% of a subaperture.

D R A F T

aO Engine CDD


Figure 4: Example simulation with photon noise and read noise.

3.3.2.2 Calibration offset bias

Calibration offset bias refers to the error between the position our algorithm thinks is the optimal pupil

alignment and the true optimal pupil alignment. Initially, this value will be determined through simulation

but may need to be calibrated manually due to irregularities in the HOWFS. The calibration process to

determine the center point involves manually positioning the pupil and recording the HOWFS subaperture

illumination for known pupil offsets. Therefore, the offset accuracy relies on accurate manual positioning

of the telescope pupil on the HOWFS microlens array.

In our simulations, we assume that manual positioning is accurate to 5% of a HOWFS subaperture. This

leads to an expected offset bias of approximately 2.5 % of a subaperture based on our simulations and

matches well with what one would expect from averaging five independent measurements that are each

accurate to 5% of a subaperture (5 / √5 = 2.24 ).

Given that this is a large fraction of the total error budget, and currently the largest term, it may be worth

expending additional effort to reduce the size of this error. Taking advantage of the fact that when the

pupil is perfectly centered, it should not move as it rotates, a calibration scheme that centers the pupil

while rotating the coudé lab should be able to improve on the currently specified calibration scheme. As

this error budget is revised, if some of the terms grow to the point where this error term needs to be

reduced, alternate calibration options will be explored.

3.3.2.3 Gain calibration error

The quad-cell centroid formula used to determine pupil position requires two gains, gx and gy. Initially,

these gains will be estimated based on simulation results but their values are very sensitive to pupil

eccentricity and the intensity roll-off at the edge of the pupil so estimating them to better than 10%

accuracy is unlikely.

D R A F T

aO Engine CDD


The pupil stabilization algorithm is null-seeking so small errors in estimating the quad-cell gains will not

affect the steady-state performance of the system but will degrade its transient response. We base this

error budget term on the following analysis.

Pupil position error as a function of gain misestimation is given by the following formula,

where is the pupil position error, is the difference between the estimated gain and the actual gain,

is the actual gain, and is the actual pupil position. Based on our simulations, manual pupil

positioning accuracy to 5% of a subaperture during calibration leads to a ⁄ ratio of approximately

0.06. Figure 5 shows an example simulation result demonstrating how this number was obtained.

Figure 5: Simulated pupil calibrations. (top): actual. (bottom): with noise and 5% subaperture positioning error.

The Active Optics system is designed to maintain pupil alignment to better than 5% of a HOWFS

subaperture. Therefore, the maximum pupil alignment error between consecutive iterations in closed loop

should be less than 5% of a subaperture. Based on these assumptions, the maximum error due to gain

misestimation will occur at a pupil deflection equal to 5% of a subaperture.

Using 5% of a subaperture in the above equation for pupil error results in an error value of 0.30 % of a

subaperture.

D R A F T

aO Engine CDD


3.3.2.4 Pupil eccentricity

The telescope pupil on the HOWFS microlens array will rotate as the coudé lab rotates and as the

telescope articulates in altitude and azimuth. If the telescope pupil is elliptical, pupil rotation will cause

position measurement errors as the pupil drifts away from center.

Our simulations allow us to insert an elliptical pupil and rotate it on the lenslet array while observing the

output of the pupil position estimator. To estimate the effect of pupil eccentricity on the pupil position

estimator, we first introduced an elliptical pupil with an offset position of 5% of a subaperture in x and y,

then determined the rotation angle that produced the maximum error. Results of this simulation are shown

in Figure 6. Unsurprisingly, the error is maximized when the pupil is rotated 45 degrees clockwise from

nominal. Figure 6 also shows the error incurred when the rotation angle is fixed at 45 degrees and the

eccentricity varies from 0.00 to 0.30.

Figure 6: (left): Pupil position error vs. rotation angle (right): Pupil position error vs. pupil eccentricity

The error allocation assigned to this item is 1.0 % of a subaperture, corresponding to a pupil eccentricity

of 0.15. Based on ZEMAX ray-tracing calculations of the current telescope optical design, the expected

eccentricity of the telescope pupil on the HOWFS microlens array is 0.122.

If pupil eccentricity is found to exceed 0.15, pupil position error due to eccentricity can be mitigated by

using the telescope altitude, azimuth, and coudé rotation angles to calculate pupil rotation angle on the

HOWFS lenslet array and applying a corrective factor to the quad-cell formula.

3.3.2.5 Pupil edge variation

Our method of sensing pupil position relies on subapertures at the edge of the pupil so it is sensitive to the

shape of the intensity roll-off at the edge of the pupil. As the edge of the pupil blurs, the quad-cell gains

used to calculate the pupil position increase. If the edge of the pupil is uniform, the specific shape of the

roll-off at the edge is unimportant because the quad-cell gain calibration will account for it. However, if

the roll-off at the edge of the pupil is non-uniform, the quad-cell gains will change as the pupil rotates on

the HOWFS lenslet array, resulting in misestimation of the pupil position.

Initial modeling has shown that variation along the edge of the pupil will be very minor, leading to a top-

down estimate of 0.25% of a subaperture for this error term. The WFC team is working with SEIC to

obtain a better estimate of the pupil edge profile so that this error term can be refined by further modeling.

D R A F T

aO Engine CDD


3.3.2.6 M3 repeatability

M3 will be actuated to control the pupil position on the HOWFS lenslet array. Its repeatability affects

how accurately the pupil can be controlled and any repeatability errors are additive with the other pupil

positioning errors.

As specified in SPEC-0131, Transfer Optics Assembly Specification, M3 repeatability in tip and tilt is 0.5

arcseconds per axis, which translates into approximately 1 micron on the HOWFS lenslet array or 0.2 %

of a subaperture. The M3 assembly is currently under fabrication and expected to meet its accuracy and

repeatability specifications.

3.3.2.7 Pupil drift

Pupil drift refers to how far the pupil is expected to drift during the time elapsed between when one

measurement is taken and M3 is commanded to correct the measured pupil error. The default update rate

for the pupil stabilization loop is 1 Hz, so this number refers to the maximum expected pupil drift in one

second. Based on modeling done for the TMA FDR, an estimate of 1 micron per second is used to

generate the error value of 0.2% of a subaperture. The TMA FDR report can be found in project

document ATST-ANA-22100-01-05.

3.3.2.8 Reserve

The current error budget contains 0.35 % of a subaperture in reserve. As the telescope mount and mirrors

are installed on site, our models will be refined with as-built data and the error budget will be updated

accordingly.

3.4 MODAL BASES USED IN ACTIVE OPTICS

3.4.1 Zernike Basis

The Zernike polynomials define an orthogonal basis of functions within a circular aperture. They are

well-known functions often used to describe optical aberrations within a pupil and are particularly useful

for describing low-order wavefront aberrations such as those the Active Optics wishes to correct.

DKIST uses the Fringe Zernike modes as a project-wide standard. The Fringe Zernike polynomial was

developed by John Loomis at the University of Arizona Optical Sciences Center in the 1970s, and is

described on page C-8 of the CODE V® Version 10.4 Reference Manual. Active Optics is specifically

concerned with correcting modes Z4-Z23 of the Fringe Zernikes.

3.4.2 M1 natural modes

The M1 natural modal basis is determined through finite element analysis of the natural bending modes of

the M1 mirror and cell assembly. The M1 natural modes bear similarities to the Zernike functions;

however, they have an advantage in that they should be much easier to reproduce with M1 as opposed to

the Zernikes, which can have very steep features that a semi-rigid mirror will have difficulty with.

For further information on M1 natural modes, refer to the M1 cell assembly documentation (see AMOS

document 2106/01/28, AO Sensitivity Matrices).

3.5 INPUTS

During active correction, the aO Engine requires two error input arrays: wavefront error modal

coefficients and boresight error measurements. During normal observing, the WFC mode determines

which subsystem the aO Engine will use for each input, as shown in Table 3. In WFC mode calibrate, the

Active Optics can be set to passive or active correction in order to assist science instrument calibrations.

If Active Optics is set to active during calibrate, the aO Engine will use pupil-position measurements

D R A F T

aO Engine CDD


from the HOWFS to stabilize the pupil. For non-routine operation, sources of wavefront and pupil-

position error inputs can be set manually from the WCCS engineering GUI. In all cases, the WCCS is

responsible for properly configuring these systems to send their data to Active Optics and also for

configuring the aO Engine to accept inputs from the proper sources.

WFC mode Wavefront error source Boresight error source

Off N/A N/A

Idle N/A N/A

Calibrate HOAO or LOWFS HOWFS + CV

Diffraction limited HOAO HOWFS

Seeing limited on-disk LOWFS HOWFS

Seeing limited coronal N/A N/A

Limb tracking N/A N/A

Table 3: aO Engine default input sources as determined by the WFC mode during routine observations

3.5.1 Wavefront error input

The aO Engine receives wavefront error estimates from the HOAO or the LOWFS depending on the

current WFC mode, as described above. The format of these estimates is an array of 20 modal coefficients

in either the Zernike basis or the basis of the M1 natural mirror modes. In addition, the wavefront error

estimates are accompanied by an array of values, one for each mode, indicating the effective confidence

of each estimate. The format of the wavefront error inputs is identical whether it comes from the HOAO

or from the LOWFS.

The array of 20 modal coefficients represents the mean wavefront error measured by the particular

subsystem, decomposed into the first 20 coefficients of the specified modal basis. The modal basis is

controlled at the WCCS level so that all WFC subsystems are kept in synch. This ensures that the

wavefront error estimates use the same modal basis as the correction sent to the M1CS. The Fringe

Zernike functions and numbering scheme are used to represent the modal coefficients when the Zernike

basis set is used. The modal basis functions used for the M1 natural modes and the ordering of the

coefficients are those defined by the M1CS vendor (see AMOS document 2106/01/28, AO Sensitivity

Matrices).

The confidence of each modal coefficient is estimated differently depending on whether the measurement

is made in the LOWFS or the HOAO. The wavefront estimates from the LOWFS are computed by time-

averaging each subaperture’s cross-correlation functions, then reconstructing modal coefficients from the

peak values of these time-averaged functions. The confidence of each modal coefficient for these

measurements is found by computing the noise variance in each subaperture and using the modal

reconstruction matrix to propagate subaperture noise variances into modal coefficient variances. For

more detail on this calculation, refer to SPEC-0142. Wavefront estimates from the HOAO are computed

by taking selected frames from the HOAO telemetry stream (default: every 10th frame), calculating modal

coefficients from the DM actuator commands, and time-averaging the modal coefficients over the

designated period (default: 30 seconds). The HOAO estimates confidence by calculating the reciprocal of

the sample variance of each wavefront coefficient.

During normal observing, both the HOAO and the LOWFS send wavefront errors to the aO Engine.

Based on the current WFC mode the aO Engine selects which source to use for the wavefront error input

(this behavior may be overridden using aO Engine parameter settings). Both sources average their

wavefront error measurements over a user-specified time period (default 1 second) and then send the

D R A F T

aO Engine CDD


averaged wavefront coefficients to the aO Engine for processing along with an array representing the

confidence of each modal coefficient within the wavefront measurement. Refer to the HOAO and

LOWFS design documents for more detail on the calculation of the modal coefficients and confidence

values.

3.5.2 Boresight error input

The boresight error input is divided into two separate measurements: pupil position error and image

position error. During normal active correction operation, the pupil position error will come from

HOWFS and no image position error will be received. Generally, HOAO will actively control image jitter

with M5 so no image position correction is required from the aO Engine. In the rare case that M5 is not

used to control image jitter, the aO Engine will use an internal image motion model to drive M3 and M6

to compensate for any image movement caused by M2 offsets.

The boresight calibration is a special case where HOWFS will provide pupil position error and the CV

will provide image position error.

The HOWFS pupil position measurements are provided in the form of four subaperture intensity

measurements. When the aO Engine receives the subaperture intensity measurements it must convert

them into pupil position error. When it is measuring pupil position error, the HOWFS will average its

subaperture intensity measurements for a user-specified period (default 1 second) and then send the

averaged subaperture intensities to the aO Engine for processing.

3.6 WAVEFRONT CORRECTION OUTPUTS

Outputs from the aO Engine consist of set point position offsets for M1, M2, M3 and M6. These offsets

are sent to the appropriate mirror control systems (M1CS, TEOACS and FOCS). The aO Engine will send

set point offset commands whenever it has measured a significant and statistically likely quasi-static

wavefront error. For more detail on this process, section 1.1.1.

3.6.1 M1 axial actuator error

The M1CS receives set point position offsets from the aO Engine and adds them to the current M1 shape

to correct for the wavefront error measured by the WFC. The position offsets may be received by the

M1CS in in one of two ways: as a set of 30 modal coefficients or as a vector of 118 individual actuator

forces. Modal coefficients are the default method used by the aO Engine for sending these offsets. The

M1CS multiplies the modal coefficients by the appropriate sensitivity matrix for the selected modal basis

(Zernike or natural mirror modes) to convert them to individual actuator forces which are then added to

the current M1 axial actuator positions. The modal offsets received from the aO Engine are integrated and

applied to the current LUT-based mirror position. This integrated modal offset may be cleared as desired.

For more detail on how the M1 set points are adjusted based on aO Engine wavefront errors, see Section

4.

The WFC is only capable of measuring up to 20 modes of wavefront error with sufficient fidelity for

correcting the wavefront error in the Active Optics system, while the M1CS expects to receive 30 modal

coefficients. Hence, the upper 10 modes of the correction array are zeroed out. When Fringe Zernike

modes are selected as the basis set for the correction, modes Z1 – Z4, which correspond to piston, tip, tilt

and focus, are excluded. Modes Z5 through Z24 are sent along with zeros for modes Z25 – Z34, for a

total of 30 modes. When natural mirror modes are used, measured values for modes M1 through M20 are

sent along with zeros for modes M21 – M30, for a total of 30 modes. The order and numbering of the

natural mirror modes is defined in AMOS document 2106/01/28, AO Sensitivity Matrices.

Finally, the aO Engine is able to send corrections as a vector of 118 individual actuator commands to the

M1CS. Force commands sent in this way will be added to the current LUT position and applied directly

D R A F T

aO Engine CDD


to the M1 actuators, ignoring any offsets from previous aO Engine events. The ability to send direct force

commands is intended for use in troubleshooting and system identification rather than routine operation.

3.6.2 M2 hexapod position error

Outputs of M2 hexapod position errors are sent in the form of 6-element arrays. The six array elements

are set point position errors in the six hexapod degrees of freedom (dx, dy and dz translation, and dα, dβ,

and dγ rotation). When the TEOACS receives a set point position error from the aO Engine, it will add

the position errors to the current M2 hexapod position. For more detail on how the M2 set points are

adjusted based on aO Engine set point errors, see Section 4.

3.6.3 M3 tilt error

Outputs of M3 tilt errors are sent in the form of 2-element arrays. The array elements are position errors

to the M3 α and β rotation angles. When FOCS receives an event containing position offsets to M3 from

the aO Engine, it will add them to the current M3 position set points.

3.6.4 M6 tilt error

Outputs of M6 tilt errors are sent in the form of 2-element arrays. The array elements are position offsets

to the M6 α and β rotation angles. When FOCS receives an event containing position offsets to M6 from

the aO Engine, it will add them to the current M6 position set points.

3.6.5 Clear Active Optics offsets: aoZero

The set point offsets sent to each mirror control system described above are integrated so that the mirror

position offset applied to the mirror is the sum of the current LUT position offset and the accumulated

offsets from the aO Engine. Under certain conditions (described in more detail below) the accumulated

offset must be set to zero. The aO Engine has a special attribute, aoZero, that is part of the offset event

sent to each mirror controller that is used to do this. If the aoZero attribute in the event is true, the active

mirrors will zero all accumulated error offsets from the aO Engine before adding the error offsets

contained in the current event. The aO Engine will be able to zero each active mirror individually using

this attribute.

An example use case for aoZero is if the aO Engine is commanded to change the M1 modal basis during

active correction. To do this, the aO Engine needs to zero out the M1 axial coefficients in the current

modal basis and replace them with coefficients in the new modal basis that describe an equivalent surface

shape. The aO Engine will determine the accumulated modal coefficients currently in use by reading the

latest M1 status event. It will then convert these modal coefficients from the basis currently in use to the

desired modal basis. The new modal coefficients will then be sent to M1CS in a new event with aoZero =

true. This will result in a modal basis change without an interruption in the active correction.

3.7 CORRECTION MONITORING

During active correction, the aO Engine will monitor both the incoming wavefront measurements and the

motions of M1, M2, M3, and M6 to determine whether the LUTs driving M1, M2, M3, and M6 are

helping or hindering the quasi-static wavefront control of the telescope. If one of the mirror LUTs is

determined to be significantly hindering the performance of the Active Optics system, the aO Engine will

raise an alarm so that the operator can manually disable the offending LUT. This is discussed in further

detail in Section 5.2.5.

3.8 LOGGING

Whenever it is actively measuring the telescope wavefront, the aO Engine will log all events that it

publishes and all events to which it subscribes. The aO Engine will be considered to be actively

D R A F T

aO Engine CDD


measuring the wavefront whenever the WFC mode is set to WFC-OPM1: diffraction limited or WFC-

OPM2: seeing-limited on-disk.

Included in the events logged will be data pertaining to the telescope state and quasi-static wavefront

measurements. Telescope state data incudes telescope mount position, M1 actuator forces and LUT

values, TEOA hexapod position and LUT values, M3 and M6 position and LUT values, coudé rotator

position, external temperature, M1 temperature, M1 temperature gradient, and any other data which may

influence the quasi-static wavefront of the telescope. Wavefront measurements that are logged consist of

HOWFS pupil position measurements, DM offloads (if in diffraction-limited WFC mode), LOWFS

measurements (if in seeing-limited WFC mode), and aO Engine position commands sent to the M1CS,

TEOACS, and FOCS.

Events will be logged to the CSF Archive Database, which allows for recording short bursts of data at the

CSF Attribute level into a searchable database for engineering purposes. Logging is implemented by the

aO Engine software, as described in section 6.3.6. The list of events published by the aO Engine is

contained in section 6.3.2 and the list of events subscribed to by the aO Engine is contained in section

6.3.3.

Logging all the aO Engine events will serve to construct a database of quasi-static wavefront

measurements for a wide variety of telescope positions and environmental conditions. The database can

be used to identify trends that can provide updates to the LUTs for the M1CS, TEOACS, and FOCS.

3.9 DATA TRENDING

The WFC system will provide a software tool that is able to mine the logged data and plot historical

mirror positions, LUT values, wavefront measurements, and/or aO Engine offset commands as functions

of external variables such as telescope position and temperature. The data trending will show daily

operational cycles as well as long-term trending over monthly periods of operation. The design and

implementation of this tool will occur during lab integration and testing.

3.10 SET POINT ALGORITHMS

This section describes the algorithms the active mirrors use to determine their set points at a given time.

3.10.1 Notation

The following notation is used throughout this document.

α = slow rotation about the x-axis.

β = slow rotation about the y-axis.

γ = slow rotation about the z-axis.

θalt = Telescope mount angle (altitude).

θaz = Telescope mount angle (azimuth).

θcoudé = Coudé rotation angle.

aM1,act = Actuator force setpoints to M1from Active Optics (118 element array).

aM1,mode = Modal offsets to M1 from Active Optics (20 element array).

aM2 = Position setpoint offsets to M2 from Active Optics (6 element array).



D R A F T

aO Engine CDD


e = Wavefront error modes sent to Active Optics from HOAO or LOWFS (20 element array).

e0 = Wavefront modes measured when the telescope is in its best-corrected state (20 element

array).

FM1 = Matrix that maps M1 surface figure modal coefficients to M1 actuator forces (118 x 20

matrix).

H = Interaction matrix that maps M1 bending modes and M2 rigid body modes to wavefront

modes measured by the HOAO or LOWFS (20 x 26 matrix).

LM1,alt = M1 altitude lookup table (each entry is a 20 element array).

LM1,az = M1 azimuth lookup table (each entry is a 20 element array).

LM1,T = M1 temperature lookup table (each entry is a 20 element array).

LM1,static = M1 static shape lookup table (20 element array).

= M1 differential temperature lookup table (each entry is a 20 element array).

LM1,mask = M1 dead actuator mask (118 x 118 element array).

LM1,tot = Total of all M1 lookup tables (20 element array).




LM2,static = M2 static shape lookup table (6 element array).

LM2,zpoint = M2 zero-point lookup table (6 element array).

= M2 lookup table based on M1 differential temperature (each entry is a 6 element array).




LM3,static = M3 static lookup table (2 element array).






LM6,static = M6 static lookup table (2 element array).




n = Noise vector representing the noise present in each wavefront mode (20 element array).

D R A F T

aO Engine CDD


P = Penalty matrix on M1 and M2 forces (26 x 26 diagonal matrix).

sM1,act = Vector of force setpoints for M1 actuators (118 element array).

sM1,mode = Vector of mode setpoints for M1 figure (20 element array).

sM2 = Vector of position setpoints for M2 hexapod (6 element array).

sM3 = Vector of position setpoints for M3 (2 element array).

sM6 = Vector of position setpoints for M6 (2 element array).

T = M1 surface temperature (reported by Facility Control System).

= Differential temperature from one side of M1 to the other (reported by Facility Control

System).

3.10.2 Generalized algorithm

The control of quasi-static wavefront errors requires periodic updating of the set points of M1, M2, M3,

and M6 to compensate for flexure and thermal effects throughout the entire DKIST optical system. There

are two methods available for computing actuator set points, passive correction and active correction.

Each set point determination method defines the absolute set points for M1, M2, M3, and M6 at any given

moment in time.

Unless specifically mentioned, all lookup tables shall be stored in databases so that they are available to

the mirror control systems at all times and will not be lost in case of power outage or other system failure.

3.10.3 Passive Correction

As mentioned earlier, passive correction is a distributed control method in which each active mirror is

responsible for positioning itself using an internal LUT. Previously recorded data from the aO Engine and

WFC wavefront sensors is used to define and update the active mirror LUTs but no position offsets are

sent from the aO Engine during passive correction. Controllers for all four active mirrors (M1, M2, M3,

and M6) must maintain LUTs based on all relevant telescope parameters. LUTs that will be maintained at

the start of IT&C are telescope altitude, telescope azimuth, M1 temperature, and M1 temperature

gradient.

It may seem unintuitive that M6 requires a LUT based on M1 temperature and could, instead, be slaved to

M3 or M2. As a counterexample, consider these two cases. In case A, a change in M1 temperature

induces astigmatism in M1 and M2’s LUT is tilted to cancel it out. The tilt of M2 induces a change in

telescope pointing which must be corrected by M6. In case B, gravitational flexure causes M2 to sag, and

M2’s LUT corrects the sag by repositioning M2. In this case, assuming no other mirrors are out of

alignment, M6 should maintain its position. Note that in both cases, the pupil position stays constant so

no M3 motion is desired.

In the above example, if M6 is slaved to M3 it will not correct the pointing error in case A and if M6 is

slaved to M2 it will erroneously “correct” a perceived error in case B. The best way to ensure that M6

provides an optimal correction is to have its LUT position dependent only on the actual telescope

parameters, not the positions of the other mirrors. This implementation also avoids problems that may

occur in case of a mirror control malfunction where one of the mirrors misreports its position.

The passive correction method determines the M1 axial actuator set points at a given time, t, in the

following way,

( ) ( ( ) ( ) ( ) ( )).

D R A F T

aO Engine CDD


In the above equation, the * operator represents elementwise multiplication and is a sensitivity matrix

that maps modal coefficients to M1 axial actuator forces. The specific sensitivity matrix will depend on

which modal basis the WCCS is configured to use. is a 118 element vector that can mask a

single bad actuator. is determined from the M1CS internal lookup tables in the following way,

( ) ( ) ( ) ( ) ( ),

where , ( ), ( ), ( ), and ( ) are lookup table values from the

static lookup table, the altitude angle lookup table, the azimuth angle lookup table, the temperature lookup

table, and the temperature gradient lookup table. Each lookup table contains values of the relevant

parameter that span the full expected operating range of the telescope. Within the lookup table, each

parameter value is paired with a 30-element array of modal coefficients that represent the surface figure to

be applied to M1 for the given parameter value. When calling each lookup table, the M1CS searches the

appropriate lookup table to find the two parameter values that most closely bracket the desired parameter

value. It then uses linear interpolation between these two parameter values to estimate the 30-element

modal coefficient vector that is associated with the desired parameter.

The TEOACS determines the M2 hexapod position set points in a similar way,

( ) ( ( ) ( ) ( ) ( )),

where

( )

( ) ( ) ( ) ( ).

The TEOACS contains two static lookup tables, LM2,static, the static lookup table, and LM2,zpoint, the zero-

pointing error lookup table. Both of these lookup tables contain six hexapod position values that act as

offsets to correct any static error that may be present. The difference between the two static lookup tables

is that the zero-pointing error lookup table is non-persistent. The zero-pointing error lookup table is used

to correct the tilt repeatability error that is introduced when the TEOACS powers up and must perform a

homing operation to initialize its encoders. Therefore, the zero-pointing lookup table must be re-

calibrated every time the TEOACS transitions from powered off to powered on and there is no need for it

to be persistent.

M3 and M6 are also positioned according to lookup tables,

( ) ( ( ) ( ) ( ) ( ))

( ) ( ( ) ( ) ( ) ( )),

where

( ) ( ) ( ) ( ) ( )

( ) ( ) ( ) ( ) ( ).

The FOCS contains lookup tables for M3 and M6 positions with regard to static aberrations, altitude

angle, azimuth angle, temperature, and M1 temperature gradient. For lookup table implementation details,

see section 4.1.

3.10.4 Active Correction

Active correction determines each mirror’s set points at a given time, t, in the following way,

D R A F T

aO Engine CDD


( ) ( ( ( ) ( ) ( ) ( )) ∑ ( )

)

( ) ( ( ) ( ) ( ) ( )) ∑ ( )

( ) ( ( ) ( ) ( ) ( )) ∑ ( )

( ) ( ( ) ( ) ( ) ( )) ∑ ( )

.

In these equations, the “a” vectors represent outputs of the aO Engine reconstructor, a process that

calculates errors in the active mirror set points based on wavefront error inputs. The outputs from the aO

Engine are computed relative to the current mirror positions so they must be summed to get the total

position offset from the lookup table. aO Engine outputs to the active mirrors are summed from the most

recent aO Engine event to t0, the time of the latest aoZero command. It is important to note that the

lookup table updates may happen at a rate that differs from the aO Engine output rate. Within the active

mirror controllers, the lookup table updates and the aO Engine updates are handled by two separate

processes that occur independently of each other. The lookup table offsets update at a constant rate and

the aO Engine offsets update whenever a new aO Engine event is received.

For implementation details, see section 4.2. Note that the M1 set point errors are sent from the aO Engine

as modal coefficients, which must be converted to actuator forces by multiplying by the FM1 matrix. This

representation is for a generic modal basis, each modal basis implemented within the M1CS will have a

different F matrix.

D R A F T

aO Engine CDD


4 IMPLEMENTATION

4.1 PASSIVE CORRECTION

Each of the active mirror control systems is responsible for storing its own lookup tables internally. The

M1CS, TEOACS, and FOCS must all contain lookup tables for telescope altitude angle, telescope

azimuth angle, and temperature. They must also be able to easily accommodate the addition of other,

heretofore unidentified, lookup tables.

A lookup table is a mapping that matches arrays of mirror position offsets with values of a chosen input

variable. Lookup tables will be implemented using tools provided by CSF, as described in TN-0088.

Lookup tables can be tables of discrete values with lookups via interpolation or parameterized functions.

The input values accepted by the lookup table should span the entire range of parameter values that may

be encountered during operation. Each individual mirror controller is responsible for ensuring that LUT

output positions are checked to ensure they are within its allowable range of values so that sensor errors

or LUT errors cannot cause unsafe operation. Lookup tables should also be easily modifiable to

accommodate updates based on measured telescope performance.

When using passive correction, the M1CS, TEOACS, and FOCS will update their set points at regular

time intervals. The time interval between updates is user-adjustable and ranges from one second to ten

seconds. At each set point update, the control system will access its lookup tables to determine its new set

point using the proper equation from section 3.10.3. Once the new set point has been calculated, the

control system will move its mirror to the new position and hold there until the next set point update

occurs.

For further detail on the active mirror controllers, see doc# OSL/2106/30/27 for the M1CS design, doc#

SDD-32506 for the TEOACS design, and SPEC-0132 for the FOCS design.

Because all lookup tables reside within M1CS, TEOACS, and FOCS, the aO Engine is not required to

take any action during passive correction.

4.2 ACTIVE CORRECTION

When operating in active correction, the aO Engine processes residual wavefront measurements from the

HOAO or LOWFS, calculates set point errors, and sends them to the active mirror controllers. The set

point adjustments are sent as events, using the CSF event network. The structure of each event is

described in the relevant ICD between the WCCS and each mirror control system. The aO Engine uses

the algorithms detailed in section 5 to calculate the set point errors based on the quasi-static wavefront

measurements it receives.

Quasi-static wavefront measurements arrive as inputs to the aO Engine at a user-defined rate (default 1

Hz) from either the LOWFS or HOAO. The aO Engine uses these wavefront error inputs to determine its

own estimate of the current quasi-static wavefront error through an input filtering process to ensure that

atmospheric effects are removed from the quasi-static wavefront error estimate. Once the aO Engine has

determined that its wavefront error estimate exceeds the set confidence threshold, it uses its wavefront

error estimate to calculate set point errors for M1 and M2. Each set point error event sent by the aO

Engine requires processing multiple wavefront error inputs so the set point error events will be issued at

irregular intervals that are longer than the time between wavefront error inputs. Typical update rates for

set point error events are expected to vary between 10 seconds and 60 seconds.

The aO Engine also uses a similar but separate process to filter the incoming pupil position errors and

generate set point errors to M3 and M6 for boresight stabilization.

Set point errors sent from the aO Engine to M1CS, TEOACS, and FOCS are errors relative to their

current positions (set points). As such, the errors must be accumulated within the M1CS, TEOACS, and

D R A F T

aO Engine CDD


FOCS. The set point errors sent from the aO Engine are in the local coordinate systems used by M1,

TEOA, and Feed Optics so they must be converted to the relevant coordinate system before being

transmitted. The coordinate transformation is described in section 5.1.

Set point position errors to M1 and M2 from the aO Engine are not sent at regular time intervals, they are

instead sent whenever the aO Engine determines that it has measured a significant and statistically likely

quasi-static wavefront error. Whenever the aO Engine sends a set point error signal to one of the active

mirrors, it will monitor the status events from that mirror controller to determine when the mirror has

reached its new position. Any wavefront error inputs that arrive before the mirror has reached its new

position will be disregarded.

During active correction, active mirrors will operate from LUTs in the same way as in passive correction

except the mirror set points will be adjusted from the LUT values by the accumulated aO Engine offsets,

as shown in the equations in section 3.10.4. The offsets from the LUTs will be adjusted every time the aO

Engine sends out a new error signal. This process is described in more detail for each active mirror in the

following three subsections.

4.2.1 M1 active correction

When in active mode, M1 receives set point errors from the aO Engine in the form of modal coefficients

of a shape that is to be applied to the M1 surface. Full details of how the M1CS applies aO Engine set

point errors and LUT values can be found in Figure 21 of the M1 control system design document,

presented at the M1 Assembly FDR[3]

. Whenever M1CS receives an aO Engine event, if it is in active

mode, it must take the following steps:

1) Receive aO Engine event, check its attributes for validity, determine whether the event contains

forces or modal coefficients, check M1 actuators to ensure they are in good health and able to be

moved.

2) Check for the aoZero attribute in the event. If true then clear the accumulated aO Engine offsets.

3) Compute the array of aO Engine force offsets:

a. If the aO Engine event contains modal coefficients, add the modal coefficients

contained in the current aO Engine event to the accumulated aO Engine modal

offsets. Then convert the accumulated aO Engine modal offsets from modal

coefficients to actuator force set points. This is now the array of aO Engine force

offsets.

b. If the aO Engine event contains forces then the force array becomes the array of aO

Engine force offsets

4) Add the current LUT force set points to the aO Engine force offsets to find the new absolute M1

actuator force set points.

5) Apply dead actuator compensation and remove any piston that is present in the new set points (all

forces should sum to zero).

6) Re-distribute forces to lateral actuators based on current telescope altitude if necessary.

7) Check that new set points are within valid operating range of M1 actuators.

8) Move the M1 actuators to their new force set points.

9) Continue applying the offsets in the M1 LUTs at the designated rate, adding the aO Engine force

offsets to the LUT values. Update the aO Engine force offsets according to the above procedure

whenever an aO Engine event arrives.

D R A F T

aO Engine CDD


If any of these steps fails or is unable to complete then the M1CS will take appropriate steps to notify the

user and ensure safety.

4.2.2 M2 active correction

The M2 receives set point offsets from the aO Engine in the form of a 6-element hexapod position offset.

Details of the application of these offsets are described in the TEOACS software design document [4]

.

Whenever the TEOACS receives an aO Engine event it must take the following steps:

1) Receive aO Engine event, check its attributes for validity, check M2 actuators to ensure they are

in good health and able to be moved.

2) Check for aoZero attribute in the event. If true then clear the accumulated aO Engine position

offsets.

3) Add the position offsets contained in the current aO Engine event to the accumulated aO Engine

position offsets.

4) Add the current lookup table position to the accumulated aO Engine position offsets to find the

new absolute M2 hexapod position set points.

5) Check that new set points are within valid operating range of M2 actuators.

6) Move the M2 hexapod to its new position set point.

7) Continue applying the M2 LUTs at the designated rate, adding the accumulated aO Engine

position offsets to the LUT values. Update the accumulated aO Engine position offsets according

to the above procedure whenever an aO Engine event arrives.

If any of these steps fails or is unable to complete then the TEOACS will take appropriate steps to notify

the user and ensure safety.

4.2.3 M3 and M6 active correction

The FOCS receives set point offsets from the aO Engine in the form of a 4-element position offset array

that contains offsets for α and β positions for both M3 and M6. Whenever FOCS receives an aO Engine

event it must take the following steps.

1) Receive aO Engine event, check its attributes for validity, check M3 and M6 actuators to ensure

they are in good health and able to be moved.

2) Check for aoZero attributes in event. If true for M3 then clear the accumulated aO Engine

position offsets for M3. If true for M6 then clear the accumulated aO Engine position offsets for

M6.

3) Add the position offsets contained in the current aO Engine event to the accumulated aO Engine

position offsets for M3 and M6.

4) Add the calculated lookup table position offsets to the accumulated aO Engine position offsets to

find the new absolute M3 and M6 position set points.

5) Check that new set points are within valid operating range of M3 and M6 actuators.

6) Move M3 and M6 to their new position set points.

7) Continue applying the M3 and M6 LUTs at the designated rate, adding the accumulated aO

Engine position offsets to the LUT values. Update the accumulated aO Engine position offsets

according to the above procedure whenever an aO Engine event arrives.

D R A F T

aO Engine CDD


If any of these steps fails or is unable to complete then the FOCS will take appropriate steps to notify the

user and ensure safety.

D R A F T

aO Engine CDD


5 AO ENGINE ALGORITHMS

This section describes all the algorithms used within the aO Engine. The aO Engine processes inputs from

the HOAO or LOWFS to determine whether a significant misalignment exists and, if a misalignment is

detected, it sends offsets to the relevant active mirrors that remove the effects of the detected

misalignment.

When performing active correction, the aO Engine runs two simultaneous processes: wavefront correction

and boresight correction. The wavefront correction process monitors quasi-static wavefront errors

measured by the HOAO or LOWFS and corrects them by sending offsets to the M1CS and TEOACS.

The boresight correction process monitors pupil motion measurements from the HOWFS and corrects

them by sending offsets to M3 and M6.

This section describes the algorithms used for both processes. The next subsection discusses the

coordinate rotations necessary for each process then the two following sections present the detailed

algorithms used for wavefront correction and boresight correction.

5.1 ACTIVE OPTICS COORDINATE TRANSFORMATIONS

Reconstruction matrices in the aO Engine assume that the telescope maintains a fixed position where θalt,

θaz, and θcoudé remain constant at θalt = 90°, θaz = 0, and θcoudé = 0. In reality, θalt, θaz, and θcoudé will be

changing constantly and, as they change, the rotations of the active mirrors will change with respect to the

aO sensors.

In order to account for these motions, the aO Engine will operate in a coordinate system that moves along

with the three rotational axes of the TMA. Derotation into this co-moving coordinate system ensures that

the reconstruction matrices are always working within the same reference frame for which they were

calculated.

For wavefront control, M1 and M2 maintain a constant relative rotation to each other. Therefore,

derotation into the co-moving coordinate frame will be done on the wavefront measurements as they are

received. Each wavefront measurement vector sent to the aO Engine will be accompanied by attributes

that report the altitude, azimuth, and coudé rotation angles of the telescope both at the beginning and end

of that measurement. Relative rotation between the primary aperture and its image on the DM and WFC

sensors is derived in TN-0014 – Pupil Rotation,

.

So derotation into the co-moving coordinate frame is done by estimating from the mean positions of

the three telescope axes as reported in the wavefront error event,

,

where is a static offset that defines the zero point. The vector of wavefront error coefficients, eZern[k],

is then multiplied by a Zernike rotation matrix to derotate it into the co-moving coordinate frame.

D R A F T

aO Engine CDD


( )

(

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

( )

( )

( )

( )

( )

( )

( )

( )

( )

( )

( )

( )

( )

( )

( ))

In this case, we want to derotate by so

( ) ,

where represents the wavefront error Zernike coefficients at time k, de-rotated into the co-

rotating coordinate system. When operating in the M1 natural mode basis, the calculation is the same

except the M1 natural mode rotation matrix is used instead of the Fringe Zernike rotation matrix.

Wavefront error due to derotation and averaging of measurements at different rotation angles is quantified

in the LOWFS error budget.

Derotation of the boresight reconstruction errors is a slightly different process because the relative

rotation between M3 and M6 changes as a function of telescope altitude. For the boresight reconstruction,

there are two coordinate rotations that must be done, the first on the incoming pupil and image position

errors to get them to the M6 reference frame, and the second rotation that is done post-reconstruction to

rotate the M3 position offsets into the co-rotating telescope coordinate system. The coordinate rotations

are described in more detail in sections 5.2.1 and 5.3.1.

5.2 WAVEFRONT CORRECTION

The wavefront measurements sent to the aO Engine by the LOWFS or HOAO subsystems represent

modal decompositions of the quasi-static wavefront error. These wavefront measurements are made in

different ways depending on which system is taking the measurements but the modal coefficients sent to

the aO Engine from both subsystems use the same format, as described in section 3.5.1.

The aO Engine will monitor status events from M1CS, TEOACS, and FOCS , which contain mirror

position information. The aO Engine will keep track of the inPosition attributes in each event and ignore

any wavefront measurements that arrive while the inPosition flag of any of the four active mirrors is set to

false. All active mirror and telescope mount position events are issued at rates of 1 Hz or greater.

5.2.1 Input Derotation

As described in section 5.1, the first step towards wavefront reconstruction is derotation of the wavefront

measurements received by the aO Engine. Each time the aO Engine receives a wavefront error event from

the subsystem it is listening to, it will derotate the wavefront error vector contained in that event and pass

it through the input filtering process. The derotation equation is,

( ) ,

where e[k] is the vector of wavefront coefficients in the event received at time k, is the mean

rotation calculated from the telescope angles in the event (calculated as described in section 5.1), is the vector of de-rotated modal coefficients, and is the rotation matrix corresponding to the modal

basis used to calculate . Rotation matrices for both modal bases are given in section 5.1.

D R A F T

aO Engine CDD


The wavefront coefficient confidence vector also must be derotated using the same matrix as the

wavefront error vector,

( ) ,

where is the confidence vector associated with in the wavefront error event, and is the

de-rotated confidence vector that is passed along to the input filtering step.

5.2.2 Wavefront Error Processing

Once the wavefront inputs are de-rotated, the aO Engine uses the new wavefront error measurements to

update its internal estimate of the quasi-static wavefront error. The confidence vector associated with each

measurement is used as a weighting factor so that noisy measurements will not affect the internal

wavefront estimate as much as highly-confident measurements. The default method for assigning

confidence values is so that the weighting factor for each measured coefficient represents the reciprocal of

its variance.

The aO Engine also estimates the signal to noise ratio of each individual wavefront modal coefficient

using a recursive sample variance estimator.

The incoming wavefront measurement, , is composed of wavefront modal coefficients, , where

m varies from 0-19. The weighted mean of each of the 20 wavefront modal coefficients is updated as

follows,

( ),

where is the internal wavefront estimate for modal coefficient m at time k and wm,k is the total of all

confidence values for modal coefficient m. Initially, and .

The aO Engine also updates the signal to noise ratio of each modal wavefront coefficient every time a

new measurement is received,

( )( )

(

)

√ ,

where is the signal to noise ratio of internal wavefront coefficient m at time k and is the

sample variance of . Initially, , , , and . If is ever

equal to zero then will be reported to be 10,000. This method of estimating the signal-to-noise

ratio calculates the sample variance of each modal wavefront coefficient and uses that to compute the

signal to noise ratio of the data. The 4k/(1+4k) factor removes bias due to small sample size[5]

.

Whenever and are updated, they are compared to two threshold arrays, wfeThresh and

snrThresh, to determine if the internal wavefront estimate is both significant and reliable. If is

greater than or equal to the mth

value of wfeThresh then will be considered significant. If is

greater than the mth value of snrThresh then will be considered reliable. For these reasons, attribute

wfeThresh will be referred to as the significance threshold and attribute snrThresh will be called the

reliability threshold.

Every time the aO Engine receives a new wavefront measurement, it will perform the above update

calculations and threshold tests on all 20 wavefront modal coefficients before the next wavefront sensor

measurement is received (default 1 second).

D R A F T

aO Engine CDD


After completion of these calculations, the aO Engine will check its cadence attribute to determine the

next action. It will check whether k times the wavefront sensor update period is greater than or equal to

the cadence setting. If no, nothing will be done until the next wavefront measurement. If yes, the aO

Engine will select all coefficients of the current internal wavefront estimate which are both significant and

reliable, and send them to the Active Optics reconstructor. Active Optics will then reset all k’s to zero.

5.2.3 Wavefront Reconstruction

The aO Engine wavefront reconstruction process takes error measurements from the previous step as

input and converts them into position errors for M1and M2.

The aO Engine uses two different user-selectable methods for calculating M1 and M2 errors based on

wavefront error inputs. The force-constrained least-squares (FCLS) method uses M2 to correct as much of

the wavefront error as possible, minimizing the actuator forces applied to M1. The neutral pointing plus

focus (NPF) method uses M2 to correct defocus and astigmatism wavefront modes while constraining M2

to move along the z-axis as well as rotate about the center of curvature of its parent. This constrained

“neutral pointing” reduces image motion caused by the motion of M2.

Both wavefront correction methods are based on a pseudo-inverse solution to a linear least-squares

problem. Both methods are described in detail in the two following subsections. While different in their

mathematical solutions, their implementations differ only in the reconstruction matrices used.

5.2.3.1 Force-constrained least-squares

The FCLS method uses Tikhonov regularization to constrain the force on the M1 actuators. The solution

used to calculate the M1 and M2 position errors based on the wavefront error estimate is as follows,

(

) ( ),

where aM1 and aM2 are the position errors of M1 and M2 in co-rotating telescope coordinates, is the

vector of wavefront modal coefficients calculated in section 1.1.1, and is the vector of wavefront

modal coefficients measured when the optical system is in its optimal configuration. The aO Engine uses

two different RFCLS reconstruction matrices, one for each wavefront modal basis. Calculation of the FCLS

reconstruction matrix is a calibration procedure for the aO Engine and is described in section 5.4.3.1. It is

expected that calculation of RFLCS will only need to be done during IT&C and it will not need to be

recalculated on a regular or frequent timescale. Any manipulation of the reconstruction matrices will be

the responsibility of the WFC specialist.

5.2.3.2 Neutral pointing plus focus

The NPF method also uses a reconstruction matrix, similar to the FCLS method. The only real difference

between the implementation of the two methods is the way the reconstruction matrices are calculated,

(

) ( )

where aM1 and aM2 are the position errors of M1 and M2 in co-rotating telescope coordinates, is the

vector of wavefront modal coefficients calculated in section 1.1.1, and is the vector of wavefront

modal coefficients measured when the optical system is in its optimal configuration. The aO Engine uses

two different RNPF reconstruction matrices, one for each wavefront modal basis. Calculation of the NPF

reconstruction matrix is a calibration procedure for the aO Engine and is described in section 5.4.3.2. It is

expected that calculation of RNPF will only need to be done during IT&C and it will not need to be

recalculated on a regular or frequent timescale. Any manipulation of the reconstruction matrices will be

the responsibility of the WFC specialist.

D R A F T

aO Engine CDD


5.2.4 Output Gain Control

In the penultimate step before position error signals are sent to the active mirror control systems, each

error vector is multiplied by a proportional gain. Each active mirror will have a separate gain that can be

modified from the WCCS engineering GUI. Initially all gains will be set to 1 but they may be fine-tuned

during IT&C.

Finally, the position error signals are sent to the M1CS and M2CS using the CSF event network. This

process is described in more detail in the software design description.

5.2.5 Correction monitoring

As discussed in section 3.1, active correction using the aO + LUT method may perform poorly if the

LUTs are anti-correlated to the optimal mirror trajectory. The aO Engine will attempt to detect this

condition by monitoring the total RMS value of the wavefront errors sent to the reconstructor for

processing. If the total RMS wavefront error value is above the lutCheckThresh value for more than 5

consecutive measurements, the aO Engine will alert the operator by changing the lutCheck attribute in its

status event to true and setting its health to ill. This signals the operator that the Active Optics are not

performing to the expected level and disabling one or more of the LUTs currently in use may improve

performance. Experience gained during IT&C will guide the operator as to which LUTs are likely to be

problematic and what other possible corrective actions may be necessary to restore nominal performance

of the Active Optics.

The aO Engine will continue to monitor the wavefront error values sent to the reconstructor and will set

the lutCheck attribute to false if it measures a sufficient number of consecutive RMS wavefront error

values below the lutCheckThresh value. The threshold for number of consecutive measurements to

disable the lutCheck flag will be the same as the threshold for the number of consecutive measurements to

enable the lutCheck flag and will be a parameter set by the WFC specialist.

5.3 BORESIGHT CORRECTION

The boresight correction process runs simultaneously with the wavefront correction process. Both

processes are similar mathematically in the sense that they use least-squares solutions to actively maintain

telescope alignment. They differ somewhat in their implementation because boresight correction is done

at a set update rate and doesn’t use confidence factors to optimize its estimation process. Boresight

alignment is also simpler to implement because it doesn’t require the use of multiple basis sets and it only

has 4 sensor degrees of freedom and 4 actuator degrees of freedom.

The following subsections describe the full boresight reconstruction process: pupil error calculation,

derotation, reconstruction, re-rotation, and output filtering.

5.3.1 Pupil error calculation and derotation

The first step in boresight correction is performed whenever the aO Engine is set to active correction and

receives a pupil position event. A pupil position event will contain four subaperture intensities that must

be converted into pupil position errors. Let i0, i1, i2, and i3 be the intensities of the four subapertures

reported by HOAO, in clockwise order from top left in the HOWFS coordinate system. Pupil position

error is found using a quad-cell formula,

(( ) ( )

)

(( ) ( )

)

D R A F T

aO Engine CDD


where and are the pupil position offsets and gx and gy are the x and y pupil calculation gains. The

procedure for calibrating these four values is described in section 5.4.

The aO Engine will recursively average pupil position measurements based on the maximum cadence set

for the boresight correction. For example, if the maximum cadence is set at 2 seconds, pupil position

measurements will be averaged until the time elapsed since the last correction sent to M3/M6 is greater

than or equal to 2 seconds.

Once the pupil error is calculated, the aO engine must check whether it is doing a normal boresight

correction or whether it is performing a boresight alignment calibration or boresight reconstruction matrix

calibration. If it is set to perform one of these calibrations then the aO Engine will wait until it receives

both an image position error event from the Context Viewer (CV) and a pupil position measurement.

Once the aO Engine has both received a CV image position event and averaged incoming pupil position

errors over the specified cadence interval, it will concatenate them into a boresight error vector,

( )

where , , , and represent the pupil error x and y components and

the image error x and y components in the wavefront sensor coordinate system.

If the aO Engine is not performing one of the two aforementioned calibration procedures, then it will

place the pupil position errors into the boresight error vector with zeros for , and .

Once the boresight error vector has been calculated, it must be derotated into the M6 coordinate frame for

reconstruction. M6 is after the altitude rotation, so the rotation angle between M6 and the HOAO pupil is,

,

and the boresight error vector must be derotated,

( ) ,

where is the mean rotation angle estimated from the telescope start and end angles contained in the

pupil position event,

,

and is the boresight rotation matrix,

( ) (

),

The next step in boresight reconstruction uses to calculate M3 and M6 motions that will correct the

telescope pupil alighnment. is a stored constant that defines the zero-point of the M6 derotation.

5.3.2 Boresight reconstruction

The boresight reconstructor is a matrix multiplication,

(

) (

) (

),

where , , , and are the position errors for M3 α-tilt and β-tilt and M6

α-tilt and β-tilt in M6 coordinates. The Rbore matrix is the boresight reconstruction matrix and ,

D R A F T

aO Engine CDD


, , and represent the pupil error x and y components and the image error x and y

components in M6 coordinates.

The boresight reconstruction matrix is calculated from the inverse of the boresight sensitivity matrix.

Assuming a linear relationship between the position of M3 and M6 and the pupil and image position

errors,

(

) (

) ,

where Hbore is the boresight sensitivity matrix and n is a vector of Gaussian white noise, then the optimal

solution is the boresight reconstructor shown above with

( ) .

Calculation of Hbore and Rbore is done as part of the Active Optics calibration process described in section

5.4. It is expected that this calculation will be done very infrequently. These matrices will be stored in the

CSF Bulk Data Store so they can be loaded as needed by the Active Optics Engine Controller.

5.3.3 M3 coordinate rotation

As mentioned in section 5.1, M3 and M6 rotate relative to each other so the correction sent to M3 must be

rotated into the M3 local coordinate system before it is applied. This is done by rotating the M3

commands by 90 minus the altitude angle,

( ) ,

where is the mean of the starting and ending altitude angles of the telescope, as reported in the pupil

error event,

,

and is a rotation matrix,

( ) (

).

is a stored constant that serves to define the zero-point of the altitude derotation.

The final offset position vectors, and are each multiplied by a final gain factor and then

sent to the FOCS over the CSF event network.

5.4 CALIBRATION

Calibration routines for the aO Engine are designed to empirically measure sensitivities within the

telescope. Initially the sensitivity matrices and other parameters within the aO Engine will be populated

from simulated values but measuring based upon the as-built telescope will generally improve the

accuracy of the aO Engine. Sensitivity matrices and aO Engine parameters should not change

significantly during the course of operations unless a significant component within the telescope changes.

As such, these matrices will be calculated and refined during IT&C and are then expected to not need

adjustment for a long time. Maintenance and recalculation of the aO Engine control matrices is the

responsibility of the WFC specialist.

Calculation of system sensitivity matrices requires moving active mirrors and measuring the resulting

quasi-static wavefront and alignment errors, either using the LOWFS or HOAO/HOWFS. Therefore, in

order to perform these calibrations, the telescope must be dedicated for use by the WFC specialist. Any

D R A F T

aO Engine CDD


mirrors that will be moved need to be set to active mode by the TCS. The WCCS is unable to issue these

commands so it will be the WFC specialist’s duty to ensure the correct configurations are set from the

OCS before performing these calibrations. If the configuration to put the WCCS into WFC mode:

calibrate is initiated from the OCS level (GUI or OP script), the TCS will automatically put the active

mirror controllers into the appropriate configurations. If the WCCS is configured from the WCCS

engineering GUI then the active mirror controllers must be manually configured from the telescope

operator GUI or the TCS engineering GUI.

5.4.1 Boresight reconstruction matrix

The boresight reconstruction matrix is built from the pseudo-inverse of the boresight sensitivity matrix. In

general, the boresight sensitivity matrix should be well-conditioned but a regularizing term can be used in

the pseudo-inverse to improve solution robustness.

The boresight sensitivity matrix is built by perturbing M3 and M6 about their nominal positions and

measuring the pupil position and image position responses to the perturbations. The minimum increment

used for this perturbation, , is a user-set parameter that can be changed from the aO Engine engineering

GUI.

The boresight sensitivity matrix is built as follows:

1. The telescope is pointed at the sun and the FOCS is set to active mode.

2. WFC is set to WFC mode Calibrate with boresight reconstruction matrix calibration selected and

an inverted point source is inserted at the GOS.

3. The WFC boresight calibration is executed to bring M3 and M6 to their positions of best

alignment.

4. The HOAO is configured to send pupil position measurements to the aO Engine at 1 Hz. The

script running the boresight reconstruction matrix calibration requests centroid measurements

from the CV at 1 Hz.

5. The aO Engine averages np pupil position measurements and ni image centroid measurements,

then rotates them into the co-moving coordinate frame, as described in section 5.2.1, to obtain

the zero-point vector,

(

)

,

where and represent the average pupil position error in x and y and and

represent the average image position error in x and y.

6. The aO Engine sends a perturbation, a1, to the M3 and M6 mirrors. For the purposes of this

calibration, commands to M3 and M6 are expressed as vectors of the form,

(

),

where and are offset errors to M3 in the α and β rotation axes and and

are offset errors to M3 and M6 in the α and β rotation axes. Perturbation vectors represent

columns of the perturbation matrix, A, which is defined as,

D R A F T

aO Engine CDD


( | | | ) ( | | ),

where I is a 4 x 4 identity matrix.

7. The aO Engine waits for the mirrors to move, then averages np pupil position measurements and

ni image centroid measurements, and rotates the mean values into the co-rotating coordinate

reference frame to obtain the response vector,

(

)

,

and saves the result.

8. Steps 6 and 7 are repeated with perturbation vectors a2 through a12 and the response vectors e2

through e12 are saved. Response vectors that correspond to M3 movements must be derotated by

altitude, azimuth, and coudé angles while vectors that correspond to M6 movements must be

derotated only by azimuth and coudé angles.

9. The response vectors are concatenated into the response matrix E, ( | | | )

( | | | ),

and the boresight sensitivity matrix, Hbore, is computed,

( )

.

10. Finally, the boresight reconstruction matrix is computed,

( ) ,

and stored in the CSF Bulk Data Store.

5.4.2 Wavefront sensitivity matrix

The wavefront sensitivity matrix maps perturbations of M1 and M2 to corresponding Zernike or M1

natural modes measured by the LOWFS. The aO Engine must keep track of a minimum of two wavefront

sensitivity matrices, one for each modal basis. Calculation of each sensitivity matrix follows the same

procedure with the only difference between them being the modal basis used for LOWFS measurements.

The minimum increments used for this perturbation, Z, x and , are user-set parameters that can be

changed from the aO Engine engineering GUI.

Note: calculation of a wavefront sensitivity matrix may take close to an hour due to the length of time

required for each measurement.

A wavefront sensitivity matrix is built as follows:

1. The M1CS, TEOACS, and FOCS are set to active mode.

2. WFC is set to WFC mode Calibrate and the telescope is pointed at a low-contrast area of the sun.

3. An inverse pinhole is inserted and GOS and the WFC boresight calibration is executed to bring

M3 and M6 to their positions of best alignment. The pinhole is then removed and the telescope is

pointed to a high-contrast area of the sun.

4. The aO Engine boresight correction is enabled so that the pupil is stabilized on the WFC sensors.

5. The LOWFS is configured to send wavefront measurements to the aO Engine every 30 seconds.

D R A F T

aO Engine CDD


6. The aO Engine receives a measurement from the LOWFS, rotates it into the co-moving

coordinate system using the rotation matrix in section 5.1, and saves it as the zero-point vector,

(

),

,

where represents the ith element of the LOWFS measurement. In the Fringe Zernike basis

will refer to the (i-4)th Zernike coefficient and in the M1 modal basis it will refer to the i

th M1

natural mode coefficient. If desired, this zero-point vector can also be saved to the calibration

database to be used as in the wavefront reconstruction step, as shown in section 5.2.3.

7. The LOWFS is configured to stop taking wavefront measurements and clear any ongoing

wavefront measurements.

8. The aO Engine sends a perturbation, a1, to the M1 and M2 mirrors. For the purposes of this

calibration, commands to M1 and M2 are expressed as vectors of the form,

(

),

,

where ( )T is a 20-element vector of M1 bending mode commands and

( )T is a 6-element vector of M2 rigid body commands.

Perturbation vectors represent columns of the perturbation matrix, A, which is defined as, ( | | | )

( | | | ) ( | | ),

where B is a 26 x 26 diagonal matrix with diagonal elements,

( ).

9. The aO Engine waits for the mirrors to move to their requested positions, then configures the

LOWFS to send wavefront measurements to the aO Engine every 30 seconds.

10. The aO Engine receives a measurement from the LOWFS, rotates it into the co-moving

coordinate system using the rotation matrix in section 5.1, and saves it as a response vector,

(

) .

11. Steps 7-10 are repeated with perturbation vectors a2 through a78 and the response vectors e2

through e78 are recorded.

12. The response vectors are concatenated into the response matrix E, ( | | | )

( | | | ),

and the wavefront sensitivity matrix, HM1M2, is computed and stored in the CSF Bulk Data Store,

( )

.

D R A F T

aO Engine CDD


5.4.3 Wavefront reconstruction matrices

Wavefront reconstruction matrices for the aO Engine are built from either of the two wavefront sensitivity

matrices, which can be empirically measured using the calibration procedure in section 5.4.2. Initially,

calculation of the wavefront reconstruction matrices will be done offline by the WFC specialist. The

wavefront sensitivity matrices will be manually extracted from the CSF Bulk Data Service, used to

compute the reconstruction matrices, then the reconstruction matrices will be manually loaded in to the

Bulk Data Service.

The wavefront reconstruction calculation uses two types of matrices, FCLS and NPF, as described in

section 5.2.3. Each of these methods can be done in either the Fringe Zernike modal basis or the M1

natural mode basis, leading to a total of four total wavefront reconstruction matrices needed for aO

Engine operation.

The following subsections describe the methods used for calculating the two types of reconstruction

matrix. Each matrix type can be constructed for either of the two wavefront modal bases, with the modal

basis of the reconstruction matrix set by the choice of which wavefront sensitivity matrix is used.

5.4.3.1 FCLS reconstruction matrix

A FCLS reconstruction matrix is constructed from the following parameters, which are loaded from the

calibration database:

, the wavefront sensitivity matrix for the selected wavefront modal basis.

, the M1 and M2 force sensitivity matrix for the selected wavefront modal basis. is

a 124 x 26 matrix that maps combined M1 and M2 command vectors, as seen in section 5.4.2 step

8, to their corresponding actuator forces. The matrix is constructed using the M1 force sensitivity

matrix, , provided by the M1 cell vendor, and the M2 force sensitivity matrix, , which

will be set by the WFC specialist to provide the necessary constraints on M2,

(

*.

Initially, will be set to the Identity matrix but it may be modified if necessary.

, the wavefront reconstruction force penalty matrix. This matrix will be set by the WFC

specialist and stored in the CSF Bulk Data Store. It is independent of the wavefront modal basis

and is a 124 x 124 diagonal matrix whose first 118 diagonal entries serve to penalize specific M1

actuators. Initially the penalty values of each actuator will be set to the same value but they may

be modified based on test results. The last 6 diagonal values of the penalty matrix serve to

penalize M2 motion and these will serve to stabilize the solutions based on simulation results.

Once these three matrices have been retrieved from the calibration database, the FCLS reconstruction

matrix for the chosen wavefront basis is calculated,

(

)

,

and stored in the CSF Bulk Data Store.

5.4.3.2 NPF reconstruction matrix

A NPF reconstruction matrix is created from the following parameters, which are loaded from the

calibration database.

, the wavefront sensitivity matrix for the chosen wavefront modal basis.

D R A F T

aO Engine CDD


, the wavefront reconstruction modal penalty matrix for the selected wavefront modal basis.

These matrices will be set by the WFC specialist and stored in the CSF Bulk Data Store. They are

23 x 23 diagonal matrices whose first 20 diagonal entries serve to penalize specific M1 bending

modes and whose last 3 diagonal entries serve to penalize M2 NPF motions. NPF motions are z-

translation, and α and β rotation about the center of curvature of M2’s parent mirror.

, the neutral-pointing transformation matrix. This 26 x 23 matrix will be stored in the CSF

Bulk Data Store and is independent of the wavefront modal basis selected. It is constructed as

follows,

(

)

where is a 3 x 3 matrix of zeros, is a 17 x 17 identity matrix, and is a 6 x 3 matrix

that maps NPF-constrained M2 motion to 6-axis hexapod commands. The matrix will be

calculated by the WFC specialist based on optical models of DKIST.

The next step is to calculate , the NPF sensitivity matrix,

,

and use the result to calculate the NPF reconstruction matrix,

(

)

.

The new reconstruction matrix for the chosen wavefront modal basis is then stored in the CSF Bulk Data

Store.

5.4.4 Pupil position

Pupil position measurements are received from the HOAO in the form of four subaperture intensity

measurements. A quad-cell method is used to calculate the pupil position error based on the intensity

measurements, as discussed in section 5.3.1. The gains, gx and gy, and offsets, x0 and y0, used in the quad-

cell formula must be carefully calibrated because they affect the accuracy of the pupil position

measurement. Initially, these values will be calculated based on simulation but this calibration offers a

way to empirically measure them based on the actual system.

In order to perform this calibration, the telescope must not be performing any other observations. It is

estimated that this calibration will require approximately ten minutes but, once calculated, should only

need to be repeated on the rare occasion that the HOWFS subapertures used to sense pupil position are

changed or become compromised in some way.

The telescope should be pointed to the sun and a HOWFS gain calibration should be performed.

Afterwards, the WFC specialist should check the HOWFS status screen to make sure the HOWFS is

sufficiently illuminated and adjust the exposure time so that the HOWFS pixel wells are approximately

80% full with no saturated pixels.

5.4.4.1 Pupil position gains and offsets

This calibration requires a user-set parameter, x, that sets the step size of the pupil motion. Typically, x

should be approximately 0.25 but may be changed based on results during IT&C. Pupil motion is

measured in units of HOWFS subapertures. The WFC specialist will manually steer M3 so that the pupil

is centered at [-2x, 0] relative to the HOWFS. When the WFC specialist informs the aO Engine that the

D R A F T

aO Engine CDD


pupil is in position, the aO Engine takes 5 consecutive subaperture intensity measurements from the

HOWFS, averages them and calculates ,

( ) ( )

,

where i1, i2, i3, and i4 are the four mean subaperture intensities from the HOWFS. This value is saved for

later use.

The WFC specialist then manually steers M3, using the FOCS engineering GUI, so that the pupil is

centered at [-x, 0] relative to the HOWFS. Again, the aO Engine averages 5 consecutive subaperture

intensity measurements from the HOWFS and calculates using the same formula. The process is

repeated three more times to get , , and corresponding to pupil positions [0,0], [x, 0], and [2x,

0].

The 5 measured x values are then concatenated into the vector ( ) , and the reciprocal

of the slope of the best-fit line is calculated to find ⁄ . Where

(

) ( ) ,

and ( ), 1 is a 5-element vector of ones, and ( ) . The intercept of the

best-fit line is also calculated and saved as the x-offset, .

The y-axis gain, gy, and y-axis offset, y0, are calculated in the same way as the x axis gain and offset

except the pupil is moved along the y axis instead of the x axis and the y-position quad cell formula is

used instead of the x-position formula.

D R A F T

aO Engine CDD


6 SOFTWARE DESIGN

6.1 OVERVIEW

The Active Optics (aO) Engine software supports two main functions: 1) the receipt and processing of

wavefront sensor data or deformable mirror position data to send corrections to the M1 Control System

and the Top End Optical Assembly (TEOA) Control System for quasi-static wavefront control, and 2) the

receipt and processing of pupil position data to send corrections to the Feed Optics Control System

(FOCS) for telescope boresight stabilization. The Active Optics control software will be implemented

using the DKIST Common Services Framework as specified in SPEC-0022, Common Services

Framework: Users’ Manual, and will be written according to DKIST software concepts and requirements

as outlined in SPEC-0005, Software and Controls Requirements, and SPEC-0013, Software Concepts

Definition.

Figure 7: Active Optics System Context

The Active Optics Engine, typically referred to as the aO Engine, is one of the five subsystems of the

Wavefront Correction Control System (WCCS), which is illustrated above in Figure 7. A context diagram

of the aO Engine software is illustrated below in Figure 8. The aO Engine is implemented as a single CSF

controller that receives event inputs from the HOAO and LOWFS WFC subsystems and generates output

events for the M1CS, TEOACS and FOCS to send corrections for quasi-static wavefront errors and for

boresight stabilization. The aO Engine also receives status events from the three mirror control systems,

M1CS, TEOACS, and FOCS for archive purposes.

Observatory Control System

(OCS)

Telescope Control System (TCS)

Wavefront Correction Control

System (WCCS)

Limb Tracker (LT)Context Viewer

(CV)

Low-Order Wavefront Sensor

(LOWFS)aO Engine

High Order Adaptive Optics

(HOAO)

D R A F T

aO Engine CDD


Figure 8: aO Engine software context diagram.

6.2 USE CASES

In describing the use cases for the aO Engine, it is important to understand that it is just one component of

the larger WCCS system. It receives commands from the WCCS originated by operator action at the OCS

level or from the WCCS GUI. Technically this makes the operator the “actor” for these use cases, but it is

conceptually simpler to illustrate and discuss these use cases from the perspective that the WCCS is the

actor. During normal operation the aO Engine responds only to commands and configurations sent by the

WCCS (for engineering purposes it can also be controlled from its engineering GUI). Its operational

mode is based on the overall WFC mode of the WCCS, as defined in SPEC-0129, WCCS Operational

Concepts Definition. The mode is passed down to each WCCS subsystem using the attribute

atst.tcs.wccs.<subsystem>.mode, where <subsystem> represents one of the 5 WCCS subsystems shown

above in Figure 7 (in the case of the aO Engine, this attribute is atst.tcs.wccs.ao). The seven WFC modes

are: off, idle, calibrate, diffractionLimited, seeingLimitedOnDisk, seeingLimitedCoronal, and

limbTracking. How the aO Engine behaves in these WFC modes is shown in the table below.

WFC Mode Meaning for aO Engine

off The aO Engine is not running

D R A F T

aO Engine CDD


WFC Mode Meaning for aO Engine

idle The aO Engine is initialized but is not active.

calibrate The aO Engine is used in the telescope boresight calibration. Calibrate mode

may also be used to calibrate the aO Engine’s internal matrices.

diffractionLimited The aO Engine receives and processes wavefront sensor events and pupil

position events from the HOAO and sends output events to the M1CS,

TEOACS and FOCS. The aO Engine receives status events from these systems

as well.

seeingLimitedOnDisk The aO Engine receives and processes wavefront sensor events from the

LOWFS and pupil position events from the HOAO and sends output events to

the M1CS, TEOACS and FOCS. The aO Engine receives status events from

these systems as well.

seeingLimitedCoronal The aO Engine is initialized but is not active.

limbTracking The aO Engine is initialized but is not active.

Table 4: The meaning of the various WFC modes for the aO Engine.

The main purposes of the aO Engine are to support correction of quasi static wavefront errors and

boresight stabilization during diffraction-limited and seeing-limited on-disk observing. These correspond

to the WFC science use cases OPM-WFC1 and OPM-WFC2, respectively, as outlined in SPEC-0129.

The aO Engine supports the calibration mode to assist in the telescope boresight alignment and when the

calibration of its own internal matrices is required. For the remaining modes, the aO Engine is either in an

idle state or off. Finally, the aO Engine must support basic startup and shutdown activities. All five of

these use cases are discussed in further detail in this section.

In addition to these use cases, the operator (Telescope Operator or WFC Specialist) may change the

offload basis for the WFC system at any time at his or her discretion. The details of how that is handled

and the impact on the aO Engine are discussed in this section as well.

A UML Use-Case diagram for the aO Engine is shown below.

D R A F T

aO Engine CDD


Figure 9: aO Engine Use case diagram

6.2.1 Startup

The ao Engine will startup automatically when the host computer is booted. This will cause the CSF

environment to be started up, all aO Engine software components to be deployed and sequenced through

their lifecycle initialization states. When this is complete, all of the aO Engine software components will

be deployed and running. The host computer that runs the aO Engine software will be specified such that

the system will be operational and ready to receive and act upon commands within 5 minutes of a cold

power-off start (the computer specifications for the WFC System are listed in Section 4.5.5 of SPEC-

0178, WFC Common Items CDD).

At this point, the aO Engine software is up and running, but the aO Engine as a system must still be

started up. To accomplish this, the WCCS sends a CSF Configuration instructing the aO Engine to go to

the “idle” WFC mode along with a command for it to run its startup sequence. During the startup

sequence, the following actions take place:

D R A F T

aO Engine CDD


The default parameters are downloaded from the CSF Property Database and the CSF Bulk Data

Store.

The aO Engine processing threads are started and wait patiently at the top of their processing

loops.

The aO Engine subscribes to the status events from the M1CS, TEOACS and FOCS.

A monitoring thread is started that checks to make sure each subscribed event has arrived by a

user selectable timeout. If an event does not arrive within the prescribed time interval, the

monitor thread takes action using the health and alarm services as described below.

6.2.2 Diffraction Limited Observations

The WCCS instructs the aO Engine to transition to this mode by sending a CSF configuration containing

the WFC mode attribute set to “diffractionLimited”. In this mode, the aO Engine processes wavefront

sensor input data from the HOAO and computes corrections to send to the M1CS and TEOACS as CSF

events. It also processes pupil position data from the HOAO and sends corrections to the FOCS. Finally,

the aO Engine subscribes to status events from these TCS sub-systems and logs the data using the CSF

Archive Service, which allows for high-speed recording of CSF Attributes (see SPEC-0022).

6.2.3 Seeing Limited On-Disk Observations

The WCCS instructs the aO Engine to transition to this mode by sending a CSF configuration containing

the WFC mode attribute set to “seeingLimitedOnDisk”. In this mode, the aO Engine processes wavefront

sensor input data from the LOWFS and computes corrections to send to the M1CS and TEOACS as CSF

events. It also processes pupil position data from the HOAO and sends corrections to the FOCS. Finally,

the aO Engine subscribes to status events from these TCS sub-systems and logs the data using the CSF

Archive Service.

6.2.4 Calibrations

The aO Engine supports the following calibrations:

Telescope Boresight Alignment Calibration

Boresight Sensitivity Matrix Calibration

Wavefront Sensitivity Matrix Calibration

Pupil Position Gain and Offset Calibration

The Telescope Boresight Alignment Calibration is used to calibrate the positions of M3 and M6 for

optimal alignment of the telescope. This is different from the boresight alignment correction performed

by the aO Engine, which applies offsets to M3 and M6 in near-real-time to keep the boresight aligned

during normal operation. The two sensitivity matrix calibrations generate and store the data required to

calibrate the reconstruction matrices used by the aO Engine to perform wavefront corrections and

boresight alignment corrections. Finally, the pupil position calibration is used to calibrate the offset and

gain associated with the pupil position measurements. Overviews of each calibration are presented in this

section. A detailed discussion of the boresight alignment calibration is presented in the description of the

use case details later in the document.

6.2.4.1 Boresight Alignment Calibration

The Boresight Alignment Calibration is performed to align the boresight of the telescope. The procedure

requires both the image position measurement capability of the Context Viewer (CV) and the pupil

sensing capability of the HOAO. Because it requires the simultaneous use of the HOAO, CV and aO

Engine, the procedure is scripted from the WCCS. At the aO Engine level, pupil position measurements

D R A F T

aO Engine CDD


are received from the HOAO and image position measurements are received from the CV. These

measurements are asynchronous with respect to each other. When both measurements have been received,

the aO Engine concatenates them into a single vector which is multiplied by the boresight reconstruction

matrix to produce the corrections for M3 and M6 in the FOCS. The corrections are sent to the FOCS

using a CSF event. These corrections are calculated by the boresight stabilization thread described below.

The boresight alignment calibration procedure is repeated by the WCCS script as needed.

6.2.4.2 Boresight Sensitivity Matrix Calibration

This calibration procedure computes the sensitivity of the HOAO pupil measurements and CV image

position measurements (centroids) to small perturbations in the positions of M3 and M6. These

measurements are stored in the CSF Archive Database along with timestamps and telescope position

information, which are used later to calculate the Boresight Sensitivity Matrix and its pseudo-inverse, the

Boresight Reconstruction Matrix. These calculations are performed after the fact, outside of the CSF

control environment, using customized software tools provided by the WFC team. The results saved to

the CSF Bulk Data Service for later use by the aO Engine. The measurement process is described in detail

in Section 5.4.1 and is not repeated here. The calibration procedure will be implemented as a Jython script

to be executed by the aO Engine. Initially the procedure will simply save the HOAO pupil measurements

and CV image position measurements along with telescope position data to be analyzed later. As we get

more experience in the computation of the sensitivity and reconstruction matrices we will automate more

of the procedure in the script.

6.2.4.3 Wavefront Sensitivity Matrix Calibration

This calibration procedure is performed to compute the sensitivity of the LOWFS wavefront

measurements to small perturbations in the positions of M1 and M2 measured in both Zernike and natural

mirror modes. These measurements are stored in the CSF Archive database along with timestamps and

telescope position information, which are used later to calculate the Wavefront Sensitivity Matrix and its

pseudo-inverse, the Wavefront Reconstruction Matrix. These calculations are performed after the fact,

outside of the CSF control environment, using customized software tools provided by the WFC team. The

results saved to the CSF Bulk Data Service for later use by the aO Engine. The measurement process is

described in Section 5.4.2 while the reconstruction algorithms are described in Section 5.4.3. The details

are not repeated here. The calibration procedure will be implemented as a Jython script to be executed by

the aO Engine. Initially the procedure will simply save the LOWFS wavefront measurements along with

telescope position data to be analyzed later. As we get more experience in the computation of the

sensitivity and reconstruction matrices we will automate more of the procedure in the script.

6.2.4.4 Pupil Position Gain and Offset Calibration.

This calibration procedure calculates the gain and offset used in the pupil position measurements. The

quad cell formula has a response that varies from -1 to +1 in a sigmoidal fashion. These values must be

multiplied by a gain factor to convert to meaningful physical units. The pupil motion is to be measured in

units of HOWFS subapertures. The following steps are performed during the calibration:

The WFC specialist steers M3 manually to position the pupil so it is centered at [-2δx, 0] relative

to the HOWFS, where δx has a default value of 0.25 subapertures

The next 5 pupil position measurements from the HOWFS are acquired and averaged

The x pupil position is calculated according to the quad cell formula as shown in Section 5.4.4.1

and the value saved

The above steps are repeated for pupil positions corresponding to [-δx, 0], [0, 0], [δx, 0], and

[2δx, 0], relative to the HOWFS

The gain is computed as the inverse of the slope from a least squares fit of the data

D R A F T

aO Engine CDD


The offset is computed as the zero crossing of the least squares line fit

The entire process is repeated for y axis

The x and y gain and offset values are sanity checked and then saved under user control to update

the property database entries for these values

6.2.5 Shutdown

Shutdown of the aO Engine may be initiated from the aO Engine Engineering GUI or from the WCCS by

sending a configuration with a WFC mode attribute set to “off”. During the shutdown, the aO Engine will

perform the following actions:

Interrupt and halt both the boresight and wavefront processing threads.

Terminate all active CSF event subscriptions.

Initiate the CSF lifecycle shutdown sequence, which causes the aO Engine to be shut down.

The hardware may be shut down if desired.

6.2.6 Change in Modal Basis

During normal observing in either Diffraction-Limited On-Disk mode or Seeing-Limited On-Disk mode,

the LOWFS, HOAO and aO Engine use a consistent modal basis for the communication of wavefront

error information with each other. The modal basis may be set to either Zernike modes or M1 natural

mirror modes, with the default being Zernike modes. The mode may be changed by the Operator, from

the OCS GUI or an OP Script, or by the WFC Specialist from the WCCS Engineering GUI. The mode

change configuration is sent to the WCCS, which propagates it to the three subsystems.

The aO Engine maintains internal wavefront error calculations that are updated over many iterations.

These partial calculations are maintained in the current modal basis selected for the system. If a change in

modal basis occurs, any partial calculations must be converted to the new modal basis before additional

computations may continue. The aO Engine manages these mode changes in two ways:

By maintaining reconstruction matrices for both Zernike and natural mirror modes resident in

memory so they can be used immediately when needed. When a mode change occurs, the active

reconstruction matrix variable is changed to point to the matrix for the new mode selection.

By maintaining two conversion matrices that are used to convert the internal partial calculations

from one mode to the other (Zernike natural or natural Zernike). This conversion is

accomplished immediately upon notification of the mode change, before any additional

calculations are accomplished.

By communicating the current mode in use to the M1CS, which can accept mirror offsets in

either Zernike or natural mirror modes.

While changing the modal basis in the middle of an observation is unlikely to occur, it could occur during

IT&C or engineering testing and the aO Engine must be able to support it. Moreover, the wavefront

correction process (described in more detail in the sections that follow) checks each wavefront error

estimate that is received to make sure it is in the correct modal basis. If it is not in the correct modal basis,

the aO Engine converts it to the correct basis and updates its health and alarm status appropriately,

depending on whether the problem is transient or chronic.

D R A F T

aO Engine CDD


6.3 DETAILED DESIGN

6.3.1 aO Engine Controller

The aO Engine is implemented as an extension of the CSF/Base Script Interpreting Controller class with

custom code to implement the desired sequencing of tasks for the use cases described earlier. It has two

persistent threads that are used for the main computational tasks: one for the wavefront corrections for the

quasi-static alignment, and the other for the boresight stabilization. Both of these threads spend most of

their time sleeping at the top of their computation loop, waiting for inputs. When an input arrives they

wake up, check their status flags to determine if processing is needed, process the data and send output

events containing the results to the appropriate TCS control systems. Once they have completed sending

the output events, the threads return to the top of their computation loops and wait for additional inputs.

Simultaneously while the computational threads are running, the aO Engine listens for status events from

the various TCS systems. When a status event arrives, the aO Engine updates any internal variables

needed by the computational threads and logs the data to the CSF Archive database if requested. The

event subscriptions use a callback mechanism for notification of the event arrival. Because the

computations used to update the internal variables and log the data to the Archive Service are so small,

they are performed as part of the callback (i.e., using the callback’s thread). This greatly simplifies the

design, as it eliminates the need for maintaining a number of persistent threads to process the events. The

script interpreting capabilities of the controller are used to implement the Calibration Script Engine which

executes the sensitivity matrix calibration procedures described earlier. These calibration procedures are

implemented as Jython scripts. The design concept for the aO Engine is illustrated in Figure 10 below.

For clarity, the connection to the WCCS and other CSF entities are not shown.

D R A F T

aO Engine CDD


Figure 10: Block diagram of the aO Engine internals.

Flowcharts for each of the computational threads are shown below in Figure 11 and Figure 12 (wavefront

correction thread) and Figure 13 (boresight alignment thread).

D R A F T

aO Engine CDD


Figure 11: A flowchart for the wavefront correction computation thread (part 1).

Start

Wait for wavefront

measurements

HOAO/LOWFS wavefront

measurements

Update due?No

Yes

Rotate into M1/M2 coordinate frame.

M1/M2 status events

Check Status ID Match, Mirrors

In Position

Compute significance and reliability of each

mode based on thresholds

Go to A

Update internal calculations

B

C

D R A F T

aO Engine CDD


Figure 12: A flowchart for the wavefront correction computation thread (part 2).

Calculate total WFE. Test if total WFE ≥ max allowable. Set health and alarm status as

appropriate.

Multiply extracted modes by

reconstructor

Number of extracted modes

> 0?

Yes

No

Send corrections to M1CS and TEOACS

A

Extract mode coefficients that are

significant and reliable. Zero accumulators for

all modes.

To B

To C

D R A F T

aO Engine CDD


Figure 13: A flowchart for the boresight stabilization thread.

Both of these loops start by waiting for their associated mirror status events to show that the mirrors are

“In Position”. Also, if this is not the first time through the loop, the mirror status events are checked to

make sure the unique ID contained in the event matches the unique ID of the last mirror offset event sent

by the aO Engine. The execution of the loop will not proceed until these conditions are satisfied, or a

Start

Calibration?

Wait for both pupil and image measurements

Wait for pupil measurement

Yes No

Rotate M3 correction into M3 coord frame. Send

corrections to FOCS

Check Status ID Match, Mirrors

In Position

M3/M6 status events

Alignment criteria

satisfied?Yes

No

Rotate measurements into

M6 coord frame. Multiply by

reconstructor.

HOAO pupil measurements

CV image measurements

D R A F T

aO Engine CDD


timeout occurs. If a timeout occurs, it is counted and logged and execution of the loop proceeds. If

chronic timeouts occur, the aO Engine will raise an alarm.

6.3.1.1 Attributes

The following attributes are received and acted upon by the aO Engine controller.

Name Type Comment

atst.tcs.wccs.ao

.mode String The current WFC mode

.startup Boolean Instructs the aO Engine to go through its startup sequence

.shutdown Boolean Instructs the aO Engine to go through its shutdown

sequence

.calibrate String The specific calibration task to be performed

.offloadBasis String The modal basis used for the aO Engine calculations

.wfeThresh Float[] The significance threshold for a modal wavefront error

estimate

.snrThresh Float[] The SNR threshold for a modal wavefront error estimate

(reliability threshold)

.lutCheckThresh Float The total allowable RMS wavefront error threshold,

relevant for indicating if LUTs may be anti-correlated to

telescope trajectory

.lutCheckIters Int The maximum number of iterations the total RMS

wavefront error is allowed to exceed the threshold before

operator notification occurs

.wfcCadence String The cadence of the wavefront correction updates

.wfcZernReconMat String The name of the reconstruction matrix to be used with

wavefront measurements in the Zernike basis

.wfcNatReconMat String The name of the reconstruction matrix to be used with

wavefront measurements in the natural mirror basis

.wfcZernRotMat String The name of the rotation matrix used to rotate wavefront

measurements in the Zernike basis into the M1/M2

coordinate frame

.wfcNatRotMat String The name of the rotation matrix used to rotate wavefront

measurements in the natural mirror basis into the M1/M2

coordinate frame

.zern2Nat String The name of the matrix used to convert modal vectors

from Zernike basis to natural mirror basis

.nat2Zern String The name of the matrix used to convert modal vectors

from natural mirror basis to Zernike basis

D R A F T

aO Engine CDD


.boreRotMat String The name of the rotation matrix used to rotate boresight

measurements into the M6 coordinate frame

.pupilOffsetThresh Float The maximum pupil offset allowed before a correction is

required

.imageOffsetThresh Float The maximum image offset allowed before a correction

is required

.boreReconMat String The name of the boresight reconstruction matrix to be

used

.m1DeltaZ Float The Zernike coefficient offset used to perturb the M1

mirror shape during aO Engine calibrations

.m2DeltaPhi Float The angular offset used to perturb the M2 mirror position

during aO Engine calibrations

.m2DeltaX Float The translational offset used to perturb the M2 mirror

positions during aO Engine calibrations

.m3m6DeltaPhi Float The angular offset used to perturb the M3 and M6 mirror

positions during aO Engine calibrations

.logEvents Boolean Used to indicate whether the events used in the aO

Engine, both subscribed and published, should be

recorded

6.3.1.1.1 .mode

Data Type: String

Units: N/A

Valid Values: off | idle | calibrate | diffractionLimited | seeingLimitedOnDisk | seeingLimitedCoronal

| limbTracking

Default Value: None

The .mode attribute represents the current operational mode of the WCCS and is used to control the

behavior of the aO Engine.

6.3.1.1.2 .startup

Data Type: Boolean

Units: N/A

Valid Values: true | false

Default Value: None

The .startup attribute is used to command the aO Engine to go through its startup sequence: to download

all default parameters from the CSF Property Database and Bulk Data Store, to start the wavefront and

D R A F T

aO Engine CDD


boresight processing threads, and to subscribe to the various TCS status events for the M1, M2, M3, and

M6 mirrors.

6.3.1.1.3 .shutdown

Data Type: Boolean

Units: N/A

Valid Values: true | false

Default Value: None

The .shutdown attribute is used to command the aO Engine to go through its shutdown sequence: to

interrupt and halt the wavefront and boresight processing threads, terminate all active subscriptions, and

initiate the CSF lifecycle shutdown sequence for all the CSF components in the CV.

6.3.1.1.4 .calibrate

Data Type: String

Units: N/A

Valid Values: boreAlign | boreSens | wavefrontSens | pupilPosn

Default Value: None

The .calibrate attribute is used to indicate what particular type of calibration is to be performed. If this

attribute is present, calibrations will be performed only if the WFC mode is set to calibrate. If both

attributes are present, the appropriate calibration procedure will be executed by the aO Engine.

6.3.1.1.5 .offloadBasis

Data Type: String

Units: N/A

Valid Values: zernike | mirrorModes

Default Value: None

The .offloadBasis attribute sets the basis to be used in converting the cross-correlation shift measurements

into wavefront estimates. The .offloadBasis attribute is used by the IPM to determine which

reconstruction matrix should be used in the final step of the wavefront estimation. The IPM will have

both Zernike and mirrorMode reconstructors loaded so this change can be made quickly.

6.3.1.1.6 .wfeThresh

Data Type: Float

Units: nm RMS of wavefront error

Valid Values: value ≥ 0

Default Value: TBD

D R A F T

aO Engine CDD


The .wfeThresh attribute is used to specify the threshold level at which a wavefront modal coefficient is

deemed significant. This value is used by the wavefront processing thread as one of the factors in

determining if a wavefront correction should be made.

6.3.1.1.7 .snrThresh

Data Type: Float

Units: N/A


Default Value: TBD

The .snrThresh attribute is used to specify the threshold level at which the SNR of a wavefront modal

coefficient will be deemed reliable. This value is used by the wavefront processing thread as one of the

factors in determining if a wavefront correction should be made.

6.3.1.1.8 .lutCheckThresh

Data Type: Float

Units: N/A


Default Value: TBD

The .lutCheckThresh attribute is used to specify the threshold level for the total allowable RMS

wavefront error. If the total RMS wavefront error sent to the reconstructor for processing exceeds this

value for more than some number of user specified iterations then the aO Engine will alert the operator by

changing the lutCheck attribute in its status event to true and setting its health to ill.

6.3.1.1.9 .lutCheckIters

Data Type: Int

Units: N/A


Default Value: 5

The .lutCheckIters attribute is used to specify the maximum number of iterations of the wavefront

correction loop the total RMS wavefront error may exceed the maximum allowable error (specified above

with the .lutCheckThresh attribute) after which the operator is notified by an alarm.

6.3.1.1.10 .wfcCadence

Data Type: Float

Units: Seconds

D R A F T

aO Engine CDD



Default Value: 10

The .wfcCadence attribute is used to specify how frequently wavefront corrections will be made. If set to

a number, say N, then wavefront correction updates will occur every N seconds. If set to zero, then

wavefront corrections will be sent at the same rate as the incoming wavefront measurements. In either

case a correction will only be sent if the significance and reliability thresholds are satisfied.

6.3.1.1.11 .wfcZernReconMat

Data Type: String

Units: N/A

Valid Values: Name of the reconstruction matrix to be downloaded from the bulk data service

Default Value: TBD

The .wfcZernReconMat attribute is used to specify the reconstruction matrix to be used by the wavefront

correction thread when the offload basis is set to Zernike modes. The matrix will be downloaded from the

bulk data service.

6.3.1.1.12 .wfcNatReconMat

Data Type: String

Units: N/A

Valid Values: Name of the reconstruction matrix to be downloaded from the bulk data service

Default Value: TBD

The .wfcNatReconMat attribute is used to specify the reconstruction matrix to be used by the wavefront

correction thread when the offload basis is set to natural mirror modes. The matrix will be downloaded

from the bulk data service.

6.3.1.1.13 .wfcZernRotMat

Data Type: String

Units: N/A

Valid Values: Name of the rotation matrix to be downloaded from the bulk data service

Default Value: TBD

The .wfcZernRotMat attribute is used to specify the rotation matrix to be used by the wavefront

correction thread when the offload basis is set to Zernike modes. The matrix will be downloaded from the

bulk data service.

D R A F T

aO Engine CDD


6.3.1.1.14 .wfcNatRotMat

Data Type: String

Units: N/A


Default Value: TBD

The .wfcNatRotMat attribute is used to specify the rotation matrix to be used by the wavefront correction

thread when the offload basis is set to natural mirror modes. The matrix will be downloaded from the bulk

data service.

6.3.1.1.15 .zern2Nat

Data Type: String

Units: N/A


Default Value: TBD

The .zern2Nat attribute is used to specify the rotation matrix to be used by the wavefront correction

thread when converting wavefront measurements from the Zernike modal basis to the natural mirror

modal basis. This conversion is used to rotate any accumulated internal calculations into the proper basis

when a change in modal basis occurs. The matrix will be downloaded from the bulk data service.

6.3.1.1.16 .nat2Zern

Data Type: String

Units: N/A


Default Value: TBD

The .nat2Zern attribute is used to specify the rotation matrix to be used by the wavefront correction

thread when converting wavefront measurements from the natural mirror modal basis to the Zernike

modal basis. This conversion is used to rotate any accumulated internal calculations into the proper basis

when a change in modal basis occurs. The matrix will be downloaded from the bulk data service.

6.3.1.1.17 .boreRotMat

Data Type: String

Units: N/A


Default Value: TBD

D R A F T

aO Engine CDD


The .boreRotMat attribute is used to specify the rotation matrix to be used by the boresight correction

thread to rotate the pupil offset and image offset measurements into the M6 coordinate frame. The matrix

will be downloaded from the bulk data service.

6.3.1.1.18 .pupilOffsetThresh

Data Type: Float

Units: arc-sec


Default Value: TBD

The .pupilOffsetThresh attribute is used to specify the threshold level at which a pupil position

correction must occur. The boresight processing thread uses this value during both boresight alignment

and pupil stabilization to determine if a pupil position correction should be made.

6.3.1.1.19 .imageOffsetThresh

Data Type: Float

Units: arc-sec


Default Value: TBD

The .imageOffsetThresh attribute is used to specify the threshold level at which an image position

correction must occur. The boresight processing thread uses this value during boresight alignment to

determine if an image position correction should be made.

6.3.1.1.20 .boreReconMat

Data Type: String

Units: N/A

Valid Values: Name of the boresight correction reconstruction matrix to be downloaded from the

bulk data service and used

Default Value: TBD

The .boreReconMat attribute is used to specify the reconstruction matrix to be used by the boresight

correction thread. The matrix will be downloaded from the bulk data service.

6.3.1.1.21 .m1DeltaZ

Data Type: Float

Units: µm

Valid Values: value > 0

D R A F T

aO Engine CDD


Default Value: TBD

The .m1DeltaZ attribute is used to specify the minimum Zernike or natural mirror mode coefficient

perturbation for the modal figure to be applied to the M1 mirror position during Wavefront Sensitivity

Matrix calibrations.

6.3.1.1.22 .m2DeltaPhi

Data Type: Float

Units: Arcsec


Default Value: TBD

The .m2DeltaPhi attribute is used to specify the minimum angular perturbation to be applied to the M2

mirror position during Wavefront Sensitivity Matrix calibrations.

6.3.1.1.23 .m2DeltaX

Data Type: Float

Units: mm


Default Value: TBD

The .m2DeltaX attribute is used to specify the minimum translational perturbation to be applied to the

M2 mirror position during Wavefront Sensitivity Matrix calibrations.

6.3.1.1.24 .m3m6DeltaPhi

Data Type: Float

Units: Arcsec


Default Value: TBD

The .m3m6DeltaPhi attribute is used to specify the minimum angular perturbation to be applied to the

M3 and M6 mirror positions during Boresight Sensitivity Matrix calibrations.

6.3.1.1.25 .logEvents

Data Type: Boolean

Units: N/A

Valid Values: True | False

Default Value: False

D R A F T

aO Engine CDD


The .logEvents attribute is used to indicate whether the events used in the aO Engine, both subscribed and

published, are to be logged. CSF does not provide automatic logging of events, so the logging is

accomplished by using the CSF Archive Service to record the attributes posted to an event. The archive

service is called by the aO Engine immediately after the posting or receipt of an event.

6.3.1.2 Change of modal basis

6.3.1.3 Properties

The CSF properties associated with the aO Engine Controller will be identified and documented during

implementation. They will include the following:

Typical CSF parameters such as csf:threadModel, csf:numThreads, csf:maxThreads,

csf:fullThreadAction, etc.

Any default values needed by the aO Engine system when it first starts up, including default

reconstruction matrices, thresholds, cadences and event monitor rates.

To meet its availability requirements, the aO Engine Controller will be implemented using a CSF

threadModel of “growable”, with the upper bound on threads to be determined during lab integration and

testing.

6.3.2 Events Published by the aO Engine

The aO Engine publishes the following events. Note: Most of these events are defined in detail in ICDs

between the WCCS and several of the TCS subsystems. To avoid double dimensioning these events are

not described in detail here. The reader is referred to the respective ICDs for the details.

Name Rate( Hz) Comment

atst.tcs.wccs.ao

.cStatus 1.0 The general status of the aO Engine

atst.tcs.wccs

.m1FigureError Varies The wavefront correction to be applied to M1. See ICD

1.2-2.3 for details.

.m2PosError Varies The wavefront correction to be applied to M2. See ICD

1.3-2.3 for details.

.m3tiptilterror Varies The boresight correction to be applied to M3. See ICD 1.5-

2.3 for details.

.m6tiptilterror Varies The boresight correction to be applied to M6. See ICD 1.5-

2.3 for details.

6.3.2.1 .cStatus

This event reports the general status of the aO Engine. The attributes are listed in the table below.

Attribute Name Type Units Range Comment

timestamp String N/A N/A A timestamp expressed as a valid

D R A F T

aO Engine CDD


AtstDate format

cMode String N/A

off | idle | calibrate |

diffractionLimited |

seeingLimitedOnDisk

|

seeingLimitedCoronal

| limbTracking

The current mode of the aO Engine

wfeThresh Float[20] nm

RMS ≥ 0

The significance threshold for a

modal wavefront error estimate

snrThresh Float[20] N/A ≥ 0

The SNR threshold for a modal

wavefront error estimate (reliability

threshold)

lutCheckThresh Float nm

RMS ≥ 0

The total allowable RMS wavefront

error threshold

pupilOffsetThresh Float arc-sec ≥ 0 The maximum pupil offset allowed

before a correction is required

ImageOffsetThresh Float arc-sec ≥ 0 The maximum image offset allowed

before a correction is required

totalRmsWFE Float nm

RMS ≥ 0

The total measured RMS wavefront

error

wfcCadence String Seconds <number> | auto The cadence of the wavefront

correction updates

wfcReconMatName String N/A A meaningful text

name

The name of the wavefront

reconstruction matrix to be used

boreReconMatName String N/A A meaningful text

name

The name of the boresight

reconstruction matrix to be used

inPos Boolean N/A true | false

A flag indicating whether the aO

Engine is “in position” or not. The aO

Engine is in position when it is in its

requested/desired configuration or

state.

status String N/A N/A A string providing additional status

information (error information, etc.).

6.3.3 Events Subscribed to by the aO Engine

The aO Engine subscribes to a number of TCS events to acquire status and position information on the

M1, M2, M3 and M6 mirror systems. These events are listed in the table below. All of these events are

defined in detail in the ICDs between the TCS and the various systems. To avoid double dimensioning,

only the event names are listed here. The reader is referred to the respective ICDs for the details.

D R A F T

aO Engine CDD


Event Rate System Document

atst.tcs.teoacs.cStatus 0.1 Hz TEOACS ICD 1.3-4.4

atst.tcs.teoacs.m2pos.cStatus 1 Hz TEOACS ICD 1.3-4.4

atst.tcs.teoacs.m2tt.cStatus 1 Hz TEOACS ICD 1.3-4.4

atst.tcs.teoacs.thermal.cStatus 0.02 Hz FMS??? ???

atst.tcs.m1cs.cStatus 1 Hz M1CS ICD 1.2-4.4

atst.tcs.m1cs.axial.cStatus 1 Hz M1CS ICD 1.2-4.4

atst.tcs.m1cs.axial.cEngStatus 1 Hz M1CS ICD 1.2-4.4

atst.tcs.m1cs.thermal.cStatus 1 Hz M1CS ICD 1.2-4.4

atst.tcs.m1cs.lateral.cStatus 1 Hz M1CS ICD 1.2-4.4

atst.tcs.focs.cStatus 1 Hz FOCS ICD 1.5-4.4

atst.tcs.focs.m3.cStatus 1 Hz FOCS ICD 1.5-4.4

atst.tcs.focs.m6.cStatus 1 Hz FOCS ICD 1.5-4.4

atst.tcs.focs.thermal.cStatus 1 Hz FOCS ICD 1.5-4.4

atst.tcs.ems.airTemperature 0.1 Hz FMS ??? ????

atst.tcs.mcs.cPos 10 Hz MCS ICD 1.1-4.4

6.3.4 Headers

The aO Engine is not required to respond to any header requests.

6.3.5 Interlocks

The aO Engine does not respond to any GIS interlocks. If an interlock occurs, the TCS will automatically

ignore any correction commands sent by the aO Engine.

6.3.6 Logging

There are two types of logging used in the aO Engine software: general status logging and event logging.

CSF provides general status logging to the log database automatically for the following types of actions:

lifecycle changes

health changes

connection changes

commands and responses

alarms

In addition, the aO Engine will incorporate logging of debug messages using varying debug levels as

outlined in SPEC-0022, Section 6.3, Debug Messages:

Level 1: at the entry/exit of major code sections (code modules),

Level 2: at the entry/exit of methods and procedures (unless these are expected to be called within

tight loops) and in object constructors (with the same caveat),

D R A F T

aO Engine CDD


Level 3: at key points within methods and procedures (again, outside of tight loops), and

Level 4: within tight loops (should be small messages with critical information only).

These debug messages are intended for diagnostic and engineering purposes.

CSF does not provide automatic logging of events. The aO Engine implements event logging using

custom software that saves desired event attributes to the CSF Archive Service. The specific events to be

recorded are listed above in Section 6.3.2 and 6.3.3. The enabling and disabling of event recording is

controlled using the .logEvents attribute described earlier.

6.3.7 Health and Alarms

6.3.7.1 Health

The aO Engine will set its health according to the guidelines outlined in SPEC-0022. Health is only

reported when a component’s health status changes state. If a component is operating normally, its health

is GOOD. The aO Engine will set its health to GOOD upon startup and initialization. If the aO Engine

detects a failure within itself and it is still able to operate, but at a reduced capability, it will set its health

to ILL. If the aO Engine detects a failure within itself and it is no longer able to operate, it will set its

health to BAD. If the aO Engine is able to recover from a failure and operate normally, whether by

internal means or by external intervention from the operator, it will return its health to GOOD.

The event monitoring thread in the aO Engine will set the health to ILL if a subscribed event has not

arrived within a user specified time frame. If the event continues to be missing for another user specified

time, the thread sets the health to BAD and also raises an alarm as described below.

6.3.7.2 Alarms

Alarms are to be used when operator notification and possible action are required to report equipment

danger or failure, or when continued operation in a malfunctioning state will result in bad data being

recorded either by the system in question or by other systems or instruments impacted by the

malfunctioning system.

We have analyzed the possible failure scenarios for the aO Engine, resulting in the following table of

failures and aO Engine alarm responses.

Failure Alarm Response

An event critical to the

operation of the aO Engine

does not arrive within a

specified timeout period.

The aO Engine depends on several

status events from the various TCS

subsystems in order to function

properly. The aO Engine will raise an

alarm.

Viable measurements from

the HOWFS/LOWFS/CV

are not received within a

specified timeout period.

The aO Engine depends on accurate

wavefront error and pupil position

error measurements from the HOWFS

and LOWFS subsystems and image

position measurements form the CV

subsystem in order to function

properly. The aO Engine will raise an

alarm.

A call to a CSF service by

an aO Engine component

If the service is critical to the proper

functioning of the aO Engine and to

D R A F T

aO Engine CDD


fails the viability of the aO Engine

correction data, the component in

question will raise an alarm.

A component detects an

internal SW resource

problem

If the resource failure can result in

bad aO Engine correction data being

produced, the component will raise an

alarm.

6.3.8 GUI Screens

The aO Engine will provide two Engineering GUI screens: a general screen that provides control of all

the aO Engine functionality and a status screen. The general screen will provide the capability to set or

read all of the aO Engine attributes detailed in this document. The status screen will have the following

features:

A display area showing the current positions of the M1, M2, M3 and M6 actuators and an

indication of whether they are near the end of their travel ranges

A display area showing the LOWFS and HOWFS subaperture images at a 5 Hz minimum update

rate

Time averaged modal wavefront error spectra for both the HOWFS and LOWFS

The current aO Engine wavefront error estimate

Basic status information on the current configuration of the aO Engine, such as gains,

reconstruction matrices in use, and other system parameters

The subaperture images will displayed as they are in the main WFC Status Screen.

6.4 USE CASE DETAILS

In this section we present detailed descriptions of the important uses cases of the aO Engine: diffraction

limited and seeing limited on-disk observing, and the boresight calibration.

6.4.1 Diffraction limited and seeing limited observing

This observing use case demonstrates the operation of both the wavefront correction thread and the

boresight stabilization thread. They are independent and asynchronous with respect to each other and run

simultaneously. The wavefront correction thread receives low order wavefront measurements from the

HOAO or the LOWFS and uses them to calculate correction offsets for the M1 and M2 mirrors. When

operating in diffraction limited mode the wavefront measurement from the HOAO is used. Conversely,

when operating in seeing-limited mode the wavefront measurement from the LOWFS is used. During

normal observing, both the HOAO and the LOWFS provide measurements to the aO Engine and it selects

which source to use based on whether the WFC mode is diffraction limited or seeing limited. The diagram

used below does not show the selection of which source is used, it simply shows “HOAO or LOWFS”.

The boresight calibration thread receives pupil position measurements from the HOAO and uses them to

calculate correction offsets for the M3 and M6 mirrors. Whether the WFC mode is diffraction limited or

seeing limited, the pupil measurements only come from the HOAO.

The following actions take place (refer to Figure 14 below):

1. The WCCS initially sends a startup configuration to all the WFC subsystems commanding them

to go through their startup sequences.

D R A F T

aO Engine CDD


2. The aO Engine downloads its default parameters from the property database, the Bulk Data Store

and the parameter set database.

3. The aO Engine creates the wavefront correction thread and starts it. The thread waits patiently for

receipt of the next status events from M1CS and TEOACS (M2 status).

4. The aO Engine creates the boresight calibration thread and starts it. The thread waits patiently for

receipt of the next status event from the FOCS (containing M3 and M6 status). The aO Engine is

now in idle mode.

5. After some time the WCCS sends a configuration to all the AO subsystems indicating that they

should go to the desired mode (either diffraction-limited or seeing-limited).

6. The aO Engine goes to the desired mode and begins processing wavefront measurements. The

HOAO or LOWFS receives a similar command (not shown) and begins calculating and

publishing low order wavefront measurements.

7. The aO Engine receives status events from the M1CS and TEOACS. These are really two

separate events, but are shown as one for clarity and due to space constraints.

8. The aO Engine signals the wavefront correction thread that the M1CS and TEOACS status events

have arrived.

9. The wavefront correction thread checks the M1CS/TEOACS status events to see if the mirrors are

in position. If not in position, the thread waits for the next status events. The thread also checks to

see if the last corrections sent by the aO engine have been processed by the M1CS and TEOACS.

If the events were not processed, the thread sets the aO Engine’s health to ill and continues

processing. If multiple events were not processed, the thread raises an alarm no notify the

operator that the M1CS and/or TEOACS is/are not processing corrections from the aO Engine.

The thread continues and waits patiently for the next set of wavefront measurements from the

HOAO/LOWFS. Note: much of this is omitted from the sequence diagram for clarity and due to

space constraints; see the flow-chart in Figure 11 and Figure 12 for details.

10. The aO Engine receives a status event from the FOCS (containing M3 and M6 status).

11. The aO Engine signals the boresight correction thread that the TEOACS status event has arrived.

12. The boresight correction thread performs similar checks and actions to those described above for

the wavefront correction thread, but for the M3 and M6 mirrors using the TEOACS status event.

The boresight correction thread continues and waits patiently for the next set of pupil position

measurements from the HOAO. Note: much of this is omitted from the sequence diagram for

clarity and due to space constraints; see the flow-chart in Figure 13 for details.

13. The HOAO or LOWFS publishes a low order wavefront measurement, to which the aO Engine

subscribes.

14. The aO Engine signals to the wavefront correction thread that a new measurement has arrived.

15. The HOAO publishes a pupil position measurement, to which the aO Engine has also subscribed.

16. The aO Engine signals to the boresight stabilization thread that a new measurement has arrived.

17. The wavefront correction thread processes its measurement and produces corrections for both the

M1 and M2. This includes the analysis of the reliability and significance of the measurements. If

the error is significant enough, the corrections are sent to M1 and M2 as shown below. If the error

is not significant, steps 18, 19, and 31are skipped and the thread waits for the next measurement.

18. The wavefront correction thread publishes an event containing the correction for the M1.


D R A F T

aO Engine CDD


20. The boresight stabilization thread processes its measurement. If the boresight is aligned to within

the desired criteria, no action is taken and steps 21, 22 and 25 are skipped. Otherwise, corrections

are calculated for both M3 and M6.

21. The boresight stabilization thread publishes an event containing the correction for the M3.


23. The aO Engine receives a status event from the FOCS.

24. The aO Engine signals the boresight correction thread that the FOCS status event has arrived.

25. The boresight correction thread checks to ensure the M3 and M6 mirrors are in-position and that

they received the last boresight correction. The thread waits patiently for the next pupil position

measurement from the HOAO.

26. The aO Engine receives another pupil position measurement from the HOAO.

27. The aO Engine signals to the boresight stabilization thread that a new measurement has arrived.

28. The boresight stabilization thread processes its measurement. If the boresight is aligned to within

the desired criteria, no action is taken and steps 32 and 33 are skipped. Otherwise, corrections are

calculated for both M3 and M6.

29. The aO Engine receives status events from the M1CS and TEOACS.

30. The aO Engine signals the wavefront correction thread that the M1CS/TEOACS status events

have arrived.

31. The wavefront correction thread checks to ensure the M1 and M2 mirrors are in-position and that

they received the last wavefront correction. The thread waits patiently for the next wavefront

measurement from the HOAO.



34. The aO Engine receives another wavefront measurement from the HOAO or LOWFS.

35. The aO Engine signals to the wavefront correction thread that a new measurement has arrived.

36. The wavefront correction thread processes its measurement and produces corrections for both the

M1 and M2. This includes the analysis of the reliability and significance of the measurements. If

the error is significant enough, the corrections are sent to M1 and M2 as shown below. If the error

is not significant, steps 37 and 38 are skipped and the thread waits for the next measurement.



The processing steps executed by both threads continue indefinitely, triggered by the receipt of new status

events and new wavefront or pupil position measurements, until the aO Engine receives a new WFC

mode.

D R A F T

aO Engine CDD


Figure 14: A sequence diagram illustrating the aO Engine operation.

D R A F T

aO Engine CDD


6.4.2 Boresight Alignment Calibration

This use case illustrates how the aO Engine will be used during the boresight alignment calibration.

Boresight alignment calibration involves making pupil position measurements with the HOAO and image

position measurements (centroid measurements) with the CV. The results of these measurements are sent

to the aO Engine for processing where it calculates how to move M3 and M6 to correct the errors in the

boresight. This process is iterative, meaning that multiple corrections may be required before reaching

the desired alignment criteria. The example shown here only uses a single iteration for brevity.

The operator routinely initiates the process by directing the WCCS to perform a boresight alignment. The

presumption is that the TCS has already been placed in aoCalibrate mode and that the WCCS has

commanded the PA&C to insert the pinhole at the GOS. These steps are not shown in the example. Next

the WCCS instructs the HOAO and aO Engine to go to the calibrate mode, supporting the boresight

alignment calibration task. The HOAO begins publishing pupil position measurements to which the aO

Engine subscribes. Next the WCCS instructs the CV to perform a centroid calculation. The CV performs

the calculation and publishes the result to which the aO Engine also subscribes. Now that the aO Engine

has both measurements that it needs, it uses them to calculate the corrections to M3 and M6 to align the

boresight and publishes these in events to which the FOCS subscribes. The FOCS receives the events and

applies the corrections to the mirror positions (the example does not show this). This process repeats

iteratively until the desired boresight alignment is achieved.

The accuracy of the boresight alignment depends on the signal-to-noise ratio at the HOWFS camera for

pupil alignment and signal-to-noise ratio at the CV camera for image alignment. See section 3.3.2 for a

discussion of the pupil alignment error and see SPEC-0180 for a discussion of expected image alignment

error.

The following steps are taken (refer to Figure 15 below):

1. The operator instructs the WCCS to perform the boresight calibration.

2. The WCCS sends a configuration instructing the HOAO to perform the boresight calibration.

3. The WCCS sends a configuration instructing the aO Engine to perform the boresight calibration.

4. The HOAO configures itself in the calibration mode and prepares to make pupil position

measurements.

5. The aO Engine configures itself in the calibrate mode and executes any required preparatory steps

for performing the boresight alignment calibration.

6. The HOAO sends “done” to the WCCS indicating that it is in calibrate mode and taking pupil

position measurements.

7. The HOAO completes a pupil position measurement and publishes it in an event to which the aO

Engine subscribes. The event process is not shown, as it would unnecessarily complicate the

diagram. Instead, a single message from the HOAO to the aO Engine is shown.

8. The aO Engine receives the pupil position measurement and signals to the boresight stabilization

thread that a new measurement has been received.

9. The boresight stabilization thread checks the mirror in-position statuses of M3 and M6 as well as

the status of the previous corrections, waiting if necessary until the status events are received (this

is not explicitly shown in the sequence diagram for reasons of clarity and space constraints, see

the flow-chart in Figure 13 for details). The thread then checks to see if it has received both a

pupil position measurement and an image position (centroid) measurement. It has not received an

image position measurement, so it waits patiently.

10. The WCCS now instructs the CV to make an image position measurement.

D R A F T

aO Engine CDD


11. The CV starts its centroid calculation.

12. The HOAO completes another pupil position measurement, which it publishes in an event to the

aO Engine. The pupil position measurements are computed periodically, with a nominal update

rate of 1 Hz.

13. The aO Engine receives the measurement and signals to the boresight stabilization thread that

another pupil position measurement has been received.

14. The boresight thread checks again to see if both a pupil position measurement and an image

position measurement have been received. The image position measurement has not been

received, so the thread continues waiting patiently.

15. The CV completes its centroid calculation and publishes the result in an event to which the aO

Engine subscribes.

16. The CV sends “done” to the WCCS indicating that it has completed the requested image position

measurement.

17. The aO Engine receives the measurement and signals to the boresight thread that it has received a

new image position measurement.

18. The boresight thread checks again to see if it has received both a pupil position measurement and

an image position measurement. This time both measurements have been received, so the

boresight thread moves on to the next step in its process.

19. The boresight thread begins processing the measurements to calculate corrections for M3 and M6.

If the measured offsets are small enough that that the desired alignment has been achieved, the

thread skips the mirror correction calculations and jumps to step 25. Otherwise the thread

continues

20. The HOAO publishes another pupil position measurement.

21. The aOEngine receives the measurement and signals to the boresight thread that a new pupil

position measurement has been received. The thread is not waiting for a signal so it takes no

action.

22. The aO Engine completes its correction computations and publishes an event containing the

correction for M3, to which the FOCS subscribes.

23. The aO Engine publishes an event containing the correction for M6, to which the FOCS also

subscribes.

24. The HOAO publishes another pupil position measurement.

25. The boresight processing thread signals to the parent aO Engine that it has completed a boresight

correction.

26. The aO Engine sends “done” to the WCCS indicating that it has completed a boresight correction

iteration. Normally at this point the entire process of events would be repeated by returning to

step 9 until the desired boresight alignment is achieved. However, this is eliminated for brevity.

27. The WCCS signals to the operator that it has completed the boresight alignment.

28. The aO Engine receives the pupil position measurement and signals to the boresight thread that a

new measurement has been received.

29. The boresight thread checks to see if both a pupil position measurement and an image position

measurement have been received. An image position measurement has not been received so the

thread continues to wait patiently.

D R A F T

aO Engine CDD


The boresight stabilization thread continues to operate in this manner until a change of WFC mode is

received by the aO Engine Even though it continues to receive pupil position measurements, it will not

publish correction events, as it will wait patiently for an image position measurement. Once a mode

change is received by the AO engine, the thread will respond to the desired change. For example, if a

normal observing mode is received (diffraction limited or seeing limited) the thread will begin to respond

only to pupil position measurements and will ignore image position measurements, which is the correct

behavior.

Figure 15: A sequence diagram illustrating the aO Engine operation during boresight alignment.

6.5 HARDWARE REQUIREMENTS

The computational requirements of the aO Engine are minimal. The sizes of the matrices used are quite

small and the computation rate is low. We plan to implement the aO Engine in the same CPU used for the

main WCCS controller. A simple quad or hex core single processor server will be sufficient. A

deployment diagram including the aO Engine is shown in the top-level WCCS design document (see:

Wavefront Correction Control System Critical Design Document).