TALONS Looking Towards the Future of Telescope Interconnectivity

1
TALONSLooking Towards the Future of Telescope
Interconnectivity
Robert R. White W. Thomas Vestrand James
Wren Przymek Wozniak Stuart Evans
2
Driving mechanism for developing TALONS

• Support stereoscopic telescope systems
• Perform collaborative analysis for all telescopes
  on network as needed
• Be fully scalable
• Be fault tolerant towards loss of a node
  (telescope)
• Monitor and log information on performance and
  alerts
• Interface with GCN
• Be able to interface with any other outside
  networks
• Interface with database queries
• Be self sustaining (monitor and repair general
  problems).
• Use a standard TCP/IP direct connection scheme
• Centralize process, due to net bandwidth
  limitations

3
Time Line of Development and Operation

• 2000 Raptor project begins
• 2001 TALONS developed to support RAPTOR
• 2002 First light on stereoscopic synchronized
  observations
• 2002 RAPTOR becomes first operational closed-loop
  robotic telescope
• 2002 RAPTOR detects first of its GRBs
  (GRB021211)
• 2003 TALONS expanded to match development of
  SkyDOT
• 2003 RAPTOR adds two new telescope systems to
  network
• 2004 TALONS expanded to support Swift
• 2004 RAPTOR detects GRB 041219
• 2005 RAPTOR detects GRB 050319
• 2005 TALONS expands to translate and record its
  own alerts and GCNs as VOEvent packets
• 2005 RAPTOR detects GRB 050713a
• Future plans..

4
TALONS Overview

• TALONS is a centralized TCP/IP server- client
  system.

• TALONS consists of four software products
• Central processing and distribution
• Client connection and filters
• Injector manual alert request
• Monitor System status monitor

5
Current TALONS Clients

• RAPTOR A B
• System separated by 38km baseline
• Wide Field mosaic system, each 4x 85mm
• Narrow field fovea, each 1x 400mm
• RAPTOR P
• 4x 400mm mosaic
• RAPTOR S
• 0.4m OTA (3 interchangeable detectors)
• Back illuminated 1k x 1k CCD
• Photon counting imager
• Grating spectrometer
• RAPTOR T (system testing)
• 4x 0.4m co-aligned OTAs
• Different filters on each camera
• RAPTOR M (under construction)
• 16x 300mm mosaic
• Proposed additions (soon to come)
• Apache Point 1.0m telescope - NMSU

6
Wozniak et al. (2005), ApJL, in press
(astro-ph/0505336)
Movie covers first 50 minutes of afterglow. There
are 19 total images composed of 2-4 frames each.
7
The Path Forward

• Taking Our Autonomous Telescopes to the Next
  Level

8
The Thinking Telescope (T3) Project
Evolving Database (SkyDOT NVO)
TALONS
Machine Learning
www.thinkingtelescopes.lanl.gov
9
Why Machine Learning ?
Data Overload!

• It is to difficult and time consuming, for a
  human to manage large databases or monitor
  real-time data and extract useful information

10
Machine Learning Enables

• Automated identification of artifacts and
  transients in direct and difference images.
• Automated classification of celestial objects
  based on temporal and spectral properties.
• Real time recognition of important deviations
  from normal behavior for persistent sources.

11
ML First StepClosing the Loop, One More Time

• RAPTOR has already closed the loop once with
  automated new object identification
• Now Automated Position VerificationFirst Step in
  our Machine Learning

Image Calibration
RAPTOR S
Position Analysis
Verify Changing Magnitude Of Candidates
Verify Candidate
12
Memory and Context
http//skydot.lanl.gov
13
Network Enablement

• Hooking in the World

14
The Seed Network
Network Enablement

• Hooking in the World

eStar
Paritel
NMSU Apache Point
Outside clients
RAPTOR System
15
Growing the Seed
NVO/IVO
GCN
eStar

Paritel
NMSU Apache Point
RAPTOR
SkyDOT
16
Elements of the Network

• Harvesters / Aggregators
• Gather event data from direct clients and from
  other Harvesters. Some will have only rudimentary
  databases, others will have access into major
  databases (SkyDOT, IVO, NVO, etc.)

Harvester A
Some Harvesters may have web interfaces allowing
users to directly insert events into the network.
Harvester B

• RSS Feeders
• Could be an excellent method for Harvesting.
• Systems could be uni- or bi-directional.
• (Harvest others and allow Harvesting of their
  data)

Clients
17

• Brokers Agents (eStar)

Distributed, non-centralized agent system. Work
in a peer based paradigm. Provides method of
passing observation requests, and alert data
using XML and RTML formats Provide a method for
brokering observation time between clients
robotically in the most efficient manner.
Clients
eStar
Database
18

• Central Hubs

Exist as two types

• Uni-directional or semi bi-directional
• Passes information from a source to a client
  list
• Does not provide detailed filtering
• Fast distribution to large numbers of clients

• Bi-directional
• Provides communication between clients through
  central server
• Allow multiple clients through single connection
  point
• Filters and controls distribution to all clients

GCN
RAPTOR System
19
Elements of TALONS Currently Supporting the
Advanced Network

• Ties to Outside Networks - easily expandable, as
  a hub, as future clients are requested
• Supports VOEvent and GCN protocols
• Distributes
• direct connect to robotic systems
• Paging and e-mail
• via eStar (available soon)
• Network activity monitor and manual alert
  injector
• User defined filters of incoming alerts and
  outgoing information.
• Machine Learning implementation modules (basics
  in place, others to come)
• Directory based database of VOEvents including
  GCN translations

20
Future Work

• Interfacing with eStar
• Harvesting of VOEvent data
• Database/repository access (SkyDOT NVO)
• Client filters for VOEvent XML (direct connect is
  supported already)
• Secure data transfer (other than direct connect)
• Upgrade to new VOEvent schema
• Self spawning server (redundancy to system)
• Merging of monitor and injector packages
• Additional versions to support OSX clients
• All GCN Filter point

21
Points of Discussion

• Delivery methods
• Direct connects
• E-mail
• RSS Aggregators
• All ? (There is room to support them)
• Issues of Speed - XML style alert verifications
  (Schema), connection handshakes, etc.
• Identifying core audience role out any first
  version to appease them.
• Access points for alert insertion other than
  robotic systems
• Security for non-direct connect alerts. Methods?