>X-Sender: owen@orca.astro.washington.edu >Mime-Version: 1.0 >Date: Mon, 16 Oct 1995 17:40:05 -0700 >To: Bruce Gillespie <gillespi@galileo.apo.nmsu.edu> >From: owen@astro.washington.edu (Russell E Owen) >Subject: Questions about rotator angles for drift-scanning TCC code >Cc: Pat Waddell <waddell@astro.washington.edu>, > Brian Yanny <brian@oddjob.uchicago.edu>, > Bob Loewenstein <rfl@hale.yerkes.uchicago.edu>, > Steve Kent <skent@fnal.fnal.gov> > >In the process of implementing drift scanning I have run into a problem >that should be answered by the user community and programmers of the >interfaces to the TCC: > >To implement drift-scanning, I am adding a new "arc" offset (in addition to >all existing offsets). This offset moves a specified distance across the >sky in a specified direction (which is specified in the object's coordinate >system -- typically FK5 RA/Dec). Specifying a velocity in the arc offset is >the basic mechanism behind drift-scanning. This offset will also probably >become the basic offset used for "nudging" and for graphical offsetting. > >To keep the instrument oriented correctly for drift-scanning, the rotator >maintains a constant angle of the "user" coordinate system with respect to >the instrument at the non-arc-offset position (rather than at the object). >If there were no arc offsets, this would be the usual "object" rotation >mode. > >So the first question is: do we also want the more obvious form of "object" >rotation: maintaining the angle at the object, rather than at the >non-arc-offset position? I suspect everybody's first impulse will be a firm >"yes", but please consider: > >Some arguments against a 2nd object rotation mode: >- The non-arc-offset mode is often what users will want: > - Suppose you are using the nudger to move around in a dense field of >stars near the pole (there is no such field, but it illustrates the point): >using the present object rotation, the field's orientation on the CCD would >remain constant. Using rotate-at-object instead, the field would rotate by >quite a bit every time you nudged the telescope. This problem remains on a >smaller scale as you move away from the pole. > - Similarly, if you have chosen a rotation angle with a particular guide >star in mind, the non-arc-offset rotation mode is more likely to keep that >guide star on the guide camera as you nudge around on the field. >- Having two flavors of object rotation is a recipe for endless confusion >and mistakes. One mode is easier to document than two, and there's no >danger of users picking the wrong mode and wondering what the heck is going >on. > >Some arguments for a 2nd object rotation mode: >- Specifying the angle at the object is what naive users may expect (until >they start nudging or graphically offsetting and run into the problem >listed above). >- If users start applying huge arc offsets they will get confused by the >resulting orientation of the CCD. But large fixed arc offsets are probably >not a good idea in any case, and small offsets favor the non-arc-offset >mode. > >Note that the rotation angle at the object will be part of status, so >Remark and the instrument headers and etc. will have enough info to figure >out what is going on in either case. > >I personally feel that two nearly identical rotation modes would be >terrible, but I would like to hear what others think. > >Bob L: this is the same issue that caused confusion for your star finding >chart offsetter (going x degrees E and then x degrees W didn't get you >where you started). The orientation was set at the offset object (rather >than the non-offset object), so the W offset was at a different orientation >than the initial E offset. > > > >The TCC also supports a "horizon" mode of rotation, which I propose will >maintain the angle of the horizon with respect to the instrument at the >object (rather than the non-arc-offset position). What do you think? > >Arguments for horizon rotates with object: >- It is much easier to implement. >- It may be what users expect, arguments about moving around in a crowded >field to the contrary. I'm on thin ice here, but still..if you are trying >to maintain a slit in a particular orientation, you really don't want the >user shafting you. > >Arguments for horizon rotates with non-arc-offset position: >- It is consistent with the proposed object rotation mode. > >Another possibility: dump the horizon mode altogether. Are folks using it? >Its purpose was to allow the slit to remain upright w.r.t. the horizon. If >it's not useful I'd love to dump it, but if it's useful let's keep it. > > > >Your comments welcome. Please feel free to call me if you have any >questions. Also please feel free to forward this to others (even mailing >lists) if you want to solicit wider feedback. But please get your feedback >to me this week if possible (or tell me why you need a delay). I wish to >finish coding this stuff so I can get it ready for the engineering down >time. > >My default solution will be to only implement the one object rotation mode >and the non-consistent-with-that horizon rotation mode. > >Regards, > >-- Russell > >Russell E. Owen >owen@astro.washington.edu University of Washington >phone: 206-543-2859 Astronomy >fax: 206-543-9850 Box 351580 > C321 Physics/Astronomy Bldg (non USPS) >http://rowen.astro.washington.edu/ Seattle, WA 98195-1580 > APO APO APO APO APO Apache Point Observatory 3.5m APO APO APO APO APO This is message 21 in the apo35-general archive. You can find APO the archive on http://astro.princeton.edu:82/apo35-general/INDEX.html APO To join/leave the list, send mail to apo35-request@astro.princeton.edu APO To post a message, mail it to apo35-general@astro.princeton.edu APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO