[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Observational session control
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/
>