My mission to Hobart & Greenhill Observatory, Tasmania, went from mid-July to the very beginning of September. And even if the Night Scheduler objective is not fulfilled, I came back to France with the feeling of having achieved quite a lot for the Greenhill Observatory.

I want to emphasise here what this mission revealed.

  1. Upgrading an observatory to the Alpaca standard is a lot easier than expected (see below about AI).
  2. We can complete this upgrade a lot faster when we work alongside in the same room.

I suspect the Greenhill Observatory was an example of an upgrade that never finishes, that I have further discussed in one of my recent blog post. Of course, as in many other places, people are highly skilled and motivated, but are simply overwhelmed with dozens of other tasks.

That’s one hidden benefit of adopting Arcsecond. Suddenly, a reliable, consistent and efficient operating mode is at hand’s reach, and new observations could soon flow in. It’s the best motivation to have all the small bits of the never-ending upgrade finally completed. Done. For real. And even improved along the way.

My mission was a continuous blend of work dedicated to the Greenhill Observatory telescopes—whether testing the improvements on-site or in the offices—and developing generic new features to Arcsecond. When we’re sitting together in the offices or the control room, we can iterate quickly, and see those improvements being applied immediately and watch the observatory’s operations improve right before our eyes.

Upgrading the telescope: done!

Here are the 4 things we managed to bring to the 50cm PlaneWave CDK telescope at the Greenhill Observatory during my stay, based on existing bootstrapped work already present (which helped enormously):

  • Re-implemented an AlpacaDevice wrapper for the control of the clamshell Dome, including individual set commands of altitude of the shells. The shells now being controlled independently, we could implement a “dome slaving” mechanism, automatically protecting the telescope from the wind! This is currently under test.
  • Implemented a whole new SBIG ST-i camera ASCOM wrapper to expose the (old) guiding camera to ASCOM Remote (Alpaca Server). Old SBIG cameras didn’t get any ASCOM support after the acquisition of SBIG by Diffraction Limited. We were able to close that gap independently from them, simply using existing documentation and drivers.
  • Implemented new AlpacaDevice for the custom “Observing Conditions monitor” (Weather Station) and a “Safety Monitor” (including a new components architecture taking into account the old Win7 box, the 6 rain sensors and the existing custom wind sensor). With those, the setup for the 50cm could be considered as complete, and ready for automatic observations!
  • With the coming refurbished mirror for the 1.3m telescope, it was also necessary to make the high-speed IR camera ready for integration. Hence, based on the excellent work and heavy lab-testing made locally (thanks Euan!), we implemented again a dedicated AlpacaDevice for it.

With all this, we managed to bring Arcsecond to a much higher level with some on-site testing of an important aspect required before considering any automation: safety.

Contenu de l’article
3 happy astronomers observing remotely from Hobart with the 50cm telescope in Greenhill Observatory (Bisdie Tier).

Safety first, of course.

A whole new tool “Safety Configuration” tool now appears as part of the Control Room. Default safety “condition sets” are automatically provided, but can be easily edited, and extended as needed. To each of them, one could then define a “Safety Procedure” that will be automatically performed as soon as a NOGO conclusion is reached.

Of course a Decision log is available, allowing to browse the history of all decisions taken automatically by Arcsecond. These logs are stored in the Arcsecond database, and are part of the “record everything” philosophy that allows to replay entirely a given night. Being part of the observatory history, these logs and the associated state points, monitoring points, weather points etc, are never deleted.

Along with this development came a whole new “lease mechanism”, that prevent concurrent and possibly contradictory instructions being sent to the equipments. A discret yet live and easy-to-reach UI has been added for it, as part of the bottom status bar.

Roadmap inversion! Let’s build the Transient Alerts now.

Approaching the end of my stay in Hobart, something became clear: it would be highly desirable to implement the automatic observations from interruptions from Transient Alerts before the Night Scheduler is implemented. As a matter of fact, even if automation is clearly the final objective of this ongoing effort, Transient Alerts and the associated observations didn’t have to wait. And it would be even easier to test it right now! So we did.

A whole new “Transient Alerts” tool has been added to the Control Room. Make sure to integrate it in the Arcsecond installation by (re-)running the arcsecond setup command in a terminal, where Arcsecond configuration is located. You will also need to provide your own NASA GCN tokens for it to work (https://gcn.nasa.gov).

Once everything is in place, Arcsecond will consistently listen for incoming events. And depending on the Policies you’ve created and edited (where you can choose the missions to react upon), Arcsecond will stop your current work, and automatically observe (following a template you’ve chosen – one is provided by default).

Arcsecond is not selling shoes (or “how does AI continue to impact our development”)

I am pretty certain to underestimate the complexity of selling shoes, but still…

As we moved forward with the Night Scheduler implementation, our IA usage reached new highs (Claude Code, Chat & Cowork). Millions of tokens were used. And a few new thoughts came along.

The IA accelerator effect is still there, and it is still with a huge factor. Yet, to keep things in perspective, it took 20 minutes of Opus 5 to fix 7 issues with FITS header writing. Although it is a very important part of Arcsecond from a usage perspective, that’s really a very small fraction of Arcsecond backend code.

So, we’re in this new world: something extremely powerful is now able to grasp in its full range a fairly complex problem, in a way much larger and complete than a humain brain, even highly trained on that particular sibject. But solving it correctly remains pretty much complicated, when the underlying reality is irreducibly complex.

My feeling is that shoes are shoes, and putting an e-store for selling them is something that an IA agent can do fairly “easily” at a tiny fraction of the past cost. And one of the explanations – in my humble opionion – is that the knowledge of what a shoe is, is already shared by millions, and thus is part of this “shared memory” upon which AI Large Language Models are built.

Correcting the FITS header cards inside a hundreds-of-thousands lines of code codebase, taking into account exposure, telescope parameters, camera parameters, weather values, and plenty of other stuff that do not come at the same time before writing, inside a given operational model (a Celery task inside a background worker), is a bit more complicated.

And guess what, even with the latest models, IA makes mistakes. Lots of small ones, even if it can auto-correct some of them. Hence, I quickly adapted to this new way of working : I spend my days reading and writing about a large mix of subjects ranging from astronomy, to Python language details. Before IA, strong design phases were separated by periods of pure “code writing” work, letting the brain have some rest first, before moving onto a new period of intense architectural work. Now, it is permanent. And it requires brain re-wiring.

Building complex software as a single person is certainly a lot more possible now with AI. But be prepared to handle every day a giant pile of consistent decisions mixing astronomy, design, deep technology, code organisation, observatory heuristics, purely computer-science architectural choices, language-specific improvements etc. And without necessarily reviewing all the code itself, be prepared to oversee in very tiny details what are the choices made by the AI for you.

They are often surprisingly good (lowering your attention level). But they also could be accumulating small mistakes, or even be still plain wrong in our vision.

AI is a dragon to tame.

The update of screenshots in our home page (https://www.arcsecond.io) is still a slow process for now, but it’s underway!

Space Telescopes in the Night Studio.

Oh, by the way, we also integrated the coordination of ground based observations with current and future space telescopes (JWST, Roman, HST, ARIEL, etc). Combined with the new 6-panes layout in the explorer, that a decision tool of its own kind!

Contenu de l’article
New 6-pane layout of the Night Explorer, showing the new annual coordination with space telescopes (middle panes).

Acknowledgments

Again, a big thank to Bryn Emptage (and all people from U. Tasmania Physics Department) for his work, commitment and warm support. It was a true pleasure to land in Hobart again, and stay during winter in the beautiful Tasmania. Renewed and infinite thanks to Jean-Philippe Beaulieu (UTAS/CNRS) for believing in (and supporting!) this project since many years.

No responses yet

Leave a Reply

Your email address will not be published. Required fields are marked *