Source: http://www.patentgenius.com/patent/7313763.html
Timestamp: 2018-05-25 05:13:14
Document Index: 457698949

Matched Legal Cases: ['art 96', 'art 112', 'art 112', 'art 112', 'art 148', 'art 148', 'art 180', 'art 180', 'art 180', 'art 180', 'art 180', 'art 180', 'art 180', 'art 224', 'art 224', 'art 224']

System for operating an astronomical observatory in real time using http - Patent # 7313763 - PatentGenius
System for operating an astronomical observatory in real time using http
7313763 System for operating an astronomical observatory in real time using http
Inventor: Bisque, et al.
Application: 10/041,971
Inventors: Bisque; Stephen M. (Golden, CO)
Bisque; Thomas M. (Golden, CO)
Bisque; Daniel R. (Golden, CO)
Bisque; Matthew L. (Golden, CO)
Assignee: Software Bisque, Inc (Golden, CO)
Assistant Examiner: Tran; Mylihn
Attorney Or Agent: Crabtree; Edwin H.Pizarro; Ramon L.Esplin; D. Benjamin
U.S. Class: 715/736; 359/362; 359/399; 359/430; 359/566; 715/738; 715/740
Field Of Search: 715/430; 709/203; 709/208; 700/245; 348/211.99; 359/430; 359/566; 359/399; 359/362; 359/847; 165/290; 356/121
Other References: US. Appl. No. 60/105,626. cited by examiner.
U.S. Appl. No. 60/143,637. cited by examiner.
Abstract: A system for operating an astronomical observatory made up of astronomical hardware, utilizing a web browser operated by a user, and a web server connected to the observatory, wherein both the control to, and feedback from the observatory are displayed to the user in real time independent of personnel support at the observatory site. The user submits a request to the observatory via the web browser, which displays the status and results of the request. A web server, coupled to the various astronomical hardware, processes the request on behalf of the user and responds with the status and results of the request. The status and/or results ae then displayed by the web browser to the user. Requests may be made by the user interactively, or in the form of a script. The system may be used over wide area networks, like the Internet, or any other type of network.
1. A system for operating an astronomical observatory, the observatorybeing located at an observatory site, via requests made by a user interactively or as a script, and located either remotely or at the observatory site, and independent of on site support personnel, wherein results and status of the requests are displayedto the user in real time, the system comprising: a web browser, said web browser providing means for the user to be able to send requests to the observatory, and receive the status and results of these requests by utilizing an http protocol, said webbrowser further providing a rich graphical interface for the user which may include displays of the status and results of the requests made by the user to various components of the system as they occur in real time; a set of astronomical hardware, saidset of astronomical hardware being located at the observatory site and supplying means for making celestial observations, said set of astronomical hardware including: a telescope, said telescope being composed of a telescopic optics system allowingmagnified observation of the sky to take place, and a telescope mount capable of controlling the position of the telescopic optics system for the purpose of pointing to and tracking on celestial objects; and an imaging camera, said imaging camera beinglocated at said telescope, said imaging camera being positioned so as to be able to capture an image of a celestial object at which said telescope is aimed, said imaging camera further capturing said image of the celestial object in a digital format; and a web server, said web server providing means for transmitting and receiving communications to and from said web browser utilizing an http protocol, said web server further including the capability of controlling said set of astronomical hardwareaccording to requests sent to said web server via said web browser from the user, said web server being made up of: a request manager, said request manager being responsible for listening for, and responding to requests sent to said web server by saidweb browser, said request manager further being relied upon to queue requests from said web browser in order to permit said set of astronomical hardware to execute the requests in an orderly fashion, said request manager also providing the means by whichinformation is sent back to said web browser utilizing an http protocol; a power manager, said power manager providing said web server the means for, at the request of said web browser, being able to power on or off any or components of said set ofastronomical hardware; a user database, said user database containing a list of user account information for use in determining if and when a user should be allowed to control the observatory; a user manager, said user manager accessing said userdatabase and using the information contained therein to serve as a gate by which the user must gain entrance if he/she wishes to control the observatory, said user manager further controlling the scheduling of users for control of the observatory atspecific times; a telescope manager, said telescope manager being the means for said web server to generate and send specific directions to said telescope based on requests made by the user, said telescope manager further being able to receive andprocess information sent to said web server by said telescope; a telescope driver, said telescope driver being capable of translating communications between said telescope and said telescope manager; an imaging camera manager, said imaging cameramanager being the means for said web server to generate and send specific directions to said imaging camera, said imaging camera manager further serving to process information from said imaging camera as well as acting as an image reducer for imagesgenerated by said imaging camera; and an imaging camera driver, said imaging camera driver being capable of translating communications between said imaging camera and said imaging camera manager.
2. The system as described in claim 1 wherein said set of astronomical hardware further includes a dome, said dome providing a protective shell for the observatory against weather and other elements of nature, said dome also having aretractable opening so as to permit said telescope access to the sky.
3. The system as described in claim 2 wherein said web server further includes a dome manager and a dome driver, said dome manager being the means for said web server to generate and send specific directions to said dome, said some driver beingcapable of translating any and all communications between said dome and said dome manager.
4. The system as described in claim 1 wherein said set of astronomical hardware further includes an auto-guiding camera, said auto-guiding camera being located at said telescope and being oriented so as to be able to find a celestial object inthe sky near the object at which said telescope is aimed, for the purpose of providing said web server with a set of reference images from which said web server may measure any necessary tracking adjustments that must be made during an image captureprocess made by said imaging camera.
5. The system as described in claim 4 wherein said web server further includes an auto-guiding camera manager and an auto-guiding camera driver, said auto-guiding camera manager being the means for said web server to generate and send specificdirections to said auto-guiding camera, said auto-guiding camera further being able to compare the location of a celestial object in different images in order to provide corrections for a tracking rate of said telescope as it follows an object, saidauto-guiding camera driver being capable of translating any and all communications between said auto-guiding camera and said auto-guiding camera manager.
6. The system as described in claim 1 wherein said web server further includes a telescope model manager, said telescope model manager being responsible for quantifying systematic errors inherent in said telescope, these errors include but arenot limited to offset or bias errors, polar misalignment, refraction, non-perpendicular axis, gear errors, tube flexure, and fork flexure, said telescope model manager quantifying these errors by using a mapping process to create a model coordinatesystem which is then translated into the coordinate system of said telescope.
7. The system as described in claim 1 wherein said web server further includes a broadcast manager, said broadcast manager serving the purpose of broadcasting the status and results of requests made by the user to any number of outsideobservers while ensuring that these broadcasts do not slow the system down, said broadcast manager further being capable of sending these broadcasts utilizing a number of different information transfer technologies, such as file transfer servers, gopher,email, fax, and/or modem.
8. The system as described in claim 1 wherein said web server further includes a celestial object database and a celestial object database manager, said celestial object database containing both ephemeris and graphical data for celestialobjects including but not limited to galaxies, minor planets, planets, satellites and stars for any field of view, for any date and time, and said celestial object database manager providing the means for said web server to be able to access saidcelestial object database to obtain any information contained therein that has been requested by the user.
9. The system as described in claim 1 wherein said web server further includes a celestial image database and a celestial image database manager, said celestial image database containing a set of reference images that cover the entire nightsky, these images being essential for certain types of discovery work like supernova and minor planet discovery, and said celestial image database manager providing the means for said web server to be able to access said celestial image database toobtain any information contained therein that has been requested by the user, said celestial image database manager further being able to automatically produce and transmit to said web browser a reference image of any object captured in an image by saidtelescope and said imaging camera.
10. A system for operating an astronomical observatory, the observatory being located at an observatory site, via requests made by a user interactively or as a script, and located either remotely or at the observatory site, and independent ofon site support personnel, wherein results and status of the requests are displayed to the user in real time, the system comprising: a web browser, said web browser providing means for the user to be able to send requests to the observatory, and receivethe status and results of these requests by utilizing an http protocol, said web browser further providing a rich graphical interface for the user which may include displays of the status and results of the requests made by the user to various componentsof the system as they occur in real time; a set of astronomical hardware, said set of astronomical hardware being located at the observatory site and supplying the means for making celestial observations, said set of astronomical hardware including: atelescope, said telescope being composed of a telescopic optics system allowing magnified observation of the sky to take place, and a telescope mount capable of controlling the position of the telescopic optics system for the purpose of pointing to andtracking on celestial objects; an imaging camera, said imaging camera being located at said telescope, said imaging camera being positioned so as to be able to capture an image of a celestial object at which said telescope is aimed, said imaging camerafurther capturing said image of the celestial object in a digital format; a web server, said web server providing means for transmitting and receiving communications to and from said web browser utilizing an http protocol, said web server furtherincluding the capability of controlling said set of astronomical hardware according to requests sent to said web server via said web browser from the user, said web server being made up of: a request manager, said request manager being responsible forlistening for, and responding to requests sent to said web server by said web browser, said request manager further being relied upon to queue requests from said web browser in order to permit said set of astronomical hardware to execute the requests inan orderly fashion, said request manager also providing the means by which information is sent back to said web browser utilizing an http protocol; a power manager, said power manager providing said web server the means for, at the request of said webbrowser, being able to power on or off any or components of said set of astronomical hardware; a user database, said user database containing a list of user account information for use in determining if and when a user should be allowed to control theobservatory; a user manager, said user manager accessing said user database and using the information contained therein to serve as a gate by which the user must gain entrance if he/she wishes to control the observatory, said user manager furthercontrolling the scheduling of users for control of the observatory at specific times; a celestial object database, said celestial object database containing both ephemeris and graphical data for celestial objects including but not limited to galaxies,minor planets, planets, satellites and stars for any field of view, for any date and time; a celestial object database manager, said celestial object database manager providing the means for said web server to be able to access said celestial objectdatabase to obtain any information contained therein that has been requested by the user; a celestial image database, said celestial image database containing a set of reference images that cover the entire night sky, these images being essential forcertain types of discovery work like supernova and minor planet discovery; a celestial image database manager, said celestial image database manager providing the means for said web server to be able to access said celestial image database to obtain anyinformation contained therein that has been requested by the user, said celestial image database manager further being able to automatically produce and transmit to said web browser a reference image of any object captured in an image by said telescopeand said imaging camera; a telescope manager, said telescope manager being the means for said web server to generate and send specific directions to said telescope based on requests made by the user, said telescope manager further being able to receiveand process information sent to said web server by said telescope; a telescope driver, said telescope driver being capable of translating communications between said telescope and said telescope manager; a telescope model manager, said telescope modelmanager being responsible for quantifying systematic errors inherent in said telescope, these errors include but are not limited to offset or bias errors, polar misalignment, refraction, non-perpendicular axis, gear errors, tube flexure, and forkflexure, said telescope model manager quantifying these errors by using a mapping process to create a model coordinate system which is then translated into the coordinate system of said telescope; an imaging camera manager, said imaging camera managerbeing the means for said web server to generate and send specific directions to said imaging camera, said imaging camera manager further serving to process information from said imaging camera as well as acting as an image reducer for images generated bysaid imaging camera; and an imaging camera driver, said imaging camera driver being capable of translating communications between said imaging camera and said imaging camera manager.
11. The system as described in claim 10 wherein said set of astronomical hardware further includes a dome, said dome providing a protective shell for the observatory against weather and other elements of nature, said dome also having aretractable opening so as to permit said telescope access to the sky.
12. The system as described in claim 11 wherein said set of astronomical hardware further includes an inside dome camera, said inside dome camera providing a real time image of the inside environment of said dome and the other components ofsaid set of astronomical hardware enclosed therein.
13. The system as described in claim 12 wherein said web server further includes an inside dome camera manager and an inside dome camera driver, said inside camera manager being the means for said web server to generate and send specificdirections to said inside dome camera, and said inside dome camera driver being capable of translating communications between said inside dome camera and said inside dome camera manager.
14. The system as described in claim 11 wherein said set of astronomical hardware further includes an outside dome camera, said outside dome camera providing to said web server a real time view of the sky at the observatory site.
15. The system as described in claim 14 wherein said web server further includes an outside dome camera manager and an outside dome camera driver, said outside camera manager being the means for said web server to generate and send specificdirections to said outside dome camera, said outside dome camera manager further being capable of comparing an image of the sky at the observatory sit generated by said outside dome camera with a virtual image of the sky at the observatory site providedby said celestial object database in order to determine if the sky at the observatory site is free from cloud cover, and said outside dome camera driver being capable of translating communications between said outside dome camera and said outside domecamera manager.
16. The system as described in claim 11 wherein said web server further includes a dome manager and a dome driver, said dome manager being the means for said web server to generate and send specific directions to said dome, said dome driverbeing capable of translating any and all communications between said dome and said dome manager.
17. The system as described in claim 10 wherein said set of astronomical hardware further includes an auto-guiding camera, said auto-guiding camera being located at said telescope and being oriented so as to be able to find a celestial objectin the sky near the object at which said telescope is aimed, for the purpose of providing said web server with a set of reference images from which said web server may measure any necessary tracking adjustments that must be made during an image captureprocess made by said imaging camera.
18. The system as described in claim 17 wherein said web server further includes an auto-guiding camera manager and an auto-guiding camera driver, said auto-guiding camera manager being the means for said web server to generate and sendspecific directions to said auto-guiding camera, said auto-guiding camera further being able to compare the location of a celestial object in different images in order to provide corrections for a tracking rate of said telescope as it follows an object,said auto-guiding camera driver being capable of translating any and all communications between said auto-guiding camera and said auto-guiding camera manager.
19. The system as described in claim 10 wherein said set of astronomical hardware further includes a set of weather station instrumentation, said set of weather station instrumentation providing information about the weather at the observatorysite to said web server, this information might include such measurements as wind speed, temperature, air pressure, and/or humidity.
20. The system as described in claim 19 wherein said web server further includes a weather station manager and a weather station driver, said weather station manager being the means for said web server to generate and send specific directionsto said set of weather station instrumentation, said weather station manager also being able to match existing weather measurements taken by said set of weather station instrumentation with a configurable set of allowable values, thus said weatherstation manager can determine if the weather at the observation site will allow for celestial observation, and said weather station driver being capable of translating communications between said set of weather station instrumentation and said weatherstation manager.
21. The system as described in claim 10 wherein said web server further includes a broadcast manager, said broadcast manager serving the purpose of broadcasting the status and results of requests made by the user to any number of outsideobservers while ensuring that these broadcasts do not slow the system down, said broadcast manager further being capable of sending these broadcasts utilizing a number of different information transfer technologies, such as file transfer servers, gopher,email, fax, and/or modem.
This invention relates to controlling an astronomical observatory by means of a web browser and web server communicating by an http protocol and more particularly, but not by way of limitation to controlling an astronomical observatory wherein auser, by means of the web browser, may manipulate the observatory either remotely or locally in real time and independent of personnel support located at the observatory site.
In U.S. Pat. No. 4,682,091 to Krewalk et al. a telescope control system is described. The control system found therein discloses the use of a microprocessor and a motor placed on each of two axis which makes it possible for an operator toreceive digital information concerning the position of a telescope and further allow the operator to manipulate the telescope digitally.
U.S. Pat. No. 5,133,050 to George et al. discloses a system for operating a telescope wherein a graphical display representing the night sky maybe used by an operator to guide a telescope. In this system as the operator locates an object onthe graphical display the telescope processes the objects location and automatically points to its coordinates.
In U.S. Pat. No. 6,304,376 to Baun et al. a fully automated telescope system with distributed intelligence is described combining a telescope with a controlling processor unit such as a computer wherein, once the geographic location of thetelescope has been ascertained, the telescope will automatically point to or track any object in the sky.
None of the above mentioned prior art patents specifically disclose the unique features of the subject system for controlling an astronomical observatory in real time by means of a web browser and web server communicating by way of an httpprotocol.
In view of the foregoing, it is a pry object of the invention to provide real time control of an astronomical observatory to a user independent of personnel support at the observatory site.
Still another object of the system for web browser control of an astronomical observatory is to give a user an opportunity to remotely observe a night sky other than the one under which he/she is located. This would allow the user to performobservations during daytime hours and would permit the user to control equipment in areas with less light pollution than is present at his/her locale.
Yet another object of the system is to allow a user to control an astronomical observatory over a network such as the internet using standard internet protocols in order to allow communication between the user and the astronomical observatory topass freely through corporate firewalls without requiring auxiliary holes in the firewalls to be created.
An additional object of the invention is to allow a user to control an astronomical observatory via a web browser independent of any particular operating system, component technology, or object calling convention in order to allow for a maximumclient reach.
The subject system is used for controlling an astronomical observatory made up of astronomical hardware, utilizing a web browser operated by a user, and a web server connected to the observatory. Wherein both the control to, and feedback fromthe observatory are displayed to the user in real time and are independent of personnel support at the observatory site. The user submits a request to the observatory via the web browser. A web server, coupled to the various astronomical hardware,processes the request on behalf of the user and responds with the status and results of the request. These results and/or status are then displayed by the web browser to the user. Requests may be made by the user interactively, or in the form of ascript. Since the system may be used over wide area networks, like the Internet, any other type of network, or even no network at all, the invention allows the user to control the observatory either remotely from a distance, or locally at theobservatory site. In addition, the distributed nature of the system allows for the user to be in control of multiple observatories simultaneously, and permits any number of spectators to view the results coming from the subject observatories.
These and other objects of the present invention will become apparent to those skilled in the art from the following detailed description, showing the contemplated novel construction, combination, and elements as herein described, and moreparticularly defined by the appended claims, it being understood that changes in the precise embodiments to the herein disclosed invention are meant to be included as coming within the scope of the claims, except insofar as they may be precluded by theprior art.
In FIG. 1, an exemplary environment of the present invention is shown having general reference numeral 10 wherein the environment 10, is made up of a web browser 12, a network 14, and an observatory 16. The elements of the observatory 16 may bebroken down further into two distinct sets, the software included in the web server 18, and the astronomical hardware 20.
The web browser 12 provides a rich graphical user interface for a user to interact with the observatory 16 in a number of standard ways. The graphical interface could include features like an interactive, virtual star chart of the sky at theobservatory 16 in order to simplify selection by the user of a desired target. The web browser 12 could further include interactive virtual models of various components of the astronomical hardware 20, such as, a dome 22 which provides a protectivehousing for the observatory 16. A telescope 24, made up of a telescopic optics system and a means for controlling the position of the telescopic optics system for the purpose of pointing to and tracking on celestial objects. An imaging camera 26located at the telescope 24 and positioned for the purpose of capturing a digital image of a celestial object at which the telescope 24 is aimed. An auto-guiding camera 28 located at the telescope 24 and able to find a celestial object in the sky nearthe celestial body at which the telescope 24 is aimed for the purpose of providing the software with a set of reference images on which it may measure the necessary tracking adjustments as the telescope 24 moves across the sky. The astronomical hardware20 further includes an inside dome camera 30, an outside dome camera 32, and a set of weather station instruments 34. The interface between the user and the observatory 16 could might also feature an image of a celestial object created by the imagingcamera 26, at the request of the web browser 12, a wide angle view of the inside of the observatory 16 produced by the inside dome camera 30, and/or a wide angle view of the sky at the observatory 16, captured by the outside dome camera 32. In short,the function of the web browser 12 in the exemplary environment 10 is to, at the behest of the user, make requests using an http protocol to the observatory 16, and display the results of requests received from the observatory 16 by means of an httpprotocol. These requests being carried out by the web server 18 and the astronomical hardware 20. To one skilled in the art it would be obvious that an https protocol would fail into a sub category of http protocols. Consequently, it is assumed thatany components in the system described as using an http protocol for communicating could alternatively be utilizing an https protocol without departing from the present invention. Furthermore, those skilled in the art will recognize that the list ofpossible features located at the web browser 12 are not in any way limiting, and that the functionality of the web browser 12 could be larger or smaller without departing from the scope of the present invention.
The web server 18, as depicted in the exemplary environment 10, includes the software that makes operating the astronomical hardware 20 possible. This list of software includes a request manager 36, a power manager 38, a user manger 40 connectedto a user database 42, a celestial object database manager 44 which controls a celestial object database 46, a celestial image database manager 48 connected to a celestial image database 50, a dome manager 52 attached to a dome driver 54 which controlsthe dome 22, a telescope manager 56 linked to a telescope driver 58 that feeds requests to the telescope 24, a telescope model manager 60, an imaging camera manager 62 and an imaging camera driver 64 that control the imaging camera 26, an auto-guidingcamera manager 66 and an auto-guiding camera driver 68 which are connected to the auto-guiding camera 28, an inside dome camera manager 70 electronically linked to an inside dome camera driver 72 and the inside dome camera 30, an outside dome cameramanager 74 attached to an outside dome camera driver 76 that passes requests to the outside dome camera 32, a weather station manager 78 and a weather station driver 80 coupled to the weather station instruments 34, and a broadcast manager 82.
The request manager 36 is responsible for listening for and responding to web browser 12 requests. The request manager 36 also queues requests while other requests are in progress, allowing the user to control the observatory 16 in a scriptedmanner. All requests from the web browser 12 have an associated timeout and are closed loop. Whenever a request fails, the web browser 12 is informed of the failure along with a descript status of the failure. When a request succeeds, the status ofthe request along with its results are presented to the web browser 12 by way of the request manager 36 using an http protocol.
The power manager 38 provides the means for the web browser 12 to power on or off, any or all of the astronomical hardware 20 located at the observatory 16. The access to power operations via the web browser 12 would normally be reserved forusers with administrative privileges. This is due to fact that the ability to power devices is primarily for startup and shutdown. In the case of a problem with a particular component of the astronomical hardware 20 power operations might also benecessary to "reboot" the device by toggling its power.
The user manager 40 is the gate by which users must gain entrance if they wish to control the observatory 16 via the web browser 12. As the user attempts to login the user manager 40 locates the users account in the user database 42 and givesthe user the privileges permitted by his/her account. The user manager 40 further controls the scheduling of advance dates and times by users for manipulating the observatory 16. Under most circumstances the user manager 40 would allow only one user ata time to control the observatory 16 to avoid conflicting requests from multiple users, however, simultaneous operation by multiple users is possible, and the status of and results of the requests made by one user could be made available to any number ofother users via the broadcast manager 82.
The celestial object database manager 44 provides access to the celestial object database 46. Through the celestial object database manager 44 the user can get either ephemeris or graphical data for celestial objects including but not limited togalaxies, minor planets, planets, satellites and stars for any field of view, for any date and time.
The celestial image database manager 48 is the means by which the user may obtain data from the celestial image database 50. The celestial image database 50 contains a set of reference images that cover the entire night sky. This information isessential for certain types of discovery work like supernova and minor planet discovery. When acquiring an image of a celestial object, the web browser 12 could also receive an optional accompanying image from the celestial image database 50 forreference.
The dome manager 52 controls the dome 22 with communications interpreted by the dome driver 54. This control includes the ability to request the current position of the dome and to open or close the dome slit, or in the case of a roll roof orthe equivalent, open or close the roof. Control further includes being able to slew the dome 22 or to track the dome 22, and to compute the required altitude and azimuth of the dome slit with respect to the telescope. This last task, although it maysound trivial, is quite complicated. This is because different types of telescopes and mounts have rotating axis which are not located at the rotational center of the dome 22. The dome manager 52 is able to take into account the geometry of both thetelescope 24 and the dome 22 and automatically align the dome slit with the direction in which the telescopic optic is aimed.
The telescope manager 56 sends directions to the telescope 24 via the telescope driver 58. These directions could include both startup and shutdown instructions for the telescope 24. The communication between the telescope manager 56 and thetelescope 24 further contains the ability to get and set the current position of the telescope 24, as well as the capability of providing the telescope 24 with a direction in which to slew.
The telescope model manager 60 is responsible for quantifying systematic errors inherent in the telescope 24. These errors include but are not limited to offset or bias errors, polar misalignment, refraction, non-perpendicular axis, gear errors,tube flexure, and fork flexure. In order to quantify the previously listed errors the telescope model manager 60 utilizes a process called mapping. Mapping involves pointing the telescope 24 at a sufficient number of celestial objects, over asufficient portion of the sky, and then noting the difference between where the telescope 24 was directed to point and where it actually went. Once a model taking into account these pointing errors is in place the telescope model manager 60 is the meanswhereby coordinates submitted by the user may be converted to model coordinates which are then used to insure that the telescope 24 will point in the proper direction. Additionally, the model is used by the telescope model manager 60 to make adjustmentsin the tracking rate of the telescope 24, accounting for the same systematic errors.
The imaging camera manager 62 and the auto-guiding camera manager 66 are responsible for controlling the imaging camera 26 and the auto-guiding camera 28 respectively. The instructions from the camera managers 62 and 66 are sent by way of theimaging camera driver 64 and the auto-guiding camera driver 68. All the functionality to operate the cameras 26 and 28 are provided in the camera managers 62 and 66. Operation at a minimum would include the ability to acquire an image. Otheroperations, like regulating the temperature, bin mode, etc. of the cameras 26 and 28 would also be done by the camera managers 62 and 66. The imaging camera manager 62 and the auto-guiding camera manager 66 also serve as image processing programs andare able to perform various image reductions on acquired images, such as account for dark, flat, and bias frames. The imaging camera manager 62 further provides access to an imaging camera focuser 84, an imaging camera filter wheel 86, and an imagingcamera field de-rotator 88. The auto-guiding camera manager 66 likewise is the means for controlling an auto-guiding camera focuser 90, an auto-guiding camera filter wheel 92, and an auto-guiding cameral field de-rotator 94.
The inside dome camera manager 70 and outside dome camera manager 74 control the inside dome camera 30 and outside dome camera 32 via the inside dome camera driver 72 and the outside dome camera driver 76 respectively. Any and all functionperformed by the dome cameras 30 and 32 are controlled by the dome camera managers 74 and 74. Typically the dome cameras 30 and 32 would provide a wide-angle view of the inside and outside of the observatory 16 that would be available to the web browser12, or any other software manager in the observatory 16.
The weather station manager 78 controls and monitors the weather station instruments 34 through the weather station driver 80. Both the real-time and archived status of weather conditions, for example, wind speed, outside temperature, insidetemperature, air pressure, and/or humidity, would be available to the web browser 12 trough the weather station manager 78.
The preset invention specifically addresses the problem of how to make the results and status of observatory in operation available to multiple clients. The nature of observatory control lends itself to control by a single user at the webbrowser 12. However, the results and status of requests made on behalf of this "primary user" can be made available to any number of other users. In the subject invention it is of the utmost importance that the primary user receive status and resultsin a timely manner. To accomplish this, broadcasting is done on a lower priority and on a completely separate process (or even CPU) from the primary user. In this way, when the user is in control of the observatory 16, the system will not hang or getbogged down by broadcasting to multiple clients. Instead, copies of status and results are made available to any number of "viewers" through a separate lower priority process than that of the primary user. The broadcast manager 82 is able to broadcastresults in any number of ways including through other web servers, file transfer servers, gopher, email, fax, modem, etc., etc.
Of course those skilled in the art will recognize that the exemplary environment 10 is not intended to limit the scope of the present invention. For example, the web browser 12 could be run on the same computer as the web server 18, eliminatingthe need of the network 14. Moreover, the distributed nature of the software components, any combination of computer to component could be used. For example, each of the drivers for the astronomical hardware 20 could be run on a separate computer. Inthe exemplary environment 10 the core or majority of the processing is done on the server computer. This allows the client side processing to be simple and thus increase the reach of observatory control to the broadest audience possible. Those skilledin the art will recognize that other or alternative environments could be used without departing from the spirit of the current invention.
In FIG. 2 a flowchart of the general logic of the web browser 12 with reference numeral 96 is shown, wherein the web browser 12 is submits a request to the web server 18 and then displays the status and/or results of the request. The first blockin the flowchart 96 is an initialization block 98. In the initialization block the web browser 12 is initialized. The user then selects a request, symbolized by a select request block 100, and the selected request is submitted to the web server 18shown as a submit request to web server block 102. Whether or not the request submitted in the submit request to web server block 102 has been completed is then evaluated by a request completion decision tree 104. If the request is not finished thenthe web browser 12 submits a status request to the web server in a submit status block 106. The status of the request is then displayed by the web browser 12 in a display status block 108, at which point the system returns to the request completiondecision tree 104. If the request submitted to the web server 18 in the submit request to web server block 102 has been completed then the result of the request are displayed in a display results block 110.
The loop represented by blocks 104, 106, and 108 is a traditional client poll method to determine the status of an ongoing request. The client poll method is shown here for simplification, other methods for determining the status of an ongoingrequest, such as server push, could be used. However, client poll, as a common platform independent method, would likely allow for a simple web browser 12 and a more sophisticated web sewer 18, resulting in maximum client reach.
Referring now to FIG. 3, a flowchart of the general logic of the web server 18 having general reference numeral 112 is shown, wherein the flowchart 112 represents the general logic used by the web server to process a request made by the webbrowser 12. The flowchart 112 begins with an initialization block 114, which represents the initialization of the web server 12 and manager components including the power manager 38, the user manager 40, the celestial object database manager 44, thecelestial image database manger 48, the dome manager 52, the telescope manager 56, the telescope model manager 60, the imaging camera manager 62, the auto-guiding camera manager 66, the inside dome camera manager 70, the outside dome camera manager 74,the weather station manager 78, and the broadcast manager 82.
The next step in the flowchart 112 is a browser request decision tree 116 which determines if the request manager 36 has received a request from the web browser 12. If a request has not been received then control is transferred to an observatoryusage decision tree 118. If a request is present then control is transferred to a user identification decision tree 120 where the identity and profile of the user are searched for by the user manager 40 in the user database 42. If the user is not foundin the user database 42 then control is transferred to a request response block 122, at which point an appropriate response is sent to the user via the web browser 12. If the user is found, then the system continues to a user schedule block 124 at whichpoint the user manager 40 determines if that user is scheduled to have control of the observatory 16 at that time. If the user is not scheduled then the system responds at the request response block 122. Should the user be scheduled properly thencontrol passes to a startup request decision tree 126. At the startup request decision tree 126 the request manager 36 evaluates whether the request is a startup request. If the request is a startup request then the request is executed at a startuprequest block 128. Should the request not be a startup request, the system then proceeds to an image request decision tree 130, where the request manager 36 sends image requests to a image request block 132 to be carried out, and alternative requests toa shutdown request decision tree 134 which also takes place in the request manager 36. The function of the shutdown request tree 134 is to, in case of a shutdown request, send the system to a shutdown request block 136, where the system is shutdown. Inthe case that the request is not a shutdown request, the shutdown request decision tree 134 transfers control to a status request decision tree 138. For the case that the request is a request from the web browser 12 regarding the status of a previousrequest then the requested status is obtained at a status request block 140. If the request is not a status request then the system proceeds to an other request decision tree 142. This other request decision tree 142 represents the request manager 36routing other requests. These requests might include any portion of operations in the startup, image, and shutdown requests or any other operation involved in controlling the observatory 16.
Returning now the observatory usage decision tree 118, here the request manager 36 determines if the observatory 16 is in use. If the observatory 16 is in use then control is given to a weather decision tree 144, at which point the weatherstation manager 78 determines is the weather conditions at the observatory 16 are acceptable for observation. If weather conditions are not conducive to observatory 16 usage then the system proceeds to a shutdown request block 146 which is identical infunction to the shutdown request block 136.
FIG. 4 shows a flowchart 148 of the general logic of the web server 18 while performing a startup request. The flowchart 148 begins with the startup request block 128. The system is then directed to a weather decision tree 150 where the weatherstation manager 78 determines if weather will allow the observatory 16 to be operational. Configurable options allow for specifying tolerable values for different weather variables such as wind speed, outside temperature, barometric pressure, humidityand dew point. If the weather is bad then the system is transferred immediately to a request complete block 152 without completing any further startup procedures. If the weather is acceptable then the system proceeds to a clear sky decision tree 154.
At the clear sky decision tree 154, whether or not the sky is clear enough to observe is determined by the outside dome camera manager 74. The outside dome camera manager 74 accomplishes this by acquiring a wide-angle view of the sky from theoutside dome camera 32 and comparing the stellar pattern of that image with a virtual stellar pattern generated by the celestial object database manager 44. If the picture from the outside dome camera 32 matches the virtual image without too manyobstructions then the sky is clear and the system proceeds to a set of hardware power ups 156.
The first step in the set of hardware power ups 156 is a power dome block 158 which represents the power manager 38 powering the dome 22. Next a power telescope block 160 symbolizes the power manager 38 powering the telescope 24. The system isthen controlled by a power imaging camera block 162 which depicts the power manager 38 powering the imaging camera 26. The power manager 38 then powers the auto-guiding camera 28 at a power auto-guiding camera block 164. The last power up in the set ofhardware power ups 156 is performed by the power manager 38 as it powers the inside dome camera 30, which is represented by a power inside dome camera block 166.
After the set of hardware power ups 156 the system then progresses to a set of hardware initializations 168. The initialization procedures contained in the set of hardware initializations 168 are specific for each piece of hardware. They areone-time procedures that prepare the hardware to be ready for use from a recently powered up state. For simplification initialization is shown as a serial process, however, one skilled in the art could also accomplish them as a set of asynchronousprocesses wherein control is not continued until all initializations are complete.
The first block shown in the set of hardware initializations 168 is an initialize dome block 170. This signifies the dome manager 52 initializing the dome 22 and preparing the dome 22 or use. Any device specific commands necessary to make thedome 22 ready for use from a powerless state are performed here. For example, the dome 22 would be instructed to find its home sensors and be set to its home position. In addition the dome slit would be opened, or, in the case of a roll off roof or itsequivalent, the roof would be opened.
As the set of hardware initializations 168 continues the system advances to an initialize telescope block 172. At the initialize telescope block 172 the telescope manager 56 initializes the telescope 24 and provides the telescope 24 with any andall commands necessary to make it useful from a powerless state. An illustration of this would be instructing the telescope 24 to find its home sensors and be set to its home position.
At an initialize imaging camera block 174 the imaging camera 26 is initialized by the imaging camera manager 62. Here the imaging camera manager 62 would give instructions like: cool to a desired temperature, to the imaging camera 26. Theseinstructions given by the imaging camera manager 62 allow the imaging camera 26 to become useful from a recently powered up state.
As the system reaches an initialize auto-guiding camera block 176 the auto-guiding camera manager 66 initializes the auto-guiding camera 28. At the initialize auto-guiding camera block 176 the auto-guiding camera manager 66 would give anycommands necessary to the auto-guiding camera 28 in order to bring the auto-guiding camera 28 into a state of readiness from a recently powered up state.
The final block shown in the set of hardware initializations 168 is an initialize inside dome camera block 178. At the initialize inside dome camera block 178 the inside dome camera 30 is initialized by the inside dome camera manager 70 in amanner similar to the way in which the imaging and auto-guiding cameras 26 and 28 were initialized by the imaging camera and auto-guiding camera managers 62 and 66 in blocks 174 and 176. Upon completion of the set of hardware initializations 168 thesystem then proceeds to the request complete block 152 where the results of the startup request are sent back to the web browser 12.
FIG. 5 depicts the general logic of the web server 18 performing the steps of an image request in a flowchart 180. The flowchart 180 is initiated by the image request block 132. Control of the system then continues to an image coordinate block182 where the celestial object database manager 44 resolves a named based image request to celestial coordinates. Once these coordinates are obtained they are converted by the telescope model manager 60 into modeled coordinates. This process isrepresented by a model coordinates block 184 in the flowchart 180. The modeled coordinates created by the telescope model manager 60 take into account systematic ems inherent in the telescope 24. A telescope slew block 186 and a dome slew block 188 arethen shown as occurring simultaneously. The telescope slew block 186 corresponds to the telescope manager 56 directing the telescope 24 to slew. The parameters of the slew are then converted to the appropriate form by the dome manager 52 and the dome22 begins to slew at the rate necessary to keep from obstructing the view of the telescope 24. Upon completion of the slews control of the system is relinquished to a slew complete block 190 where the system waits for both the dome 22 and the telescope24 to reach their final position before control passes to a focus camera block 192.
At the focus camera block 192 the imaging camera and auto-guiding camera managers 62 and 66 achieve focus in the imaging and auto-guiding cameras 26 and 28 respectively. One way to accomplish this is by converging on the maximum frequencycontent of several images acquired while adjusting the imaging camera and auto-guiding camera focusers 84 and 90.
Once focus is achieved the next step in the flowchart 180 is a find guide star block 194. The find guide star block 194 represents the task of the auto-guiding camera 28 acquiring a suitable celestial object to serve as a guide star. This isaccomplished as the auto-guiding camera 28 varies exposure time (longer reveals dimmer stars) while the telescope 24 makes small positioning adjustments in order to bring known nearby stars, whose coordinates are supplied by the celestial object databasemanager 44, into view.
After an appropriate guide star has been located by the auto-guiding camera 28 the system begins to take the image requested by the user in a begin image block 196. At this point the imaging camera manager 62 select a filter on the imagingcamera filter wheel 86 and instructs the imaging camera 26 to begin the exposure. The parameters of the exposure, after leaving the imaging camera manager 62, are converted to the necessary form by the imaging camera driver 64, and sent to the imagingcamera 26.
Now control of the system is passes to an exposure complete decision tree 198 where the imaging camera manager 62 determines if the exposure is complete. If it is not then the system is transferred to an adjust telescope tracking block 200. Theadjust telescope tracking block 200 represents the telescope model manager 60 computing tacking adjustments for the position of the telescope 24 to account for the systematic errors present. These adjustments are then passed to the telescope manager 56which implements them.
Once the telescope 24 tracking has been adjusted the necessary tracking corrections are passed to the dome manager 52 which then converts the corrections in order to keep the opening in the dome 22 aligned with the telescope 24. This process isrepresented in the flowchart 180 by an adjust dome tracking block 202.
The next block shown is an acquire auto-guiding image block 204. This symbolizes the auto-guiding camera 28 acquiring an image of the reference guide star. Once this is complete control of the system passes to a guide star movement decisiontree 206, which represents the auto-guiding camera manager 66 determining if the guide star has moved with respect to its position in an earlier image. If the position of the guide star has not changed, then the system is transferred back to theexposure complete decision tree 198. However, if the position has changed then the progression of the flowchart 180 leads to a telescope correction block 208 where the telescope manager 56 moves the telescope 24 in order to correct the offset found inthe guide star movement decision tree 206. Once this correction is complete, direction of the system is again shifted to the exposure complete decision tee 198.
If, at the exposure decision tree 198, the imaging camera manager 62 determines that the exposure is complete the system advances to an acquire image block 210, where the imaging camera manager 62 acquires the image from the imaging camera 26 byway of the imaging camera driver 64. As the system passes to a perform image reduction block 212 the imaging camera manager 62 makes a copy of the acquired image and reduces the copied image. After the image has been copied and reduced both theoriginal and copied images are archived by the imaging camera manager 62 in an archive image block 214. Next the system continues to a generate comparison image block 216. Here the celestial image database manager 48 generates an actual image of thesame portion of the sky that is captured in the image that was just taken. This comparison image is provided as an option to users who wish to have a frame of references for their image. The next step in the flowchart 180 is a generate virtual imageblock 218 where a virtual image of the portion of the sky captured by the user is generated from the celestial object database manager 44. Once all of the desired images have been generated they are made available to all other appropriate viewers as itbecomes convenient for the web server 18, via the broadcast manager 82, as is represented by a broadcast results block 220. Finally, an image request complete block 222 signifies that the image request has been completed and the results and status ofthe request are sent to the web browser 12 in real time.
Referring now to FIG. 6, a flowchart 224 is shown, wherein the general logic of the web server 18 performing a shutdown request from the web browser 12 is represented. The first step in the flowchart 224 is the begin shutdown request block 136,which is functionally identical to the shutdown request block 146. Command of the system is then shifted to a set of hardware uninitializations 226.
As with the set of hardware initializations 168, the representation of these uninitializations is shown as a serial process with a specific order. It should be remembered that this is in no way out of necessity and that these processes couldeven be performed in parallel.
Presented in the flowchart 224 as the first step in the set of hardware uninitializations 226 is an uninitialize dome block 228, which represents the dome manager 52 giving the dome 22 any and all instructions prerequisite to the dome 22 beingturned off. Such instruction could include rotating the dome 22 to its park position and closing its slit or roof.
The next block shown is an uninitialize telescope block 230 wherein the telescope manager 56 guides the telescope 24 through the procedures required for it to be powered down. An example of one such procedure would be slewing the telescope 24 toits park position.
Following the uninitialize telescope block 230 an uninitialize imaging camera block 232 is shown. The uninitialize imaging camera block 232 represents the imaging camera manager 62 causing the imaging camera 26 to perform such tasks as briningthe camera 26 to ambient temperature in preparation of having the power tuned off.
In an uninitialize auto-guiding camera block 234 and an uninitialize inside dome camera block 236 the auto-guiding camera and inside dome camera managers 66 and 70 cause the auto-guiding and inside dome camera 28 and 30 to go through the stepsnecessary to prepare them to be powered down. These processes would be nearly identical to the instruction given the imaging camera 26 by the imaging camera manager 62 in the uninitialize imaging camera block 232.
Once the set of hardware uninitializations 226 is complete the system is then sent through a set of hardware power downs 238. The set of hardware power downs 238 are all performed by the power manager 38 of the system. The first power downshown is the power manager 38 cutting power to the dome 22 in a power down dome block 240. Next a power down telescope block 242 denotes the power manager 38 powering down the telescope 24. Then, in turn, a power down imaging camera block 244, a powerdown auto-guiding camera block 246, and a power down inside dome camera block 248 signify the power manager 38 shutting off the power to the imaging camera 26, the auto-guiding camera 28, and the inside dome camera 30, respectively. After the set ofhardware power downs 238 is complete the control of the system is transferred to a request complete block 250 which represents the completion of the shutdown request.
While the invention has been particularly shown, described, and illustrated in detail with reference to the preferred embodiments and modifications thereof it should be understood by those skilled in the art that the foregoing and othermodifications are exemplary only, and that equivalent changes in form and detail may be made therein without departing from the true spirit and scope of the invention as claimed, except as precluded by the prior art.
Method for searching heterogeneous compound databases using topomeric shape descriptors and pharmacophoric features
Arrangement for past DPCM coding of video signals according to a 2-D or 3-D coding method
Continuous process for production of oil seed protein isolate
Method for assisting bowlers in maintaining an optimum follow-through angle