It all began with a problem that wasn't a problem, that lead to the discovery of another non-existent problem which all spiralled on from there. No tools existed for solving any of the problems I eventually found and so I had to first make the tools to solve the problems before I could actually do anything about them. But first back to the beginning.
One of our users, watching the webcams as the telescope took images, noticed that the telescope was pointing at one position in the sky while the dome seemed to be pointing in another direction and wondered why this was the case. The reason is a simple one and is shown in the diagram below. Simply put, as the telescope slews around the sky, it isn't always looking out from the centre of the dome, so sometimes the dome needs to move to the side to allow the best view.
 |
| You can see how the telescope is pointing to the left but the dome door is at an angle |
 |
| The mount model in action |
The mount model seemed to show that this particular job was partially obstructed by the top of the door (the gap in the dome is represented by the solid grey bit). This is of course a problem and needed to be solved. I began at once trying to map out where in the sky this problem occurred so that we could program the scheduler the avoid these parts.
In order to get it done as quickly as possible I simply built my mapping program right into the mount model. The mount model itself is written on top of a generic 3D code library for Flash called Away3D. I was able to use the built in functionality in that library for testing whether a line intersects a polygon to quickly determine whether any of the main scope's view was not going through the dome.
(Quite by chance, I had just finished constructing a tool to allow us to view 3D telescope statistics across the sky only two days before. This was meant for viewing things like pointing error and waiting time statistics etc, however it was easily put to use here for showing dome issues.)
The other thing I needed to do was to implement the dome's position code in the flash model. The mount model usually relies on being told where the dome is positioned at a particular time or for a particular job. If I was going to test every possible coordinate in the sky, I needed to know precisely where the dome would position itself if the telescope were pointed at those coordinates.
This was fairly simple as it is just a whole load of complicated mathematics, which is something that doesn't change much between different programming languages. However, when I ran my simulation, the result was that the dome was blocking the scope's view everywhere in the whole North East quarter of the sky.
This was alarming, but I quickly realised that this could not be correct. In the 3D model, the dome was pointing itself in complete wrong direction in that area, which we would have noticed before. I didn't at this point understand what all the mathematics actually did, but I have done enough mathematical modelling to recognise certain patterns. A 3D rotation matrix here. A polar to Cartesian coordinate conversion there. There was one little part that looked just like it was trying to ensure that a certain angle was presented between -180 and 180 degrees and not between 0 and 360. Except that it wasn't quite right.
By luck, when the code is used in the telescope control server, the angles provided to the algorithm are already in the correct range so the error never presented itself. In my implementation, the angles were not in that range and so the error surfaced. When I changed the code to what I thought it should have looked like, the positioning was fixed and I was able to generate another map which looked like this:
 | |
|
Now with my plausible looking results I was very satisfied with my work. The next step would have been to pass this data to Chris so he could make sure the telescope avoided these areas of sky. But little could I have know that this would only be the very beginning of my dome adventures.
