This document is obsolete. See the updated version in the CAN archive 481s620

Description of the TCS Binocular Operational Philosophy

This document is intended as the conceptual level description of how the LBT software group is building binocular functionality into the TCS. The details like the command syntax needed for effective programming of this control are included in reference 2 below.


  • Mount point: The mount point is the compromise mount position based on the separate solutions computed for the left and the right sides of the telescope. It is a function of the coordinates and the weighting for each side and is the location for which mount and rotator tracking polynomials are ultimately generated. Offsets from any source (presets to different coordinates or offsets for dithering) will be measured with respect to the "mount point".

  • Co-pointing Constraint: The co-pointing constraint is the requirement that both telescopes point to positions on sky that are separated from the mount point by no more than a certain (TBD) amount. Given physical limits on the articulated optics on the two telescopes, we estimate that a pointing separation of +/-20 arcsec (actual value TBD) of either telescope from where the mount is pointing can be tolerated between the two sides in seeing-limited observations. Adaptive optics and interferometry will likely need to impose more stringent co-pointing limits.

  • Co-pointed: In the TCS, co-pointed means that the two pointing origins at the projected mechanical rotator centers in the delivered telescope focal planes have identical on-sky RADEC coordinates. In the binocular paradigm, the collimation models seek to keep both telescopes well-collimated as well as co-pointed as a function of elevation and temperature. Note that this definition is independent of any instrument attached to the telescope, and therefore independent of the precise pixel position on the instrument detectors. Where the rotator centers project to the detectors is determined additionally by the mechanical coupling of the instrument to the rotator as well as internal flexures of the instrument.

  • BinocularControl: A new IIF command being introduced here to enable instruments to notify the TCS that they intend to issue presets or offsets that violate the telescope's co-pointing constraint.

  • It is useful to consider what it means to be a real telescope. In a perfect binocular telescope, both sides would be well collimated at the point where the left and right pointing origins and the mount point all have identical coordinates on sky, and this state is maintained for all elevations and the thermal state of the telescope. In a real telescope like the LBT, when each side is well collimated the left and right pointing origins may no longer have the same coordinates on sky, and the separation between these two points may change as a function of elevation and temperature. Getting back to the on-sky alignment of a perfect telescope requires adjustments to the optics on each side, and this adjustment has implications on the delivered image quality. That is, you must move away from the best collimation position to achieve on-sky alignment The goal at the LBT is to maintain the on-sky alignment while minimizing any aberrations induced by this alignment.


Fundamentally, for the LBT to be a fully binocular telescope, the primary rule must be "do no harm" meaning that anything that is done on one side of the telescope should have no effect on any ongoing observations on the other side. This allows commands from the left and the right side to happen independently. However, since there is only one mount, there is a real constraint (the co-pointing constraint) that the two sides must remain pointed in approximately the same direction.

Because we cannot see how to make truly independent presets work correctly in all circumstances we are restricting the problem by forcing some coordination on binocular presets. In the future we may find ways to remove some of the restrictions, but we can have useful binocular operations in the meantime. Thus, the TCS will enforce a pointing change limit of \xB120 arcsec that a preset can request unless the TCS is notified by the the instrument that a larger pointing change is needed. The notification will be in the form of a new IIF command BinocularControl. The command is not sided (but some forms still must be issued by both instruments involved), and tells the PCS that the next preset(s) can move the telescope anywhere. The command will be extended for other functionality as binocular development proceeds. Note that a BinocularControl command does not interrupt anything the telescope is currently doing. Tracking, guiding, etc. continue uninterrupted until any subsequent presetTelescope command comes in to reposition to a new source.

The synchronous/asynchronous preset scheme presented herein is designed to support instrument operations from a single observing script for the fully binocular telescope and still execute if there may be problems on one side with either the instrument or telescope. On the instrument side, it will be necessary in the user interface to be able to continue running even with one side either not present (only one LUCIFER or MODS until the second one is brought to the LBT) or there is a functional problem on one side of the telescope (e.g. the RIGHT rotator not working). The key is to maintain independence of operation between the two instruments as much as possible, while maintaining efficient operations through a unified user interface. This will ease the requirements on advanced preparation (only one script needed for all conditions) as well as real-time response by the observers executing the observing plan (indicate on the UI that errors on one side are to be ignored, no need to edit scripts at the telescope). We believe this will automatically cover a fall-back to monocular operations gracefully (authorize "NONE" on the unused side) as well as open the possibility of mixed-mode observing with two different instruments (the authorization will reject the unnecessary commands from the unused halves of the two pairs of instruments).

There are two types of binocular presets, described below. Note that there will be a parallel definition of binocular offsets with similar control requirements, but that will be detailed elsewhere.

Synchronous presets:

Synchronous presets are intended for setting up a fully binocular telescope on a new field. The TCS will require notification from the instruments that this is going to happen, and the BinocularControl command will be used with an appropriate flag to issue this notification. Exactly two BinocularControl commands must come in, one on the left and one on the right, but the order does not matter. The IIF will reject additional BinocularControl commands on the same side. Following the BinocularControl command, each side must send a preset, but one side may send its BinocularControl and preset before or after the other. Only when both BinocularControl commands have been received will the synchronous condition be fulfilled. Before this happens one side can continue sending asynchronous presets and offsets while the other side is waiting. The operator will have a control on the IIFGUI to cancel the synchronous condition if one of the BinocularControl commands cannot be issued. Once both BinocularControl commands have been received, the IIF will wait until both presets are also received.

The PCS will now combine the pointing part of the two presets, because it knows about both sets of data and can set up the mount correctly. The first preset will start the mount slewing, and the second preset will cause the PCS to adjust the mount point as determined by the left-right weighting and then check that the pointing is OK on both sides. Following the pointing processing the presets will proceed independently, and can fail independently for non-pointing reasons. This gives the instrument the necessary flexibility to respond to and recover from real-world observing conditions.

Note that a presetTelescope to "both" as it is currently defined is a (crippled) subset of a fully synchronous binocular preset. This was implemented to allow operation of the binocular LBC cameras, but does not contain sufficient flexibility for binocular Gregorian instruments. Responding to problems on one side of the telescope is not possible with a "both" preset as any problems encountered on either side will cause the entire preset to fail. A synchronous preset with identical information (coordinates, guide stars, position angles, telescope modes, etc.) will accomplish precisely the same thing as a single preset to "both".

The assumptions in the fully binocular sequence of events outlined below are that a pair of identical instruments (two LUCIFERs or two MODS) send two slightly different central coordinates, along with different position angles and guide stars in ACTIVE mode. This exercises the full range of functionality on the telescope needed for binocular operations in seeing-limited mode. For adaptive optics operations, the handoff between GCS and AOS is handled internally, but triggered by commands from the instrument. Note that it is irrelevant to the telescope/TCS precisely what type of observation is being made (imaging, long-slit, or MOS spectroscopy), only that the correct sequence of commands are sent. In the sequences below, instrument actions or responses are preceded by "I:" and telescope actions or responses are preceded by "T:"

Synchronous Preset Command/Response Sequence

  • I: Each side sends a BinocularControl command with the appropriate numerical flag value signaling that a synchronous preset to a new target will be following.

  • T: Responds that the BinocularControl succeeded. The IIF sets internal flags indicating two presets are expected. Note that there is no change to the current state of the telescope, it continues tracking the current source, if any, in whatever mode (TRACK, ACTIVE, etc) it was already in.

  • I: Sends an ACTIVE preset to a new source, PA, and guide star for the LEFT side. The IIF waits for both presets before notifying the PCS of either one. The LEFT instrument should block on this preset in a separate connection to the IIF until a success or fail message is received back from the TCS.

  • I: Sends an ACTIVE preset to different coordinates, PA, and guide star for the RIGHT side. The IIF now sends both presets to the PCS. The RIGHT instrument should block on this preset in a separate connection to the IIF until a success or fail message is received back from the TCS.

  • T: PCS clears its coordinate buffers and will not apply the co-pointing constraint to the first preset. PCS starts generating mount and rotator polynomials for the new position. The telescope begins slewing. PCS now does check that the co-pointing constraint is satisfied (both presets will fail if the positions differ by >20" from the calculated mount point). The new position will slightly modify the current polynomials, the telescope adjusts its slew as needed. The mount point will be the weighted mean of the two preset coordinates, with the differential pointing on the two sides accommodated by the optics on each side.

  • T: Once each side goes "on source", the usual GCS acquisition sequence is triggered. The only difference is that the initial pointing correction is applied to the optics on that side rather than to the mount in order to not affect anything that might be happening on the other side. PCS, PSF, and GCS communicate to adjust pointing and optics to keep the telescope well-collimated. Once the guide loop has closed and the guide star position has been verified, GCS starts wavefront sensing and the preset for that side returns to the instrument.

  • T: Returns success for the RIGHT preset. See the next section for what to do when one of the synchronous presets fails.

  • I: Begins acquisition or science observations on the right side, if so desired. Note that for now instruments will likely continue monitoring of the isCollimated flag until the wfs improves the collimation of that telescope. There is no need to wait until the other side completes the preset as any subsequent commands from either side will be applied in such a manner to not disturb ongoing observations, unless this wait is imposed by the instrument for other reasons.

  • T: Returns success for the LEFT preset.

  • I: Begins acquisition or science observations on the left side. Note that any coordination in the data taking (e.g. both sides start taking data at the same time) is left for the instrument to impose on their observing sequences. At this point the two telescopes will act independent of each other as long as the co-pointing constraint is not violated.

Asynchronous presets:

Asynchronous presets, for astronomical observations under typical or normal scenarios, will mostly be useful to recover from issues that caused one of the two synchronous presets to fail. Once you are on-source, offsets will be used for local pointing changes both within (asynchronous) and beyond (synchronous) the +/-20 arcsec co-pointing constraints. The TCS will not require notification from the instruments that an asynchronous preset is going to happen. However, if this preset is intended to move to a position exceeding the +/-20 arcsec co-pointing constraint (like to a new field), then it will be necessary to notify the TCS through the BinocularControl command with an appropriate flag to issue this notification (or one should consider using a synchronous preset). Unlike with synchronous presets, the IIF will block the second preset (if any) until the first one has finished the pointing operation. With asynchronous presets, the PCS will treat each preset as a separate operation and thus there is no balancing of pointing offsets with respect to the mount point.

Note that asynchronous binocular presets cover all normal monocular operations. When the intention is to run as a single-sided telescope, perhaps due to "issues" with either the telescope or instrument on the other side, the TO can authorize the bad side as NONE. This will use nearly all the binocular machinery except for the rotator on the side not in use. Presets to the side not in use will be rejected by the IIF. Because there is no second telescope to worry about, offsets and guiding updates will be applied to the mount instead of the optics.

The asynchronous preset is not normally used as part of a standard observing sequence; this would typically consist of a synchronous preset to a new target followed by synchronous offsets to dither further than the co-pointing constraint or asynchronous offsets to dither or for mask alignment within the co-pointing constraint. But asynchronous presets will be useful for recovery from problems encountered during a synchronous preset as outlined above. So the assumption here is that the synchronous preset outlined above has had the right preset fail because no guide star was found on the acquisition image. This can happen (and does even with our telescope running only a single instrument) when un-modeled thermal gradients change the relative alignment of the two telescopes beyond the acquisition camera's 25-arcsec field of view. The sequencing and notation are as in the synchronous example above.

Asynchronous Preset Command/Response Sequence

  • T: Synchronous preset above ends with success on the LEFT side and failure to find a guide star on the RIGHT side.

  • T: OSA manually adjusts RIGHT side optics as needed. This may consist of sending an ACQUIRE mode preset plus adjustment of the right side pointing model or position of the optics to effect a pointing change. Note that efficient and effective tools to do this will likely need to be developed.

  • I: Sends an ACTIVE preset to the same source, PA, and guide star for the RIGHT side. Note that no BinocularControl command is necessary as the position is within the co-pointing constraint from the current mount point. If this was not true, the preset would fail. The syntax of the preset is identical in all cases, what makes it asynchronous is the lack of the BinocularControl command or the requirement by the TCS of the second preset.

  • T: PCS tests that the source is within the co-pointing constraint, then the preset continues, ending in success. Any pointing correction that is needed will be accomplished by moving the optics on the RIGHT side so as to not disturb any ongoing observation on the left side. Note that the mount point, determined as part of the synchronous preset above, does not change with an asynchronous preset.

  • I: Begins acquisition or science observations on the RIGHT side.


  1. David L. Terrett, "Pointing Algorithms for Binocular Telescopes", LBT CAN#481x122a, SPIE 6274-16
  2. Chris Biddick, "The ICE Instrument Interface Control Document", LBT CAN#481s013
  3. Michele D. De La Pena, et. al. "Practical Considerations for Pointing a Binocular Telescope", SPIE 2010.

LUCIFER Binocular Use Case Document received from N.Ageorges 15 April 2010: LUCIFER_Use_Cases_in_Binocular_Mode-v3.pdf


Note that in our comments below we assume that the TCS executes valid requests from the instruments without fail, not counting human errors. To the extent that this is not satisfied under real-world conditions, it may rapidly get much more complex to control a binocular telescope, perhaps more so on the control side of the instrument as it tries to respond to the problems in a flexible manner. So the instrument user interface must be able to tolerate and/or recover from problems on one side such that those problems do not affect any setup or observations on the other side. The design of how the synchronous/asynchronous presets are intended to operate considers this, but may not cover all situations. Something to keep in mind.

NB: The LUCIFER Team's outline seems to assume that there is a binocular mode with reduced functionality. This "rigid binocular observing" is just timing imposed on observation sequencing by the instrument, not a mode of the telescope that will get phased in on the TCS side. One should be cautious about applying experiences with LBC to Gregorian instruments, as the LBCs came to the LBT long before there was any experience with Gregorian operations and they simply make do with whatever is delivered by the telescope without regard to pointing or co-pointing constraints. For Gregorian instruments, everything in the TCS that is needed for fully generic binocular observing is also needed to accomplish what is called "rigid binocular observing". So we are either binocular or monocular, not something intermediate.


"Pointing offset": In "TCS-speak" we refer to this as the "pointing corrections". This is better understood as the open-loop (i.e. TRACK mode) positional offset between the two sides induced by gravity and thermal issues on the LBT and the pointing center followed by the mount. The collimation model incorporates corrections for a lot of this, and Andrew's efforts with the laser tracker measurements will potentially make significant improvements, but we suspect we will continue to have problems in strong temperature gradients with the co-pointing and collimation of the telescope. These pointing offsets remain in effect in TRACK mode, but will be corrected by the acquisition sequence in GUIDE mode or higher. The difference is that while we currently correct this in a one-eyed mode by moving the mount, in the binocular case you must move the optics in order not to disturb anything on the other telescope. A successful synchronous closed-loop (GUIDE or ACTIVE mode) preset to the same coordinates on both sides ends up with the two sides collimated and co-pointed. And because of the thermal issues on the telescope, ACTIVE mode presets should be the starting point for all science observations at the LBT.

Sect. 2.

This mode of observing, for either imaging or spectroscopy, is embodied in synchronous presets and offsets. Because of the reduced flexibility of a single preset to "both" telescopes, this option will be rejected by the IIF for all Gregorian instruments. Instrument teams should implement this type of operation with a full synchronous preset as described above. It is, as for all requests sent through the IIF, left up to the instrument to make sure that observations are completed on both sides. As with how presets and offsets are currently implemented with a single LUCIFER, the TCS will use the opportunity of synchronous presets and offsets to offload anything built up in the optics (i.e. shell tip-tilt, M2 hexapod repositioning, etc) as necessary to keep the two telescopes optimally aligned and collimated.

Under imaging, it is noted that "Acquisition: not needed". We believe this should be interpreted as verification and adjustment of the pointing with LUCIFER (on-sky alignment), in which case we agree. Nancy, please let us know if this is not a correct interpretation. But there is a potential for confusion here as in GUIDE+ modes the GCS must still go through its acquisition sequence in order to establish guiding and wavefront sensing.

Under Imaging:Comments it is noted that different exposure times will be needed. This is also true for calibrations as well as mixing observation types (e.g. imaging + spectroscopy with 2 LUCIFERs). This is up to the instrument to enforce efficiency in data gathering and why all Gregorian instruments should build a sophisticated planning tool to help maximize the efficiency of the observations. It makes no sense to take imaging for 5 minutes on one side if you are integrating a spectrum for 10 minutes on the other, and only the instrument is aware of instrumental overheads and what either side is currently doing. The planning tool should point this discrepancy out to those preparing observation scripts, often well in advance of the observing time at the telescope, and/or automatically adjust to maximize open-shutter time. The "super" LUCIFER service mentioned here is too late in the sequence of steps leading up to taking observations efficiently, that needs to be built into the planning tool. But the "super" LUCIFER service would be useful in effectively compensating for real-world operations, such as recovering from a failed preset on one side while the other one succeeds.

Under Spectroscopy:Acquisition it is noted that spectroscopic acquisitions will be done sequentially. This will violate the root-2 goal set by Gredel-Osmer-Rix. Acquisitions need to be automated and parallel if there is any hope of efficiency. Based on experience with LUCIFER1, any advanced planning tool should be aware of what is easily visible in the acquisition images taken with LUCIFER to align slits/masks on sky, such that the alignment sources are bright enough to be automatically identified. And the alignment sequence ("MOS Acquisition" on the LUCIFER UI) should be more automated. It should be straightforward to predict adjusted coordinates of the "next" alignment star in a sequence by using the coordinates of the "previous" N sources, and auto-centroid on them if a well-detected source is found.

Section 3.

Note that the mirrors are needed for guiding in the "rigid" mode as well, which is why it does not make sense to talk about rigid mode separately from the fully generic binocular case.

Other comments from Section 2 apply here as well.

Section 4 Questions:

Q: What is the value of the pointing offset?
A: In TRACK mode the pointing offset is governed by the collimation model plus any thermally-induced differential drifts, and these are expected because of the asymmetry of the telescope. In any mode from GUIDE on up, the acquisition sequence on the GCS will issue pointing corrections such that the corrected pointing delivered to the instrument at the conclusion of the preset/offset command will be dominated by the 50mas rms positioning of the AGw stages and any inaccuracies in the user-supplied coordinates for the guide stars.

Q: How well synchronized are the motions on both sides?
A: They are expected to be comparable in duration, although probably not identical (no data yet). The is no requirement imposed on the TCS side of things that everything happens in lock-step. Requests are processed independently as fast as possible. LBTO should work to make sure both sides take comparable time to execute requests from the instruments.

Q: How much of the needed commands are encompassed in the BOTH option?
A: 100% or a small fraction, depending on what you are asking. As noted above, the "both" option will be rejected by the IIF for Gregorian instruments as this is not the correct way to execute what are synchronous presets as described above. With two LUCIFERs, we expect most presets to new fields to be of the synchronous variety, real-world recovery to use asynchronous presets, and normal observations to use both types of offsets depending on the needs of the observations.

Q: We assume here that not only can slightly different fields be pointed but also different position angle and guide stars can be provided independently.
A: Yes. This is the fully generic binocular observation.

Q: How do you foresee preset/offset commands to look like. Will they be treated separately on both sides?
A: Yes, independent operation of the two sides is what enables effective binocular operations. The preset/offset commands will retain the same syntax as now. The intent to allow the telescope to move to a new field on presets or offsets (i.e. breaking the co-pointing constraint) will be signaled by the instrument sending the BinocularControl command with an appropriate flag value.

Q: How do you intend to do the needed guiding corrections during acquisitions?
A: Both the larger acquisition offsets needed to start guiding as well as the normal (small) guiding offsets will also have to be done with the optics and not the mount in order to maintain independence on the two telescope sides.

Q: Who check/guarantee that the differential pointing requested is within the reachable range of flexibility of the telescope?
A: The TCS will reject any differential pointing request in presets or offsets that exceeds a configurable and as yet undetermined amount (see next question). That will, of course, result in frequent rejection of poorly planned observations, so to maximize efficiency of the observations this limit should also be imposed in any LUCIFER observation planning tool.

Q: What is the limit for differential pointing...?
A: We currently suggest assuming a pointing offset of +/-20 arcsec between either telescope and the "mount point" over the sum of all offsets plus the initial preset, independent for each side. This is safely inside the maximum range of the optics, but some of the range will be taken up by corrections for elevation and temperature in the collimation models, and any un-modeled drifts or thermal gradients corrected for in the GCS acquisition sequence. A final value will be determined in on-telescope tests. Note that offsets with M2 only (i.e. a coma-free pointing change on M2) does have a larger range than M1 but offsets applied in this way have consequences for the aberrations on the delivered focal plane. In general, seeing-limited instruments should not worry about how an offset is applied as the TCS will do so in the most aberration-free manner. Note that additional control of the telescope optics is possible and likely necessary for interferometers as they have much tighter requirements on positioning and tilts of both the focal planes and the pupils. But at the moment, for seeing-limited binocular observations with two LUCIFERs, we suggest you only impose the +/-20 arcsec co-pointing restriction in planning tools (as a configurable value), and send the BinocularControl command as needed and as outlined above in order to tell the TCS that the next presets are allowed to break this co-pointing constraint rule.

Q: We need to know the philosophy thought behind the SW implementation of the binocular mode = do both sides move simultaneously or do commands go on one side first and then onto the other side.
A: Both options are available. For the fully generic case the two sides are effectively independent, and the two modes of implementation are described above. There really is no intermediate mode where the telescope is less than fully binocular as handling the realities of the thermal performance of the telescope even in what you call "rigid binocular" mode requires all of the functionality needed for the generic case. Given that, how presets are applied is determined by whether they are synchronous or asynchronous (see discussion above).

D. Thompson, C. Biddick, M. De La Pena 23 Jun 2010
Topic revision: r23 - 22 Nov 2013, KelleeSummers
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback