[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Observational session control
A few comments
1) XML is a program to program interface. Human's should never
have to read/write it. Use XML is you like but you don't need
to tell us that you are
2) The one example of an active Mk IV user we have to go by (Tom)
does not use the "target list model" to control his system. He
uses a simple algorithum that defines a scan sequence. This
is actually the best use of the system in terms of photons
per hour
Whatever the input to the scheduler looks like it had better allow
a user to specify a loop and relative movement.
You could make the "targt" a very large patch of sky and have the
program design the best scan pattern.
It might be good to first compile a list of requirements:
Some people are wanting to do a scan pattern but jump over the
specif fields as they get near.
What about overlapping operations? For example doing a dark
frame while the mount moves?
How many people would really use the target list model? I don't
think most will use that as the primary method
That's what drove me to think a programing language was required.
One more: I had time-tagged ALL of the low level conmmands that
were to go to the controler. The final compiled file had a
timestamp on every line. There is a triveal program that reads
a line waits for the timestamp to equal to current time and then
sends the reast of the line to the controller
--- "Creager, Robert S" <CreagRS@LOUISVILLE.STORTEK.COM> wrote:
>
> Hey Chris,
>
> Thanks for the info. I like it. Now that both you and Michael have
> mentioned somthing akin to compiling/linking (gathering valid
> observations/scheduling them), and Michael and Steve have both
> brought up
> RTML (XML based - http://sunra.lbl.gov/rtml2/), maybe it's the start
> of a
> plan.
>
> How's this for an outline:
>
> 1) A set of XML files is created somehow which contain the desired
> observing
> targets, both present and future
> 2) Using gnu make, these files (with 1 or more observing protocols
> per file)
> are "compiled" by a program which basically filters out stuff which
> cannot
> be observed for the night or isn't scheduled yet, and reduces the XML
> into
> either a XML subset, or a tabular format, or something else, which is
> the
> "object" file.
> 3) The "object" files are then "linked", which actually accomplished
> the
> scheduling of the observations.
> 4) A real time process "executes" the resultant file, which contains
> what
> you indicated below, except I would add an expected time stamp to
> each
> expose image.
> 5) After the observing run, a cleanup is run which manages completed,
> ongoing and bad observations for the next night
>
> The reason I add the expected time stamp in 4, is that during
> scheduling, we
> need to estimate the time it takes to move from the current field to
> the
> next. If we under estimate that time, we may run out of night to
> take
> pictures, or bump observations needed at a specific time. If we over
> estimate, then we may be idle for a few seconds before taking the
> exposure.
> Would there be any need for this, or would that just be adding
> complexity
> needlessly? As an example, if you had a 2 minute
> expose/move/download
> window, during a 6 hour observation schedule, you could get 180
> pictures (I
> said could ;-). If you were off in your move estimates by 2 second
> per
> observation, 360 seconds off by the end of the session. Maybe not
> big
> enough to worry about.
>
> Reasonable? If we use RTML, their XML is not cumbersom, with only a
> few
> fields being required (i.e. it could be done by hand without too much
> trouble).
>
> > -----Original Message-----
> > From: Chris Albertson [mailto:chrisalbertson90278@yahoo.com]
> > Sent: Thursday, March 21, 2002 7:42 PM
> > To: Creager, Robert S; 'Tass Mailing List'
> > Subject: Re: Observational session control
> >
> >
> > Here are a few ideas....
> >
> >
> > I had thought a little about the same problem. My idea was
> > to use a two step process. In the first step you create
> > a file like the one you describe that specifies what you
> > wouold LIKE to observe. You send this file to a program
> > that "compiles" this whish list into a set of lower level
> > commands, each paired with a time tag.
> >
> > Next there is yet another program that reads the time tagged file
> > ad issures the commands directly to the real time controller.
> >
> > The real-time controller only sees lower level stuff like
> > POINT_TO <ra, dec>
> > TRACK
> > EXPOSE_IMAGE
> > POINT_TO <ra, dec>
> > TRACK
> > EXPOSE_IMAGE
> > ...
> >
> >
> > So there are two command formats "wish list" and "time tagged
> > primitives" with a compiler/optimizer that does the translation.
> > Technically speaking, I was going to use in interpeter to do the
> > translation. The interpeter and therefore the "wish list"
> > language would allow loops, if statements and full arithmatic
> > expressions, variable and so on. A lot of work? No, the
> > "wish list" language is TCL. All you need to do is define a
> > few functions in TCL like "park <time>" then if for some wierd
> > reason you want to park the telescope twice you could
> > write
> > foreach time ($firsttime $secondtime) park $time
> > are whatever the TCL syntax is, I forget.
> > but you get the point, "park $time" is executed twice with two
> > values of $time.
> > What "park" is access a model of the Mk IV and see if it is
> possible
> > for the "move_to_home_loc" command to execute at $time. Maybe
> > it can't because there is some other command active at $time.
> > Now if that other command is marked "movable" and has lower
> priority
> > then does "park" it gets moved.
> >
> > What I found was that some people want to run ithe Mark IV in a
> scan
> > pattern while others want to hit specific feilds. Some will
> > want to do both. So I needed TCL's programability as part of
> > the.
> >
> > Here is one possable control program that Tom might use.
> > (I don't like TCL much anymore as you can see) notice there
> > are no times.
> >
> > while (ItIsDarkOutside())
> > {
> > point_relative (-30, 0) # full RA limit and dec=0
> > expose_dark(100) # Do a dark while mount moves
> > track # follow the stars
> > expose_image(100) # 100 second exposure
> > expose_image(100) # 100 second exposure
> > expose_image(100) # 100 second exposure
> > expose_image(100) # 100 second exposure
> > }
> > park
> >
> > I might want to add this line to the above loop to catch so things
> > that happen to pass by while I'm scanning
> >
> > If (distance( GetCurrentLoc(), SomeCoolObject) {
> > point_absolute(SomeCoolObject)
> > expose_image(100)
> > }
> >
> >
> > Loads of work how far did I get?
> > 1) I built a TCL interface to the real-time controller's socket
> > interface
> > 2) I have the program which reads the time tagged low level
> > file and spools it down the real-time controller's socket
> interface.
> >
> >
> >
> >
> > The reason is
> > 1) Your "whish list" may not actually work. It is easy to over
> commit
> > the hardware. So you need to run the scheduler/optimizer in
> > advance so that the optimizer can "move" a command back in time if
> > it needs to.
> >
> > 2) IMO a real-time controler should NOT also be a scheduler. It
> > is just plain cleaner to make two programs. Connect them with
> > a pipe if you must.
> >
> > 3) Allows the possibility of multiple "wish list" formats. Give
> > others a chance to make a better verson. It also allows
> > say a GUI or web based from end so the "wish list TCL' format
> > becomes one of many ways to talk to a Mk IV.
> >
> > =====
> > Chris Albertson
> > Home: 310-376-1029 chrisalbertson90278@yahoo.com
> > Cell: 310-990-7550
> > Office: 310-336-5189 Christopher.J.Albertson@aero.org
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Movies - coverage of the 74th Academy Awards(r)
> > http://movies.yahoo.com/
> >
>
=====
Chris Albertson
Home: 310-376-1029 chrisalbertson90278@yahoo.com
Cell: 310-990-7550
Office: 310-336-5189 Christopher.J.Albertson@aero.org
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/